Re: [sugar] [PATCH] #447: grab/scroll key
On Mon, Jul 14, 2008 at 6:06 AM, Erik Garrison [EMAIL PROTECTED] wrote: How is the cursor pixmap currently set? Is there an existing function in the sugar codebase to set the cursor pixmap? No, we just use the gdk functions. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Mon, Jul 14, 2008 at 12:06 AM, Erik Garrison [EMAIL PROTECTED] wrote: On Sun, Jul 13, 2008 at 11:19:46AM -0400, Eben Eliason wrote: On Sun, Jul 13, 2008 at 11:03 AM, Brian Jordan [EMAIL PROTECTED] 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. Great to hear! I can't wait to give it a try myself...it's been a long time in coming. I'll give you a demo tomorrow. 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. That's an interesting idea. However, the reason there are two keys is so that interaction works well for both left- and right-handed users, without the need for them to cross their arms to scroll around. What we might be able to do, though, is map an SHIFT-HAND shortcut to a drag/drop action instead. (I suggest shift because it's the only modified which is present on both sides of our keyboard, for the same reason as above.) I like Brian's idea but felt similarly about the difficulty in deciding which hand button executes which function. SHIFT-HAND is a good solution, and relatively easy to implement. Agreed, SHIFT-HAND +1 UI wise, will there be a way to distinguish between SHIFT-HAND and a regular click? For example, in Physics, I can imagine having SHIFT-HAND move objects around even if a non-grab tool is selected. To make that work well, I think we'll need to manage the display of the cursor appropriately. perhaps we can use the horizontal/vertical/fleur arrows to indicate scrolling options, switch to the open hand when shift is pressed to indicate drag mode, and switch to a closed hand after a drag has been started. People always did enjoy the open/closed hand of Adobe Reader. :) I think this is a fantastic idea. How is the cursor pixmap currently set? Is there an existing function in the sugar codebase to set the cursor pixmap? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
marco pesenti gritti wrote: On Thu, Jul 10, 2008 at 8: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. Have you considered implementing this at the X level? If so, why did you decide to go for a Sugar specific solution? I have no idea if/how that's possible but I see that the synaptic driver has a TwoFingerScrolling option and I've seen something similar for thinkpads a while ago. for thinkpads? do tell? i'd love to be able to scroll using the eraserhead thing -- along with ALT, maybe. actually, any scrolling accelerator would be welcome. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Mon, Jul 14, 2008 at 05:36:44AM -0400, Brian Jordan wrote: On Mon, Jul 14, 2008 at 12:06 AM, Erik Garrison [EMAIL PROTECTED] wrote: I like Brian's idea but felt similarly about the difficulty in deciding which hand button executes which function. SHIFT-HAND is a good solution, and relatively easy to implement. Agreed, SHIFT-HAND +1 UI wise, will there be a way to distinguish between SHIFT-HAND and a regular click? For example, in Physics, I can imagine having SHIFT-HAND move objects around even if a non-grab tool is selected. I think it would be possible at the price of a degree of software complexity. We would probably have to modify the keyhandler to issue some kind of signal about the grab state. Your application would have to listen for that signal. I suspect there is a way to manage this at your client application's level. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Thu, Jul 10, 2008 at 8: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. Have you considered implementing this at the X level? If so, why did you decide to go for a Sugar specific solution? I have no idea if/how that's possible but I see that the synaptic driver has a TwoFingerScrolling option and I've seen something similar for thinkpads a while ago. Eben, could you give it a try and comment on the user experience? Cheers, Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
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
Re: [sugar] [PATCH] #447: grab/scroll key
On Sun, Jul 13, 2008 at 11:03 AM, Brian Jordan [EMAIL PROTECTED] 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. Great to hear! I can't wait to give it a try myself...it's been a long time in coming. 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. That's an interesting idea. However, the reason there are two keys is so that interaction works well for both left- and right-handed users, without the need for them to cross their arms to scroll around. What we might be able to do, though, is map an SHIFT-HAND shortcut to a drag/drop action instead. (I suggest shift because it's the only modified which is present on both sides of our keyboard, for the same reason as above.) To make that work well, I think we'll need to manage the display of the cursor appropriately. perhaps we can use the horizontal/vertical/fleur arrows to indicate scrolling options, switch to the open hand when shift is pressed to indicate drag mode, and switch to a closed hand after a drag has been started. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Sun, Jul 13, 2008 at 11:20 AM, [EMAIL PROTECTED] wrote: 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. The behavior of GTK sliders has bothered me. I'd expect to be able to click anywhere on the slider to immediately set it's value to the location I clicked, or click on the handle to drag it. Unfortunately, GTK doesn't behave this way, and instead moves the handle by small increments each time you click. Does anyone know if there is a way to change this? I love drag'n'drop, but I'd strongly prefer not to /require/ it. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On 13 Jul 2008, at 16:19, Eben Eliason wrote: On Sun, Jul 13, 2008 at 11:03 AM, Brian Jordan [EMAIL PROTECTED] wrote: 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. That's an interesting idea. However, the reason there are two keys is so that interaction works well for both left- and right-handed users, without the need for them to cross their arms to scroll around. What we might be able to do, though, is map an SHIFT-HAND shortcut to a drag/drop action instead. (I suggest shift because it's the only modified which is present on both sides of our keyboard, for the same reason as above.) SHIFT-HAND would be a good direct alternative to the trackpad left button. It would then be useful in many existing places/activities for drag'n'drop operations while leaving the primary HAND use for scrolling. I'd probably use SHIFT-HAND instead of the trackpad button for clicking – it's already usually a two handed operation for me to avoid confusing the touch pad. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] #447: grab/scroll key
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.
From 9fd6e08513d7829c9919b109d49a554588d63c71 Mon Sep 17 00:00:00 2001
From: Erik Garrison [EMAIL PROTECTED]
Date: Wed, 9 Jul 2008 18:48:33 -0400
Subject: [PATCH] #447: Enable grab/scroll button functionality.
---
src/view/keyhandler.py | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 44ea759..d1140be 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -62,6 +62,8 @@ _actions_table = {
'altshifto' : 'open_search',
'altshiftr' : 'rotate',
'altshifts' : 'say_text',
+'Super_L': 'grab_button_pressed',
+'Super_R': 'grab_button_pressed',
}
J_DBUS_SERVICE = 'org.laptop.Journal'
@@ -78,6 +80,8 @@ class KeyHandler(object):
self._key_pressed = None
self._keycode_pressed = 0
self._keystate_pressed = 0
+self._mouse_xy = [None, None]
+self._grab_key_mouse_delta = 10
self._speech_proxy = None
self._key_grabber = KeyGrabber()
@@ -85,6 +89,8 @@ class KeyHandler(object):
self._key_pressed_cb)
self._key_grabber.connect('key-released',
self._key_released_cb)
+self._key_grabber.connect('motion-notify',
+ self._motion_notify_cb)
self._tabbing_handler = TabbingHandler(_TABBING_MODIFIER)
@@ -137,6 +143,13 @@ class KeyHandler(object):
self._get_speech_proxy().SayText(text, reply_handler=lambda: None, \
error_handler=self._on_speech_err)
+def handle_grab_button_pressed(self):
+self._key_grabber.grab_pointer()
+
+def handle_grab_button_released(self):
+self._key_grabber.ungrab_pointer()
+self._mouse_xy = [None, None]
+
def handle_say_text(self):
clipboard = gtk.clipboard_get(selection=PRIMARY)
clipboard.request_text(self._primary_selection_cb)
@@ -278,6 +291,10 @@ class KeyHandler(object):
return False
def _key_released_cb(self, grabber, keycode, state):
+logging.debug('_key_released_cb: %i %i' %
