focus related bugs.

[Teika Kazura <teika lavabit com>]

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)