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 162726 - Multiple Latin layouts in XKB break keyboard shortcuts
Multiple Latin layouts in XKB break keyboard shortcuts
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkMenu
unspecified
Other Linux
: Normal normal
: Medium feature
Assigned To: gtk-bugs
gtk-bugs
: 126956 158902 171075 334155 337169 337751 399947 409469 412970 413311 418246 424623 536865 539796 540784 543163 547451 557445 563460 564633 568355 569554 571261 575616 575618 575620 577760 585977 595204 602865 606781 615975 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-01-02 15:50 UTC by Christian Persch
Modified: 2016-09-21 21:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
different behavior for keyboard bindings. (2.14 KB, patch)
2006-08-23 15:40 UTC, did447
none Details | Review
Screenshot of low-tech work-around (57.44 KB, image/png)
2008-06-25 02:12 UTC, Matt McHenry
  Details
Updated version of earlier patch which fixes Owen's comments. (2.87 KB, patch)
2008-12-06 18:07 UTC, Simos Xenitellis
none Details | Review
Checks if GTK_IM_SEPARATE_SHORTCUTS is set. (2.37 KB, patch)
2008-12-07 00:40 UTC, Simos Xenitellis
none Details | Review

Description Christian Persch 2005-01-02 15:50:22 UTC
Steps to reproduce:
0) Add French keyboard layout from GNOME Control Centre Keyboard capplet
1) Start testmerge
2) Press "Alt-F" (File)
3) Press "A" (which is not assigned to any item in the File menu, either as
accel or shortcut key)

Expected results:
Nothing.

Actual results:
Quit action is activated!

Note that Q activates the Quit action, and in the french keyboard layout, A is
where Q is in the english keyboard layout.

gtk+ from cvs HEAD 2005-01-02 15:30 UTC
Comment 1 Owen Taylor 2005-01-02 17:38:18 UTC
The reason GTK+ behaves this way is because the real use case for having
multiple layouts is languages like Greek, Hebrew, Russian, Arabic, where
the user switches back and forth between the two layouts frequently and
where the set of key symbols on the two layouts is distinct.

In that case, it's a big win for the user to be able to activate menu
items without having to switch keyboard layouts.

I don't know how to distinguish the "user fooled around with the keyboard
capplet" case.
Comment 2 Christian Persch 2005-02-02 14:18:56 UTC
The same thing also applies for shortcut keys: i.e. in an app where Ctrl-Q is
bound to Quit, and which has a text entry, pressing Ctrl-A in the text entry
(expected to select all text) quits the app instead! IMHO that's a serious
_data-loss bug_.

> I don't know how to distinguish the "user fooled around with the keyboard
> capplet" case.

Do you consider it illegitimate to have more than one keyboard layout installed?
IMHO it's not "fooling around" with the keyboard applet, but a basic task for
multilingual users.
Comment 3 Owen Taylor 2005-02-02 16:53:51 UTC
Having more than one latin layout installed is a corner case...
maybe you dont't have any trouble remembering that when you hit some
key on your keyboard all the keys move around, but I doubt that's
something we want to encourage in general.

(Presumably the use case you have is not French/English but
rather French/C. There should be no trouble typing English on
a French keyboard :-)
Comment 4 Tor Lillqvist 2005-02-02 16:59:04 UTC
except thqt so,e letter co,e out zrong::: 
Comment 5 Loïc Minier 2005-05-08 16:43:50 UTC
*** Bug 158902 has been marked as a duplicate of this bug. ***
Comment 6 Phil Hagelberg 2005-11-30 17:05:44 UTC
I've got the same bug with USA and USA-Dvorak. For instance, in Epiphany, Ctrl-F
open the find dialog, and Ctrl-U is View-source (needs an extension). I have
Dvorak as my default layout, and U in Dvorak is F in Qwerty. Pressing Ctrl-F in
Qwerty (which is Ctrl-U in Dvorak) opens View-Source, even though Ctrl-F is
bound to the find dialog in Qwerty.

(Same problem reproduced in Gnome-Terminal and Evolution with different commands.)

Ideally the solution to this instance would be to switch everyone away from
Qwerty to Dvorak, but since this bug also affects multi-lingual users that
cannot be the only solution. =D
Comment 7 Michael Leuchtenburg 2005-12-03 18:27:29 UTC
I also experience the same problem with QWERTY and Dvorak layouts. It's been
annoying me for a long, long time now. It is, in fact, the reason why other
people have to go through a lot of rigamarole to use my laptop in QWERTY instead
of just hitting both shift keys at once.

I don't know how I can convince you that there really are use cases other than a
Latin layout and a "Greek, Hebrew, Russian, Arabic" layout. Maybe that's your
use case, but it's very clear that there are other people who are using the
system differently. It's also clear that QWERTY is special-cased, since the
QWERTY bindings take precedence even though Dvorak is the default layout.

While I agree that, while in a layout like Arabic which doesn't have the latin
keys at all, it's desirable to continue being able to use bindings, it's also
clear that it's desirable to have things not be totally broken for people using
multiple Latin layouts.

I think that a good workaround until some better system can be put in place
could work simply and effectively for both use cases, though a mix of the two
will still cause problems. Just provide a gtkrc option, such as
hold_keyboard_bindings_across_keymap_change. If it's set, then the current
behavior will hold. If it's not set, then the behavior which every commenter in
this thread has requested will hold.
Comment 8 Owen Taylor 2006-04-04 13:12:37 UTC
*** Bug 337169 has been marked as a duplicate of this bug. ***
Comment 9 Andrew Conkling 2006-04-25 20:59:11 UTC
Another US/Dvorak user.

I'm baffled that having the keybindings persist when changing layouts is considered a "feature".  I can understand that a user may be confused if accidentally switching layouts, but I don't think it's GTK+'s job to handle that case; that should be the job of the app/GNOME/a keyboard applet.  Rather, I think that when the X layout changes, the keys should switch.  Seems simple enough.

I'm not sure what needs to be hashed out or brainstormed, but this is kinda broken at the moment....
Comment 10 Owen Taylor 2006-04-25 21:40:28 UTC
Folks, look, US/Dvorak is a tiny number of users compared to
all users of Russian, Arabic, Greek, etc. While the feature may
seem weird to you, it's really important for those users.

If someone wants to contribute to a fix, work with the XKB
developers to figure out a way that GTK+ can decide if a keyboard
layout is an alternate Latin layout or a second language.
Maybe it's as simple as iterating through the layout and looking
at what scripts are in it ... you'll find similar code already in
GTK+ for RTL/LTR layouts.

(If it's not clear, if you don't need *two* layouts... if you
don't need to switch between Qwerty and Dvorak on the fly, then
just configure the Dvorak layout and you won't have a problem)
Comment 11 Michael Leuchtenburg 2006-04-26 08:14:51 UTC
The folks using US/Dvorak and US/QWERTY aren't the only people having trouble with this. The original reporter was using US/QWERTY and FR/QWERTZ, from the sound of things. This affects everyone switching between two or more Latin layouts. The reporter of bug 158902 is another example of a non-Dvorak user having this problem.

Additionally, if you look at bug 337169, you'll see an example of an application becoming totally unusable because of this bug. This is not just a case of people having to deal with inconvenient keybindings - it's making it impossible for people to operate in certain obvious modes.
Comment 12 Simos Xenitellis 2006-04-26 17:59:31 UTC
As Owen mentioned, you need to ask the XKB developers for some insight on this.

For example, you could ask Sergey (http://cia.navi.cx/stats/author/svu).

Comment 13 Simos Xenitellis 2006-04-30 17:33:55 UTC
Some bug reports that show the other viewpoint; Firefox still does not accept, for example, Ctrl-C, when the current layout in Linux is Russian, Greek or something non-latin.
https://launchpad.net/distros/ubuntu/+source/firefox/+bug/22151
https://bugzilla.mozilla.org/show_bug.cgi?id=69230
The Mozilla report will lead to a big audience that is affected. Check the DUPs, the dependencies and the references to GTK+.

OpenOffice.org used to have this problem as well (i.e. Ctrl-C needs a C in the current layout in Linux to work), however it was fixed recently.
http://qa.openoffice.org/issues/show_bug.cgi?id=23836
http://qa.openoffice.org/issues/show_bug.cgi?id=42122

To sum up, add "svu" to this report to get some extra feedback.
Comment 14 Sebastien Bacher 2006-05-30 17:09:17 UTC
*** Bug 337751 has been marked as a duplicate of this bug. ***
Comment 15 Sebastien Bacher 2006-05-30 17:12:51 UTC
Ubuntu bug reported on gedit about that: https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/47399

"When I type ctrl+q in gedit, it selects all. According to the menus, it should quit. Select all is assigned to ctrl+a."
Comment 16 Eric Anderson 2006-06-09 18:49:08 UTC
I would say that the general feature may be okay, but it is certainly broken that a non-current keymap is able to steal the short-cut key combination. It might almost be acceptable if ctrl+q first tried the current keymap and then continued to other keymaps if that failed. This would fix most of the problems that people are having. The problem is that things like gnome-terminal send unknown key combinations to the terminal the console program to use.

Is there at least a way we can disable the feature?
Comment 17 Christian Rose 2006-07-04 18:23:50 UTC
Adding Sergey to the cc: list. Sergey, do you have any input on this and in particular comment 10 ?
Comment 18 Sergey V. Udaltsov 2006-07-05 21:32:56 UTC
I completely support Owen on this. As Russian, I really do hate Firefox for not handling Ctrl-C propertly (all Russians do, BTW - who are not using MSWin where this is handled properly). There is long outstanding bug in the mozilla's bugzilla about this bad behaviour. IMHO the proper shortcut handling should ignore the current group.
On the XKB side, there is no reliable way to detect "latin-based" layout but to walk through the keymappings and analyze the keysyms. May be, having configurable option, like Eric advised, could be a good idea (if it is cheap) - but I strongly insist that the default behaviour should be kept as it is now.
Comment 19 Andrew Conkling 2006-07-06 00:23:25 UTC
Sergey, the problem is that this behavior is inconsistent.  And for people that use different keyboards (Dvorak is the only one I know offhand), how are they to tell where the "default" keys are?  C is not in the same place on a US keyboard and a Dvorak one....

This is a complicated issue and there are a few intermediate workarounds, but I think we have yet to see a satisfactory solution.  The gtkrc one is the best one so far, IMO.
Comment 20 did447 2006-08-23 15:40:41 UTC
Created attachment 71469 [details] [review]
different behavior for keyboard bindings.


Hi,

In my understanding the problem is that the binding are layouts independent, ie on the keycode (the physical key), _only_ if the keyval (the symbol A ; ") is defined in one layout.

When the keyval is defined in many layouts (you can get this bug even with  latin/non latin layouts, on punctuations keys):

- If only one keyval has a binding both keycodes work. Sometimes it's a nuisance, for example in gaim with a french/english layouts CTRL Z close the window (the binding is on CTRL W). 

- If both keyvals have a binding then it's random and applications dependent.
Either bindings are layout dependent or one binding doesn't work at all. It's related to the way the widgets stack is set and from a user POV bindings are broken, when you start an application you can't tell what they do.

the patch attached uses the layout dependent binding and only this one when a keyval is defined in multiple layouts, ok not exactly but it's the idea.

So for a latin/non latin layouts punctuations key bindings are modified (but for a lot of layouts it doesn't matter because a lot of keyvals use the same keycode between layouts).
 
For a latin/latin layout the binding is always on the keyval.

This patch is only for testing and feedback.

Notes
same bug:
http://bugzilla.gnome.org/show_bug.cgi?id=171075

http://bugzilla.gnome.org/show_bug.cgi?id=343622

http://bugzilla.gnome.org/show_bug.cgi?id=110763

need to check
http://bugzilla.gnome.org/show_bug.cgi?id=136280

http://bugzilla.gnome.org/show_bug.cgi?id=103331
Comment 21 Sandy Armstrong 2007-02-10 19:27:57 UTC
*** Bug 171075 has been marked as a duplicate of this bug. ***
Comment 22 Sebastien Bacher 2007-03-01 10:02:30 UTC
*** Bug 412970 has been marked as a duplicate of this bug. ***
Comment 23 Sandy Armstrong 2007-03-01 21:43:46 UTC
*** Bug 413311 has been marked as a duplicate of this bug. ***
Comment 24 Alexander “weej” Jones 2007-03-02 00:47:10 UTC
This is an issue with having Dvorak and QWERTY enabled at the same time. Both are latin, and all hell breaks loose with some apps and keyboard shortcuts.
Comment 25 Alexander “weej” Jones 2007-03-13 02:24:45 UTC
This is enough of a usability disaster to stop me using two keyboard layouts. I really think the importance of this bug should be upgraded.
Comment 26 Christian Persch 2007-03-13 22:22:57 UTC
*** Bug 409469 has been marked as a duplicate of this bug. ***
Comment 27 Vincent Untz 2007-03-14 19:29:19 UTC
I don't think having two latin keyboard layouts is such a cornercase, and it's a big annoyance in this case. I'm pretty sure this can cause some data loss because a user will think the keybinding does an action while it actually does something else.

We really need to fix this (without breaking the current behaviour for Russian, Greek, Arabic, Japanese, etc.).
Comment 28 Christian Persch 2007-03-30 20:55:54 UTC
*** Bug 424623 has been marked as a duplicate of this bug. ***
Comment 29 Philip Withnall 2007-05-26 16:45:53 UTC
Patch 71469 applies cleanly. Reviewing it would take a little while.

(Working on http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html)
Comment 30 Vincent Untz 2007-06-17 15:47:59 UTC
*** Bug 418246 has been marked as a duplicate of this bug. ***
Comment 31 Matt McHenry 2007-08-22 03:34:23 UTC
I'm running gentoo with x11-libs/gtk+-2.10.13 and I see this bug in x11-terms/gnome-terminal-2.18.1.  I applied the patch in attachment 71469 [details] [review] to x11-libs/gtk+-2.10.13 and re-emerged (re-compiled) both it and gnome-terminal.  Unfortunately it doesn't seem to have fixed the problem.  (Using US-Qwerty and US-Dvorak layouts, shortcut keys in dvorak still behave like they're qwerty.)

If anyone has any further patches, I'd be happy to try them.
Comment 32 Jan Schmidt 2007-08-22 09:08:09 UTC
Like Matt, I am using gnome on gentoo, x11-libs/gtk+-2.10.13. The patch applies fine, sources compile, and the patch indeed changed the behavior. Keyboard shortcuts now only work from the currently chosen layout. So for me, working with two latin layouts in parallel is possible now. (Matt: I experienced that after remerging gtk+ with the patch applied you have to close all running gnome-terminals and then start a new one to make gnome-terminal load the new libgtk-x11-2.0.so.0.)

Anyway, I agree this must be fixed in general, without breaking the current features. In my opinion, the best way would be a config option (check box for the user) like "try other keyboard layouts when resolving shortcuts? (y/n)". That way, users mixing latin and non-latin layouts could choose Y to keep the current behavior, users using multiple latin layouts would choose N instead.
Comment 33 Matt McHenry 2007-08-23 02:33:54 UTC
I quit entirely out of gnome (back to gdm) after recompiling the first time.  I just tried again, this time doing the entire compilation while both X & gdm were shut down.  It's still not working.

Jan, what keyboard layouts are you using?  Something other than us-qwerty and us-dvorak?

It's been too long since I've done any C programming ... does anyone have any suggestions about how I can determine whether (a) I've failed to apply the patch somehow, (b) gnome-terminal isn't using the version of libgtk-x11 that I recompiled, (c) the patch itself isn't working for some reason, or (d) something else that I haven't thought of is going wrong?
Comment 34 Jan Schmidt 2007-08-27 06:38:57 UTC
I'm using us-qwerty and de-qwertz (german).

(a) emerge -av x11-libs/gtk+ (make sure you are remerging some 2.x version!), wait until emerge applies its patches, press ctrl+z, cd to working dir, patch -p1 < path/gtkkeyhash.c.binding.patch, fg
(b) ldd `which gnome-terminal` | grep gtk
Comment 35 Bert Van Vreckem 2007-09-29 18:24:11 UTC
(In reply to comment #27)
> I don't think having two latin keyboard layouts is such a cornercase, and it's
> a big annoyance in this case.
<snip>
> We really need to fix this (without breaking the current behaviour for Russian,
> Greek, Arabic, Japanese, etc.).

Hear, hear.

I prefer qwerty, but where I live, you can only buy laptops with belgian azerty layout. That's why I attach an external qwerty keyboard to my laptop when I'm working at home.

When I use my external keyboard, some applications (OpenOffice.org, Firefox, e.g.) behave as expected, but in native Gnome apps like Nautilus or Evince, I have to press CTRL-Z to close windows (instead of CTRL-W) and CTRL-A to quit (instead of CTRL-Q).

I appreciate that the behaviour is preferable for the use cases mentioned above, but please appreciate that in MY (and other people's) case, it is not. Why not make this configurable? 

Oh yes, this is Gnome. It would probably "confuse users"... ;-) As if having to press CTRL-Q in one application and CTRL-A in another for the same basic functions is not...
Comment 36 Myk Melez 2007-11-15 01:07:13 UTC
Mac OS X 10.5 provides both options to their users.  For a number of layouts, including some Latin ones, you can choose either a version that uses qwerty shortcuts or one that doesn't.  Layouts for which Mac OS X provides both options include Czech, Dvorak, Gujarati, Hebrew, Slovak, and Turkish.

If I recall correctly, earlier versions of Mac OS X provided one only layout per language but had a separate checkbox for specifying that you wanted to use qwerty shortcuts with all layouts.

Windows XP provides similar functionality, with qwerty shortcut versions of the layouts for Czech, Slovak, and Latvian, although they don't provide one for Dvorak, and most layouts have no qwerty shortcut version.

I appreciate that perhaps many users want to always use one layout's shortcuts even when they are typing in another layout, but there are clearly some (perhaps many, given the presence and prevalance of this option in other OSes) users who want different behavior, and given that you can do it without compromising usability for the rest, it seems worth accommodating that second set of users.
Comment 37 Jan Claeys 2007-11-26 04:11:50 UTC
Launchpad currently has 17 duplicates of the first report of this bug in Ubuntu, so it's obviously not that uncommon for people to use multiple latin layouts...
Comment 38 Andrew Conkling 2008-01-31 22:15:43 UTC
*** Bug 126956 has been marked as a duplicate of this bug. ***
Comment 39 Matthias Urlichs 2008-01-31 23:22:18 UTC
If nothing else, this is a gnome-specific hack. On affected systems, Gnome programs behave unlike *any* other program.

This breaks user expectations. In a big way. And yes, it can (and does!) cause data loss.

Keyboard mapping hacks belong in the keymap! If you _really_ think that this feature makes sense, the _correct_ place for it is the X server.

So, to reiterate: SOMEBODY PLEASE REMOVE THIS MISFEATURE.
Comment 40 Mikhail Zabaluev 2008-02-01 09:29:18 UTC
(In reply to comment #39)
> Keyboard mapping hacks belong in the keymap! If you _really_ think that this
> feature makes sense, the _correct_ place for it is the X server.

I second that. Also, the bug summary understates the extent of the problem, it's really about inconsistency between xkb and Gdk input in any keyboard layout except US QWERTY.
Comment 41 Michael Leuchtenburg 2008-05-06 06:04:46 UTC
This bug also appears in the Windows version of Gtk, as can be seen in the current Inkscape win32 build.

To duplicate:
* Set up Windows XP with both QWERTY and Dvorak US layouts
* Install Inkscape 0.46
* Use a shortcut, e.g. Ctrl+Z

This bug - for it is no feature request, that categorization is wrong - is enough of a usability issue that I'm seeking to replace all of my Gtk apps.
Comment 42 Tor Lillqvist 2008-05-06 06:26:09 UTC
Michael, please don't mix in Windows issues in this bug. The code paths for Win32 and X11 keyboard handling are completely separate in GDK. This bug explicitly talks about X11 as far as I can see.
Comment 43 Balazs Scheidler 2008-05-15 08:59:31 UTC
I usually use English keyboard when I work, and use Hungarian when I need to write something in Hungarian. Don't expect me to use Hungarian when typing C code, even a ';' is accessible only via Alt Gr in the Hungarian layout.

So switching keyboards (in this sense multiple latin keyboards) is a must for me too.

Comment 44 Gabriel de Perthuis 2008-05-15 09:38:57 UTC
Ah, now I know where this comes from.

Mixing Ctrl-A and Ctrl-Q causes data loss, forces me to unlearn keyboard mappings, and is generally stressful. Just remove that “feature”.
Comment 45 Yevgen Muntyan 2008-05-15 18:39:38 UTC
(In reply to comment #44)
> Ah, now I know where this comes from.
> 
> Mixing Ctrl-A and Ctrl-Q causes data loss, forces me to unlearn keyboard
> mappings, and is generally stressful. Just remove that “feature”.

You should try typing something in Russian, and then find the latin letter C on keyboard, to copy some text. After you fail to find that latin letter, you might start understanding why this "feature" is actually a feature.
Comment 46 Bert Van Vreckem 2008-05-15 19:37:51 UTC
Okay, so for some users, the current behaviour of Gnome makes sense, for others it doesn't. Then please make it an option!(In reply to comment #45)
> (In reply to comment #44)
> > Ah, now I know where this comes from.
> > 
> > Mixing Ctrl-A and Ctrl-Q causes data loss, forces me to unlearn keyboard
> > mappings, and is generally stressful. Just remove that “feature”.
> 
> You should try typing something in Russian, and then find the latin letter C on
> keyboard, to copy some text. After you fail to find that latin letter, you
> might start understanding why this "feature" is actually a feature.

Okay, so for some users, the current behaviour of Gnome makes sense, for others it clearly doesn't. Then please make it configurable!
Comment 47 Gabriel de Perthuis 2008-05-15 22:03:18 UTC
Let me summarize how we can handle shortcuts:

1. Use the current layout, fallback on others (the attached patch 71469). Acceptable although this means secondary layout can sometimes affect the first. This has a slight confusion potential for people who often switch.

2. Use the other layout, ignore current (preferred for some locales cited here, Russian, Arabic and so on).

3. Find shortcuts in order (both Ctrl-A and Ctrl-Q close tomboy and gedit for me). Non-deterministic and worse than any other behaviour, but this doesn't break those locales. Current behaviour.

4. Only use current layout (preferred for French, German, USA-Dvorak, and others).

5. Make it configurable.

Making it configurable seems the best choice, since the preferred choices for two classes of users (2. and 4.) are incompatible. Apparently XP and OSX handle it, though they don't make it too visible.

1. is a good choice for now, and I don't understand why it hasn't been applied (lack of review, ineffective according to comment 31?).

-- -- --

Now on to discussing a “perfect” solution.

The current behaviour seems to be a layering violation; gtk+ is getting keys from xkb, and is deciding what the user “really means” from those keys. gtk+ will disagree with plain applications that follow xkb behaviour.

Now, on to the ways to make it configurable:
It has to be done via xkb, with gtk's help if xkb isn't enough (and someone has a really good reason the layering violation is warranted).
Behaviour could be: ShortcutsFromLayout, ShortcutsFromQwery, ShortcutsFromAlternative. ShortcutsFromAlternative, although it matches more closely option 2. above, is weird behaviour as it will depend on whatever the alternative layouts are, and there can be several. XP and OSX seem to get away with ShortcutsFromQwerty, which is a semantically simpler solution (I don't really know about xkb implementation complexity).

I'm not too clear on xkb rules/semantics/options/keymaps… so I'll just call these things settings. Xkb needs a new setting for this.
It could be a setting kept with layouts, a user-configurable setting, or both. Sensible defaults plus user override would be best, but I don't want to do bike-shedding here because either works.

( I hope I didn't oversimplify anything, I'm trying to factor those requirements into an acceptable solution. I'd create a bug against xkeyboard-config / xkb, but I haven't been able to get a login. )
Comment 48 Gabriel de Perthuis 2008-05-15 23:23:28 UTC
Xkb bug: https://bugs.freedesktop.org/show_bug.cgi?id=15948
Comment 49 Mikhail Zabaluev 2008-05-16 12:21:43 UTC
(In reply to comment #45)
> You should try typing something in Russian, and then find the latin letter C on
> keyboard, to copy some text. After you fail to find that latin letter, you
> might start understanding why this "feature" is actually a feature.

Just to clarify: on most Russian keyboards I've been able to get my hands on,
The US and Russian layouts are both labeled on the keys. If you need to _look_ at the keyboard to find the Latin letter, it's there (in case of C, it even shares the key with the Russian letter of same appearance).
Conversely, when you've developed the muscle memory to press Ctrl-C in the US layout, you don't really want a different muscle memory for the Russian layout. Ctrl-C doesn't change binding in the Russian layout on Windows, it doesn't change generally in Xkb, it's only GTK+ that's out on a limb.
Comment 50 Sandy Armstrong 2008-06-02 20:09:26 UTC
*** Bug 413311 has been marked as a duplicate of this bug. ***
Comment 51 Sandy Armstrong 2008-06-05 20:28:04 UTC
*** Bug 536865 has been marked as a duplicate of this bug. ***
Comment 52 Christian Persch 2008-06-23 18:56:52 UTC
*** Bug 539796 has been marked as a duplicate of this bug. ***
Comment 53 Alexander “weej” Jones 2008-06-24 11:31:32 UTC
This is actually stopping me from learning Dvorak, since when I switch back to QWERTY, I am scared of hitting ^Explode when I actually pressed ^S. How hard would it be to make this behaviour a GtkSetting?
Comment 54 Christian Persch 2008-06-24 18:52:43 UTC
*** Bug 399947 has been marked as a duplicate of this bug. ***
Comment 55 Matt McHenry 2008-06-25 02:12:43 UTC
Created attachment 113377 [details]
Screenshot of low-tech work-around

I wanted to let everyone know about an easy, low-tech work-around for this bug that I should've thought of a long time ago.

This is based on the idea of using aliases for setxkbmap, which I think I first read about in this slashdot comment: http://ask.slashdot.org/comments.pl?sid=1594&cid=1633166

To make it more user friendly, I just defined custom application launchers for the two setxkbmap commands.  I kept the keyboard indicator applet next to the launchers in the panel to display the currently-selected layout, but clicking on it doesn't do anything (which is fine -- less confusing that way).  For me, this is almost as functional as the keyboard indicator applet with two layouts configured used to be before this bug was introduced.  Hopefully it'll help out others who're trying to avoid this bug but maintain the ability to switch between layouts with a single mouse click.
Comment 56 Martin Smith 2008-06-27 15:19:38 UTC
It seems quite silly to allow key mappings from an inactive layout to cause an effect. It's inactive! I understand the other side, but come on, you're asking for a setting to NOT be disabled when I try to disable it.

Please fix it -- I'm another user with multiple latin layouts.
Comment 57 Andrew Conkling 2008-06-28 00:53:43 UTC
(In reply to comment #48)
> Xkb bug: https://bugs.freedesktop.org/show_bug.cgi?id=15948

So it's apparently not an Xkb bug: https://bugs.freedesktop.org/show_bug.cgi?id=15948#c1
"xkeyboard-config has nothing to do with it. neither xorg. The apps/toolkits get
notifications about both keycodes and keysyms (and modifiers and groups etc).
The rest is up to them. If some key produces letter S with group 1, and some
other key produces letter S with group 2 - xkb can do nothing with the app
looking for the symbol S but not for the keycodes.

"AFAIK gtk does not do any bad hacks - it correctly(!) just looks through all
the symbols in all groups of the pressed key."

So whose bug is this?
Comment 58 Sergey V. Udaltsov 2008-06-28 01:07:21 UTC
There is no clear "bug" here. There are different approaches, suitable for different user groups. The current gtk approach, as I said in fd.o's bug, is good for me (and other Russians and other people using "some latin + some non-latin" configurations). But it can be problematic for users who are using several latin layouts (though I would say it is quite exotic use case IMVVVVHO).
Comment 59 Matt McHenry 2008-06-28 02:01:44 UTC
In this bug, the "two latin layouts" camp is pretty clearly outweighing the "latin + non-latin" camp.  While I know it's a skewed sample because of the nature of this bug (latin+non-latin is probably still in the majority among users at large), it *is* evidence that two latin layouts is not as much of an "exotic use case" as some comments in this bug claim.

In favor of changing behaviour to support two latin layouts (unique users only):
comment 0, comment 4, bug 158902, comment 6, comment 7, bug 337169, comment 9, bug 337751, comment 15 (ubuntu bug), comment 16, comment 20, bug 171075, bug 412970, bug 413311, comment 24, bug 409469, comment 27, bug 424623, comment 31 (me), comment 32 (gnome bugs), comment 35, comment 36, comment 37 (17 ubuntu bugs), bug 126956, comment 39, comment 40, comment 43, comment 44, bug 413311, bug 536865, bug 539796, bug 399947, comment 56

In favor of existing behaviour to support latin + non-latin (unique users only):
comment 1, comment 18, comment 45

(Apologies to anyone whose comments I've mis-classified.)
Comment 60 Matthias Urlichs 2008-06-28 05:21:46 UTC
>> quite exotic use case

Well, apart from anything else, using Dvorak or whatever with gtk is going to *remain* a pretty exotic use case (as opposed to, say, using Dvorak with KDE)
until this problem is fixed.

... and I might note that typing with Dvorak (or whatever) is significantly faster. Not to mention less error-prone, and less taxing on the hands.
Comment 61 Sebastien Bacher 2008-06-28 09:04:05 UTC
> In favor of existing behaviour to support latin + non-latin

you can't count this way, why users who have no issue would come on the bug tracker looking for a bug about an issue they don't have and comment?
Comment 62 Owen Taylor 2008-06-28 12:06:10 UTC
If you want to see this bug fixed, should you?

 A) Try out the patch in comment #20 and/or work on improving it

 B) Complain about how your keyboard setup is more important than other
    people's keyboard layouts, and how we should break other people's
    layouts to make your keyboard layout work.

The patch in comment #20 also needs testing in the Russian, etc, case.
My main concern with the described approach would be a punctuation key that:

 A) In a prominent place in the Latin layout
 B) In an obscure place but still accessible in the non-Latin case

Mostly, however, I wouldn't expect punctuation to move.

My comments on the patch:

 - lookup_result_compare_by_keyval is not a valid GCompareFunc, while
   it might work here, the code would be easier to understand if
   it was just the normal -1,0,1 result

 - The code really needs more comments; it took me a long time staring at
   it to realize the point of sort_lookup_results_by_keyval() and 
   then iterating through the reslts was to test each keyval 
   in the result list only once.

 - OR, I'm not sure that the care to test each keyval only once is
   necessary. Multiple results aren't going to be very common, more
   than two results would be exceedingly rare.

 - A few coding style problems (entry => ent abbrevation, some of the
   indents look wrong)

But the patch looks like it should work fine for testing the proposed
approach.

And yes, people don't report bugs about things that work nicely for them!
Comment 63 Sergey V. Udaltsov 2008-06-28 13:36:39 UTC
I offer my apoligies to anyone who felt offended by the "exotic" word. But, as some people pointed earier, the statistics here is totally useless. And Dvorak can be used with gtk - just don't mix it with other latin layouts (why would you need them anyway, if Dvorak is so good?)

I think flexibility in that point would be great. But I am strongly convinced the default behaviour should remain as it is now.
Comment 64 Matthias Urlichs 2008-06-28 16:49:09 UTC
"just don't mix it with other latin layouts" sounds nice, but this is not how the real world works (for some tasks, you simply do need a standard layout), and that's not how non-GTK applications work.

The current default behavior may be the Right Thing for many people. If so, it needs to be implemented in a way that's consistent and controllable(!) across toolkits, without putting the people for whom it's eminently _not_ right at a disadvantage.

The fact that an additional but 'inactive' keyboard layout in my setup impacts the layout of control-character combinations (but *not* control+shift!) is ... somewhat non-intuitive. To put it _very_ mildly.
Typical user reaction (mine, for instance) is more along the lines of "Where the h*ll did my work just go?" followed, after looking closer, by "Bl*ddy idiots!"

I'll test the patch in comment #20 tomorrow; sorry, that seems to have escaped to the labyrinths of my email folders.
Comment 65 Sergey V. Udaltsov 2008-06-28 17:18:17 UTC
> for some tasks, you simply do need a standard layout
That's really interesting point. Is that some kind of usability issue with Dvorak layout? Should it be fixed? If so, we could open discussion @ fd.o bugzilla, trying to add missing mappings to Dvorak layout. And may be many people would be able to use one layout instead of two.

Could you please elaborate more on this?

> If so, it
needs to be implemented in a way that's consistent and controllable(!) across
toolkits, 
I would wholeheartedly agree but ... Unfortunately, I do not see how to approach this. Apps/toolkits are using (xlib + xkb API), which (being rather low-level) allow different approaches to the shortcuts implementation.
Again, if you want it cross-DE, cross-toolkit, it can be raised in xdg@fd.o maillist.

>To put it _very_ mildly.
I understand that. I guess, the fundamental difference is in the perception of the keyboard configuration. We (Russians) consider it ... holistically, if you like:) So even inactive US layout is an essential part of the context. So there is no "cognitive dissonance" for us in the current solution. Sure we are not in position to think that everybody should feel the same.
Comment 66 Myk Melez 2008-06-28 21:00:46 UTC
(In reply to comment #63)
> just don't mix it with other latin layouts (why would
> you need them anyway, if Dvorak is so good?)

Among other things, to enable other people to type on your computer when they want to show you something or are working together with you.


> I would wholeheartedly agree but ... Unfortunately, I do not see how to
> approach this. Apps/toolkits are using (xlib + xkb API), which (being rather
> low-level) allow different approaches to the shortcuts implementation.
> Again, if you want it cross-DE, cross-toolkit, it can be raised in xdg@fd.o
> maillist.

Per comment 36, both Mac OS X and Windows have figured out how to offer both behaviors to their users.  It's hard to imagine this couldn't be solved for gtk+ too.
Comment 67 Matt McHenry 2008-06-28 21:54:06 UTC
I think Myk is exactly right.  It seems to me that what X and/or GTK call a "layout" is not what OS X and Windows call a "layout".

In OS X and Windows, "layout" means "how does the machine interpret my keystrokes".  It determines how *both* unmodified and modified key strokes are interpreted.  If you want your keystrokes (modified or unmodified or both) interpreted differently, you switch to a different layout.  The fact that you've configured things so that you can quickly switch to another layout has no impact whatsoever.  I would argue that this is what most users expect.

In this scenario, there is a single "layout" that means "interpret my keystrokes as Russian when no modifier key is pressed, but as QWERTY when a modifier is pressed".  There might also be a layout that means "interpret my keystrokes as Russian regardless of whether a modifier key is pressed", but it sounds like that's not very useful.  However, the analogous "interpret my keystrokes as Dvorak when no modifier key is pressed, but as QWERTY when a modifier key is pressed" and "interpet my keystrokes as Dvorak regardless of whether a modifier key is pressed" *are* both useful.

In GTK, the answer to "how does the machine interpret my keystrokes" is much more complicated.  "Layouts" in this world are more low-level, and user-visible behaviour results from interactions between the active layouts that are at times non-intuitive (and not at all obvious from the Keyboard Preferences dialog).

So I think the X-windows notion of a layout is really just an implementation detail, and it ought to be hidden from users.  What users care about is how their keystrokes are interpreted (with and without modifier keys).  They should not have to worry about the fact that multiple X-windows layouts may need to be configured "under the covers" in order to get their keystrokes interpreted the way they want.

I don't know enough about xlib+xkb, GTK, etc. to say whether X ought to be hiding this implementation detail from GTK, or whether GTK ought to be hiding it from users, or some combination thereof.

ps - thanks to the devs for continuing to listen and for trying to understand the needs of us crazy Dvorak users.  ;-)
Comment 68 Sergey V. Udaltsov 2008-06-28 22:21:37 UTC
> It's hard to imagine this couldn't be solved for gtk+ too.

Of course it can - as long as we talk about gtk only (and properly written gtk apps). My point was that solving it for all toolkits in X at once is virtually impossible.

> So I think the X-windows notion of a layout is really just an implementation
detail, and it ought to be hidden from users

You are definitely wrong. Low-level implementation details are "symbols". Layouts are high-level. And when I am choosing 2 layouts (USA + Russia) I mean I want to have 2 relatively independent layouts, switched using <some shortcut specifed in xkb options>.

Regarding other platforms, FWIW, there was an open bug against Firefox/Linux to make its behavior same as gtk now. And in Firefox/Win there never was such problem: Ctrl+S works as "Save" even if current layout was Russian (there is no letter S in Russian, that key is mapped to Russian Ы).

Anyway, I think we should stop discussing whether these 2 behaviours are needed or not. My understanding is that we all agree it would be nice if gtk would be flexible enough to support both. I think it's a matter of the proper implementation now...
Comment 69 Adam Lindberg 2008-06-29 12:27:29 UTC
I would like to add a common use case for me (and I suppose other Dvorak users):

When working several people on a computer, it is sometimes handy to alternate keyboard usage. In this case, working with a non-Dvorak person, it's really handy to just being able to click the keyboard switching applet to switch layout. Thus, this is the Dvorak + latin use case.

Saying "why would you need them anyway, if Dvorak is so good?" is just ignorant bashing.
Comment 70 Christian Persch 2008-06-29 17:14:27 UTC
*** Bug 540784 has been marked as a duplicate of this bug. ***
Comment 71 Matt McHenry 2008-06-29 22:35:09 UTC
(In reply to comment #65)
> > for some tasks, you simply do need a standard layout
> That's really interesting point. Is that some kind of usability issue with
> Dvorak layout? Should it be fixed? If so, we could open discussion @ fd.o
> bugzilla, trying to add missing mappings to Dvorak layout. And may be many
> people would be able to use one layout instead of two.
> 
> Could you please elaborate more on this?

One example is some two-player games that use the arrow keys for movement.  Since there's only one set of arrow keys, the second player's movement keys are usually bound to some cluster on the left side of the keyboard, e.g. W, A, S, and D for up, left, down, and right.  On the Dvorak layout, those keys are of course not in the same places so it's hard/impossible to use them as movement keys.  (Ideally the game would allow you to configure the keybindings, but not all of them do.)
Comment 72 Andrew Conkling 2008-06-30 16:05:50 UTC
(In reply to comment #65)
> Could you please elaborate more on this?

Please, let's curtail the discussion about defending the various use cases in the interest of keeping non-bug-related discussion to a minimum.
Comment 73 Christian Persch 2008-07-15 20:54:39 UTC
*** Bug 543163 has been marked as a duplicate of this bug. ***
Comment 74 André Pirard 2008-07-27 10:20:47 UTC
I'm copying here my diverging comment to the following Ubuntu bug report
https://bugs.launchpad.net/gnome-terminal/+bug/204202/comments/8
https://bugs.launchpad.net/gnome-terminal/+bug/204202
that has been linked to a duplicate of this one :-)
It's up to you to decide
- if my report may follow that path and stay here
- or if a new Ubuntu or Gnome bug must be opened

Similar but different Ctrl key fight worth mentioning.
On 8.04.1, I configured kbd pair : RU Winkeys + UK International.
(added them and removed first (system's UK (plain)))
If you're asked why I do that in Belgium, reply Ubuntu.
Default is 0 = RU. Layout switcher set to Shift+Alt (like Windows).

Problem with gnome-terminal only (other apps OK with Ctrl):
- When Shift+Alted to RU, Ctrl-anything does nothing.
- When Shift+Alted to UK, Ctrl-char types the sticker's RU character.
That is, Ctrl acts like a layout "push" switch, temporarily.
But that's only in UK mode.
And I have searched in vain for a description of such a feature.

Workaround:
I swapped the two layouts, making them UK,int + RU, Win.
Default is 1 = RU now.
And everything works as expected.

Надеясь, это поможет. Спасибо.

André.
Comment 75 Simos Xenitellis 2008-07-27 12:00:56 UTC
Andre, that issue is probably an xkeyboard-config issue, or an Xorg issue. In either case, it's the Freedesktop Bugzilla.

See https://bugs.freedesktop.org/show_bug.cgi?id=13277#c102
for a relevant issue (the user has three layouts, and switching works depending on the order of the layouts). This has not been reported yet as a bugzilla report at FDO (FreeDesktop.Org).
Comment 76 Stefanie 2008-07-30 13:01:40 UTC
The current default behaviour seems to be buggy. I have two layouts, azerty and dvorak. 

When i select dvorak and press ctrl-L in firefox, the print window opens = azerty shortcut (dvorak L = azerty/qwerty p). But when I press ctrl-N (dvorak N = azerty/qwerty L), a new window opens = dvorak shortcut

Same goes for other applications. Some shortcuts work like qwerty/azerty-shortcuts, other ones like dvorak ones. Because of this some shortcuts aren't available (eg ctrl-l in firefox). 

I understand that the default behaviour could be useful. I wouldn't mind if EVERY shortcut were azerty/qwerty, but the current situation is driving me crazy. 

Isn't there a patch which makes sure the behaviour is consistent? 
Comment 77 Simos Xenitellis 2008-07-30 13:30:50 UTC
(In reply to comment #76)
> The current default behaviour seems to be buggy. I have two layouts, azerty and
> dvorak. 
...
> Isn't there a patch which makes sure the behaviour is consistent? 
> 

There is a patch-"work-in-progress".

See Bug 162726#c62 or comment #62 at this report.
Comment 78 Trevor Bergeron 2008-08-06 18:00:16 UTC
This thread is infuriating.
If people need it both ways, make it so it can be used both ways.
A checkbox. A dropdown box to select the keymap to copy shortcuts from. A boolean or text variable in gtkrc or the like. There are many ways, so pick one and do it.

Stop saying that either way is better, correct, or incorrect! Neither should require a hackjob workaround or manually applied patch to work correctly.

For a more automatic solution, there must be a way to determine whether a keymap is latin or not and change behavior based on that.
Comment 79 Tommy McGuire 2008-08-12 21:18:05 UTC
*** Bug 547451 has been marked as a duplicate of this bug. ***
Comment 80 Rob klein Gunnewiek 2008-09-02 15:35:55 UTC
I agree totally with Adam Lindberg.

I'm a dvorak user myself. I use it at home, and at my job. It's really frustrating when some colleague briefly wants to show you something in the terminal, and getting very frustrated because his Control+D doesn't work, or he cannot escape from Telnet.

I think the behaviour should be configurable. I am really surprised by the 'as-long-as-it-works-for-most-people attitude, that some people show here. You people basically say Dvorak/Qwerty switching is not a valid use case. Then do you also believe A website isn't broken when it cannot be viewed other than with MS IE?
Comment 81 Mikhail Zabaluev 2008-09-02 16:41:30 UTC
Forgive my ignorance about XKB and keysyms (In reply to comment #67)
> I think Myk is exactly right.  It seems to me that what X and/or GTK call a
> "layout" is not what OS X and Windows call a "layout".
> 
> In OS X and Windows, "layout" means "how does the machine interpret my
> keystrokes".  It determines how *both* unmodified and modified key strokes are
> interpreted.  If you want your keystrokes (modified or unmodified or both)
> interpreted differently, you switch to a different layout.  The fact that
> you've configured things so that you can quickly switch to another layout has
> no impact whatsoever.  I would argue that this is what most users expect.

I wholeheartedly agree. Whatever layer in this overengineered keyboard event transformation stack (I personally think the bulk of "overengineeredness" comes from XKB) is responsible for breaking this concept of independently treated layouts, needs to be fixed. The gtkrc hack may be only a cure for symptoms, not for the core problem.
Comment 82 Egmont Koblinger 2008-09-15 15:08:33 UTC
I was also shocked by this behavior after my recent software upgrade.  I'm regularly switching between English and Hungarian, and nowadays experimenting with the Colemak alternative, as well as made up a Hungarian Colemak for myself, that's 4 latin layouts.  Eventually I want to change to Colemak, which obviously implies that I have to get used to the new location of the shortcuts, too.  Using a "normally Colemak, but Qwerty if Ctrl is pressed" layout is just not an option.

Please remember that very few people actually use either a GTK/Gnome-only desktop, or a "No GTK at all" desktop.  Nearly everyone I've seen uses at least one or two KDE apps inside a Gnome desktop, or Gnome apps inside KDE desktop, or plain xlib / whichever other toolkit apps in Gnome, or Gimp under fluxbox etc...  The worst side effect of this "feature" is inconsistency.  I switch to Colemak and press Ctrl+whatever, the shell inside gnome-terminal and xterm behave differently, as they received different input.  What???  This is just totally unacceptable.  (Yep, I'm looking at the behavior of my whole complete system, not just the behavior of Gnome.)

I perfectly understand the goal of this feature.  However, I'm pretty sure that GTK is not the right level to solve this problem.  It needs to be addressed in a lower level (e.g. xlib) so that it effects all the applications.  (But wait... isn't it just a matter of having the right xkb config files? Isn't it possible to simply define an xkb layout that is, for example "russian by default but english qwerty if Ctrl is held" on its own?)
Comment 83 Mikhail Zabaluev 2008-09-15 16:01:10 UTC
(In reply to comment #82)
> isn't it just a matter of having the right xkb config files? Isn't it
> possible to simply define an xkb layout that is, for example "russian by
> default but english qwerty if Ctrl is held" on its own?

I believe it needs to be done this way, if not already. XKB variants could be used to alter behavior of Ctrl's, if necessary.
Comment 84 Christian Persch 2008-10-09 14:43:49 UTC
*** Bug 334155 has been marked as a duplicate of this bug. ***
Comment 85 Jonh Wendell 2008-10-22 16:53:57 UTC
*** Bug 557445 has been marked as a duplicate of this bug. ***
Comment 86 Marian Such 2008-10-23 09:04:49 UTC
I would like to ask, this bug has been reported more than 3 and half years ago.
It has been confirmed and annoying ever since. I would like to ask whether there is any prospect of fixing this.

Best regards
Marian Such
Comment 87 Pouya Tafti 2008-10-25 15:10:13 UTC
As someone who does use a non-Latin layout (Persian) in addition to Latin layouts, I also find this misfeature extremely non-intuitive, confusing, and generally problematic.  Please *at the very least* make it configurable!

(In fact, I fail to see how re-interpreting key strokes that have been *intentionally* remapped would be the Right Thing to do.  But even if it were, why not at least give people who want to be able to disable inactive layouts the option to do so?)

Thank you,
Pouya Tafti
Comment 88 wildemar 2008-12-01 21:25:54 UTC
I use both the German and the German Dvorak layout and I find very erratic behavior within Gnome. I will not go into detail, because it has been described in extenso in the preceding messages. I would hereby like to express my wish for the proposed configurability of this feature. I would very much appreciate it, as it would make my experience with GTK-Apps, and esp. Gnome, much more predictable and consistant.
Comment 89 Christian Persch 2008-12-06 15:28:38 UTC
*** Bug 563460 has been marked as a duplicate of this bug. ***
Comment 90 Simos Xenitellis 2008-12-06 18:07:00 UTC
Created attachment 124062 [details] [review]
Updated version of earlier patch which fixes Owen's comments.

I made the changes that Owen mentions in an earlier comment to Patch 71469.

I confirm that with the patch, if you have a qwerty layout and other layouts such as azerty, dvorak, then they shortcuts only work according to the currently active layout.

As mentioned already, if you are, let's say, a Dvorak user, you can simply have a single Dvorak layout enabled, and you do not need any patch.

It appears that the existing functionality will remain the default, and the proposed functionality will be able to be enabled on demand. 

One way to enable the proposed functionality on demand could be set an environment variable in /etc/environment (for example GTK_SHORTCUTS_ON_LAYOUT)
and let the users restart. Would such a thing be acceptable, at least as a short-term solution?

Another way to enable the proposed functionality on demand would be to have an option in the Keyboard Indicator Applet (just like OS/X, Windows? have). 
In this case, how would the Keyboard Indicator applet be able to set the setting? 
Would it be a case of setting an environment variable? What's the account-wide equivalent to the system-wide /etc/environment?
Comment 91 Egmont Koblinger 2008-12-06 21:29:49 UTC
Simon,

Thanks very much for taking on this problem!

An env var is better than nothing (and might do it as a short term solution), but very far from ideal. You can't modify a process's env var after it has been started, and there's no standard way of storing per-user env vars. (I'm not even sure that /etc/environment is absolutely standard.) Per-user env vars are usually set in one of the startup files (.profile, .bash_profile, .bashrc, .zshrc, .xprofile, .xinitrc, .xsession - it's a whole lot of confusion hell, no-one knows where to put what, and it's absolutely hopeless for a graphical application to properly modify these). Another huge disadvantage is that you have to log out and log back again for the change to take effect - it's not what users expect from today's desktops and graphical config utilities.

A separate config file might be a slightly better idea. Gconf would also be nice but unfortunately it's a gtk+ issue and gtk+ doesn't depend on gconf. (Maybe take the default from env var or config file, but if gconf is available, override it with the gconf version - ouch, doesn't sound too good...) Perhaps it could also be a root window property or an X resource. (In this case gnome-session could set it before launching any of the gtk+ stuff.)

Also, the whole discussion is about two different behaviors. One is consistent with the behavior of all other X applications, the other is meant to solve some issues, breaks others, and is incompatible with what other apps do. Which one is the better lead to a huge debate. Which one is the standard is out of question. Please make the standard option the default to increase compatibility with existing apps and to have a consistent user experience. E.g. if you stick to env vars, Gnome should behave the current way in the presence of that variable, and behave the old, standard, X and KDE and everything else compatible way in the absence of that var.
Comment 92 wildemar 2008-12-06 23:49:18 UTC
I am glad to see a convergence here. Yes, an environment variable would be OK for the time being. The best option would (obviously?) be integration into the keyboardswitcher applet, making the option *much* more visible.

Again, thanks for hearing us, even if we're just a minority. I appreciate it very much.
Comment 93 Simos Xenitellis 2008-12-07 00:40:13 UTC
Created attachment 124078 [details] [review]
Checks if GTK_IM_SEPARATE_SHORTCUTS is set.

We now check if the environment variable GTK_IM_SEPARATE_SHORTCUTS is set, 
and enable the shortcut check only in that case only.
Comment 94 Owen Taylor 2008-12-07 14:27:13 UTC
(In reply to comment #90)
> Created an attachment (id=124062) [edit]
> Updated version of earlier patch which fixes Owen's comments.
> 
> I made the changes that Owen mentions in an earlier comment to Patch 71469 [edit].
> 
> I confirm that with the patch, if you have a qwerty layout and other layouts
> such as azerty, dvorak, then they shortcuts only work according to the
> currently active layout.
> 
> As mentioned already, if you are, let's say, a Dvorak user, you can simply have
> a single Dvorak layout enabled, and you do not need any patch.
> 
> It appears that the existing functionality will remain the default, and the
> proposed functionality will be able to be enabled on demand. 
>

Simos, thanks a lot for taking on this problem. I'm not sure I understand
your comment here though. The whole idea of the patch is to "do the right 
thing" automatically with no "enable on demand". As I understand the idea 
of the patch:

 - If you have a qwerty layout and an azerty layout, it won't use the 
   'a' key in the azerty layout for 'q' accelerators, because there is
  already an 'a' key in the current layout.

 - If you have a qwerty layout and a Greek layout, it will use the
   upper left key in the greek layout for 'q' because there is no other
   q in the keymap. 

Does the patch break the existing functionality in some way?

> One way to enable the proposed functionality on demand could be set an
> environment variable in /etc/environment (for example GTK_SHORTCUTS_ON_LAYOUT)
> and let the users restart. Would such a thing be acceptable, at least as a
> short-term solution?

I can't see that, no.
 
> Another way to enable the proposed functionality on demand would be to have an
> option in the Keyboard Indicator Applet (just like OS/X, Windows? have). 
> In this case, how would the Keyboard Indicator applet be able to set the
> setting? 
> Would it be a case of setting an environment variable? What's the account-wide
> equivalent to the system-wide /etc/environment?

For GTK+, GtkSettings/XSETTINGS; in GNOME they come from GConf via
gnome-settings-daemon, other DE's like XFCE handle them as well, in other environments they can be set through ~/.gtkrc-2.0. BUT: I don't think there
is any user preference here:

 Multiple layouts for different scripts => current behavior good
 Multiple layouts for the same script => current behavior bad

If the approach in the patch from comment 20 doesn't work, then we should
just make a script determination for each layout and figure out what
situation we are in. ("layout" above is used informally and
what we are actually talking about is XKB *groups* - for somewhat similar
code, see the direction determination code in gdk/x11/gdkkeys-x11.c.)
Comment 95 Mikhail Zabaluev 2008-12-08 11:53:35 UTC
(In reply to comment #94)
>  - If you have a qwerty layout and a Greek layout, it will use the
>    upper left key in the greek layout for 'q' because there is no other
>    q in the keymap.

Isn't this mapping defined in XKB for the Greek layout already?
Does GDK even need to have custom logic here?
Comment 96 Paolo Borelli 2009-01-10 17:29:26 UTC
*** Bug 564633 has been marked as a duplicate of this bug. ***
Comment 97 Christian Persch 2009-01-19 22:28:46 UTC
*** Bug 568355 has been marked as a duplicate of this bug. ***
Comment 98 alfborge 2009-01-28 13:55:52 UTC
Please provide an option for disabling this feature.
Comment 99 Christian Persch 2009-01-28 19:28:22 UTC
*** Bug 569554 has been marked as a duplicate of this bug. ***
Comment 100 Alexander “weej” Jones 2009-01-28 20:27:49 UTC
This bug is a conspiracy against Dvorak adoption. A CONSPIRACY!
Comment 101 Alexander “weej” Jones 2009-01-28 20:42:34 UTC
And the French, apparently.
Comment 102 John Millikin 2009-01-29 06:34:43 UTC
How easy would it be to set an option in the keyboard applet/configuration to simply not set the "alternative xkb group" mode? Modifying the keymap from the command-line using setxkbmap works as expected, so it should be possible from within the applet.

The option could be as simple as:
1) A radio button in the keyboard preferences dialog, which would select which layout was used for shortcut keys.
2) A checkbox to enable/disable entirely swapping shortcuts around.
Comment 103 Jerome 2009-01-30 19:39:56 UTC
Hi all.

As far as I can tell, I only use one layout: the "keyboard" applet of system->administration only shows "France Autre" in the layouts list and, in gconf-editor, the /desktop/gnome/peripherals/keyboard/kbd/layouts only shows "fr oss" has only element in the list.

Yey, I have the same kind of problem with modified shortcuts (in gedit): if I modify the "go to line" shortcut (normal:ctrl+I) to ctrl+J (for example) and then modify the "indent line" shortcut (normal:ctrl+T) to ctrl+I, typing "ctrl+I" still provokes a "go to line" dialog.
Comment 104 Matthias Clasen 2009-01-31 20:34:23 UTC
I've decided to go with Simos' patch without the envvar for now. It seems to work fine in my de/us testing. If it causes problems for some people, we can refine it later, for now it seems like a clear improvement.

So, everybody in this bug should please try 2.15.3 in a few days, and report back if things are looking good.


        Bug 162726 – Multiple Latin layouts in XKB break keyboard shortcuts

        * gtk/gtkkeyhash.c (_gtk_key_hash_lookup): Change the handling of
        fuzzy matches: As long there are any exact matches, only exact
        matches are returned. If there are no exact matches, fuzzy matches
        will be returned, as long as they are not shadowing a possible exact
        match. This means that fuzzy matches won't be considered if their
        keyval is present in the current group. Problem reported by
        many people, patch by Simos Xenitellis.
Comment 105 André Pirard 2009-02-01 00:37:56 UTC
I only know Windows keyboard internals and I'm not sure I understand every detail in this thread, but I feel I should explain in practical terms my experience and needs with keyboards in the Ubuntu support I'm making of a small Belorussian community.
Feel free to copy this text elsewhere if you find a better place.

I think it's important to distinguish the native keyboard (a) and the additional keyboard (b).
(a) is the original keyboard of some PC (in my case laptops), whose keys are engraved and tentatively started with in such a way that we could call it primary
(b) is an alternate layout, be it that stickers or side engraving have been added or that the user has it in mind
There may be several alternative layouts to be used; the assumption that persons are monolingual or at best bilingual is false.

In my case they are
a) Belgium, US or UK
b) Russia/Phonetic or Russia/(Winkeys or whichever true Russian layout in stickers)

My profile is that I not only actually use Russian personally to communicate with them by e-mail, but also that I tested several configurations for their PC gifts, for example a replacement keyboard bought in the UK with stickers bought in Germany.

The first remark is that, in my personal configuration Belgium+Russia/Phonetic, and while I'm using Qedit and switched to Russian Phonetic, both ctrl-A and ctrl-Q select all text (ctrl-A) and both Alt-F A and Q want to quit (Alt-F Q). (Alt-F Alt-Q should work too but doesn't BTW.)
Although I get a correct AZERTY "," and "?" where the QWERTY letter M would stand, I get
a QWERTY ",./" on the next three keys and similar results for other signs.
If I add and use Russian/Winkeys, the result are the same for Ctrl and Alt but different for signs, which that layout redefines.
The whole of this is strange.

The second remark is that phonetic "layouts" should not be position based (and hence not called layouts), but that they should depend on the engraving of the primary keyboard.  In fact, they should act as back ends (post-processors) of the primary layout driver.  In addition, they should best modify only the ASCII letter keys and let all other keys alone in order to be valid for any primary layout (the final layout hence varies according to what the primary is).
On Windows, I made such a Russian layout that uses letter Q (no equivalent in Russian) as a dead key which prefixes "у" (oo) to make "ю" (ioo), "а" (a) to make "я" (ia) etc... so as to make 32 keys out of 26.  I find this better than the existing Russian/Phonetic for which only a part of the letters is really phonetic.

Third, for position based alternative layouts like Russia/Winkeys, it is still useful to work as a backend of the primary to redefine only what the stickers redefine so that these stickers work on any primary keyboard.

Last now, regarding how the primary keyboard is identified, it may simply be the first one defined in the list, or tagged as such, but its definition should be apparent and explained, none of which I ever saw.
I did once work with two primary keyboards, laptop's and an external one, but it would really be far fetched to support organ-like PCs ;-)

Oh yes, I'm doing all that on Ubuntu 8.04.1if its important to know and even if it's not.

Best regards, you all are doing a marvelous job.  André.

Comment 106 Simon Kågedal 2009-02-03 13:13:08 UTC
I have tested the GTK+ in current SVN and it seems to work great for the case of multiple latin layouts, while still working for the case of one latin and one non-latin layout. A good step forward! Bravo!

There is still strange behavior in some fringe cases. If a person has three key groups: Arabic, AZERTY and QWERTY, then when in Arabic mode, we still see the behavior where both "Ctrl-Q" and "Ctrl-A" selects all text. 

This might seem like a contrived case, but not entirely unrealistic! It would be great if all apps on the X desktop behaved similarly and predictably even in such odd cases, because you never know how someone might use their computer.

I have started to put together a little investigation of the current situation across X toolkits and apps and a description of some use cases to discuss at:

http://helgo.net/simon/hacking/shortcut.html

Please mail me with any feedback! 
Comment 107 Pedro Castro 2009-02-17 11:11:41 UTC
*** Bug 571261 has been marked as a duplicate of this bug. ***
Comment 108 Nicholas Doyle 2009-03-03 02:50:02 UTC
++ on having this somehow configurable in a UI like the keyboard applet or the layout control panel. DVORAK is simply useless with the way things are now.
Comment 109 Sandy Armstrong 2009-03-17 00:21:18 UTC
*** Bug 575620 has been marked as a duplicate of this bug. ***
Comment 110 António Lima 2009-03-17 00:35:25 UTC
*** Bug 575616 has been marked as a duplicate of this bug. ***
Comment 111 Gianluca Borello 2009-03-28 09:08:50 UTC
*** Bug 575618 has been marked as a duplicate of this bug. ***
Comment 112 Christian Persch 2009-04-02 19:45:33 UTC
*** Bug 577760 has been marked as a duplicate of this bug. ***
Comment 113 Christian Persch 2009-06-16 13:17:07 UTC
*** Bug 585977 has been marked as a duplicate of this bug. ***
Comment 114 Arno Teigseth 2009-07-08 17:47:11 UTC
SOLUTION IN UBUNTU JAUNTY
I too suddenly got this strange behaviour, but it used to work before.

Behaviour: In gnome-terminal, before I could start typing a command and then cancel it by pressing Ctrl+I on a qwerty keyboard. That is Ctrl+C on a dvorak.

Suddenly I could not. In fact all Ctrl+<whatever> did not work in gnome-terminal. But they did in openoffice, firefox etc.

After some head scratching and googling I found some hints saying it helped to delete the US layout. Made me think about that I recently had updated my keyboard configuration file (http://arno.homelinux.org/dvorak/), and to make xkb take it into consideration I usually 
0) Copy the xkb file into /usr/share/X11/xkb/symbols/
1) Open keyboard preferences and delete the dvorak layout
2) Open keyboard preferences and add the dvorak layout again
Now I can type my updated keyboard.

-But this time the "US Ctrl keys" are in effect no matter what I try, even when choosing the dvorak layout.

MY SOLUTION:
-------------------------------------------
1) Open keyboard preferences and delete all but the dvorak layout
2) Add the layouts again.
3) Enjoy.
-------------------------------------------

To me this is STILL A BUG, since now when I select US keyboard, I have to press Ctrl+I to get a Ctrl+C. In other words, dvorak rules the Ctrl-key. However since I never use anything but my custom layout I'm not very much affected...

When thinking about it, I probably never saw this bug before because I chose Norway dvorak during the install process. It is actually the system default layout, to my cow-orkers' despair. ;)

I'm writing this long story to remember it myself, maybe it will help you too.
Comment 115 Christian Persch 2009-09-14 18:45:46 UTC
*** Bug 595204 has been marked as a duplicate of this bug. ***
Comment 116 Sergey V. Udaltsov 2009-11-08 15:35:11 UTC
I guess the current fix is wrong. Currently gtk only looks in the first XKB group. That breaks things for many people.

For example, if you have xkb layouts us,ru - your shortcuts (Ctrl-A, Ctrl-C, ...) work fine.

If you have ru,us (swapped) - shortcuts do not work at all. Because the first group contains cyrillic characters. Could that be fixed please? Or at least have some gtk config parameter for that? Thanks!
Comment 117 Sergey V. Udaltsov 2009-11-16 21:16:12 UTC
It is agreed to close this bug - and open new one, specifically for the issue described in the last comment. See bug #602137
Comment 118 Sergey V. Udaltsov 2009-11-24 22:13:27 UTC
*** Bug 602865 has been marked as a duplicate of this bug. ***
Comment 119 Christian Persch 2010-01-12 21:16:41 UTC
*** Bug 606781 has been marked as a duplicate of this bug. ***
Comment 120 Matt McHenry 2010-02-27 21:43:16 UTC
(In reply to comment #104)
> So, everybody in this bug should please try 2.15.3 in a few days, and report
> back if things are looking good.

Sorry for the long delay, but I don't think this fix works.  I'm running Gnome 2.26.3 on Gentoo with:

$ equery l x11-libs/gtk+
[ Searching for package 'gtk+' in 'x11-libs' among: ]
 * installed packages
[I--] [  ] x11-libs/gtk+-1.2.10-r12 (1)
[I--] [  ] x11-libs/gtk+-2.16.6 (2)

I've configured two layouts in the keyboard preferences, "USA" and "USA Dvorak" (in that order).  When "USA Dvorak" is active, keyboard shortcuts in Gnome Terminal still behave as though Qwerty is active: I have to hit Ctrl-L to get the effect of Ctrl-P, and Ctrl-B to get the effect of Ctrl-N.
Comment 121 Pozsár Balázs 2010-03-03 17:52:59 UTC
Please note that as said in bug 602137, the patch applied in commit 17f8a2c23aba669cbcf7a5c9fc650d8dee78d7f6 has at least one serious usuability problem which should be addressed. Currently using Hungarian layout as primary and US English as secondary I cannot exit from a telnet session within gnome terminal, because ^] does not work.
Comment 122 M. Creidieki Crouch 2010-03-14 20:54:36 UTC
This bug is still a problem on Ubuntu Karmic, using gtk 2.18.3-1ubuntu2.2 .  The problem appears with the "USA" and "USA Dvorak" layouts present in that order; gnome-terminal shortcuts use the Qwerty layout even when the Dvorak layout is active.

This is not the problem described in Bug 602137, which involves nonLatin layouts.  Could this bug be reopened?  Or was it fixed after 2.18.3?
Comment 123 Sergey V. Udaltsov 2010-04-16 21:03:41 UTC
*** Bug 615975 has been marked as a duplicate of this bug. ***
Comment 124 Karl 2010-04-17 06:26:34 UTC
I am always amazed at the one-sidedness people show on some of these bug reports---this bug has been duplicated at least a dozen times (including once by myself), indicating that (a) it's a popular issue that people find really annoying, and (b) it's not easy to find this post and determine that the issue has already been addressed.  Nonetheless, I still get rude comments from people saying this is a desirable feature and my opinion that it's stupid doesn't matter.

It seems to me there's a pretty simple solution to this:  a check box (or equivalent) that says "leave ctrl+ and meta/alt+ mapped to US standard layout."  This makes everyone happy, and doesn't involve treating anyone's personal preferences as stupid or non-standard.

Comment 78 has it right on:  this thread is INFURIATING.
Comment 125 Jocelyn Delalande 2010-10-15 10:42:30 UTC
As previous commentators, I don't consider this bug as solved... Dvorak-like users (as I am) have basically no way to use their keyboard layout properly (as far as ubuntu maverick). 

I makes the gnome desktop experience painful for every dvorak-like users. Please think about it. (In everyday life, we often have to change from dvorak/other layout to lend the keyboard to someone else).

The proposal for an option in gnome-keyboard-properties seems fine.

btw, the low-tech fix won't work the wished way cause each time the computer goes to screensaver, the gnome-settings-daemon (or whatever) resets the keyboard layout set by setxkbmap.

Regards,
Comment 126 Arno Teigseth 2010-10-15 16:36:51 UTC
Hi all

I just found that my ubuntu 9.10 still suffers from this, I just hadn't noticed. How? My system is set up with dvorak as system default layout.

So in gnome-terminals, tty1..6 (Ctrl+Alt+F1..F6) all was well. Ctrl+P on the keyboard correctly sent a Ctrl+L and cleared the terminal.

But now if i select something else than dvorak layout with the gnome switcher, in a gnome-terminal or tty1..6 Ctrl+whatever still follows the DVORAK assignments. Good for me, not so much for others that may be using the computer. Strange thing is, for openoffice, firefox etc the Ctrl+whatever keys DO FOLLOW gnome-keyboard-switcher-set language. Just not Gnome Terminal (=??).

Anyway, if you want to make the dvorak layout default in the whole system, enabling Ctrl+(whatever "dvorak" key) to give the intended function, you can:


 sudo dpkg-reconfigure console-setup
which will present some boxes letting you select, among other things, your system default keyboard. Select some dvorak layout.

Note what the system says after you're done: 
* Saving console font and keymap for next boot...                       [ OK ] 
update-initramfs: Generating /boot/initrd.img-2.6.31-22-generic

which means it will be used at Boot Time :D

It's not a fix, but at least I can use dvorak in text mode, grub and gnome-terminal.
Comment 127 Karl 2011-04-01 17:10:42 UTC
I object to calling this bug "FIXED" since clearly no action has been taken to correct it.  If it's not going to be fixed, call it "WONTFIX" instead.  Or say "NOTABUG" if you insist it's the intended mode of operation.

I still request, and will continue to request, a feature in place that says, "map modified keys (CTRL+, META+, etc.) to new layout" in Gnome Keyboard Preferences.  As such, I'm reopening the bug I originally submitted that was marked as a duplicate of this one (since I don't have the authority to reopen this one).
Comment 128 Marian Such 2011-04-01 17:44:15 UTC
I completely agree with Karl. It has been more than 3 years and using dvorak in gnome feels like showering in cloth.
Comment 129 Bert Van Vreckem 2011-04-01 19:21:26 UTC
I'm also with Karl. Comments are still posted six years after the bug was reported, dozens of duplicate bugs have been posted, both in gnome and downstream. This is *not* a corner case, and it is *not* resolved.

And then they wonder why downstream projects go their own way... **COUGH**Unity**COUGH**
Comment 130 Sergey V. Udaltsov 2011-04-01 19:43:40 UTC
It could be made configurable. I would consider that as the best option, except for usability Procrustes (I am avoiding the Godwin's law:).
It can be kept as it is now (well, I am representing non-latin nations here).
What would be absolutely unacceptable is just reverting the current behavior.
Comment 131 Karl 2011-04-02 23:31:10 UTC
I completely agree with Sergey Udaltsov---it is unacceptable to make one group of users happy by breaking something for other users.  Our goal is that ALL users get the functionality they want, not that some users get to say, "nuts to you!" and give the rest the shaft.
Comment 132 Karl 2011-04-05 20:47:59 UTC
Would someone _please_ change the status of this bug to something other than RESOLVED/FIXED?  I can see the following as options:
  * Mark it as REOPENED (what I deem the proper status) 
  * Mark it as RESOLVED/WONTFIX (what some posters have evidently deemed the correct response)
  * Mark it as RESOLVED/NOTABUG (what other posters have evidently deemed appropriate)
Under no circumstances can I see 'RESOLVED/FIXED' as being appropriate here.  FIXED implies someone changed something to get rid of the observed behavior (even if it's a 'feature' not a 'bug').

If this is reopened and eventually fixed, I would anticipate a new feature in Gnome in the future that allows users to select whether their control keys get remapped when using a non-US English layout---or better yet, choose which layout they want when typing normally and which layout they want when the CTRL/ALT/etc. keys are in use.  This makes ALL users happy, and is therefore the only acceptable solution.

If the bug isn't going to be fixed, someone needs to give a reason WHY it won't be fixed.  Such a person should of course be aware that if someone is told there will be no fix, EVER, then any users who dislike the behavior may simply abandon GNOME altogether if the problem affects them enough.  I would be such a user _myself_ if I were not the only regular user of all affected computers.  I suppose it would also be possible to make a list of several things that need to be modified to fix this bug---that would give aspirant developers who DO care about this bug/feature a place to start.
Comment 133 Josh Brown 2011-06-08 11:38:13 UTC
Looking back at the bug's description, posted 6 years ago, it seems the argument was converse to that of recent times; that alternative Latin keyboard layouts should *not* use Qwerty hotkeys. The problem originally stated has indeed been fixed.

For further discussion on an option to use Qwerty hotkeys in alternative keyboard layouts, see bug 652104.
Comment 134 Karl 2011-06-27 15:11:58 UTC
Josh Brown:  I don't think we're reading the same original post here.  He said that pressing ALT-F,A with the French layout active causes the application to quit.  This happens because the A on the French keyboard is where the Q is on the US-standard layout (QWERTY), and F is in the same place, so he actually pressed ALT-F,A but got ALT-F,Q.

Recent posts (mine in particular), may not use French as their alternative layout, but they have the same problems.  For example, try this:
  1) Set /default/ layout to USA/Dvorak on a USA/standard keyboard.
  2) Open a shell, and type "ls /home CTRL-C".  The command should not be executed.  (If your keys are the USA/standard layout the command above is "p; [jsmd CTRL-I")
  3) Change the layout (/not/ the default, just the regular layout switch) to USA/standard.
  4) Type "ls /home CTRL-C".  The command will now EXECUTE, since it thinks you pressed CTRL-J (line-feed); the J key in USA/Dvorak is the C key in USA/standard.

This sequence (or one very similar) happens EVERY TIME someone else tries to use a shell on my laptop.  Call me stupid, but I'd call that a bug, as did the original poster.  Later posts are not the converse statement, it's exactly the same statement in different words.

The follow-up post (and the many other increasingly frustrating ones after it) should not be ignored---we need an option for this bug that allows both camps to be happy (such as the post provided).  Pressing CTRL-J when you think you're pressing CTRL-C can be a major problem (especially if the command you just typed was something like "rm -f my-really-important-file CTRL-C").

I should point out something else:  the keys themselves are determined by the CURRENT layout, but the control and alt/meta keys are determined by the DEFAULT layout.  This is the crux of the problem.  Each user can use his/her default layout without problems, as far as I am able to determine, it's when his/her friend comes over from the desk across the room and needs to type something on his/her keyboard that the problem surfaces.
Comment 135 Karl 2011-08-23 13:41:44 UTC
To update from my earlier post several months ago:  this bug seems to have been fixed (it's about time, huh?) in Gnome 3, at least on my Fedora 15 build of it.  The example in Comment #134 works as one might expect it to---that is, typing "echo 'hello' CTRL-C" in Gnome Terminal under US/QWERTY (when the default layout is US/Dvorak) no longer says "hello" but instead aborts the command.

Can anyone confirm?  I am closing my bug (# 615975) that was marked a duplicate of this one.

If it is indeed fixed for all users, let me simply say THANK YOU to everyone who had a hand in fixing this more-than-six-year-old pain in the tail.
Comment 136 André Pirard 2011-08-26 21:39:02 UTC
On VirtualBox I have installed 11.10 (it doesn't say it's beta nor which, but it recalls it periodically ;-:))
On top of my AZERTY keyboard I have installed Russian Phonetic.
In Russian mode cntrl+C is cntrl-C = break.

But the non alphabetic keys is a mess.
, is , but   ; is , too   : is .   = is /   etc.

Obviously, such a phonetic keyboard should transform only alphabetic keys.
Transform them after the base, default keyboard has output them.
It should leave the non alphabetic keys alone.
For Russian and probably other language it should use a key to produce more than 26 characters.
Call it dead key or compose key, let's use or call it Q for Russian.
Obviously, for Russian we will use Q for the alternate form of vowels or consonants.
Qа is я, Qо is ё, Qс is ц etc.

And wiped out are those Ctrl-C and other keys problem as they are not alphabetic and hence are processed only by the base keyboard.
Comment 137 Matthias 2012-07-01 13:43:04 UTC
Just want to mention that the "problem" still exists (for inkscape, Ubuntu precise + gnome 3). 

I'm using QWERTZ (on my laptop built in keyboard) and QUERTY on my english keyboard which I prefer for programming.
Comment 138 Frank 2016-09-21 21:34:40 UTC
Bump. I use Neo layout and standard German for my friends on my HTPC and this fucks me up…