WM suport for grab key scrolling

[Marco Pesenti Gritti]

On Fri, 2007-04-20 at 11:52 -0400, Eben Eliason wrote:
> > > Absolutely.  Ideal behaviors:
> > >
> > > 1) The scrolling region directly visible beneath the mouse gets grab focus.
> > > 2) If two scrolling regions overlap, the top one should take the grab focus.
> > > 3) If a scrolling region is embedded in another (such as an iframe in
> > > a web page), then the innermost region should get grab focus, unless
> > > it reaches its min or max scroll and can no longer move, at which
> > > point the next region in the hierarchy gets it.
> > >
> >
> > Hmm I'm not convinced about this. Usually keyboard actions apply either
> > globally (to the system or to the active window) or to the focused
> > element. I feel pretty strange, interaction wise, to have a keyboard
> > button depend on the position of the mouse.
> 
> The grab key isn't so much a keyboard action as it is a modifier key
> for the trackpad/mouse.  This is very much like the behavior of a
> scroll-wheel mouse (or Apple's two-finger scrolling), which always
> scrolls the view beneath the cursor.

Well, yeah, but the fact that's physically part of the the keyboard
doesn't really suggest it's a mouse modifier. And the fact that we have
a scrolling mode (press/release) doesn't suggest it either.

Btw what are the advantages of a scrolling mode/modifier over Apple's
two-finger?

> Requiring focus in the region won't work that well for several
> reasons.  First, it could require a click to set focus.  Additionally,
> it might be the case that every portion of the scrollable region is
> clickable (eg. a long list where each row is clickable/selectable), in
> which case the click intended to focus the region would actually have
> an immediate unintended action.
> 

I was thinking to use keyboard focus only in the case of multiple views.
That's not optimal either admittedly.

Marco