WM suport for grab key scrolling

[Marco Pesenti Gritti]

On Fri, 2007-04-20 at 01:15 +0100, Matthew Allum wrote:
> Hi;
> 
> On Thu, 2007-04-19 at 14:31 +0200, Marco Pesenti Gritti wrote:
> > Hi Matthew,
> > 
> > we have a grab key on the OLPC keyboard. When it's pressed we should
> > grab the pointer and mouse movements should cause the main view on the
> > currently active window to scroll (the web page for a browser, the
> > document for a word processor etc).
> > 
> > Zephaniah was suggesting the WM should manage this which sounds like a
> > sensible approach to me. Basically when pressing the grab key the WM
> > would:
> > 
> > 1 Grab the pointer, hide it and ensure it's always at the center of the
> > screen (otherwise when you get on the edges you would not be able to
> > scroll in that direction anymore)
> > 2 Ask the active window to scroll of a certain amount of pixels on x,y
> > axis.
> > 
> > What do you think? Is there a clean way for the WM to communicate 2 to
> > the active window?
> > 
>  
> So for 1. we can warp the point and it should be pretty strait forward.
> For 2. I assume this needs some application co-operation ? the easiest
> way to do this is for mb to send a custom X message to the root window
> for the current active application to intercept via an X event. Does it
> also need to contain x,y vals and if so where do they come from ?
> 

The events should probably look something like this:

SCROLL_START. The application highlight the scrolling view.

SCROLL_TO (x, y). The application scroll the view. x and y are decided
by the WM on the base of the motion events. I'm not sure about the exact
algorithm. Eben, do you have ideas about it?

SCROLL_END. The application remove highlighting on the scrolling view.

I'm not sure how the toplevel window will communicate with the scrolled
view. Ideally it should happen transparently but gtk currently doesn't
really have semantics to indicate the main window "canvas". People have
been talking forever about introducing an higher level Window widget but
it did not happen yet... The sugar window on the other hand will
probably have it.

Eben, I guess we want the grab key to work independently from the focus?
i.e. if the keyboard focus is *not* on the scrolling canvas, we still
want it to act on it?

The other thing which might be necessary is an hint to indicate that the
window supports grab scrolling. So that we can avoid grabbing the mouse
at all for windows which does not have a scrolling window (or that
doesn't support the protocol).


> I can patch this functionality into mb itself or we it could be
> contained in a standalone small binary which is bound to a key via the
> mb key shortcut handling. Let me know what suits you best.
> 

Eben is in cc so he can correct me but I think the exact key behavior
should be:

Press/Release -> activate scrolling mode
Press/Release again -> deactivate scrolling mode

Keep pressed -> activate scrolling mode but deactivate it on release

Can this be implement using shortcut handling? If so that approach would
work too.

> Im at ELC atm and probably wont get a chance to look closely at this
> until Im back in the UK (this weekend).
> 
> btw, is there any chance I can get a B2 machine ? I dont have one as
> yet.

Gah. Jim can we get a machine to Matthew please? :)

Thanks!
Marco