Re: Treating GtkRadioButton as one focus point

[Owen Taylor <otaylor redhat com>]

Calum Benson <calum benson sun com> writes:

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

Hmm, well I guess we just need to get things close so we can
see how it works . Personally, I don't like the idea
of stopping at the end:
 
 - On user testing on myself, I found wrapping around in 
   notebooks and list headers considerably more convenient.

 - Excessive beeping can get really annoying and encourage
   people to turn off sound entirely or whatever.

But I'll cheerfully admit that I don't necessarily represent novice
users, or even experienced users. However, the fact that Windows wraps
not stops seems to indicate that wrapping has at least some support in
user testing.

(Wrapping on lists or anything that would typically be so
big as to encourage use of autorepeat and to scroll
is a different issue.)
 
> > 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.

Mutually exclusive togglebuttons actually _are_ radio buttons 
in GTK+ terms, just drawn differently, so they aren't a problem.

What I was referring to here was the "group of checkbuttons
behavior". What's listed in the recommended column of:

 http://developer.gnome.org/projects/gap/keynav/gtk_buttons.html

Doesn't seem to really correspond to what's in 53577 so I'm
not sure what the desired behavior is, but I remembered some
idea that a group of checkbuttons should behave specially.

[ BTW, The MSWin behavior listed in the chart does not correspond to
either the Win98 behavior (arrows do nothing in checkbuttons) or the
Office98 behavior (arrows act as synonyms for tab/<shift>tab on radio
buttons. I don't have more recent versions around here to test ]

Regards,
                                        Owen