Tk Source Code

A ttk::button which has -takefocus 1, will get the focus on a <ButtonPress-1> event. This is inconsistent with normal -takefocus behaviour, which only governs keyboard traversal with <Tab>.

Even if this is intentional for ttk, it is inconsistent with the ttk documentation which 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.

Note that fixing this would also fix [1904322] and [1936220].

See also [https://wiki.tcl-lang.org/page/ttk%3A%3Abutton].

I have just checked that this behaviour is present in tcl 8.6.10 on WIndows. It is.
Here is the test script:

<verbatim>
pack [ttk::button .b1 -text takefocus1 -takefocus 1]
pack [ttk::button .b2 -text takefocus0 -takefocus 0]
pack [ttk::entry .e]
</verbatim>

I am still in favour to have the possibility to switch this behaviour off.

Logged In: YES 
user_id=92123
Originator: NO

Joe.  The referred to bugs: 1904322 and 1936220 had patches applied today to work around this issue.

Logged In: YES 
user_id=79902
Originator: NO

I'm not in favour of adding yet more options to widgets. Better to redefine things so they "do what people want", even though that breaks strict compat.

Logged In: YES 
user_id=1388916
Originator: YES

Also ttk::checkbutton and ttk::radiobutton have a -takefocus option which influences <Button-1>.
But ttk::frame has a -takefocus option too, and this is only for keyboard traversal.

Even if the focus-on-click behaviour for buttons 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).