Re: Treating GtkRadioButton as one focus point

[Owen Taylor <otaylor redhat com>]

I was looking at tweaking my GtkRadioButton patch further 
to add wrapping-around for arrow navigation at the end,
when I realized there was a bit of a problem:

 My patch currently does arrow navigation in the same
 way as arrow navigation works for focusing - it 
 geometrically figures out the "best" widget to go
 to in that direction.

 However, that poses problems in this case:

  - Wrapping around is a pain to implement. (Not a UI
    problem, and something I could fix if it was
    the right thing to do, but a pain non-the-less.)

  - If you did implement wrapping around, and had a layout
    other than a single row or a single column, then 
    it wouldn't be possible to cycle through all choices
    using a single arrow key.

  - Some layouts have inaccesible buttons using this scheme.

        [  1  ]                [  2  ]
                   [  3 ]
    
    This isn't so much of a problem for arrow-key focusing
    since you can always resort to Tab focusing which goes
    through all widgets.
 
So, I probably want to go to a different scheme for using
arrow keys - simply sort all the buttons in the radio
group geometrically and have arrow keys go through them
in order. So, if you had:

     A     B
     C     D
     E

The right arrow key would cycle A->B->C->D->E->A->...
while the down arrow key would cycle A->C->E->B->D->A->..

This is not exactly the behavior of Windows ... in Window
both up/down and right/left seem to go through radio groups
in the order of the butttons in the group were added.
But we can't do that for GTK+ because the order of buttons
is currently ignored so many apps are likely to have them
in inappropriate order. (*)

If we make this change, there would be an obvious disconnect
between arrow keynav for focusing and for radio buttons.
One solution would be to simply turn off arrow focus for
containers by default. 

(An old point is that arrow focus is quite confusing in
the presence of widgets that trap arrow keys internally.
But in some testing on Windows (98) it seems there that the
arrow keys have a similarly confusing behavior - they act
as synonyms for <shift>Tab/Tab until you hit a widget where
it does something else.)

Another possibility would be to make normal containers have
the same behavior for focusing as for selection in radio button
groups. (With wrapping and any arrow key cycling through
all widgets.)

However, this has some problems; 

 - if done blindly, then containers that have only one child (like an
   alignment) would trap the arrow keys (becuase of the wrapping
   around). 

 - So, you'd have to turn that on, say, for containers with more
   than one focusable widget it them.

 - But then whether arrow keys worked or not would probably
   seem pretty much random. 

The problem is that the container structure of the application
does not necessarily correspond in any way to the user visible
structure.

So, I don't think wrapping really works when done generically.

The key focus proposal suggests that arrow keys should only
work in certain well-defined places:

 - Groups of related check buttons
 - Groups of radio buttons
 - Notebook pages
 - Menus

Etc. Most of these are possible - but not the "group of related toggle
buttons" GTK+ just doesn't have that information.

So, the question is, if we can't achieve all details of the desired
arrow key behavior, whether it is better to leave in the current
"directional" arrow key behavior where we aren't doing something
better, or to turn it off entirely in places where we can't make it
work right?

Regards,
                                        Owen

(*) Just a guess - it might actually be OK, at least if
    you exclude user interface defined in Glade.