> 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 _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
