[Ttk]'s [button] [widget]. : http://www.tcl.tk/man/tcl8.5/TkCmd/ttk_button.htm 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 {%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 . In Tk, -takefocus only deals with keyboard traversal, and also the ttk documentation says: -takefocus: Determines whether the window accepts the focus during keyboard traversal. Either 0, 1, a command prefix (to which the widget path is appended, and which should return 0 or 1), or the empty string. See options(n) in the Tk reference manual for the full description. [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 [http://sourceforge.net/tracker/index.php?func=detail&aid=2010011&group_id=12997&atid=112997]. 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 [https://sourceforge.net/tracker/index.php?func=detail&aid=2046267&group_id=12997&atid=112997]. 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). ---- <> Custom font [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] ====== <> ---- <> Toolbutton style and custom font [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] ====== <> <> Widget