After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 53577 - KEYNAV: GtkToggleButton, GtkCheckButton, GtkRadioButton
KEYNAV: GtkToggleButton, GtkCheckButton, GtkRadioButton
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
1.3.x
Other All
: Normal normal
: Small feature
Assigned To: gtk-bugs
gtk-bugs
AP4
Depends on:
Blocks:
 
 
Reported: 2001-04-25 09:59 UTC by Calum Benson
Modified: 2013-02-04 02:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch has fix for focus wrap around problem in gtkradiobutton (1.25 KB, patch)
2002-04-03 15:03 UTC, Narayana Pattipati
none Details | Review

Description Calum Benson 2001-04-25 09:59:27 UTC
A toggle, check or radio button should not be activated if keyboard focus
is given to it by using a mnemonic that is shared by another control in the
same context.  In this case, keyboard focus should be given to that button,
at which point:

- pressing Spacebar should activate the button;

- pressing the same mnemonic again should cycles focus to the next control
in the context that shares the same mnemonic;

- pressing Enter should activate the window's default button if it has one,
otherwise does nothing.


When any button within a functional group of mutually exclusive toggle or
radio buttons has focus:

- pressing Tab should move focus to the control immediately after the last
button in that group;

- pressing Shift+Tab should move focus to the control immediately before
the first button in that group;


When any button within a functional group of check buttons has focus:

- pressing Tab should move focus to the next button in that group, or to
the control immediately after the last button in that group if it is the
last button that is currently focused.

- pressing Shift+Tab should move focus to the previous button in that
group, or to the control immediately before the first button in that group
if it is the first button that is currently focused.


When any button within a functional group of toggle, check or radio buttons
has focus (mutually exclusive or not):

- pressing the up or left arrow should move focus to the previous enabled
button in the group, wrapping around to the last button in the group if
necessary;

- pressing the down or right arrow should move focus to the next enabled
button in the group, wrapping around to the first button in the group if
necessary.


[Check http://developer.gnome.org/projects/gap/keyboardnav.html for any
 later proposals that may not have filtered through to this bug report yet]
Comment 1 Owen Taylor 2001-09-21 15:30:43 UTC
A difference between the behavior described here and that
on Windows is that on Windows when focus is on a radio
button group, the arrow keys change the selected item
with the group.

So, you focus into the group, the focus is displayed around
the currently selected item, and up/down change the selected
item.

I thought I'd mention this since it doesn't seem to be described
in the keybindings document.
Comment 2 Calum Benson 2001-09-21 16:18:17 UTC
This was an oversight on my part... I had meant to mention/propose
that behaviour in the document.  I'll update it when I get a chance...
Comment 3 padraig.obriain 2001-10-03 10:42:03 UTC
The request that Tab or Shift+Tab when on a radio button in a radio
button group should move the focus out of the group is difficult.

The problem is that up to now when moving focus each child widget in
the widget hierarchy is eligible if it is sensitive and drawable and
can receive focus.

We now want to add another condition: another radio button in a radio
button group cannot receive focus via Tab keys if a radio button has
focus.

I cannot see a clean way of implementing this.

An alternative would be to define a GtkRadioButtonGroup widget; the
radio buttons in the radio button group would be added to the widget.
Moving focus to the GtkRadioButtonGroup would cause the focus to be
moved to the first or last radio button.

This seems a bit radical for 2.0.

Comment 4 Owen Taylor 2001-10-11 23:39:05 UTC
I thought about this some and it turns out that it isn't
actually very hard to handle the desired radiobutton
behavior. The trick is to only accept the focus on
a radio button if it is active (and also if no
button is selected in the group to handle that somewhat
pathalogical case.) This can be done with an appropriate 
->focus() virtual method implementation.

The main tricky part of this is handling figuring out
what widget in the group to go when arrow keys are pressed.
It turns out that the simplest way of handling this
is to expose some internals from gtkcontainer.c which
already handles arrow-key ordering for focusing.

I'm working on a patch to do this now.
Comment 5 Luis Villa 2002-01-22 21:29:59 UTC
Adding GNOME2 keyword to all keynav bugs per sander's request. You can filter on
the phrase 'luis doing GNOME2 work' to catch all instances of this so that you
can ignore them.
Comment 6 Owen Taylor 2002-02-28 20:07:19 UTC
Was fixed a while ago.
Comment 7 keelin.boyle 2002-03-11 10:06:19 UTC
Thought I'd add my keynav comment to this bug rather than log a new
one as it's kindof related. I find Arrow keys wrap around Toggle
Buttons, Checkboxes, Radio Buttons without an audio beep warning, this
would be a really useful feature to include in GNOME2.0. I was using
the build from Feb 26th on Solaris, apologies if this feature has been
added since.
Comment 8 Narayana Pattipati 2002-04-02 06:47:18 UTC
The problem of focus wrapping around in a group of radio buttons
still exists. I have a small patch which fixes this problem. 
With this patch, when the user tries to naviagte past the first/last
radio-button in the group with arrow keys, a system beep sounds. 

I would like to submit this patch. Someone, please change the status
of the bug to NEW.??
Comment 9 Narayana Pattipati 2002-04-03 15:03:28 UTC
Created attachment 7531 [details] [review]
Patch has fix for focus wrap around problem in gtkradiobutton
Comment 10 Narayana Pattipati 2002-04-03 15:05:36 UTC
The patch(id=7531) should be applied on the following versions
of file(s):

gtkradiobutton.c    -- 1.41
Comment 11 Matthias Clasen 2002-04-05 13:35:24 UTC
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
Comment 12 Owen Taylor 2002-05-15 22:46:00 UTC
It doesn't make much sense to me to wrap around for radio
buttons, and not wrap around for menus. We need to do this
in some coordinated fashion.
Comment 13 Owen Taylor 2002-05-15 22:51:42 UTC
Forget the comment about menus... I really don't want menus
to beep instead of wrapping around.

But I still need to think about this a bit more.

*** NOTE *** after this issues is resolved, please do not reopen
             this bug. File other bugs instead. Bugs with
             dozens of unrelated issues on them don't work.
Comment 14 Calum Benson 2003-04-03 14:54:38 UTC
Updating status_whiteboard field to reflect A11Y team's assessment 
of accessibility impact.
Comment 15 Calum Benson 2003-08-07 16:09:35 UTC
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)
Comment 16 Matthias Clasen 2004-03-10 09:30:21 UTC
FWIW, Windows radio groups seem to wrap around too. 


Moving this to 2.4.1.
Comment 17 Elijah Newren 2004-06-19 18:43:56 UTC
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as
Matthias said he was trying to do himself on IRC and was asking for help with. 
If you see this message, it means I was successful at fixing the borken-ness in
bugzilla :)  Sorry for the spam; just query on this message and delete all
emails you get with this message, since there will probably be a lot.
Comment 18 Calum Benson 2004-10-21 16:49:49 UTC
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.
Comment 19 Calum Benson 2006-04-26 17:11:55 UTC
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Comment 20 Matthias Clasen 2013-02-04 02:08:34 UTC
most things here are handled nowadays