gtkWidgetKeynavFailed signal on the widget and its return
value should be interpreted in a way similar to the return value of
gtkWidgetChildFocus:gtkWidgetKeynavFailed(object, direction)objectdirectionTRUE if stopping keyboard navigation is fine, FALSE
if the emitting widget should try to handle the keyboard
navigation attempt in its parent container(s).TRUE is returned, stay in the widget, the failed keyboard
navigation is Ok and/or there is nowhere we can/should move the
focus to.
When FALSE is returned, the caller should continue with keyboard
navigation outside the widget, e.g. by calling
gtkWidgetChildFocus on the widget's toplevel.
The default ::keynav-failed handler returns TRUE for
GTK_DIR_TAB_FORWARD and GTK_DIR_TAB_BACKWARD. For the other
values of GtkDirectionType, it looks at the
"gtk-keynav-cursor-only" setting and returns FALSE
if the setting is TRUE. This way the entire user interface
becomes cursor-navigatable on input devices such as mobile phones
which only have cursor keys but no tab key.
Whenever the default handler returns TRUE, it also calls
gtkWidgetErrorBell to notify the user of the failed keyboard
navigation.
A use case for providing an own implementation of ::keynav-failed
(either by connecting to it or by overriding it) would be a row of
GtkEntry widgets where the user should be able to navigate the
entire row with the cursor keys, as e.g. known from user interfaces
that require entering license keys.
Since 2.12