[Sugar-devel] future of the grab key?

[David Farning]

Paul,

You are not probably not going to get much feedback from core
developers on grab right now.

That has nothing to do with the validity of the design or the quality
of the implementation.

It is entirely to do with where Sugar is in the release cycle.
Testing and debugging.

When the merge window opens in a few weeks you work will receive a
much more through review.

david

On Wed, Feb 25, 2009 at 2: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.)
>
> 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?
>
> 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
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>