WM suport for grab key scrolling

[Eben Eliason]

> 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?

Well, it will certainly take some experimentation to get right.  I
suspect that we're going to want a hyperbolic curve of some kind
applied to the motion data.  Roughly, we'll want the speed of the
scrolling to increase increasingly with the velocity of the finger.

Something like:  cosh(vx/k) and cosh(vy/k)

Here we compute the velocity in each direction and compute the
scrolling difference.  Getting the constant k right will be the
important part...you can graph it to get an idea of how it works.

> SCROLL_END. The application remove highlighting on the scrolling view.
>
> 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?

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.

> The other thing which might be necessary is a 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'd rather not have to visually distinguish these scrollbars from the
rest.  Ideally the majority of activities will implement it, and the
HIG can mention it as a requirement.  Of course, we can also just
extend the toolbar to handle it and provide that toolbar for
activities to use in the future anyway, right?

I think that the lack of visual response when the key is pressed
(since the scrollbar won't highlight) is enough to inform the user
that the region doesn't support grab scrolling.

> Press/Release -> activate scrolling mode
> Press/Release again -> deactivate scrolling mode
>
> Keep pressed -> activate scrolling mode but deactivate it on release

This is absolutely correct. Details about whether or not we should
change the cursor (or display a fake one in the place where the hidden
one sat) can be determined later.  The behavior is right.

As a sidenote, Marco, I noticed that the frame key does not match this
behavior in 385.  Was it changed?  I seem to recall it used to work...

- Eben