On 4/20/07, Marco Pesenti Gritti <[EMAIL PROTECTED]> 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 _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
