Grab key scrolling
Zephaniah E. Hull
warp at aehallh.com
Thu Apr 19 01:41:56 EDT 2007
Depending on exactly what you want, how easy this is ranges from a
fairly simple GTK hack (I can come up with some patches if necessary),
to wanting the newer input code in X to make it easier and a somewhat
more involved GTK hack.
Alternatively, defining a communication method between sugar and
applications that scroll to let sugar tell them to scroll would allow
the hack to be in sugar, but it's still the same approach.
When you hit the grab key, you grab the pointer events, and translate
those to scrolling around the window. GTK does something along these
lines when you click and hold down the movable part of a scroll bar,
allowing scrolling along one axis.
0: Yes, these are reversed.
1: The scaling they use to match the scrollbar position makes this less
useful then what we probably want.
2: This is where you have choices and tradeoffs.
You can simply grab the core pointer events and let the pointer move
around, this has the problem of not being able to scroll in one
direction once the pointer has reached the edge of the screen.
You can do a full pointer grab, as many games do, usually making the
pointer invisible at the same time. This allows you to scroll
around however you want, but without some tricks to save/restore
pointer position, this leaves the pointer in the middle of the
screen when you let go.
Both of those methods only work on things that move the core pointer
around as a relative device. This doesn't allow the PT to be
3: With the newer input code in X, you have another option.
Go through the list of input devices, set the ones you want to grab
to not send core events, open them, depending on usage you may want
to switch the PT to rel mode, as above treat the incoming X/Y data
as scrolling control.
I'd probably select devices on the simple basis that anything that's
sending core events and is a pointer is fair game.
Just remember on release that you close, and restore the settings
you changed (send core events, rel vs abs).
You can't currently do this in X because you can't do that to the
device that's the core pointer, it _is_ possible to hack around that
to do this in the current X server by adding a null driver acting as
a mouse, but that adds to the work involved by some amount, if
that's worth it for gen1 is someone else's call.
Let me know if for some reason this doesn't fit.
Zephaniah E. Hull.
On Tue, Apr 17, 2007 at 11:31:33AM -0400, Jim Gettys wrote:
> I think we're going to have to take a two prong approach:
> 1) something short term, the best we can figure out to do with what's
> in hand.
> 2) fix X... What we want to do is entirely reasonable, and that it is
> difficult is a bug in the design.
> - Jim
> On Tue, 2007-04-17 at 09:50 -0400, Eben Eliason wrote:
> > > 1 Scroll events can only be horizontal or vertical, you can't move
> > > diagonally for example.
> > This seems like the biggest issue, as diagonal scrolling is one of the
> > main benefits of the grab approach. Still, I really want something
> > mapped to that key. To clarify, will this even properly generate
> > horizontal or vertical events? Does it really know that left to right
> > is different than top to bottom?
> > > 2 The precision is limited since you can only move of a certain step.
> > This is true, but it's not as big an issue to me. I've worked with
> > scroll events before, and the event usually just contains a delta
> > value. This delta can be handled in any way the handler wants, and so
> > can easily be scaled up or down, or capped at some max and min values.
> > > The fact that they are already supported by applications it's clearly a
> > > big plus though. Maybe for Gen1 we could implement something using
> > > scrolling events and for later releases aim to add better semantics to
> > > X. Eben what do you think?
> > So, I guess the answer is that if this is the best we can do for now,
> > then we should try it out. Lack of diagonal scrolling is a big reason
> > to look for a better way, though.
> > - Eben
> Jim Gettys
> One Laptop Per Child
> Devel mailing list
> Devel at laptop.org
1024D/E65A7801 Zephaniah E. Hull <warp at aehallh.com>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
Having been the victim of forgeries myself, I sympathise. I've still got
my nutcraker handy for the day I identify and catch the scum...
-- Richard Gooch on l-k.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Devel