[mcclim-devel] Drei and input focus

[Christophe Rhodes]

"Andy Hefner" <ahefner at gmail.com> writes:

> On 1/19/07, Christophe Rhodes <csr21 at 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.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: focus.diff
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070125/5edc6cb4/attachment.ksh>
-------------- next part --------------

Cheers,

Christophe