[sugar] [PATCH] #447: grab/scroll key

[pgf at laptop.org]

brian wrote:
 > Brilliant work, Erik! I had a chance to play with your first working
 > hand scroll, and it's beyond explanation how fun it is to be able to
 > scroll around using the touchpad without aiming for a gtkScrollBar.
 > 
 > For all to consider: there are two grab buttons. What if one tended to
 > grab + move *objects*, and the other grabs + moves
 > *scenes/backgrounds*? From what I've heard, kids tend to have a hard
 > time left-clicking and dragging with their same hand (as with the
 > touchpad). 

adults too.  recently while demoing one of the tamtam's, it was
startling to see how much click-and-dragging was necessary (e.g.,
for a volume slider).  i suppose that would quickly become a two-handed
operation.  and i have no idea how or whether the grab buttons could
help this.  they probably can't.

paul

 > So, for applications like Browse, both grab buttons could
 > still just scroll up/down. But for graphical editors (e.g., layout
 > programs, Physics, Model, anything with a scene and objects), this UI
 > behavior may be a real time saver and fun to use. This would require
 > giving applications the ability to process events from these two
 > scroll buttons in a way that identifies them separately.
 > 
 > Bravo, sir,
 > Brian
 > 
 > On Thu, Jul 10, 2008 at 2:39 AM, Erik Garrison <erik at laptop.org> wrote:
 > > Sugar devs:
 > >
 > > This is a copy of my bug report for #447.  I have completed a first pass
 > > of the grab key implementation.
 > >
 > > -Erik
 > >
 > >
 > > Summary:
 > >
 > > I used the grab keys to convert the touchpad into a virtual
 > > mouse scrollwheel. Holding down the grab key and moving the mouse a
 > > small number pixels causes a fake mouse button 4/5/6/7 press, depending
 > > on the direction of motion. This approach works in all applications
 > > which support mouse scroll buttons.
 > >
 > > Patches:
 > >
 > > The attached patch to sugar-toolkit adds glib/C-side hooks to grab an
 > > ungrab the mouse, and pass motion-notify events to the python side of
 > > the Sugar shell. I have packaged this patch in an rpm which should be
 > > installable on an XO running a recent joyride (tested on joyride-2123).
 > >
 > > (RPMS: tested but slightly older git snapshot:
 > > 
 > http://dev.laptop.org/~erik/rpms/sugar-toolkit-debuginfo-0.81.5-4.20080705gitab8
 > c054dfb.fc9.i386.rpm
 > > or, untested but slightly newer git snapshot:
 > > http://dev.laptop.org/~erik/rpms/sugar-toolkit-0.81.6-1.fc9.i386.rpm)
 > >
 > > The attached patch to sugar (specifically keyhandler.py) adds the
 > > python-side hooks required to enable the grab/scroll button
 > > functionality.
 > >
 > > The patches work in the following manner:
 > >
 > >    When the left or right grab buttons are pressed, XGrabPointer is
 > >    called. Subsequently, we capture all of the motion-notify events
 > >    which occur when the user moves the mouse, and each event hits
 > >    KeyHandler._motion_notify_cb() with the coordinates of the mouse.
 > >    After we move N pixels (currently 10) we issue a fake mouse scroll
 > >    button press corresponding to the direction of motion of the mouse
 > >    (4/5/6/7). To issue the fake button press I have found it is
 > >    necessary to ungrab the mouse, issue the press, and then re-grab.
 > >
 > > Known issues:
 > >
 > >    In some cases key-releases are not registered. This is problematic
 > >    because without the release signal the mouse grabbing does not
 > >    stop and Sugar becomes entirely unusable. I have not been able to
 > >    establish why, but have noticed that hitting the journal view key
 > >    after Sugar startup before any of the other special keys
 > >    (registered in keyhandler.py) tends to resolve the issue for the
 > >    Super_L and Super_R keys (the grab buttons).
 > >
 > >    The mouse still scrolls around the screen, and the cursor is
 > >    visible during the grab. Solution: Hide the mouse; When a grab key
 > >    press is registered, hide the mouse by setting the cursor pixmap
 > >    to a blank map (and set it back when the grab key release is
 > >    registered).
 > >
 > >    Eventually, after scrolling in one direction, the mouse can move
 > >    out of or to the edge of the scrolling window and the scrolling
 > >    stops. Solution: Every time we issue a fake button press, warp the
 > >    mouse back to the position it was at when we first pressed the
 > >    grab key.
 > >
 > >
 > >
 > > _______________________________________________
 > > Sugar mailing list
 > > Sugar at lists.laptop.org
 > > http://lists.laptop.org/listinfo/sugar
 > >
 > >
 > _______________________________________________
 > Sugar mailing list
 > Sugar at lists.laptop.org
 > http://lists.laptop.org/listinfo/sugar

=---------------------
 paul fox, pgf at laptop.org