Ibus since Fedora 16 started using Ctrl+Space as a global shortcut when ibus is enabled. My short investigation shows that this breaks at least the following in such environment: kdevelop netbeans qtcreator, eclipse emacs (uses ctrl+space in a number of combinations) monodevelop * kate-part (virtuallly the whole KDE desktop+ kile, lyx and etc.).
And I'm pretty sure I haven't listed even half of the things breaking. Taking a well known application shortcut and making it a global one is a major and disruptive change.
As we can not come on agreement with ibus maintainer I'm raising the issue to Fesco to decide whether it's ok to break a huge number of applications in given environment. Note that ibus is required on gnome 3 and there is work on integrating it even deeper in the gnome stack.
See https://bugzilla.redhat.com/show_bug.cgi?id=756595 for the bug report. See https://live.gnome.org/ThreePointThree/Features/IBus for the ongoing gnome 3 integration.
= implementation recommendation =
I forgot to add the implementation recommendation: ibus should not use ctrl+space as global shortcut
To make sure, Ctrl-space has been began using for the same purpose since Fedora Core 2, with the IIIMF: http://archives.fedoraproject.org/pub/archive/fedora/linux/core/2/i386/os/RELEASE-NOTES-en. FYI to avoid misleading.
I'm neutral on this matter.
Adding the ibus maintainer to the CC list.
Is it possible to configure ibus to use a different combination of keys for this shortcut (without recompilation)? If not, can we at least add a configuration option to disable this shortcut entirely?
Replying to [comment:2 tagoh]:
To make sure, Ctrl-space has been began using for the same purpose since Fedora Core 2, with the IIIMF: http://archives.fedoraproject.org/pub/archive/fedora/linux/core/2/i386/os/RELEASE-NOTES-en. FYI to avoid misleading. I'm neutral on this matter.
Looking at the current spec file, there is %have_bridge_hotkey which to me seems to configure exactly this and it is disabled for Fedoras older than F-15 or I'm misreading things.
Replying to [comment:3 sgallagh]:
Adding the ibus maintainer to the CC list. Is it possible to configure ibus to use a different combination of keys for this shortcut (without recompilation)? If not, can we at least add a configuration option to disable this shortcut entirely?
ibus provides ibus-setup command to configure the shortcut keys for the user level.[[BR]] The default Control+Space has been implemented in input methods for more than ten years for me and I don't think to change the default behavior at present.[[BR]] I don't use your listed applications as daily works except for emacs.[[BR]] Probably I think you could customize the emacs key-binding or Control+@ or customize ibus.
Replying to [comment:5 akurtakov]:
Replying to [comment:2 tagoh]: To make sure, Ctrl-space has been began using for the same purpose since Fedora Core 2, with the IIIMF: http://archives.fedoraproject.org/pub/archive/fedora/linux/core/2/i386/os/RELEASE-NOTES-en. FYI to avoid misleading. I'm neutral on this matter. Looking at the current spec file, there is %have_bridge_hotkey which to me seems to configure exactly this and it is disabled for Fedoras older than F-15 or I'm misreading things.
It doesn't mean to disable Control+Space in ibus but another new feature.
What I have pointed out was, this isn't new at all and not what happened in f16. in fact we keep using Ctrl+space for switching IM context since FC2. that's it.
Some questions: Given that the conflict has been here for so long, what has changed in F16 exactly? (Which component, under which conditions...) What does Ctrl-Space do in the default configuration of ibus, especially in languages that don't use complex input methods? * Would it be possible to make the grabbing of Ctrl-Space dependent on user's configured locale, or perhaps event current keyboard layout?
Replying to [comment:9 mitr]:
Some questions: * Given that the conflict has been here for so long, what has changed in F16 exactly? (Which component, under which conditions...) F15 or former uses Control+Space to switch an ibus input method engine and a gtk input method engine. F16 uses Control+space to switch ibus input method engines and ibus xkb engines. It means users can switch to another keyboard layouts easily besides input methods. ibus xkb engines means to run an internal xkb command likes setxkbmap to switch the layouts. What does Ctrl-Space do in the default configuration of ibus, especially in languages that don't use complex input methods?
Some questions: * Given that the conflict has been here for so long, what has changed in F16 exactly? (Which component, under which conditions...) F15 or former uses Control+Space to switch an ibus input method engine and a gtk input method engine. F16 uses Control+space to switch ibus input method engines and ibus xkb engines. It means users can switch to another keyboard layouts easily besides input methods. ibus xkb engines means to run an internal xkb command likes setxkbmap to switch the layouts.
In the current Fedora, ibus runs in CIJK(as bn gu hi ja kn ko mai ml mr ne or pa si ta te th ur vi zh) locales by default. ibus does not run in other locales by default. Control+Space has been implemented as the default keybinding for input methods besides ibus. If ibus doesn't run, you need to enable ibus with im-chooser command and add ibus engines and then ibus binds Control+Space.
Would it be possible to make the grabbing of Ctrl-Space dependent on user's configured locale, or perhaps event current keyboard layout?
ibus-setup command can change the keybinding as the user level. If ibus will be enabled by default for a part of locales which needs ibus xkb engines only, probably I think the default configuration may be useful.
Suggestion: * Change the '''Ctrl-Space''' keyboard shortcut to '''Ctrl-Shift-Space''' Rationale: 1. Even ibus users want easy access to the functionality that many apps now bind to Ctrl-Space. The number of apps that bind Ctrl-Space keeps growing and changing the Fedora ibus shortcut is more practical than patching everything else. 2. East Asian users likely have run into this "Ctrl-space keyboard shortcut conflict" in other contexts in recent years, ex: Ctrl-Space activates code completion in Visual Studio on Windows, so that although Fedora has indeed used Ctrl-Space for a long time (through language specific XIM servers, IIIMF, SCIM, ibus ..) if we just document this change in the release notes even the users who actually rely on ibus are unlikely to be quite understanding.
This is from a Taiwanese Fedora user who uses ibus daily and always had to reconfigure the Ctrl-space keyboard shortcut to something else after a fresh install.
Replying to [comment:11 scottt]:
Suggestion: * Change the '''Ctrl-Space''' keyboard shortcut to '''Ctrl-Shift-Space'''
We will use Ctrl-Shift-Space for reverse conversions in ibus.
Rationale: 1. Even ibus users want easy access to the functionality that many apps now bind to Ctrl-Space. The number of apps that bind Ctrl-Space keeps growing and changing the Fedora ibus shortcut is more practical than patching everything else.
I think it's not for ibus only but vice-versa.
East Asian users likely have run into this "Ctrl-space keyboard shortcut conflict" in other contexts in recent years, ex: Ctrl-Space activates code completion in Visual Studio on Windows, so that although Fedora has indeed used Ctrl-Space for a long time (through language specific XIM servers, IIIMF, SCIM, ibus ..) if we just document this change in the release notes even the users who actually rely on ibus are unlikely to be quite understanding.
I think it's not a recent year. we use Control+Space for more than ten years. I had even changed the keybinding in Visual C++ on Windows and used Control+Space for MS-IME.
The problem here is that 2 established conventions conflict: It is common convention for IDEs that Ctrl+Space triggers completion. It is also common convention for input methods that Ctrl+Space switches method/layout.
Just to note here, FESCo has their initial discussion on this issue in meeting log http://meetbot.fedoraproject.org/fedora-meeting/2012-02-06/fesco.2012-02-06-18.00.log.html
It would be really good to get to the bottom of why people are seeing ibus running unexpectedly on their desktops - it should not be happening: ibus should only be running by default for East Asian users (locales).
So, this is supposed to be the default:
{{{ _im_language_list="as bn gu hi ja kn ko mai ml mr ne or pa si ta te th ur vi zh" _sourced_xinputrc=0 for i in $_im_language_list; do if echo $tmplang | grep -q -E "^$i"; then source "$SYS_XINPUTRC" READ_XINPUTRC=$SYS_XINPUTRC _sourced_xinputrc=1 break fi done # Locales that usually use X locale compose # FIXME: which other locales should be included here? if [ $_sourced_xinputrc -eq 0 ]; then _xcompose_language_list="am_ET el_GR fi_FI pt_BR ru_RU" for i in $_xcompose_language_list; do if echo $tmplang | grep -q -E "^$i"; then source /etc/X11/xinit/xinput.d//xcompose.conf READ_XINPUTRC=/etc/X11/xinit/xinput.d//xcompose.conf _sourced_xinputrc=1 break fi done fi if [ $_sourced_xinputrc -eq 0 ]; then # Read none.conf to set up properly for locales not listed the above. source /etc/X11/xinit/xinput.d//none.conf READ_XINPUTRC=/etc/X11/xinit/xinput.d//none.conf fi }}}
where SYS_XINPUTRC is governed by alternatives, and tends to be ibus on new installs. In other words, ibus should not be running in most locales.
I suggest that this default is reasonable for most users, and any cases where the default is different are probably bugs and should be treated as such.
Fesco agreed today at the 2012-02-27 meeting: treat other cases (e.g. ibus running in en_US) as bugs, no FESCo decission necessary
Login to comment on this ticket.