"Andy Hefner" ahefner@gmail.com writes:
On 1/19/07, Christophe Rhodes csr21@cantab.net wrote:
Well, I say the "Right Thing": _clearly_ the right thing is to abandon this horrific focus-follows-mouse-around-widgets disaster and implement a sane keyboard focus policy. Then much of the complexity can go away. Hooray. (What did Classic CLIM do?)
I'm not familiar with the horrors of the Goatee input focus kludge, but it seems straightforward to implement click-to-focus. I've attached a trivial test which demonstrates that this does indeed work (click to focus between two mock text-editor gadgets, although it is initially focus-follows-mouse until the focus is first assigned by clicking, as that simply seems to be what X does by default).
I've attached a patch which implements click-to-focus fairly pervasively, without using the X focus mechanism. The basic idea is to separate out port-keyboard-input-focus, which mediates the X focus for top-level windows, and frame-keyboard-input-focus, which is a per-frame setting. This patch deviates from CLIM II in that stream-set-input-focus does not call port-keyboard-input-focus, but merely sets the per-frame slot; the CLX event handler is adjusted to place the proper sheet in keyboard events.
The implementation of click-to-focus is kludgy. It's fine for drei-gadgets, and for text-gadgets generally; it's not so hot for general streams. I've taken the line that interactor-panes should be focusable with a click; somewhat to my surprise, you can't just write a method on handle-event to get this, but have to work with frame-input-context-button-press-handler. A potential gotcha is that I have not implented click-to-focus for application-panes; this may cause surprises, but it seemed to me the only way not to break the address book demo ;-)
One new spec compliance is that initially keyboard focus really does go to *query-io*. This might cause some surprising behaviour. Somewhat to my surprise, gsharp seems to work -- maybe because its toplevel loop is different -- but ESAs with default-frame-top-level deliver keyboard events to the minibuffer by default, which isn't ideal. On the other hand, the focus behaviour of text gadgets is, to me, much nicer -- and there's no more focus stealing going on.
I have to send this in a bit of a hurry; there's more I could say about this, but I'll be happy to hear comments.
Cheers,
Christophe