GNOME Bugzilla – Bug 162726
Multiple Latin layouts in XKB break keyboard shortcuts
Last modified: 2016-09-21 21:34:40 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
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.
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.
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 :-)
except thqt so,e letter co,e out zrong:::
*** Bug 158902 has been marked as a duplicate of this bug. ***
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
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.
*** Bug 337169 has been marked as a duplicate of this bug. ***
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....
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)
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.
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).
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.
*** Bug 337751 has been marked as a duplicate of this bug. ***
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."
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?
Adding Sergey to the cc: list. Sergey, do you have any input on this and in particular comment 10 ?
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.
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.
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
*** Bug 171075 has been marked as a duplicate of this bug. ***
*** Bug 412970 has been marked as a duplicate of this bug. ***
*** Bug 413311 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 409469 has been marked as a duplicate of this bug. ***
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.).
*** Bug 424623 has been marked as a duplicate of this bug. ***
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)
*** Bug 418246 has been marked as a duplicate of this bug. ***
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.
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.
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?
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
(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...
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.
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...
*** Bug 126956 has been marked as a duplicate of this bug. ***
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.
(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.
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.
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.
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.
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”.
(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 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!
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. )
Xkb bug: https://bugs.freedesktop.org/show_bug.cgi?id=15948
(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.
*** Bug 536865 has been marked as a duplicate of this bug. ***
*** Bug 539796 has been marked as a duplicate of this bug. ***
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?
*** Bug 399947 has been marked as a duplicate of this bug. ***
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.
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.
(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?
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).
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.)
>> 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.
> 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?
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!
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.
"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.
> 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.
(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.
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. ;-)
> 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...
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.
*** Bug 540784 has been marked as a duplicate of this bug. ***
(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.)
(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.
*** Bug 543163 has been marked as a duplicate of this bug. ***
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é.
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).
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?
(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.
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.
*** Bug 547451 has been marked as a duplicate of this bug. ***
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?
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.
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?)
(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.
*** Bug 334155 has been marked as a duplicate of this bug. ***
*** Bug 557445 has been marked as a duplicate of this bug. ***
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
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
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.
*** Bug 563460 has been marked as a duplicate of this bug. ***
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?
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.
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.
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.
(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.)
(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?
*** Bug 564633 has been marked as a duplicate of this bug. ***
*** Bug 568355 has been marked as a duplicate of this bug. ***
Please provide an option for disabling this feature.
*** Bug 569554 has been marked as a duplicate of this bug. ***
This bug is a conspiracy against Dvorak adoption. A CONSPIRACY!
And the French, apparently.
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.
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.
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.
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é.
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!
*** Bug 571261 has been marked as a duplicate of this bug. ***
++ 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.
*** Bug 575620 has been marked as a duplicate of this bug. ***
*** Bug 575616 has been marked as a duplicate of this bug. ***
*** Bug 575618 has been marked as a duplicate of this bug. ***
*** Bug 577760 has been marked as a duplicate of this bug. ***
*** Bug 585977 has been marked as a duplicate of this bug. ***
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.
*** Bug 595204 has been marked as a duplicate of this bug. ***
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!
It is agreed to close this bug - and open new one, specifically for the issue described in the last comment. See bug #602137
*** Bug 602865 has been marked as a duplicate of this bug. ***
*** Bug 606781 has been marked as a duplicate of this bug. ***
(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.
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.
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?
*** Bug 615975 has been marked as a duplicate of this bug. ***
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.
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,
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.
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).
I completely agree with Karl. It has been more than 3 years and using dvorak in gnome feels like showering in cloth.
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**
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.
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.
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.
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.
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.
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.
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.
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.
Bump. I use Neo layout and standard German for my friends on my HTPC and this fucks me up…