GNOME Bugzilla – Bug 334742
GtkRadioButton won't be activated when getting focus
Last modified: 2011-02-04 16:11:01 UTC
when using arrow keys only for moving focus in and out a group of radiobuttons, the current focused radiobutton will also be activated automatically. this automation may not be desired when the user just want to navigate through the radiobuttons without affecting the toggling state. implementation: diff -r -u gtk/gtkradiobutton.c gtkkeynav/gtkradiobutton.c --- gtk/gtkradiobutton.c 2006-02-27 15:12:28.091709123 +0800 +++ gtkkeynav/gtkradiobutton.c 2006-02-27 15:09:31.475813816 +0800 @@ -467,7 +467,6 @@ { GtkRadioButton *radio_button = GTK_RADIO_BUTTON (widget); GSList *tmp_slist; - /* Radio buttons with draw_indicator unset focus "normally", since * they look like buttons to the user. */ @@ -519,9 +518,11 @@ tmp_list = tmp_list->next; } } - + + int reach_end = 0; if (!new_focus) { + reach_end = 1; tmp_list = focus_list; while (tmp_list) @@ -539,13 +540,23 @@ } g_slist_free (focus_list); - - if (new_focus) + + if (reach_end == 1) + { + if (direction == GTK_DIR_LEFT || direction == GTK_DIR_UP) + gtk_widget_child_focus(gtk_widget_get_toplevel(widget), GTK_DIR_TAB_BACKWARD); + + if (direction == GTK_DIR_RIGHT || direction == GTK_DIR_DOWN) + gtk_widget_child_focus(gtk_widget_get_toplevel(widget), GTK_DIR_TAB_FORWARD); + } + else + { + if (new_focus) { gtk_widget_grab_focus (new_focus); - gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (new_focus), TRUE); + //gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (new_focus), TRUE); } - + } return TRUE; } else Other information: in a embedded device such as a phone with keypad only, the user may want to use the joystick to move from a group of radiobuttons to a underneath textview to input some text, but the selection made in the radiobuttons should not be changed when the user walk through them with the joystick.
This would have to be controlled by some setting ... the current behavior was spec'ed out as the correct behavior, and corresponds to the behavior on other platforms. Aren't there a lot of other areas where navigation with arrow keys only doesn't work? For example you can't get out of a GtkTextView at all.
(In reply to comment #1) > This would have to be controlled by some setting ... the current > behavior was spec'ed out as the correct behavior, and corresponds > to the behavior on other platforms. > > Aren't there a lot of other areas where navigation with arrow keys > only doesn't work? For example you can't get out of a GtkTextView > at all. > does this (http://bugzilla.gnome.org/show_bug.cgi?id=334726) address the GtkTextView problem? please be reminded that the desktop environment is in some way quite different from the phone environment.
Bug #309290 asks for someting else, namely stopping keynav at the group's boundary, instead of wrapping.
Created attachment 64854 [details] [review] Patch which makes this depend on a setting Tha attached patch does the same as the patch in the original report, only much simpler. It also abuses the gtk-touchscreen-mode setting for switching between the old and new behaviors. I think we really need a setting that says "there are only cursor keys, nothing else". Tim suggested "gtk-cursor-only-focus", that name sounds pretty good. Opinions?
I changed my mind and proposed something more general in bug #322640.
Fixed in CVS. Bug reporters, please check your use cases and file new bugs against the new features if anything doesn't work. It doesn't make sense to keep 6 bugs open. 2006-11-16 Michael Natterer <mitch@imendio.com> Add new infrastructure for notifications of failed keyboard navigation and navigation with restricted set of keys. The patch handles configurable beeping, navigating the GUI with cursor keys only (as in phone environments), and configurable wrap-around. Fixes bugs #322640, #70986, #318827, #334726, #334742 and #309291. * gtk/gtksettings.c: added properties gtk-keynav-cursor-only, gtk-keynav-wrap-around and gtk-error-bell. * gtk/gtkwidget.[ch]: added new signal "keynav-failed" and public API to emit it. Added New function gtk_widget_error_bell() which looks at the gtk-error-bell setting and calls gdk_window_beep() accordingly. * gtk/gtk.symbols: add the new widget symbols. * gtk/gtkcellrendereraccel.c * gtk/gtkimcontextsimple.c * gtk/gtkmenu.c * gtk/gtknotebook.c: use gtk_widget_error_bell() or look at the gtk-error-bell setting instead of calling gdk_display_beep() unconditionally. * gtk/gtkcombobox.c * gtk/gtkentry.c * gtk/gtkiconview.c * gtk/gtklabel.c * gtk/gtkmenushell.c * gtk/gtkspinbutton.c * gtk/gtktextview.c * gtk/gtktreeview.c: call gtk_widget_error_bell() on failed keynav. * gtk/gtkentry.c * gtk/gtklabel.c * gtk/gtkrange.c * gtk/gtktextview.c: consult gtk_widget_keynav_failed() on failed cursor navigation and leave the widget if it returns FALSE. * gtk/gtkmenushell.c * gtk/gtknotebook.c: only wrap around if gtk-keynav-wrap-around is TRUE. * gtk/gtkradiobutton.c: ask gtk_widget_keynav_failed() to decide whether to to wrap-around, and don't select active items on cursor navigation if gtk-keynav-cursor-only is TRUE. Should look at gtk-keynav-wrap-around too, will look into that.
Made radio buttons honor all relevant settings correctly: 2006-11-16 Michael Natterer <mitch@imendio.com> * gtk/gtkradiobutton.c (gtk_radio_button_focus): don't use gtk_widget_keynav_failed(). Instead, look at gtk-keynav-cursor-only and gtk-keynav-wrap-around and wrap around, beep or continue outside the group manually (bug #322640).