Note that on Windows XP, this widget looks much better than the default.
The ttk::button widget behavior deviates from normal Tk buttons in one critical way: when you click a ttk::button widget the keyboard focus goes to that widget. With plain Tk buttons this does not happen. This, I think, is a significant change in behavior. For example, imagine being in a text editor and clicking on a toolbar button -- you don't want focus to leave the text widget, and you don't want to have to add in the binding for every button to restore the focus.
To work around this you can set -takefocus to zero but then you lose the benefit of keyboard traversal which isn't good for accessibility.
The workaround I've started using is to simply change the class bindings. The original bindings call ttk::clickToFocus, which I think can be safely removed. The new class binding becomes:
bind TButton <ButtonPress-1> {%W state pressed}Changing the state is critical; without it the button becomes effectively disabled.
KD: I believe it's a bug that -takefocus has influence on <ButtonPress-1>. In Tk, -takefocus only deals with keyboard traversal, and also the ttk documentation says:
MG also thinks it's somewhat strange behaviour, but it's not a bug - I'm sure it's come up at least once on the bug tracker on Sourceforge and been closed as intended behaviour. (Though it is perhaps a documentation error that needs fixing.)
IDG Aug 11/08. It's also the cause of the regression noted in Tk bug 1936220. (Tk_getOpenFile -multiple no longer works on unix). Who knows what other regressions may lurk in the bushes? Has a rationale been presented for this ttk::button behaviour?
MG See [L1 ]. Apparantly it's the documented behaviour for most WMs. (It's not what I'm used to at all on Windows, but it's apparantly what MS have documented as the correct behaviour, though they don't seem to do it themselves in any MS app I use.)
KD: In any case I have added a new bug report about this [L2 ]. Even if the focus-on-click behaviour is intentional, I think it should not be governed by -takefocus (which has a dedicated meaning in whole Tk), but rather by a separate option (eg. -focusonclick or -clicktofocus).
HaO 2013-11-22 I am in favor that the button does not take focus on cick. For me, we loose power specially for Toolbuttons.
If the focus would be kept to the original place, one could easy emulate the current behaviour by:
::ttk::button .b -text "a" -command "%W focus"
I suppose, this would require a TIP...
HaO 2011-05-20 Use a custom style to use a custom font
ttk::style configure custom.TButton -font {size 20}
pack [ttk::button .b -style custom.TButton -text Big]HaO 2011-05-20 I really like the buildin Toolbutton style for a themed button and menubutton widget. Use a custom style to use a custom font.
ttk::style configure custom.Toolbutton -font {size 20}
pack [ttk::button .b -style custom.Toolbutton -text Big]HaO 2012-04-10 Toolbutton labels are left anchored in many styles to be beautiful if lined-up with an icon. For label-only buttons it might be desireable to have a centered label:
ttk::style configure custom.Toolbutton -anchor center pack [ttk::button .b -style custom.Toolbutton -text centered] -ipadx 10
HaO 2013-11-22 If one wants to invoke buttons also with the enter key:
bind TButton <Return> "%W invoke"
This only works, if the class was not changed to something else.
Question on clt :
I saw a post where someone edited the elements and style layout on an entry to change the behavior. I was wondering if there is a way to use elements to change the behavior of the XPNative theme for TButton style? When you set the background color, it only sets the border on the button for XPNative. I would like the entire background to be set. Is this impossible or can a new style with newly defined elements fix this to work as expected for this theme?
Answer by Pat Thoyts:
See http://paste.tclers.tk/2534 and an earlier version at http://paste.tclers.tk/43
Use a ttk::checkbutton with the Toolbutton style to get a button with a checked state.