Sugar grab/scroll key not implemented

[walter]

Ap-2, Image 182 the hand keys don't implement scrolling

[marco]

There is some initial code in sugar/lib/src/sugar-push-scroller.c, it needs to be finished up and hooked to the right keys.

[kimquirk]

Can we get this feature in Trial-3? If not, it may not ship with FRS. Moving to trial-3 and raising priority to high.

[marco]

Reassigning to behdad, he has been working on it. I'm not sure what's the status.

[marco]

Behdad, what's the status of this work?

[behdad]

I started a gtk module to do this. That was before GUADEC. It's not working at all yet, but I have a few ideas about how to go forward. Wanted to get it working this week but got distracted by mozilla font selection issues. Hopefully can submit something vaguely working by the weekend.

[marco]

Kim comment on #2965:

"Using the 'hand' keyboard button to scroll through text. Hold down the key and use the touchpad to scroll in both x and y direction."

And moving this to "blocker" because I'm marking it as a dup.

[cjb]

I think Bernie's going to work on this too.

[bernie]

X 1.4 is a prerequisite for this, so I think we should postpone this bug afteer Trial3.

[bernie]

My previous comment may have gone unnoticed due to the recent trac outage:

X 1.4 is a prerequisite for this, so I think we should postpone this bug afteer Trial3.

[erikg]

This is an old bug and a blocker. I would like to resolve it if the behavior is still desired. Otherwise we should let go of it.

[Eben]

Erik, you're my hero! We just brought this up again in the design meeting today, because it's an essential feature and we have been designing with the assumption that we will have this capability. It's definitely not something we should let drop, as there is a dedicated key on the keyboard for it!

If you think you can bring it to life, I say go for it!

[tomeu]

Yeah, would be awesome to have this. May be interesting to grab the people who have already thought about it (Bernie?).

[Eben]

This came up just recently at our last design meeting, and we all agreed that it really deserves some attention in the near future. It's certainly not something we're going to drop lightly, as the rest of the UI was built on the assumption that we'd have this functionality, and there is a dedicated key on the keyboard for it. If you think you can take a reasonable stab at it, Erik, please do!

[erikg]

Thus far I have been unable to verify that _key_released_cb() /usr/share/sugar/.../view/keyhandler.py is even hit when keys are released. I am attempting to write a string to a log file in /tmp whenever a keyrelease event triggers the callback. Can anyone reproduce this issue?

[erikg]

sugar-toolkit rpm with grab key hooks

[erikg]

patch to sugar which adds python-side grab-key functionality

[erikg]

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 (and also attached) this patch in an rpm which should be installable on an XO running a recent joyride (tested on joyride-2123).

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.

[erikg]

I should note that you also have to do "xset -r 133" and "xset -r 134". The attached patch to /usr/bin/olpc-session (in olpc-utils) does just that.

[erikg]

Patch to olpc-session which suppresses repeat on 133 and 134 (Super/Grab/Scroll keys)

[erikg]

You also need to enable the xtest extension. The following patch to /etc/X11/xorg.conf does that.

[erikg]

Replying to erikg:

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).

I have observed that the key releases are not registered when I am in the neighborhood, group, and home views. When I'm in the Activity view the keypresses are registered. This observation suggests a variety of workarounds and also provides some hints about what might be happening. Note that the neighborhood, group, and home view buttons (f2-f4) do not register key releases. I suspect they are being trapped somewhere, but it seems strange that other key releases would also be trapped.

[erikg]

Replying to erikg:

* 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.

I have tested and verified that this approach works.

[erikg]

Patch which can be applied to sugar-toolkit 0.81.6 to enable grab button functionality (with pointer warping)

[erikg]

patch to sugar which adds python-side grab-key functionality (adds warping support)

[pgf]

i've created an alternate implementation, based on a daemon that watches the user's input stream and transforms grab-modified touchpad events into scroll events. code is here: http://dev.laptop.org/git?p=users/pgf/grabkeyd

[pgf]

fixed and released in 10.1.2 (just happened on this by chance.)