WM suport for grab key scrolling

[Bert Freudenberg]

On Apr 20, 2007, at 18:07 , Marco Pesenti Gritti 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.

Who actually thinks this is a good idea? I'd much rather require  
holding the grab key. There will be numerous kids trying to move the  
pointer while nothing happens.

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

I guess the pad is cheaper? Two-finger scroll needs a special pad.

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

Apparently only half of this communication makes it to the devel  
list ...

But why would you need keyboard focus for a mouse modifier key?

- Bert -