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 <[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.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 > > [email protected] > > http://lists.laptop.org/listinfo/sugar > > > > > _______________________________________________ > Sugar mailing list > [email protected] > http://lists.laptop.org/listinfo/sugar =--------------------- paul fox, [EMAIL PROTECTED] _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
