There're two focus related bugs: 1. When you switch the workspace or the viewport, wrongly focused. 2. Sometimes (input-focus) returns wrong window.
Let's see the details. 1. This happens if the focus mode is enter-*, i.e. one of enter-exit, enter-only, and enter-focus. Procedure: prepare two windows, one covering the right half of the screen, the other the rest. Go to another viewport, move the mouse pointer to somewhere in the left half, and (display-window right-win). Then the *left* window is focused, unless `warp-to-window-enabled' is t. Reason: Viewport motion is in fact windows' motion. So when the viewport is switched, the mouse pointer "enters" the left window. Then an enter-notify-event is generated, and queued. But the control is still inside of the 'display-window', so it focuses the right-win, and returns. Now, the enter-notify-event is handled, and it invokes codes in focus.jl. Since the focus mode is enter-*, it focuses the left window. I don't know what happens in workspace switching. Fix: A. freeze events. More precisely, sawfish sets EnterWindowMask on each window, but unset it temporarily during workspace / viewport switching, and later check the window under the cursor, and sythesize an enter-notify-event at the end. B. Do all inside of lisp, by tinkering hooks. The challenge is that the last call to enter-notify-hook has to do post-cleaning, but how to judge it's last? Since multiple windows may be moved (one by one), stacking calculation is necessary. (Windows in the old viewport can trigger enter event when the covering window is moved.) It's really delicate, but possible in theory. Any idea? 2. (progn (set-input-focus w) (input-focus)) => not w in general. It's because set-input-focus is asynchronous. It's got queued, and handled later. I don't yet know exactly how bad it is. One solution is to add synchronous mode. Best regards, Teika (Teika kazura)
