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 568355 - after installing Colemak layout, menus act like Colemak is active even when QWERTY is in use
after installing Colemak layout, menus act like Colemak is active even when Q...
Status: RESOLVED DUPLICATE of bug 162726
Product: gnome-terminal
Classification: Core
Component: Keybindings
2.24.x
Other All
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-01-19 22:18 UTC by Mikel Ward
Modified: 2009-01-19 22:28 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Mikel Ward 2009-01-19 22:18:40 UTC
Please describe the problem:
After installing the USA Colemak layout in addition to the standard USA layout (which is QWERTY), some shortcuts act like Colemak is active even when the QWERTY layout is active.

Steps to reproduce:


1. Open Gnome Terminal
2. Edit->Keyboard Shortcuts
3. Scroll down to New Tab (under File group), click on the right side of the row, type Ctrl+T
4. Verify that pressing Ctrl+T opens a new tab
5. Verify that pressing Ctrl+F does what it should
    a. start a bash shell, run "bind -m emacs", type some characters, press Ctrl+B to go back then Ctrl+F to go forward
    b. edit a file using vi, press Ctrl+F to go forward one page
6. System->Preferences->Keyboard
7. Layouts
8. Click [+]
9. Country=United States, Variants=USA Colemak
10. Click Add
11. Type "asdf" in the "Type to test settings box" to ensure that a QWERTY layout is still active
12. Click Close and return to Gnome Terminal
13. Press Ctrl+F

Actual results:
A new tab is opened.

Expected results:
It should instead go down a page in Vi or go forward one character in Bash.

Does this happen every time?
Yes.

Other information:


xev shows this.

Suggests that X is sending the right thing, and that the bug is in Gnome Terminal or GTK+.

KeyPress event, serial 30, synthetic NO, window 0x4000001,
    root 0x13b, subw 0x0, time 1516844, (61,95), root:(65,168),
    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 33, synthetic NO, window 0x4000001,
    root 0x13b, subw 0x0, time 1517100, (61,95), root:(65,168),
    state 0x4, keycode 41 (keysym 0x66, f), same_screen YES,
    XLookupString gives 1 bytes: (06) ""
    XmbLookupString gives 1 bytes: (06) ""
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x4000001,
    root 0x13b, subw 0x0, time 1517180, (61,95), root:(65,168),
    state 0x4, keycode 41 (keysym 0x66, f), same_screen YES,
    XLookupString gives 1 bytes: (06) ""
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x4000001,
    root 0x13b, subw 0x0, time 1517228, (61,95), root:(65,168),
    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False


If I go back and edit the preferences with USA and USA Colemak layouts installed and with USA active, if I edit the shortcut and press Ctrl+F, it correctly identifies it as Ctrl+F (so I reset it to Ctrl+T by pressing Ctrl+T).

If I change the New Window shortcut to be Ctrl+N (by pressing Ctrl+N!), Ctrl+J opens a new window, even when QWERTY is the active layout. (QWERTY J=Colemak N, QWERTY F=Colemak T).

Typing "asdf" in the terminal produces "asdf" (QWERTY), not "arst" (Colemak) and that the Keyboard Layout applet shows USA. It's just a problem with the menus AFAICT.

Does not affect:
- Firefox
- Epiphany
- gEdit
Comment 1 Christian Persch 2009-01-19 22:28:46 UTC
Yes. Known bug in gtk+.

*** This bug has been marked as a duplicate of 162726 ***