[HCI] Focus navigation with arrow keys



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.

[ In particular, I'm trying to decide if support for
  this needs to be in the new inter-process / inter-toolkit
  embedding protocol ]

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

 - In GTK+-1.2, the directional movement doesn't work very well -
   movement with the arrow keys doesn't go where you expect.

   I've fixed this mostly in 1.3, but it still isn't going
   to be perfect,  especially when embedded widgets are involved - 
   if you have

        +------+  +------+ +-----+
        |   A  |  |   B  | |  C  |
        +------+  +------+ +-----+

     +------------------------------+
     |                              |
     |  +------+  +------+ +-----+  |
     |  |   D  |  |   E  | |  F  |  |
     |  +------+  +------+ +-----+  |
     |                              |
     +------------------------------+

   Then if DEF are in the same process as ABC, moving down
   from A properly moves to D, but if DEF in are in
   a different app, moving down from A will go to E.

   (In GTK+-1.2, down from B goes to C...)

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

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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]