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). 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 <[EMAIL PROTECTED]> 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.20080705gitab8c054dfb.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@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > > _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar