This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mfncooper
Recipients mfncooper, serhiy.storchaka, terry.reedy
Date 2021-03-13.00:58:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1615597089.68.0.233889817331.issue43411@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2021-03-13 00:58:09mfncoopersetrecipients: + mfncooper, terry.reedy, serhiy.storchaka
2021-03-13 00:58:09mfncoopersetmessageid: <1615597089.68.0.233889817331.issue43411@roundup.psfhosted.org>
2021-03-13 00:58:09mfncooperlinkissue43411 messages
2021-03-13 00:58:09mfncoopercreate