When running ibus, switching to tty and back to KDE causes ibus to be terminated. On tty, "ps aux | grep ibus" shows ibus is still running, so the process gets terminated upon switching back to KDE. Reproducible: Always Steps to Reproduce: 1. Start ibus with e.g. "ibus-daemon -drx" 2. Switch to tty. 3. Switch back to KDE. Actual Results: The ibus process no longer exists. Expected Results: The ibus daemon is still there. Journalctl: kdeinit5[1031]: ibus successfully stopped .xsession-errors has several of these: Bus::open: Can not get ibus-daemon's address.
- Can confirm this bug on Arch Linux (not reproducible on Fedora, is it patched?). - ibus is also stopped when changing keyboard settings in Systemsettings. To reproduce, open Systemsettings → Input Devices → Keyboard. Make any change, even just make one and revert, and click on Apply. ibus is stopped with `ibus successfully stopped` in journalctl. - It also seems to happen when I’m not actively behind my keyboard. - Starting ibus at startup doesn’t work (I guess it’s this same bug because it works on Fedora), I need to write a script which sleep for a few seconds, launch ibus then kill and relaunch krunner. I found the commit in plasma-desktop which introduced the «feature»: <https://quickgit.kde.org/?p=plasma-desktop.git&a=commit&h=d322ea9051c79a5d9a5eb7b48eccba54b80fa944> (the code hasn’t since been changed). This. is. terribly. awful. This code should probably be removed, even if it causes bugs, because terminating ibus is way worse. I should relaunch ibus several times a day, and I also must relaunch every open Qt5 application (really annoying with e.g. konversation) otherwise I can’t type i.e. Japanese and use dead keys anymore — and since a few days, some applications are basically left unusable (i.e. I must press several dozens of times a key to actually obtain the character). So, it’s a *really serious and awfully annoying bug*. I’m not sure the last thing I described is a KDE bug (should I open a report about that here?) because Qt4 and GTK apps works perfectly well — in fact, I just need to relaunch ibus and it’s like nothing happened (well frankly hopefully otherwise I would have been restarting Gajim and Firefox several times a day).
Still present in 5.6.2. Journalctl: kdeinit5[1167]: org.kde.kcm_keyboard: ibus successfully stopped
I also have this problem in 5.6.2, it is very annoying. Also after ibus dies, it is impossible to input any text in KDE apps (though Qt5 and GTK apps receive input fine, only KDE apps stop responding to keyboard): konsole, yakuake, kate, krunner become useless until I restart ibus-daemon manually. I found that setting "QT_IM_MODULE=<anything else except ibus>" helps to workaround this, but will disable ibus in KDE apps.
Just to correct my last comment: I have this problem with Plasma 5.7.2, not 5.6.2
Still an issue in 5.7.5. Another effect worth mentioning is that all Konsole windows (and sometimes Firefox too) stop accepting any input once ibus is terminated, i.e. when I switch back from the VT. Closing every single window and starting Konsole again makes it "operational" again, but things just really get out of hand when I have critical stuff such as vim or ssh running in the Konsole window.
At least since my last comment I don’t get the random ibus killing and I can start ibus at startup without a specific script. ibus is still killed when I get back from a TTY or when I change my keyboard configuration in the KCM. It’s a easy to fix but it’s not clear why precisely the code was introduced in the first place. In the code there’s: // stop ibus so it does not mess with our layouts, we can remove this when we integrate IM into keyboard module It sounds like it is/was a bug in ibus (and it doesn’t seem like IM will be integrated into keyboard module anytime soon). So finding a solution in the meantime would be appreciated.
I stumbled over this after upgrading my workstation from openSuSE Leap 42.1 to 42.2 (see https://bugzilla.opensuse.org/show_bug.cgi?id=1011996). Is there any resolution to this problem ?
@Thomas Schmid Leap 42.1 uses Plasma 5.5.5. Are you saying you didn't experience this on 42.1? I first reported this issue in 5.5.4, so I'm guessing openSUSE somehow went and pulled the bug from upstream along with the newer Plasma version (5.8.3).
>@Thomas Schmid >Leap 42.1 uses Plasma 5.5.5. Are you saying you didn't experience this on 42.1? Yes, I did not see this problem with Leap 42.1. >I first reported this issue in 5.5.4, so I'm guessing openSUSE somehow went and >pulled the bug from upstream along with the newer Plasma version (5.8.3). Possible. The current advice is to remove ibus-qt, which I might try.
> The current advice is to remove ibus-qt Unfortunately, this is not a solution when ibus is necessary, because KDE itself doesn't provide input engines available in ibus.
I have the same issue, i.e. switching to TTY and back kills ibus-daemon, but have managed to avoid it by disabling the "configure layouts" option in the "layouts" tab of the keyboard KCM. $ ibus-daemon -V ibus-daemon - Version 1.5.14 $ plasmashell -v plasmashell 5.7.5 $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.10 DISTRIB_CODENAME=yakkety DISTRIB_DESCRIPTION="Ubuntu 16.10" $ setxkbmap -query rules: evdev model: pc101 layout: de options: lv3:caps_switch
@Huynh Huu Long > I have the same issue, i.e. switching to TTY and back kills ibus-daemon, but > have managed to avoid it by disabling the "configure layouts" option in the > "layouts" tab of the keyboard KCM. You sir are a genius! Solved it for me. Of course, I still believe this bug should be looked into... Especially since the "configure layouts" option is enabled by default (isn't it?).
Well that doesn’t solve the problem for those who use several keyboard layouts. I use an «exotic» layout, so I need to quickly change it when I lend my computer to someone for a some manipulation.
This is a duplicate of https://bugs.kde.org/show_bug.cgi?id=379930
Merci. *** This bug has been marked as a duplicate of bug 379930 ***