https://github.com/python/cpython/pull/7287#discussion_r192546254

[native-api]

python#7287 (comment)

[roseman]

I'm still going to be stubborn and disagree with this one.

The minor point is on accuracy, as there aren't ttk equivalents of all Tk widgets (e.g. canvas, text) - and there shouldn't be.

The theming part of ttk may have been the initial motivation and the implementation focus, but for all practical intents and purposes for everyone except the author of the theming stuff, it's the better appearance that is the primary benefit.

If there are five different API's to do the same thing, I think it's still the job of the reference manual to point them to the right thing. So "if you need a normal button that looks good on all platforms, use ttk's button. If you need extensive customization at the cost of visual platform consistency, use tk's button", etc.

[native-api]

So, ttk is not intended as the next tk? I've got an impression that the latter widgets are mostly retained for backward compatibility and are going to be deprecated (if they aren't already) and dropped at some point.

If some of the old ones are rather never intended to get a replacement, it looks like it's more complicated than that.

Could you point me to something that explains the team's vision on their relationship then? I've written literally what is said at https://www.tcl.tk/man/tcl8.6/TkCmd/ttk_intro.htm -- it only highlights the theming.

[native-api]

"Dated look" is basically a faulty premise. If the team is unhappy with it, why don't they "update" them to look like Ttk? There must be another underlying reason here, and my current impression is exactly the previous message -- that they are deprecated and are not getting updates any longer (whatever the reason for that is -- I guess it's that it's too hard to implement looks consistent with Ttk, or the docs give too many promises for that to be possible).

[roseman]

I'd mentioned before that the classic Tk widgets promise (too much) configurability. Check out the number of options between a Tk widget and a corresponding ttk one; far more in the former. But being able to change a button's background color, border width, etc. etc. interferes with the ability to make them modern looking. The ttk widgets remove a lot of the configurability so that they have more control of the appearance, and can therefore map onto platform conventions much better. But a lot of classic Tk UI's built things that deliberately didn't look like normal UI elements, and for those the flexibility of Tk widgets was needed. (Not that I think this is still necessarily a good idea, but...)

Some Tk widgets there's no ttk equivalent of (canvas and text) since they're more of a blank slate, and of course all the non-widget stuff (geometry management etc.) is used by both.

The original promise of theming had a lot to do with the Linux desktops, even ideally that as the user changed the system-wide theme that ttk would pick up on that, but that never really went anywhere. The main real advantage is better UI on Mac and Windows, and more modern on X11. The switching themes thing gives good demo, but...

[native-api]

If some elements need a customized look, hierarchical (cascading ;) ) styles approach is the best thing currently invented. Dunno if Ttk supports it but this is the way to manage appearance in a scalable manner. You can compare Tk's options with HTML's inline styles and Ttk's theme with CSS. They are not mutually-exclusive as you can see. The key point though is that an overriding style needs to be able to modify upstream values (potentially, in arbitrary ways), not only set new ones unconditionally. Anyway, I think I can now write a more coherent text.