[Tickit-dev] Scroller widget, distributed keybindings

Alastair Douglas alastair.douglas at gmail.com
Wed Jun 22 09:20:55 BST 2011


Here's a mail that got no response:

On Fri, May 27, 2011 at 12:20 PM, Paul LeoNerd Evans
<leonerd at leonerd.org.uk> wrote:
> I'm pondering extending this model, to say that after a window has tried
> passing it to its own on_key handler, and it declined, try passing it to
> all its other windows. This would turn it into a depth-first search of
> the entire window tree, looking for a handler to handle the key,
> favouring the focused child window at each level first.
>
> What does anyone think of this?

I think I would prefer a mechanism by which the parent window can
selectively despatch the event to a specific child if the parent
window finds itself in charge of the event. Otherwise, each child will
conceivably require knowledge of all the other children. I can't think
of an example but it's not infeasible that the handler of the event is
not dependent on focus but on context. The key event IMO should start
with the focused window, and bubble up, DOM-style: a parent container
with funky event logic can then trigger the event on any old element
and absorb the original.


More information about the Tickit-dev mailing list