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).
There appear to be quite a few things left to do on the keyboard focus front. The frame already has a slot to store the focus, so we need to assign the correct initial focus when the frame is adopted. I also notice the correct timestamps do not reach xlib:set-keyboard-focus, which needs fixing. There's also the issue of how a gadget can detect when the window manager has taken the focus away, since there's no 'note' function for it that I'm aware of, and relatedly why my note-input-focus-changed doesn't appear to work, which I'd intended to note transfer of the assigned focus within an application. Then there's the fun parts, like cycling of focus with the tab key.