GNOME Bugzilla – Bug 693747
input source switch shortcut should work on PRESS, not on RELEASE
Last modified: 2013-04-02 07:21:48 UTC
Currently the input source switch shortcut seems to be triggered on RELEASE, but it should work on PRESS event because: 1. Conventionally such CJK input toggle key has been worked on PRESS for decades since the beginning of CJK keyboard input. Users are confused if it works on RELEASE. Actually Korean AT/PS2 keyboards don't even generate RELEASE signal on the Hangul toggle key. 2. Users make typos. The mode switching delay after shortcut RELEASE is, according to what a user measured [1] in GNOME 3.6, about 140ms. So users should not input any text for 140ms after releasing the shortcut key. But most users, even slow typers, do start input in 100ms. It is very annoying. I'm not sure whether changing this shortcut to PRESS breaks the cool input switch OSD in GNOME 3.8. But I believe the OSD should be dropped if it really matters. This shortcut behavior destroys the basic usability. [1] https://groups.google.com/d/msg/gnome-kr/BGhbE9vElUc/UYpoZnWUX_4J
Found this comment message: ef29fcf8223a0f9293c2a9c8af6a27fba6e2e7af : We usually only trigger the switch on key release because we don't : want to prevent applications from getting e.g. Ctrl+Shift+E if the : shortcut is Ctrl+Shift. This is really unfortunate. I don't think those who set their shortcut to Ctrl+Shift will be surprised by Ctrl+Shift+E not working.
OK, since I posted the above comment, I have learned that Ctrl+Shift was a much reqeusted for feature by many. But the change from key-press to key-release is detrimental to CJK users. Please make it configurable. ++ I modified gnome-settings-daemon to bring back the old behavior and the difference is night and day. diff --git a/plugins/media-keys/gsd-media-keys-manager.c b/plugins/media-keys/gsd-media-keys-manager.c index ef97cd7..292d0de 100644 --- a/plugins/media-keys/gsd-media-keys-manager.c +++ b/plugins/media-keys/gsd-media-keys-manager.c @@ -2034,6 +2034,7 @@ filter_key_events (XEvent *xevent, case SCREEN_BRIGHTNESS_DOWN_KEY: case KEYBOARD_BRIGHTNESS_UP_KEY: case KEYBOARD_BRIGHTNESS_DOWN_KEY: + case SWITCH_INPUT_SOURCE_KEY: /* auto-repeatable keys */ if (xiev->evtype != XI_KeyPress) return GDK_FILTER_CONTINUE;
From the beginning, it was wrong to map an ibus input method to an input source. Input source was designed like a keymap; switching keymaps means language switch which doesn't happen very often. But CJK users' input methods switching is between alphanumeric and their native scripts. It happens every several minutes. Maybe the ideal solution is to make another kind of meta input source which wraps another ibus input methods. And switching between the "child" ibus input methods can be done with traditional language toggle keys.
(In reply to comment #3) > From the beginning, it was wrong to map an ibus input method to an input > source. Input source was designed like a keymap; switching keymaps means > language switch which doesn't happen very often. But CJK users' input methods > switching is between alphanumeric and their native scripts. It happens every > several minutes. > > Maybe the ideal solution is to make another kind of meta input source which > wraps another ibus input methods. And switching between the "child" ibus input > methods can be done with traditional language toggle keys. An input method can have multiple 'input modes'. For instance, ibus-anthy already has hiragana japanese script mode and latin script mode and they can be switched to and fro with shortcuts. So an ibus-anthy user can keep anthy activated all day and never switch to another input source. This mode of operation may be conceptually more correct than me switching between 'en' and 'mozc' all the time, but it feels old-fashioned and pre-unicode to me. And an input method's providing latin mode is a waste of resource while there are latin input sources readily available. And it is more complicated. ** I think a solution is simple: Do not allow modifiers-only shortcuts, like alt-shift. It is an insane microsoftism. Other sane key-combos e.g. alt-space is no less convenient. ** The commit id I pasted above in comment #1 was bogus. The correct one is: c2329474216ff63bc41f5f5882ad2548b1faf227 "keyboard: Trigger input source switching on key press for Caps Lock" https://mail.gnome.org/archives/commits-list/2012-November/msg03904.html This commit is a direct consequence of letting in modifiers-only shortcuts.
(In reply to comment #4) > (In reply to comment #3) > > From the beginning, it was wrong to map an ibus input method to an input > > source. Input source was designed like a keymap; switching keymaps means > > language switch which doesn't happen very often. But CJK users' input methods > > switching is between alphanumeric and their native scripts. It happens every > > several minutes. > > > > Maybe the ideal solution is to make another kind of meta input source which > > wraps another ibus input methods. And switching between the "child" ibus input > > methods can be done with traditional language toggle keys. > > An input method can have multiple 'input modes'. For instance, ibus-anthy > already has hiragana japanese script mode and latin script mode and they > can be switched to and fro with shortcuts. Most existing ibus methods don't work like that. They just handle one script only. Changing these ibus methods for this GNOME bug is very difficult and sometimes not desirable because some people, for example, want use Dvorak or European dead keys with their own native script. > So an ibus-anthy user can keep anthy activated all day and never switch > to another input source. This mode of operation may be conceptually more > correct than me switching between 'en' and 'mozc' all the time, but > it feels old-fashioned and pre-unicode to me. And an input method's > providing latin mode is a waste of resource while there are latin input > sources readily available. And it is more complicated. >
There are several bugs covered in this discussion: 1. Shortcut keys should work on press rather than on release. But which shortcut? The OSD switcher (defaults to Super+Space) or the modifiers-only shortcut which simply advances to the next input source? For the OSD case there's no way to make it work on press only since what makes the OSD stay visible is that one of the modifiers involved is still pressed. For the modifiers-only shortcut I'm actually changing the implementation right now and the patches I have are actually working on press indeed. Bug 697002. 2. Handling of language specific input toggle keys, bug 682319. 3. Lag and lost key events to the wrong input source, there are patches in bug 697007. 4. Being able to specify a layout in addition to an ibus engine is a design problem that we've been aware of for some time but haven't got around to fix yet. See bug 697073. I'm going to dupe this on bug 697002 since that one covers the issue reported on this bug's summary. *** This bug has been marked as a duplicate of bug 697002 ***