The focus is defined in The Tk Way of Thinking. The purpose of the concept is to determine which window gets keystroke events. At one level, the concept is simple, the unique widget with the focus gets the keystrokes. Widgets get the focus when you click the mouse on them or when you use the tab key to cycle the focus to them.

There are two important complications:

1. Tk's focus mechanism is different than the window manager's focus mechanism. The window manager gives the focus to one of the windows it is managing in its own way. Tk gives the focus to at most one widget in any of its windows to which the window manager has given the focus. This section discusses only Tk's part of the focus mechanism.

2. When a given widget has the focus, some keystroke events are not sent to it. This is because some bindings to top-level windows are effective when any part of the window has the focus and because some bindings are effective for all keystrokes.

   This was illustrated with the enhanced Caps example of Figure 11.4a. When the entry widget in that example had the focus, printable characters went to the entry widget. Tab keyboard events, however, did not go to the entry widgets. Another binding took effect.

   This feature is a part of a mechanism described below in Bindings.

There are other complications but they aren't important unless you want to change the way in which the focus is assigned to a widget.

Tk's default mouse mechanism for changing the focus is called click to focus. There is another common way that GUI systems change the focus, it is called focus follows mouse. The names say it all. To change Tk so that it will use the focus-follows-mouse model, execute

tk_focusFollowsMouse

The Tk library currently has no way to change back to the click-to-focus model.

Alongside one of these mouse mechanisms for changing the focus is the keyboard mechanism that uses the Tab key to cycle through a set of widgets that may accept the focus. Holding the shift key down when using the Tab key reverses the cycling direction. Of course, for this mechanism to work, the binding to Tab key events cannot be altered.

There is a command your scripts can use to assign the focus to a widget. It is used this way.

focus WIDGET_NAME

Exercise 12.1a

Revise the script in Figure 11.4a so that Tk will always pass the focus along to the entry widget.

Solution

As you have seen by now, Tk provides a visual indication of which widget has the focus. This indicator is set up by default for those widgets that get the focus by default and not for those that do not. Look in Colors below for how to change this indicator.

Tk actually determines the focus in a very complex way. You may wish to skip the rest of this section on first reading.

Widgets have a -takefocus option to determine whether they will accept the focus. When they are visible and this option is true, they can accept the focus. The -takefocus option has three possible values: true, false, and the empty string. The default tends to be the empty string. The value of this option is used inconsistently with different kinds of widgets and the three ways of letting the user pick the focus: the Tab key, focus follows mouse, and click to focus. The next exercise exhibits some of the inconsistencies.

Exercise 12.1b

Create three button widgets labelled "Default," "Takes Focus," and "Doesn't Take Focus" and make sure the value of their -takefocus option matches these labels. Also create three entry widgets whose -takefocus option likewise takes on the three possible values. Pack these widgets so that the two default -takefocus values come first, then the two true values, then the two false values.

See how the focus changes when you use the Tab key.

See how the focus changes when you click the left mouse button.

Execute tk_focusFollowsMouse and see how the focus changes as you move the mouse cursor. Remember that once you do this you cannot return to the click-to-focus method.

Solution

Some of the inconsistency you see in doing this experiment can be explained by saying that if you want to create an application that permits buttons to be pushed without using the mouse, the Tab mechanism must be able to pass the focus to buttons. On the other hand, if the user is pushing buttons with the mouse, it is probably distracting to see the focus switch when the button is clicked – unless the focus is following the mouse anyway.

Another part of the inconsistency can be fixed by noting that widgets that permit keyboard entry of data have another option that acts a lot like -takefocus. See below in Active/Normal/Disabled.

I do not feel that either of these considerations justifies the complex inconsistencies that surround Tk's focus mechanism. Luckily, the issue does not seem important for most applications.