Re: Treating GtkRadioButton as one focus point

[Calum Benson <calum benson sun com>]

Owen Taylor wrote:

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

I think we eventually sort of decided that wrapping around a group of
radio buttons (or anything else) is probably the wrong thing to do in
most cases, for accessibility reasons-- particularly with larger groups,
it makes it hard for somebody who can't see the screen to tell where the
beginning and end of the group is.  It's probably better to stop with
the standard system warning beep (whatever the user may have defined
that as) when they try to go past the ends.  (Ditto when moving focus
around lists, between notebook pages etc.)

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

That doesn't sound too bad, provided everybody lays out their dialog
boxes nicely  :)

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

That would be my preferred option, I think... although I don't think I
explicitly said so in the keynav proposal (although I did in subsequent
posts about it), I was kind of working on the principle that arrow key
navigation would go away except where it was explicitly specified, for
the reason you cited (but I snipped from this post...)
 
> So, I don't think wrapping really works when done generically.

I would agree; as I said, I don't think wrapping is generally a great
idea anyway as it can lead to accessibility problems.  (The exceptions
that spring to mind all relate to tabbing rather than using arrow keys).

> The key focus proposal suggests that arrow keys should only
> work in certain well-defined places:
> <snip>
> Etc. Most of these are possible - but not the "group of related toggle
> buttons" GTK+ just doesn't have that information.

Well, we'll just have to live with the toggle buttons, I guess.  From a
UI perspective, toggle buttons shouldn't normally appear in dialog boxes
anyway, unless you're really stuck for space, so it shouldn't be too
irksome.  And in their more natural habitat, toolbars, keyboard
navigation is somewhat different anyway.

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

Well, for what it's worth, I vote for turning it off except where it
works sensibly, unless that leaves any particularly infuriating gaps in
our navigation picture.

Cheeri,
Calum.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson ireland sun com    Desktop Engineering Group
http://www.sun.ie                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems