gtk apps reading accelerator keystrokes incorrectly with alternative keymaps

[Christopher Armstrong]

Binary package hint: gnome-control-center

This is a pretty strange and complicated interaction. I'm using an up-to-date Dapper installation.

1. My low-level keymap is set to dvorak (whatever that means). That is, when I installed Ubuntu I told it I want to use dvorak. My keyboard is physically qwerty. Both my Linux console and X are using dvorak by default.

2. Without adding any alternate keymaps to the keyboard selector applet, everything works fine.

3. When I *add the option* to switch to qwerty via my keyboard indicator applet (something I occasionally do when pair-programming with other people), all gtk apps (gedit, gtimelog, gaim) stop reading keyboard accelerators correctly: When I hit ctrl-q, the app does not try to quit, when I hit ctrl-l, it does not clear the screen, etc -- HOWEVER, when I hit *ctrl-'* (ctrl and single quote), it tries to quit. When I hit ctrl-n it clears the screen. single-quote happens to be where the "q" key is physically on my keyboard "n" happens to be where the "l" key is physically on my keyboard. Note that I didn't actually *switch* to qwerty here, I just added the option to my keyboard selector.

All other apps, for instance emacs, do not get my keyboard accelerators confused.

[didier (did447-deactivatedaccount)]

Same here on Edgy with french/english keyboards, in gedit:
CTRL Q is using CTRL A action (french keyboard layout is azerty, qsdf...).

in gtk/gtkkeyhash.c
_gtk_key_hash_lookup() returns both exact matches and matches with a different keyboard group (it seems to be a feature).

As gedit TextView window doesn't have a binding for CTRL+Q it catches the 'q -> a' entry from group 1, cf gedit/gedit-window.c:gedit_window_key_press_event(), and uses CTRL A binding.

#if 0 the partial match in _gtk_key_hash_lookup() or #if 0 the
gedit_window_key_press_event() fix it.

I don't understand the rational behind the partial match logic for keybinding, IMO it's confusing.

[Christopher Armstrong (radix)]

This remains annoying. Can someone at least verify that this bug is reported in the correct place?

[didier (did447-deactivatedaccount)]

Yes it is, cf.
Bug #23244 of which this one is a duplicate.
I haven't marked it as such because malone search ignores duplicates.

There's a gtk bug number, and there's a patch too at least for testing a saner (IMO) behavior both for latin/non latin and latin/latin, but no feedback from the gtk bugzilla.

I don't mind playing bozo the clown, but this time when I'll have to say that yes we can have multi layouts as in osx and windows but that accelerators are broken, ouch it will be a hard sell. As a matter of fact it could be the straw.

[Sebastien Bacher (seb128)]

marking as duplicate, the fact that the default query doesn't list duplicate doesn't mean a gtk+ duplicate should be kept open on control-center