Description of problem: Despite the saying in Fedora 18 release note that it's know there's no default shortcut key to turn input method on and off, it's still an issue which I hope to be properly addressed in coming control-center point release. https://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Desktop.html#idp714464 Version-Release number of selected component (if applicable): control-center-3.6.3-1.fc18.x86_64 How reproducible: 100% Steps to Reproduce: 1. Fresh install or Upgrade to Fedora 18 GNOME Desktop 2. Go to System Config -> Language/Region -> Input Source to make sure there's at least one source listed as pre-configured. 3. Try to use previously working/traditional shortcut key to enable input method. Among zh_CN users, it will be Ctrl+SPACE. In different language or region there might be other combinations. Actual results: Nothing happens. No input method is turned on. User has to click the hyper link of Shortcut Key Setup to assign a shortcut key manually. Expected results: If upgrading from a previous version of Fedora, it should understand the already defined shortcut key. If installing a fresh instance, it should pre-configure a shortcut on/off key according to user's language/region setting. For example, if the user's language is simplified or traditional Chinese, Ctrl+SPACE should be the default shortcut key to turn input method on/off. Additional info: Although it's not hard to re-assign a shortcut key in g-c-c, it introduces a highly possible UX break for end users, both for the ones who migrate from other OSs or DEs and the ones who have used previous version of Fedora. Since we can config a default input method source for a particular language/region, it shouldn't be too hard to config a default on/off shortcut key.
I understand the main concern is default setting is somehow different for different language/region, but I think beside that, what type of application does user use is also related. The new keyboard architecture in GNOME restricted a lot of technical possibilities. Previously applications that conflict with the input method key just disable the input method, which will not create any input contexts. However in this new architecture, it is not aware of input contexts and this conflicting key will always be intercepted by GNOME. For example, if you set Control-<space> as next-language-source, you will *never* be able to use Emacs. If you set to Super-<space> you will *never* be able to use kupfer or Gnome-Do (if I remember the default binding correctly...). Anyway, the reason I bring this issue up is this problem is *very complicated* under the current input architecture of GNOME.
(In reply to comment #1) > I understand the main concern is default setting is somehow different for > different language/region, but I think beside that, what type of application > does user use is also related. > > The new keyboard architecture in GNOME restricted a lot of technical > possibilities. Previously applications that conflict with the input method > key just disable the input method, which will not create any input contexts. > However in this new architecture, it is not aware of input contexts and this > conflicting key will always be intercepted by GNOME. > > For example, if you set Control-<space> as next-language-source, you will > *never* be able to use Emacs. If you set to Super-<space> you will *never* > be able to use kupfer or Gnome-Do (if I remember the default binding > correctly...). Anyway, the reason I bring this issue up is this problem is > *very complicated* under the current input architecture of GNOME. Thanks Mike to bring it up. If needed, please file a separate issue for this Feature Request. For this one, please focus to define a default on/off shortcut key for a given language.
(In reply to comment #2) > (In reply to comment #1) > > I understand the main concern is default setting is somehow different for > > different language/region, but I think beside that, what type of application > > does user use is also related. > > > > The new keyboard architecture in GNOME restricted a lot of technical > > possibilities. Previously applications that conflict with the input method > > key just disable the input method, which will not create any input contexts. > > However in this new architecture, it is not aware of input contexts and this > > conflicting key will always be intercepted by GNOME. > > > > For example, if you set Control-<space> as next-language-source, you will > > *never* be able to use Emacs. If you set to Super-<space> you will *never* > > be able to use kupfer or Gnome-Do (if I remember the default binding > > correctly...). Anyway, the reason I bring this issue up is this problem is > > *very complicated* under the current input architecture of GNOME. > > Thanks Mike to bring it up. If needed, please file a separate issue for this > Feature Request. > > For this one, please focus to define a default on/off shortcut key for a > given language. with gnome-3.8 (in Fedora 19) defined shortcut key (Super+Space) https://live.gnome.org/GnomeOS/Design/Whiteboards/KeyboardShortcuts
Verified in GNOME 3.8 in Fedora 19. The default key is SUPER + SPACE, which is the same as in Win8.