"Andy Hefner" ahefner@gmail.com writes:
On 1/25/07, Christophe Rhodes csr21@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