Fix my keyboard, fix your apps!
Many people still use their keyboard to navigate through their applications, despite they use a graphical environment like Gnome. People with disabilities (can we say a touchpad is a disability ?), or people used to use their keyboard, like you may be, and like I am. Anyway, parts of the Gnome environment are broken in that regard. Let’s have a look at two common mistakes that I find rather annoying, and, in my opinion, should really be fixed.
Let’s begin with the one which is, I guess, the most obvious one: widget cycling, or keyboard navigation. Here is what the Gnome HIG say about it:
- Tab, Shift+Tab
- Moves keyboard focus to next/previous control
- Ctrl+Tab, Shift+Ctrl+Tab
- Moves keyboard focus out of enclosing widget to next/previous control, in those situations where Tab alone has another function (e.g. GtkTextView)
User Input: Standard Application Shortcut Keys (Gnome HIG)
Please, ensure that one of those accelerators does actually work. This is a really important matter. In fact, these are the defaults, so it’s not that difficult indeed. The most obvious (and effective) way to do that is not to override the Tab key behaviour when possible, and, moreover, to never use Ctrl+Tab as an accelerator. If you use Tab, this includes checking that the mod mask does not contain the Ctrl key.
This one is more often broken than the previous one, and a bit more difficult to achieve.
When using keyboard, you usually show context menues using the Menu
key (the one beside the right Ctrl key). This fires a
signal for the currently focused widget. Thus All you have to do is catch this
signal and show the popup menu.
Next painful thing is where to position the menu, and it is in that regard that most applications are broken. Indeed, many applications show the context menu where the mouse is on the screen. This leads to weird situations:
Keyboard-triggered context-menu in gnome- terminal.
Mmmh, wait. Let’s remember… I was using my keyboard, wasn’t I? So where is my mouse? Well, I guess it’s out of sight, ‘cause otherwise it would probably annoy me. So, why the hell is the context menu positionned at the mouse location when I trigger it using my keyboard? It does not sound very logical, does it?
This can be done by having two different
gtk_menu_popup calls for both
menu-popup signals. The former is the simple one
event is the second argument of the handler):
gtk_menu_popup (GTK_MENU (context_menu), NULL, NULL, NULL, NULL, event->button, event->time);
The latter is a bit more tricky: you have to provide a GtkMenuPositionFunc to
position the menu according to the widget type. For instance, you want to show
the menu under the current selected row in a TreeView. There are two such
gedit-utils.c. Then you just have to invoke
gtk_menu_popup this way:
gtk_menu_popup (GTK_MENU (context_menu), NULL, NULL, menu_position_callback, widget, 0, gtk_get_current_event_time ()); gtk_menu_shell_select_first (GTK_MENU_SHELL (context_menu), FALSE);
And you’re done!
Please, I enjoin you to fix your apps with regards to this matter. I already sent a patch for xchat-gnome (which got in a few days ago), and I guess I could fill bugs for the apps I use, but it wouldn’t be sufficient. So, Gnomee people, please make me (and your keyboard-loving users) happy, please do :-) Maybe this might become a new Gnome Goal?