[Tickit-dev] Scroller widget, distributed keybindings

[Paul LeoNerd Evans]

Tickit::Widget::Scroller is coming along well now; it's now in a
minimally-functional state. It supports storing a list of items, pushing
new items draws them, possibly by scrolling down to follow the tail. It
supports arbitrary scroll positions. Unless anything massive seems
missing, I'll CPAN it tonight.

  http://bazaar.leonerd.org.uk/perl/Tickit-Widget-Scroller/

Some TODO items:

  * Item::RichText - will depend on String::Tagged, needs more work

  * Abstract away the "item storage model" out of the actual widget.

  * Implement more storage models:
     + Tangence-backed, for using in circle-fe-term
     + Some sort of database
     
  * Keybindings

This last item, keybindings, is a curiously interesting one.

My current demo program to test the scroller, uses $tickit->bind_key()
to bind PageUp, PageDown, Ctrl-Home and Ctrl-End to scroll up/down/to
top/to bottom. This obviously won't work in a real widget situation..

So my initial thought was, to give Tickit::Widget::Scroller an on_key
method, and just have it capture those four keys. But this in itself
won't work, as the on_key routing walks down the focus chain; and most
likely the scroller widget will never have focus.

The current on_key/focus model works by having each window possibly have
a single child window which is focused. On receipt of a keypress, first
a window tries to pass it to its focused child. If the child doesn't
handle it, it tries to pass it to its own on_key handler, if one exists.
This lets the innermost window (and hence widget) that cares, handle the
key.

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.

My intended use-case is something like the irssi/circle/etc.. console,
whose widget tree would look like:

 Toplevel = Notebook
  |-- VBox
  |    |-- Scroller
  |    |-- HBox[ status bar stuff ]
  |    +-- Entry   *FOCUS LIVES HERE*
  |
  +-- VBox
       |-- Scroller
       ...

With the Entry focused, it would eat most of the input keys (such as
plain text or line editing). On such a key as PageUp, the Entry receives
it first, declines it. So now the VBox would iterate its remaining
windows instead, soon finding the Scroller, which accepts it.

What does anyone think of this? I can see it has the potential to get
very confusing if too many widgets start eating too many keypresses that
get broadcast out like this. On the other hand, it does seem to neatly
solve this problem, and a few related ones, so long as widgets were
fairly conservative in their eating of unhandled broadcast keypresses
like this.

-- 
Paul "LeoNerd" Evans

leonerd at leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://mail.leonerd.org.uk/pipermail/tickit-dev/attachments/20110527/b57847d9/attachment.pgp>