More human readable generated widget names #71212
Comments
|
For now Tkinter generates Tk widget names just from Widget instance id. >>> import tkinter
>>> root = tkinter.Tk()
>>> frame = tkinter.Frame(root)
>>> button = tkinter.Button(frame)
>>> str(button)
'.3070531884.3055478668'These names are not very readable and distinguishable. I think it would be better to generate names from widget type and short sequential number. For example '.frame#1.button#2' or '.1frame.2button'. There are some questions:
|
serhiy-storchaka
added
topic-tkinter
type-feature
|
First thoughts on the proposal. I overall like it. The 'virtue' of the digit strings names is that they match tk behavior (I presume) and are consistently opaque ;-) *Someone* will object to change. Is your proposal to have (_)tkinter add a name= option when not provided by the user? The main problem I see is breaking code that assumes digits if no name= options are given. Is this currently guaranteed?
Something else, I believe, generates alphanumeric names similar to what you propose.
Conflicts: tk does not prevent duplicate names by users.
...
>>> entry2
<tkinter.Entry object .e1>
>>> entry
<tkinter.Entry object .e1>
I am not sure of the consequence of this.The doc could say, "If you want widget names of the form <class-name(lowercased)><sequence number> either consistently supply them yourself with name= options, or let tkinter supply them for you." |
No, in Tk you have to give names for all widgets. frame .main This is similar to how classes or functions are declared in Python. The name becomes an attribute of an object and a reference to an object. You shouldn't repeat it twice. Here is a patch that implements nicer generated widget names. The problem with ".frame1.button2" or ".frame-1.button-2" is that they look too human readable. If you use explicit names for the part of widgets and allow generating names for other part, there is large chance that generated "button2" or "button-2" will conflict with explicit names. I think we should use something that makes generated names uglier. Maybe prefix them with "_"? "._frame1._button2". |
|
Ah, the patch makes it clear. Tkinter is already generating a name to submit to tk, and you are proposing to replace using the Python id for that purpose. +1. I also notice that duplicate names cause the old tk widget to be destroyed even if the Python instance is not. Knowing that, I agree with the leading underscore to minimize interference. The consequence of collision and the new default should both be documented somehow. |
|
You can apply show_widget_names.diff to see all widget names. Run IDLE and open the configuration dialog for example. |
|
To make the experiment easy to repeat, say after the patch, I wrote this. (Perhaps inspired by Ned Batchelder's 'machete debugging' PyCon talk.) import tkinter as tk
from idlelib.configdialog import ConfigDialog
_realsetup = tk.BaseWidget._setup
def _wrapsetup(self, master, cnf):
_realsetup(self, master, cnf)
print(self.widgetName, self._w)
tk.BaseWidget._setup = _wrapsetup
root = tk.Tk()
ConfigDialog(roo)
ttk.BaseWidget._setup = _realsetupObservations: the longest path rather long: .<num1>.....<num9>. The root to widget paths collectively represent a tree and, sorted, could be used to populate a tree widget, such as a Treeview. With the proposed new names, this would give one a useful overview of the total gui, or a part thereof. If one subclasses a widget, such as class MyFrame(Frame, would the instance .widgetName used in the patch 'Frame' or 'MyFrame'? The latter would make the treeview really useful, and reward judicious subclassing. |
|
Try this instead. import tkinter as tk
from idlelib.configdialog import ConfigDialog
from idlelib import macosx
_realsetup = tk.BaseWidget._setup
def _wrapsetup(self, master, cnf):
_realsetup(self, master, cnf)
print(self.widgetName, self._w)
tk.BaseWidget._setup = _wrapsetup
root = tk.Tk()
macosx._initializeTkVariantTests(root)
ConfigDialog(root)
tk.BaseWidget._setup = _realsetup |
|
+1 I think would be a nice improvement. |
|
I have experimented with different naming schemes. Original output with Terry's example (actually names are longer in IDLE, since the configuration dialog is created as a child of other toplevel widget): label .3070117292.3069168812.3069169068.3069251628.3068822220.3069266540.3068822348.3068839820.3068851532 Using Tk command name as a base of a name: label ._toplevel1._frame1._frame2._frame73._labelframe10._frame127._canvas6._frame128._label28 Using Python class name: label ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe6._canvas6._frame105._label28 It is more informative, but names are usually longer. Using an abbreviation (upper letters from Python class name in camel style): label ._cd1._tps1._f1._f61._lf10._vsf6._c14._f105._l32 Names are short, but different classes can have the same abbreviation (e.g. Checkbutton and Canvas). This doesn't cause name clashes, just widget types become non-distinguishable by names. One problem with these schemes is that they change the rule for avoiding name conflicts. Currently you can just use names that are Python identifier -- they never conflict with generated names. With above schemes you should avoid names starting with an underscore. Other problem is that they use sequential numbering for every widget type. If you already created 100 frames, the single frame in new window will have name ._frame101. If use separate count for every parent widget, numbers can be smaller (the number is first because it is the serial number of the child in the parent widget): label .1toplevel.1frame.1frame.5frame.3labelframe.6frame.2canvas.1frame.7label If use separate numbering for every child type in a parent: label ._toplevel1._frame1._frame1._frame5._labelframe1._frame6._canvas1._frame1._label4 |
|
While a widget tree could be constructed using tk's introspection functions, I believe there are other good uses for monkey patching. The attached .py file defines a monkeypatch context manager (does one exist already?). The file uses the c.m. twice to patch ConfigDialog.CreatePageFontTab so it patches tk for the duration of its call. The result is 16 rather than 287 lines of output.
In the future, the last line might be shortened to
I don't know what to say about numbering, except that I would prefer any of the options to status quo. |
|
Patch updated.
|
|
I agree with back-compatibility, suppression of '1' suffix, and numbering, which makes suppressed '1' common. I prefer '1' rather that '0' prefix. Visually, '1' leaves more space between digit and word. Semantically, each component represents 1 of something. 0 this, 0 that, 0 etcetera, is a bad semantic clash. |
|
"1" looks too similar to "l". |
|
I based my opinion on trying to actually read and understand the output of tknames.py, with your patch done both ways, in a way that I would do in use. Since class names always begin with upper case, it did not occur to me to read '1' as anything other than 'one'. '0' is just as easily confused with 'O'. In both cases, the resemblance depends on the font. For the Lucida Console I use for IDLE, there is no internal marker dot or bar and O0 only differ slightly in shape. In a mixed digits and caps string like '' I might have to type the two to be sure which is which. On the other hand 1l are much more different, as 1 has a rather long horizontal serif while l has none. Neither comments are true in the fixed font (Courier?) I see now in Firefox. The semantic clash problem, which is the bigger problem for me, may be stronger for me as a native speaker. I read '0Frame' and '1Frame' as 'zero Frame' and 'one Frame', not as arbitrary character sequences. Being able to switch to semantic reading is the point of this issue. |
|
Generated names are in lower case. |
|
I apologize for my mistake, but it is not of much relevance. My preference is based on my subjective reactions on reading both variations. I used tknames.py, which outputs < 20 names, rather than the code that output > 200 names, because the former seems more realistic and makes it easier to focus on reading one path. The intellectual justifications and explanations came after and are subsidiary. If you put yourself in the position of a naive user, do you really prefer reading 'zero toplevel zero frame zero button' or 'one toplevel one frame one button'? If you prefer the former, then we are simply different and will not agree. However, I would like to revisit the criteria for a generated name. Currently, widget names are nearly undocumented, and I don't know of any doc for the 'name=' option. Our tkinter doc only discusses pathnames in the tcl/tk section, which nearly everyone will skip. Even there, there is no mention that "button .fred -bg 'red'" translates to "Button(master, name='fred', bg='red')". The translation obliterates the distinction between 'name' being required and write-once versus 'bg' being optional and rewritable. In docstrings, 'name' is not listed in Valid resource names, because it is not one. In help(widget), the pathname only appears in the listing of __str__, nametowidget, and maybe a few other places. There is no mention of how tkinter generates the required unique name or that it even does so. The Lundh Tkinterbook makes no mentions of names that I could find. The Shipman NMU Reference says that name components *are* .n, where n is a stringified int and never mentions, that I could find, the 'name' option to make it otherwise. The use of 'name=' seems correspondingly rare. IDLE names 4 Scrollbars (out of about twice as many) 'vbar' or 'hbar'. It names just a few Menus. In my reading of stackoverflow tkinter questions, 'name=' is rare there also. To me, the near absence of name documentation and use gives us latitude in what alternative we pick. I understand the name clash problem. For a given master, a person might create a widget with no name and later create a widget of the same class with a name. The generated name for the first widget, *whatever it is*, might clash with the later name.* The only way to eliminate all clashes is to check all explicit names. Join the name to the master name and try to use it in the cheapest way possible, perhaps 'pathname.children'. If this raises tclerror 'name not recognized' (or whatever the message is), use the name. If this succeeds, the name would clash, so raise name clash error. *The virtue of injecting id(python_widget) after the widget is created is that a user could only calculate the same number before creation with detailed knowledge of id creation. On CPython, this is tricky, though on other systems, I believe it could just be as simple as id(last widget)+1. If there is no null value for a default argument, then the most likely explicit argument is a good choice. For name, that might be the class name or a lower-cased version thereof, possibly suffixed. The *only* reason to not use that is if clashes with rare but possible future explicit names are deemed too likely. Ugly, by itself, is bad. A number prefix is not required. For other prefixes that would reduce clash possibility, I tried: >>> for c in "01'|+-*&^%$#@!~` ":
print(".%stoplevel.%sframe.%sbutton" % (c, c, c)).0toplevel.0frame.0button I like ` best (unobtrusive and meaningless), ^ second. |
|
` and ^ LGTM. We can change this in any time if it looks bad. |
|
New changeset 304c61263ae6 by Serhiy Storchaka in branch 'default': |
|
The change is a super great idea (see below), but I now think (my suggestion of) ' https://stackoverflow.com/questions/37904750/tkinter-tclerror-invalid-command-name-54600176-error-what-is-going-on basically asks What does '''_tkinter.TclError: invalid command name ".54600176"''' mean? In my comment to the answer, I noted that 3.6.0a2 now says '''invalid command name ". |
|
Worse yet, SO replaces a single |
|
I'm working on a patch that allows to trace all Tcl commands passed from Tkinter, and a number of ".`" in widget names looks not nice. |
|
Now it is clear that '`' is bad prefix. There are 32 non-alphanumerical non-control ASCII characters: '!', '"', '#', '$', '%', '&', "'", '(', ')', '*', '+', ',', '-', '.', '/', ':', ';', '<', '=', '>', '?', '@', '[', '\\', ']', '^', '_', '`', '{', '|', '}', '~'. '{', '}', '"', '[', ']', '$', '\\' is basic part of Tcl syntax. What is left? '!', '&', '+', '/', ':', '<', '=', '>', '@', '^', '_', '|', '~'. '@' starts coordinates or image path in some commands. Not all of these arguments are absolute stoppers. Personally I like '!', '?' and '@'. Unlikely generated names are saved in X resources or searched by patterns. If you need the widget being named, you just specify a name instead of allowing Tkinter generate arbitrary one. What are your preferences Terry? |
|
Agreed that ` is not best and should be changed. An alternative should be in next release. I looked back at the output in msg268406. ! is similar to | but shorter, and better for that. It is also, generally, thicker, which is better. With the font used on this page in FireFox, at my usual size setting, |is 1.5 pixels, so it tinged red or green depending on whether the half pixel is to the right or left. ! is 2 pixels and black, which is better. Smaller font sizes could reverse the situation, but unlikely for me. @ is email separator and twitter name prefix. Firefox recognizes this and colors the first @ and all names blue. I don't like this. Not an issue in code editors, etc, but code and especially results, get displayed elsewhere, as here. Aside from that, it is visually too heavy and I cannot avoid reading @ as 'at'. Let's skip it. I still like my previous 2nd choice, ^, but you apparently do not. I omitted ? before, I think just by oversight. Let's try both with ! also, isolated from other options. >>> for c in "^!?":
print(".%stoplevel.%sframe.%sbutton\n" % (c, c, c)).^toplevel.^frame.^button .!toplevel.!frame.!button .?toplevel.?frame.?button ? strikes me as slightly too heavy, but worse is the semantic meaning of doubt, close to negation. With the noise of other alternatives removed, and looking again several times, I like ! about as much as ^, both visually and semantically. Perhaps from knowing some Spanish, which uses inverted ! to begin sentences, I read ! as mild affirmation. I would be equally happy with either. If you prefer !, go with it. |
|
New changeset 603ac788ed27 by Serhiy Storchaka in branch '3.6': New changeset 505949cb2692 by Serhiy Storchaka in branch 'default': |
|
Good point about "@". I missed this. Thanks Terry. "!" LGTM. Committed to 3.6 too. I consider this as the fix of the bug in 3.6 feature. |
Misc/NEWSso that it is managed by towncrier #552Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: