keyboard shortcut mixed when using several keymaps

[Chris Moore]

In gnome-terminal, I'm used to pressing control-t to open a new tab.

I'm also used to using control-k when editing bash command lines. control-k is
supposed to delete from the cursor to the end of the current line.

At the moment, however, both control-t and control-k are creating new tabs.
This is very frustrating when trying to edit bash command lines!

I think the problem first started when I added the UK Dvorak layout to my
keyboard preferences. Note that qwerty's 'k' key is dvorak's 't' key.

I don't use the dvorak layout - I just have it as one of the options in my list
of layouts in the keyboard preferences. The 'k' key sends a 'k' as it should,
but when I hold the control key and press 'k' it seems to send a control-t
instead of a control-k.

This problem doesn't show up in firefox 1.0.7 from the breezy repository, nor in
firefox 1.50b1 from mozilla.org. It *does* show up in galeon from the breezy
repository, so I guess this isn't a gnome-terminal bug. I don't know which
package to file it against though.

[Chris Moore (dooglus)]

breezy's xchat shows the same bug - both control-t and control-k open a new tab
for me.

I tried switching to the dvorak layout using the keyboard indicator.

Yd. t.fmal jdabi.o... sorry.
The keymap changes as it should, but both control-t and control-k still open a
new tab in xchat.

[Chris Moore (dooglus)]

I just ran the GNOME 'Configuration Editor' and turned on the
"/desktop/gnome/interface/can_change_accels" option.

Then I ran gnome-terminal and changed the key binding for 'open tab -> default'
from control-t to control-r.

Now control-r opens a new tab, as it should, and control-t and control-k are
both sent through to the shell, as they should be. If I run an "emacs -nw"
inside the gnome-terminal, it sees the control-t and the control-k as separate
characters. control-o now opens a new tab as well, since qwerty's 'o' is
dvorak's 'r'.

I bound 'open tab -> default' back to control-t and then both ^t and ^k were
making new tabs again.

Finally I bound it to control-o, and then both ^o and ^s were making new tabs.
(qwerty's 's' in dvorak's 'o').

[Daniel Stone (daniels)]

can you please send the output of pressing ctrl and then k (while still holding
down ctrl) in xev? just the keypress and keyrelease events will be fine.

[Chris Moore (dooglus)]

Here's the output you requested. I'm running breezy (final) now and control-k
still creates a new tab in gnome-terminal if I map control-t to create a new
tab. So most of the time I map shift-control-t to be create-tab - then I can
use control-k without it making new tabs (although then shift-control-k makes a
new tab, but I never type that).

----
KeyPress event, serial 26, synthetic NO, window 0x5600001,
    root 0x3b, subw 0x0, time 70780400, (2,-50), root:(17,67),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x5600001,
    root 0x3b, subw 0x0, time 70780784, (2,-50), root:(17,67),
    state 0x4, keycode 45 (keysym 0x6b, k), same_screen YES,
    XLookupString gives 1 bytes: (0b) "
"
    XmbLookupString gives 1 bytes: (0b) "
"
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x5600001,
    root 0x3b, subw 0x0, time 70780852, (2,-50), root:(17,67),
    state 0x4, keycode 45 (keysym 0x6b, k), same_screen YES,
    XLookupString gives 1 bytes: (0b) "
"

KeyRelease event, serial 29, synthetic NO, window 0x5600001,
    root 0x3b, subw 0x0, time 70781587, (2,-50), root:(17,67),
    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
----

Incidentally, here's the corresponding xev output for shift-control-k:

----
KeyPress event, serial 29, synthetic NO, window 0x5600001,
    root 0x3b, subw 0x0, time 71028685, (324,202), root:(334,296),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x5600001,
    root 0x3b, subw 0x0, time 71028706, (324,202), root:(334,296),
    state 0x4, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x5600001,
    root 0x3b, subw 0x0, time 71031514, (324,202), root:(334,296),
    state 0x5, keycode 45 (keysym 0x4b, K), same_screen YES,
    XLookupString gives 1 bytes: (0b) "
"
    XmbLookupString gives 1 bytes: (0b) "
"
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x5600001,
    root 0x3b, subw 0x0, time 71031568, (324,202), root:(334,296),
    state 0x5, keycode 45 (keysym 0x4b, K), same_screen YES,
    XLookupString gives 1 bytes: (0b) "
"

KeyRelease event, serial 29, synthetic NO, window 0x5600001,
    root 0x3b, subw 0x0, time 71032263, (324,202), root:(334,296),
    state 0x5, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:

KeyRelease event, serial 29, synthetic NO, window 0x5600001,
    root 0x3b, subw 0x0, time 71032282, (324,202), root:(334,296),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
----

Note that I've not applied the 2 .deb patches in bug 21595, and was experiencing
keyboard problems r...

[Daniel Stone (daniels)]

okay, can you please try those debs then?

[Chris Moore (dooglus)]

(In reply to comment #6)
> okay, can you please try those debs then?

I tried them, but they didn't make any difference - I still see the problem.

I just noticed a related problem: I have bound alt-l to lock the screen. In
GNU Emacs I use alt-p to bring back previous shell commands, but now alt-p locks
the screen instead. (I run a version of Emacs I built from their CVS repository
rather than the official ubuntu build). Interestingly enough, control-k works
fine in Emacs, even while it's being treated like a control-t by gnome-terminal.

[Daniel Stone (daniels)]

it came to me in a blinding-bloody-obvious flash of inspiration last night.
system->preferences->keyboard, layouts tab, disable 'separate group for each
window'; does that help?

[Chris Moore (dooglus)]

Nice idea, but it's not enabled. I use the same layout for all applications.

[Tollef Fog Heen (tfheen)]

I can confirm this fine. It seems to only affect gtk applications though, so I'll reassign there.

[Christopher Armstrong (radix)]

Ok, I found an example that really enrages me. Gnome Dictionary won't let me type in a "z" in Dvorak. I cannot look up the definition of "zebra"! Instead, it pops up the search bar. That's because dvorak 'z' is on qwerty '/'.

By the way, much more useful information about this problem is in the bug I reported (which was marked as a duplicate of this one), at https://bugs.launchpad.net/ubuntu/+source/control-center/+bug/51871 -- at least reading the comments should clarify the issue a bit.

The lame excuses about being able to use latin keybindings from non-latin keymaps are getting old. This is becoming a serious usability issue. I understand the need to offer those keybindings to non-latin keymap users, but something needs to change so it doesn't screw up the usability for people who use alternative latin keymaps. (I realize that the 'lame excuses' are coming from upstream, not Ubuntu. Just venting.)

[WillSmith (undertakingyou)]

Also when in dvorak CTRL +c should interrupt the command line process, but instead it tabs, while hitting CTRL +j will cause an interrupt. When using qwerty the behavior is normal.

[Martin Hamrle (hamrle)]

It seems that it is duplicate of bug http://bugzilla.gnome.org/show_bug.cgi?id=126956

[Max (mjs510)]

The Alt keys are also affected by this bug. I have United Kingdom Dvorak and United Kingdom installed, and use UK Dvorak by default. Under UK Dvorak, you type an F by pressing the Y key on a QWERTY keyboard. If I press Alt and the Y key, I get the File menu. However, I also get the File menu if I press Alt and the F key. The same is true for all the other Alt menu shortcuts. This is frustrating, as it stops me being able to use Alt+. in Bash - to get a dot, I have to press the E key, so this instead triggers the Edit menu.

[jemand (ich-22)]

Confirmed.
Running hardy, in Xchat Alt-2 does the same as Alt-f: Open the Menu shortcutted to f. Curious about this: Alt-2 should be assigned to open the second Tap.
The 2-Key is f under an other layout.

[Damien Cassou (cassou)]

Probably related to bugs #229850 and #229851.

[Gabriel de Perthuis (g2p)]

Users of Russian, Greek, Arabic, Japanese want to be able to type accels using a qwerty layout. Users of French, German, and latin languages do not want it.

Currently the first behaviour is implemented as a gtk+ hack - http://bugzilla.gnome.org/show_bug.cgi?id=162726 . The second set of users suffers.

This behaviour should be implemented in xkb in a configurable way, so that it can be removed from gtk+ and both sets of users can be happy.

[Sergey V. Udaltsov (svu)]

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.

PS Though, being Russian, I personally really like the way gtk behaves - and sincerely cannot understand users having several latin layouts in one configuration

[Tom Brown (tomubun4)]

The workaround I posted to https://bugs.launchpad.net/bugs/229851 (now marked as a duplicate of this)

It seems like the ctrl keys use the mapping of the first keyboard in the Keyboard Preferences -> Layouts list. Once I put my primary layout at the top this hasn't been very annoying because I only use key combinations in one layout.

[Lionel Dricot (ploum-deactivatedaccount)]

I confirm this bug but I do not agree with Tom Brown : Sometime, Ctrl+C does a "cut" because "C" in my primary layout is "X" in my secondary layout. My primary layout is a the top in the layout list.

[Egmont Koblinger (egmont-gmail)]

I've just upgraded from Dapper to Hardy and I'm also hit by this bug. Currently I'm experimenting with the Colemak layout and changing back-n-forth from Qwerty. Dapper had no problem with this. In Hardy I can't do this because the Ctrl'ed keys don't change in GTK apps, they always stay Qwerty (or always stay Colemak, whichever is the first one loaded). However, these keys do work correctly in other apps (e.g. plain old xterm).

It was hardly a few years ago that X developers finally made it possible to load multiple layouts and switch with a shortcut key that works always and immetiately. Now we're back to the old ages where the only way to change the layout is to execute a setxkbmap or xmodmap command each time, which might take some time depending on the system load, connecting to a shortcut key is tricky and does not always work (e.g. shortcut keys are usually not working if an app has its menu open), and is not compatible with the Gnome keyboard applet.

I'm pretty much shocked to see that this bug has "importance: low". Do you really mean it?
- Keyboard is the device I'm using 8 hours a day, and I'm sure I'm not the only guy with this strange habit.
- It's clearly a regression from old Ubuntu versions.
- GTK apps interpret keypresses differently than other apps, which is a blocker on its own in my opinion. (The same physical keypress should send the same logical keystroke to all apps.)
- A cool feature of X is unusable due to this bug and switching layouts becomes painful as it was in the old ages.
- Gnome keyboard switcher app is unusable due to this bug.
- 23 duplicates were reported so far. This makes me feel that fixing this bug is important for a lot of people.

[Matthias Meulien (orontee)]

I can't believe this bug has "low importance"!! Sure this comment is useless, but when I ctrl+k to kill it, the computer copy it: The "k" key in dvorak layout is at the "v" key location of an azerty layout... I can't believe this bug has "low importance"!! Sure this comment is useless, but when I ctrl+k to kill it, the computer copy it: The "k" key in dvorak layout is at the "v" key location of an azerty layout...I can't believe this bug has "low importance"!! Sure this comment is useless, but when I ctrl+k to kill it, the computer copy it: The "k" key in dvorak layout is at the "v" key location of an azerty layout...I can't believe this bug has "low importance"!! Sure this comment is useless, but when I ctrl+k to kill it, the computer copy it: The "k" key in dvorak layout is at the "v" key location of an azerty layout...

[Pedro Villavicencio (pedro)]

fixed upstream thanks for reporting.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gtk+2.0 - 2.15.3-0ubuntu1

---------------
gtk+2.0 (2.15.3-0ubuntu1) jaunty; urgency=low

  * New upstream version:
    - Keyboard shortcut handling has been changed, to help with a longstanding
    complaint about the way GTK+ handles multiple layouts. GTK+ now only uses
    keys from groups other than the current group if they are not present in
    the current group. Feedback on this change is appreciated. (lp: #23244)
    - Bugs fixed:
    569336 change in gtkbutton klass is causing crash...
    569435 make maintainer-clean removes non-generated sources
    145058 Inputting "^^" requires four keystrokes on Win32...
    559408 Transparency lost when images are copied...
    359288 Toolbar items are not shown after hiding
    569918 64bit portability issue in gtkrecentchooser.c
    162726 Multiple Latin layouts in XKB break keyboard shortcuts
    569635 fontchooser should reload list of families/styles on...
  * debian/patches/071_jasper_link_fix.patch:
    - the change is in the new version

gtk+2.0 (2.15.2-0ubuntu1) jaunty; urgency=low

  * New upstream version:
    GtkAction:
    - Make toolitems pick up icon names from actions
    - Draw proxies of radio actions properly
    - Make menu proxies of recent actions work
    - Avoid accidental activations when changing actions on proxies
    - Make derived button classes work as proxies
    Input methods:
    - Avoid an assertion due to early use of input methods
    GtkScale:
    - Avoid a segfault in the marker drawing code
    GtkImageMenuItem:
    - Add a property to override the show-menu-images setting
    Bugs fixed:
    566628 gdk_display_close always asserts on win32 and quartz
    569240 Crasher when using markers
    569104 Toggle menu entries showed as check menu entries...
    322932 Always show icons on panel menus
  * debian/patches/061_use_pdf_as_default_printing_standard.patch:
    - updated to fix an implicit declaration issue (lp: #287611)

gtk+2.0 (2.15.1-0ubuntu1) jaunty; urgency=low

  * New upstream version:
    GtkFileChooser:
    - Remember the file chooser's size across invocations
    - Handle uris that are entered in the entry
    - Improve autocompletion, in particular for uris
    GtkEntry:
    - New property "im-module" for selecting input methods per-widget
    - New icon-related API got renamed for consistency
    - Added properties and setters for icon tooltips
    GtkTextView:
    - New property "im-module" for selecting input methods per-widget
    - New signal "paste-done" to allow better handling of async pasting
    GtkScale:
    - New api to add annotated marks: gtk_scale_add_mark.
    GtkAction:
    - Rework the way actions and proxies interact, to make the
      interaction less ad hoc, more extensible, and better suited
      for support in GUI builders like glade.
      To be used as a proxy, a widget must now implement the
      ` GtkActivatable interface, and GtkActivatable implementations
      are responsible for syncing their appearance with the action
      and for activating the action.
      All the widgets that are commonly used as proxies implement
      GtkActivatable now.
      This is a big change, a...

[nanotube (nanotube)]

Hi
Problem still persists. Running ubuntu jaunty 9.04, gtk version as follows:
-------------
$apt-cache show libgtk2.0-0
Package: libgtk2.0-0
Priority: optional
Section: libs
Installed-Size: 5260
Maintainer: Sebastien Bacher <email address hidden>
Architecture: i386
Source: gtk+2.0
Version: 2.16.1-0ubuntu2
----------------

default layout is qwerty. when switch to the dvorak layout, all the control shortcuts in gnome-terminal are still in qwerty. however, can still type in dvorak normally, only the control shortcuts are broken.

[Alex Dehnert (adehnert)]

This feels like the same bug as https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/204202. (Not that that is really likely to help anyone.)

[MatatTHC (matatthc)]

Just want to mention that the "problem" still exists (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.