WM suport for grab key scrolling

[Eben Eliason]

On 4/20/07, Marco Pesenti Gritti <mpg at redhat.com> wrote:
> 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.

Well, that's true, but that's out of necessity.  In any case, if you
consider how we got to the current spec it may make more sense.
Initially, pressing the key would change the cursor into a hand,
allowing one to click and drag a view around.  This is a very direct
interaction, and clearly the hand should grab the view it's on top of.
 After some thought, it became apparent that this required both a
modifier key and the mouse button, one of which would have to be
repeatedly pressed and released.  It is an optimization
(interaction-wise) to lock the cursor and simply scroll the view
without need to click the mouse button to actually perform the grab --
the grab is implicit.

Perhaps we should really put a placeholder cursor graphic where the
mouse was when the grab started.  Some fixed graphic (perhaps the
hand, or perhaps we need to change the hand icon on the keyboard
altogether since the grab is a little ambiguous now) swap for the
cursor would clearly indicate it's context.  The reason we opted to
hide it altogether was to make it easier to read the content within
the scrolling region.  That may be over-thinking it; I'm not sure.

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

There is none, except perhaps discoverability.  I'd rather have
two-finger scrolling, but this may be patented and I understand that
our trackpad can't provide multi-touch data anyway.

- Eben