GNOME Bugzilla – Bug 413311
Ctrl+X closes note with Dvorak layout enabled but QWERTY active
Last modified: 2008-06-02 20:09:26 UTC
I (and I imagine, many others) frequently use the Ctrl+X key combo to cut text in order to shuffle it about. Unfortunately, Tomboy started taking this keyboard shortcut to mean "close". We're already using the conventional Ctrl+W for close, so I'm not really sure what's going on here, but it's been a frequent source of "wtf?"s from me for a few weeks now! :P Can we revert this change, please?
The only time that I saw this was when I was fiddling around with Keyboard Layouts to test out some things in other languages. If I removed the other keybaord layouts from the Keyboard Preferences applet in Control Center, Ctrl+X works exactly as expected (cuts text).
Maybe similar to Tomboy bug #171075 (which is a dupe of gtk+ bug #162726)? Sorry, don't have time to look into this more thoroughly.
I can confirm that I have both English and English (Dvorak) keyboard layouts active.
I'm afraid this is a duplicate, then. I'll mark it as such. I feel for you, this bug must be very frustrating. :-) *** This bug has been marked as a duplicate of 162726 ***
Sanford: I hope you don't mind if I re-open this and adjust the title. I've marked the other bug as a dependency. IMO, this bug is still an issue in Tomboy, even if it is caused by something lower down the stack. I think it might be beneficial to highlight what issues that bug is blocking. Interestingly, I can't find any other applications that suffer from this side-effect. In Qwerty->Dvorak translation, X is Q, and , is W. All four of these keys cause the note to close. In, e.g. GEdit, this doesn't happen, despite those same shortcuts existing. If you disagree, close it again and we'll be done with it. I just find it incredibly difficult to keep track the bugs that I'm affected by when they are DUPd like that! No hard feelings. :)
I'm still a little new to GNOME Bugzilla, so sorry if I closed this erroneously. When I tested bug #171075 I had the same problem in Epiphany. See associated comments in bug #162726.
Bug 171075 seems a bit wrong, C in US/QWERTY layout is J in US/Dvorak, not I. QWERTY G is also Dvorak I, but even with both layouts enabled and in QWERTY mode active, Ctrl+G does not cause selected text to go italic unless Dvorak is made active. This is correct behaviour! Is this because the Ctrl+I shortcut is a different kind of shortcut to Ctrl+Q, somehow?
Ah piss, regarding the other bug, I read it the wrong way around. Oops. :P
Setting the default assignee and QA Contact to "tomboy-maint@gnome.bugs".
I am using Tomboy Notes version 0.10.1. The "Ctrl+X" in the title of this bug actually *quits* Tomboy, thereby closing *all* open notes. I am also using two keyboard layouts (USA qwerty & USA Dvorak). When set to Dvorak, Tomboy shows evidence of a dual personality: * Ctrl+j [qwerty 'c'] act as copy * Ctrl+k [qwerty 'v'] act as paste * Ctrl(+Shift)+z [qwerty '/'] act as undo/redo. * Ctrl(+Shift)+; [qwerty 'z'] act as undo/redo. * Ctrl+q [qwerty 'x'] act as quit * Ctrl+' [qwerty 'q'] act as quit * Ctrl+w [qwerty ','] act as close * Ctrl+, [qwerty 'w'] act as close * Ctrl+x [qwerty 'b'] act as bold toggle * Ctrl+b [qwerty 'n'] act as bold toggle * Ctrl+i [qwerty 'g'] act as italics toggle * Ctrl+c [qwerty 'i'] act as italics toggle * Ctrl+h [qwerty 'j'] act as highlight toggle * Ctrl+d [qwerty 'h'] act as highlight toggle * Ctrl+s [qwerty ';'] act as strikeout toggle * Ctrl+o [qwerty 's'] act as strikeout toggle * Ctrl+f [qwerty 'y'] act as find in note * Ctrl+u [qwerty 'f'] act as find in note These are the shortcut keys I found and tested. The issue comes from the difference between shortcut keys based on physical location versus logical (letter) location. Note that the keys for Undo-Cut-Copy-Paste-Close are mostly physically-based and that the Quit-Italics-Bold-Strikeout-Find-Highlight are mostly logically-based. I am sure this issue has come up before and I would be happy to look for relevant design docs. I hope this helps the discussion.
I've decided (again) to resolve this as a duplicate of bug #162726. We're not going to do anything about it...it needs to be resolved in gtk+. Please add input to the bug #162726 if you have anything to add (make sure to read all of the existing comments first). *** This bug has been marked as a duplicate of 162726 ***