[Sugar-devel] future of the grab key?

[Eben Eliason]

On Tue, Feb 24, 2009 at 3:31 PM,  <pgf at laptop.org> wrote:
> since we're examining unloved features today, i have something
> to show and tell, too.
>
> i'd like to get input on some work i've done to get the grab
> key(s) on the XO working.  i don't think what i've done is quite
> how they were originally planned to work, but maybe it's close
> enough.  i also know erik did a bunch of work on this last fall
> (see extensive patches on #447), and i've never been sure why
> that hasn't gotten picked up, so i'd like to know more about
> that, too.
>
> background:  i've been working on a (non-XO) project recently
> that led me to implement a userspace virtual keyboard.  as the last
> step of that project, i implemented modifier-based scrolling -- i
> can hold a key, use the joystick (on the keyboard device in
> question), and instead of getting motion events, scroll-button-press
> events are generated and injected into the uinput device.  it
> works very nicely.
>
> when i asked a question related to my project a few weeks ago on
> IRC, tomeu asked if i was thinking about the grab key.  i wasn't
> back then, but the thought stuck with me.
>
> so:  i've now implemented a fairly small daemon that sits between
> the XO keyboard/touchpad pair and the evdev kernel driver.  it
> opens the keyboard and touchpad /dev/input/eventN nodes (in such
> a way that X will skip them when it starts), creates a third
> eventN node via uinput, and shuttles events in between.  the only
> thing it does with the data is watch for the grab keys -- when it
> sees one, it does as described above:  ensuing touchpad events
> are translated into a smaller number of scroll-button events, and
> as a result the window moves instead of the mouse pointer.
>
> but as i was finishing it up and testing it, i realized that it
> doesn't really do what i pictured the grab key as doing.
>
> i had pictured the grab key as causing the mouse cursor to, well,
> "grab" the window contents, to allow dragging it around.  (just
> like clicking and dragging on google maps.)
>
> but what i'd done was different:  when one's finger moved on the
> touchpad, the _scrollbars_ moved.  the mouse pointer stayed
> stationary with respect to the window edges, and the window
> contents moved in the _opposite_ direction from the finger on
> the touchpad.
>
> since i wasn't sure what to make of this frame-of-reference
> reversal, i did the obvious thing:  i reversed the behavior, but
> added a commandline option to put it back, just in case.  (the
> original "backward" behavior still feels more correct on the
> joystick pointer of my original project, for instance.)

Yes, I believe that reversing the events as you have is the correct default.

> since the mouse cursor remains stationary on the screen, it still
> doesn't feel like you're "grabbing" the contents, but it's may be
> more intuitive than the way it was.  any thoughts on this?

Right.  This is a subtle problem anyway, since naturally it's
undesirable to require one to release the grab key, move the pointer
back, press the grab key again, and repeat in order to continue
scrolling.  One option is to move the cursor in accordance with the
finger on the touchpad, but automatically slide it back to the point
of the initial grab when the finger loses contact, as though on a
spring.

That solution doesn't seem particularly ideal either, though.  Perhaps
a stationary cursor is fine, and certainly any working behavior is
better than a useless button.  What would be nice, though, is some
feedback in the form of a cursor change.  We have hand cursors (both
open and closed); we also have the fleur, and double horizontal and
vertical arrows.  It might be quite nice to detect the axes that
support scrolling (is this possible?) and change the cursor to one of
these three options accordingly.

- Eben

> you can try it if you'd like:
>    http://dev.laptop.org/git?p=users/pgf/grabkeyd
> it needs to be started before X, and uinput needs to be loaded.
> (happily, uinput is already in the XO releases.) initially the
> easiest way to test it is:
>    # modprobe uinput
>    # init 3
>    # ./grabkeyd -l
>    [ check that grabkeyd is running, check /var/log/messages
>        for failure ]
>    # init 5
>
> as i recall, one of the objections to erik's implementation last
> year was that it required the XTEST extension, which is considered
> a security risk.  as far as i know, there's no risk to my current
> implementation.  (other than, if it dies, you lose your mouse and
> keyboard.  uh oh -- better run it from init.  :-)
>
> because it's in a fairly critical path, grabkeyd has facility for
> running at an elevated scheduling priority.  currently this is a
> SCHED_FIFO priority, which is probably safe, but perhaps
> overkill.  it's not the default.
>
> comments solicited...
>
>
> paul
> =---------------------
>  paul fox, pgf at laptop.org
>