Re: [HCI] Focus navigation with arrow keys

[Hans Breuer <hans breuer org>]

At 13:11 03.03.01 -0500, Owen Taylor wrote:
>
>A rather unusual feature that GTK+ has had for a long time
>is the ability to move the keyboard focus not just with
>Tab/<Shift>-Tab, but also with the arrow keys.
>
>That's sounds like a nice feature, so what's the problem -
>well, it doesn't work very well, and, that being the
>case, I'm not sure it is worth the extra complexity.
>
IMO it is worth to look how this feature is handled by the evil, but
*please* - if you don't think so - instead of flaming me, simply ignore
this mail ...

On windoze there is a combination of Tab/<Shift>-Tab and Cursor Keys as
well, but the cursor movement is restricted to widgets of the same kind and
doesn't leave it. Example:

testgtk::tree 

The selection dialog (Set Tree Parameters) consists of four Groups:
"Selection Mode" with radio buttons. Navigating only within this group with
the cursor up/down keys would be common. But Gtk cursor navigation does not
take grouping into account.

"Options", Check Box Group - Would be the same as with the Radio Button Group.

"Size Parameters", two edit controls. It's nice and common to "step" the
edit controls with "buddies" by cursor up and down. The next entry is
selected in both worlds with Tab.

"(Buttons)" of the Dialog : Cursor movement should be restricted to switch
only between them, if one of them orginally had the focus.

After opening the "Tree Sample" the differences become significant. In Gtk
it seems to be impossible to navigate the tree control with the cursor
keys. The only thing I managed to change the focus to are the four buttons.
If one could set the focus to the tree, cursor navigation within it could
be simply up/down (obvious) to go to the next or previos item. Windoze
would also allow to open/close nodes with children by left/right cursor.

>[ In particular, I'm trying to decide if support for
>  this needs to be in the new inter-process / inter-toolkit
>  embedding protocol ]
>
(Never heard of this :)

> - A number of widgets use arrow keys for their own purposes
>   (cursor navigation in the entry, etc.) This makes trying
>   to use arrow keys for navigation quite frustrating
>   because you go along for a while, then get stuck
>   in a widget where they don't navigate the focus.
>
If the cursor/tab navigation could be split to "within items of equal type"
/ "between groups" this would be common. IHMO the only totally unexpected
key navigation is one of the features of the file selection dialog. It
doesn't catch the arrow keys but breaks Tab navigation (to mask the list of
files). At least I'm used to do such, by simply entering the file mask.
E.g.: *.png and hit Return.
(And yes: im aware of - and like - tab completion in shells)

> [...]
>
>I think the first problem makes this capability pretty useless
>with the current key bindings. We could have different keys
>that _always_ moved the focus, but finding a modifier+arrows
>combination that:
>
> A) is not already in use.
>
> B) Users will have some chance of discovering.
>
>Seems a little difficult. (Control-arrows, Shift-arrows
>are standard CUA bindings. Combinations of multiple-modifiers
>plus arrows are frequently used by window managers, and
>are obscure in any case.)
>
Seems impossible (all possible modifiers already in use by The Gimp :-)
While we are on key bindings. It seems a little bit odd to me, that the Del
key can not be used to delete objects from the canvas (e.g. in Dia). Could
the special meaning of the Del key be restricted to the nice menu
accelerator thing ?

>One possible reason that occurs to me that we might to
>keep this facility is that having the underlying capability
>might be important when controlling the focus with alternate 
>input devices.
>
>Any thoughts on this issue people have would be appreciated..
>
>Thanks,
>                                        Owen
>
Thanks for listening,
	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert