Ticket #798 (closed maintainer issue: fixed)

Opened 2 years ago

Last modified 2 years ago

ibus makes Ctrl+Space a global shortcut

Reported by: akurtakov Owned by:
Priority: major Keywords:
Cc: fujiwara, overholt, i18n-team Blocked By:
Blocking:

Description

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

Change History

comment:1 Changed 2 years ago by akurtakov

I forgot to add the implementation recommendation: ibus should not use ctrl+space as global shortcut

comment:2 follow-up: ↓ 5 Changed 2 years ago by 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.

comment:3 follow-up: ↓ 6 Changed 2 years ago by sgallagh

  • Cc fujiwara added

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?

comment:4 Changed 2 years ago by overholt

  • Cc overholt added

comment:5 in reply to: ↑ 2 ; follow-ups: ↓ 7 ↓ 8 Changed 2 years ago by akurtakov

Replying to 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.

comment:6 in reply to: ↑ 3 Changed 2 years ago by fujiwara

Replying to 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.
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.
I don't use your listed applications as daily works except for emacs.
Probably I think you could customize the emacs key-binding or Control+@ or customize ibus.

comment:7 in reply to: ↑ 5 Changed 2 years ago by fujiwara

Replying to akurtakov:

Replying to 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.

comment:8 in reply to: ↑ 5 Changed 2 years ago by tagoh

Replying to akurtakov:

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.

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.

comment:9 follow-up: ↓ 10 Changed 2 years ago by mitr

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?

comment:10 in reply to: ↑ 9 Changed 2 years ago by fujiwara

Replying to 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?

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.

comment:11 follow-up: ↓ 12 Changed 2 years ago by scottt

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.

comment:12 in reply to: ↑ 11 Changed 2 years ago by fujiwara

Replying to 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.

  1. 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.

comment:13 Changed 2 years ago by kkofler

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.

comment:14 Changed 2 years ago by pnemade

  • Cc i18n-team added

comment:15 Changed 2 years ago by pnemade

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

comment:16 Changed 2 years ago by petersen

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).

comment:17 Changed 2 years ago by mitr

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.

comment:18 Changed 2 years ago by kevin

  • Status changed from new to closed
  • Resolution set to fixed

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

Note: See TracTickets for help on using tickets.