[mcclim-devel] Drei and input focus

[Christophe Rhodes]

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

> On 1/25/07, Christophe Rhodes <csr21 at cantab.net> wrote:
>> 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 ;-)
>
> The degree to which read-gesture separates the programmer from the
> interaction implemented by the stream via various button handling
> methods, functions bound in special variables, etc., has always made
> me nervous. It's somehow relieving to see it causing someone
> difficulty.

Well, glad to be of service :-)

> Maybe we want a slot or method defined on those panes implementing
> click-to-focus behavior which determines whether they are currently
> focussable. An interactor-pane would default to t, application-pane
> nil. If nil, clicks would pass through and be handled as they are
> currently, without reassigning focus. This should preserve the
> behavior of the address book.
>
> I'm slightly concerned that because
> frame-input-context-button-press-handler is a function from the spec,
> users might expect that defining their own method for it would not to
> break input focus handling. Maybe focus handling should be pushed down
> into stream-read-gesture, but I'm not sure how/where.

At the moment, because I've implemented the focus behaviour as a
:before method, it shouldn't matter if users define their own methods
for it.  I generally agree that allowing the user to decide whether
individual panes should be focussable is reasonable, though.

>> 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.
>
> Hmm, that's tricky. Playing around yesterday, I'd added an
> :initial-input-focus initarg for the frame, but that only works in
> gadget-y applications where there is no query-io (otherwise
> run-frame-top-level uses that instead). Maybe we can just change how
> the specified behavior is achieved, so that (keyboard-input-focus
> frame) is nil by default, and focus is initially assigned to (or
> (keyboard-input-focus frame) (frame-query-io frame)) ?

I'm actually fairly sanguine about query-io; I think it's reasonable
for clicks to invoke stream-set-input-focus, thereby taking focus away
from query-io, and leaving just the initial focus setting to there by
default -- it's in the spec, after all, and for "normal" clim apps
this is probably the right thing anyway.  For ESAs with their
different gesture handling, it's perhaps not surprising that a
toplevel customization is needed, and that Bad Things happen if that
toplevel isn't present; if there's an adjustment needed, it's probably
in ESA's classes, or to the behaviour of the minibuffer when it
receives keyboard events...

How shall we move this forward?  I want (very much) something
implementing behaviour similar to that in my patch, because there are
applications that I would like to build that would suck much less with
that kind of behaviour.  I'm sensitive to the fact that I'm not the
only mcclim user, though, and I don't really want to break everyone
else's applications, or send us down a mire of supporting an
unsupportable API... on that subject, what implications does this have
for other backends?

Cheers,

Christophe