Below is a patch for tk3.1/tk3.2 to modify the way focus and keyboard events are handled. The patch implements two independent changes (you can choose between using none, either, or both of the modified behaviors). First the two modifications are described, and then the patch file itself. focus-follows-pointer --------------------- tk2.3 used a focus-follows-pointer model, while tk3.1 introduced a click-to-focus model. Below is patch for that allows the application designer (or user) to select between the two models at runtime. focus-follows-pointer (tk2.3): By default, all keyboard events are sent to the window under the mouse cursor. The "focus" command may be used to establish a focus window where all keyboard events are sent regardless of where the mouse pointer is. After the focus window is destroyed or after a "focus none" command, keyboard events will again be sent to the window under the mouse cursor. click-to-focus (tk3.1): Keyboard events are always sent to the focus window. If there is no focus window, keyboard events are dropped. The "focus default" command allows two levels of focus, so that a temporary window may be created, given the focus, and then when the temp window is destroyed the focus will be automatically restored to the original state. After you have rebuilt your application, tk will still use the default click-to-focus model. To switch to the focus-follows-pointer model, issue the tcl command: focus pointer on focus none The behavior will then be similar to tk2.3. It is only "similar" to tk2.3, because the "focus default" of tk3.1 is still available and active. propagate-key ------------- tk2.3 used a "flat" model for Key events (KeyPress and KeyRelease). That is, key events were matched against bindings for the focus window or, if no focus window, the window under the pointer. The patch below allows the application designer to select a "propagation" model. This is used only when there is no active focus window. Key-events will be matched not only against the window under the pointer, but all of its parents, until a match is found. Thus (conceptually) the key-events are propagated up the window hierarchy. Prof. Ousterhout's implementation of event bindings allows such propgation to be efficiently and conventiently implemented. After you have rebuilt your application, tk will still use the default "flat" model. To switch to the "propagation" model, issue the tcl command: focus propagation on Note: Some widgets "absorb" all key events (.e.g, Menu and Entry) and discarded them even if the key event is not used. Such events are not propagated upwards. Perhaps a mechanism is needed to allow such widgets to examine the key and "refuse" it, in which case it would get propagated. Or perhaps that would just complicate things. comments -------- Both of these patches were easy to implement and are small. The focus-follows-pointer is a strait-forward concept with little subtlety. In contrast the propagate-key seems more complicated (How far up should the keys be propagated? Should propagation terminate at top-level windows? At user selected top-level windows? Should propagation occur even with an active focus? How can it be used to better implement menu traversal?) If you find bugs or have questions/additions, please let me know. The patch file is below. Kennard focus3.1a patch (fixed) --------------- This patch was designed for tk3.1, but should work with tk3.2 as well. The patch will modifify tk.h, tkEvent.c, tkFocus.c, and tkCmds.c. It will also create "focusDemo.tcl", a short script that demonstrates these modifications. For focus-follows-pointer behavior support, you must modify the Makefile so that the CFLAGS includes "-DPOINTER_FOCUS". If this is not defined in the Makefile, the focus-follows-pointer modification will be ifdef'd out, and you will get vanila tk3.1. For propagate-key bevhavior support, you must modify the Makefile so that the CFLAGS includes "-DPROPAGATE_KEY". If this is not defined in the Makefile, the propagate-key modification will be ifdef'd out, and you will get vanila tk3.1.