Martin Cooper added the comment:
I think you are confusing the perspective of the implementor with that of the
typical developer _using_ the toolkit without reading through its source code.
In my tkinter applications, I pretty much always use ttk widgets where they are
available. This is largely because of the consistent background colour (on a
Mac, at least). In the case of Frame specifically, a regular Frame has a white
background that doesn't go well with ttk widgets, while a ttk.Frame has a grey
background. So naturally, when I started trying to implement a pop-out window,
I was using ttk.Frame everywhere.
Then, when I started getting the error cited above, telling me that ".!frame"
was not a frame, I was more than a little perplexed. Because in my view, I
*had* a frame. I don't really care what the widget's unique name is, contrary
to your suggestion that I'm confused by it. If I had given my ttk.Frame the
name "garply", and the error was '".garply" is not manageable: must be a frame,
labelframe or toplevel', I would have looked back at my code, and seen that,
yep, garply was indeed a ttk.Frame, so what's the problem?
It took me a long time to figure out that only a tkinter Frame, and not a ttk
Frame, will work with wm_manage() (disregarding labelframe and toplevel in this
context). Because as a regular developer using the library, it simply wasn't at
all clear that using a ttk.Frame is fundamentally different under the covers,
and isn't actually considered to be a frame for the purposes of wm_manage().
Who'd have thought? Seriously. Regular developers naturally assume that ttk
components are a kind of specialised version of their non-ttk counterparts,
albeit with different options and style support, rather than a parallel world.
You noted that "Our ttk doc does not discuss the ttk widgets that are
essentially copies of tk widgets except the mostly documented differences". I
think it *would* be worthwhile to say something about the fact that these are
parallel components, and not derivatives, because, as this issue clearly
illustrates, it can be important to understand this.
I even read through the tkinter and ttk source code to try to understand what
was going on. The doc string for wm_manage() would have been a good place to
say something, but there's nothing. I do understand that that is outside of ttk
per se, but still, the two are not so separate that a comment couldn't help
explain the constraint, and it really is important to the use of this method to
understand that a ttk Frame is not a Frame.
It's unfortunate that the readable names used in the path aren't different for
tkinter and ttk widgets, especially given how different they are. That would
have helped. I realise, though, that changing it now is likely not a viable
option.
In the end it was a hunch, perhaps born out of desperation and a lack of
anything else to try, that led me to discover that a ttk Frame is not a Frame.
I wasted a lot of time on this. I filed this issue in the hope that some
documentation might be added so that others like myself don't also have to
waste their time.
--
___
Python tracker
<https://bugs.python.org/issue43411>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
