@DataDrake It seems you've been handling a lot of the ibus stuff, do you know anything about how to fix this?

I've had mixed experiences getting this to work correctly. There definitely seems to be issues with older applications. I'm a bit swamped with my day job, but I'll definitely take a look when I have a chance.

OK one more fix: https://git.solus-project.com/packages/ibus/commit/?h=ibus-1.5.14-9

budgie-desktop-branding fix https://git.solus-project.com/packages/budgie-desktop-branding/commit/?h=budgie-desktop-branding-6-17

FWIW I'm still not completely happy with it. For it to work exactly how I want, we'll need budgie-daemon to provide the candidate window.

I'm getting this problem for Chinese input too. Glad to see it's being worked on!

I'm having this problem for quite some time too.

• I installed ibus + chinese input pinyin using the Software Center, but the ibus icon never appears in the top panel, neither the input candidate window, despite ibus-deamon being running
• my workaround is:
  1. open a terminal
  2. run ibus exit; ibus-daemon &
• after that the ibus icon is visible and works as expected, but only in the terminal window
• if I want to use ibus in other apps (e.g. firefox), I have to launch the app from the terminal

Thanks for your help!

I've been using a similar workaround. The ibus candidate window now appears for some apps:

• Firefox
• gedit (gtk-based)
• gnome-terminal (gtk-based)
• lyx (Qt-based)
• libreoffice
• WPS

but still does not appear for many others:

• Chrome and other webkit-based apps
• atom editor, wechat messenger client and other electron-based apps
• gvim
• skype client
• hexchat irc client

I previously thought that the problem was associated with Qt toolkit and proposed to add ibus-qt plug-in to solus.
However, when I built ibus-qt locally, it didn't help at all. From the list above, it seems that the problem isn't specific to a toolkit.

This is the top reason why I'm recommending my colleagues not to switch yet.

Adding the following autostart command seems to fix the issue:

ibus-daemon -r -d

I think Budgie is the best desktop environment for my use case, however, I am still not able to use it anywhere else than on a testing laptop, only because of the IBus issue and German keyboard layouts not working on a laptop with an American keyboard. I know all of this will be solved by the time Budgie 11 is around, but that might take a while. Any chance a temporary fix could be implemented so that some users may migrate to Budgie earlier?

I've improved my workaround for this issue, re-using the command provided by @whenkek

In my case, I only need pinyin and zhuyin, but Budgie integration is broken when installing using the Software Manager, so I run these commands instead:

sudo eopkg it ibus ibus-libpinyin ibus-libzhuyin
mkdir -p ~/.config/autostart
cat > ~/.config/autostart/IBus.desktop <<EOF
[Desktop Entry]
Type=Application
Name=IBus
Description=
Exec=/usr/bin/ibus-daemon -r -d
EOF

• It installs software packages, then create the restart task to be run after login.
• It only needs to run once
• After this IBus works perfectly and input candidates window displays properly

After the recent introduction of usysconf, ibus input methods work properly with all the software i'm using. So my previous comment (Jul 18 2017) is now obsolete.
However, the autostart script suggested by @seb is still needed.
I hope this script can be absorbed in the desktop environment or the ibus package, so the user doesn't have to add the script manually.

I hope this script can be absorbed in the desktop environment or the ibus package, so the user doesn't have to add the script manually.

ibus-daemon -r -d is not a sustainable solution, at least when using Budgie as it will cause the window manager to crash. Will need another solution.

In T3066#94660, @baimafeima wrote:

I hope this script can be absorbed in the desktop environment or the ibus package, so the user doesn't have to add the script manually.

ibus-daemon -r -d is not a sustainable solution, at least when using Budgie as it will cause the window manager to crash. Will need another solution.

ibus-hangul user here. I can confirm that a candidate window for the Korean-Chinese conversion does appear after running ibus-daemon -r -d command. But as @baimafeima said, there should be a better solution. Screenshots follow:

Before ibus-daemon -r -d:

After ibus-daemon -r -d:

Thanks!

I installed Solus and ibus-pinyin (Chinese IME) for my parents. There are two issues which were resolved:

1. If you select Chinese (China) input in "Region & Language" under Settings, it doesn't work. You have to install the Pinyin (ibus-pinyin) package, remove Chinese, and then add/select Pinyin. Chinese keyboards are usually standard QWERTY, so the default selection for it is practically useless.
2. Afterwards, the context menu for selecting candidate characters does not appear (i.e. topic of this thread). Seb's script for "ibus-daemon -r -d" was needed; however, I added the autostart command through Raven. Perhaps, the autostart config formatting or file location was changed?

Thanks for the fixes and support of CJK inputs. Please update documentation since most web searches regarding this topic point to old Solus forum posts stating Asian input methods aren't possible.

This has been one of the most long-lived bugs. For me it's still a critical one and I hope as the community grows there's eventually someone who will find a solution to it. There has also been some related discussion on GitHub on this issue: https://github.com/solus-project/budgie-desktop/issues/729

Frankly ibus has been a constant source of trouble for years. I had better luck with fcitx on Ubuntu since 14.04. I wonder what's reason of choosing ibus over fcitx in solus/budgie?

I've contacted an IBus developer and perhaps they found a solution: https://github.com/ibus/ibus/issues/2038

Fujiwarat wrote:

I think budgie-wm should not run ibus-daemon with --panel disable from your bug description.
https://github.com/solus-project/budgie-desktop/blob/master/src/wm/ibus.vala#L81
The workaround would be to restart ibus-daemon without --panel disable.
% ps -ef | grep ibus
% ibus exit
% ps -ef | grep ibus
% ibus-daemon --xim &

Even with the ibus-daemon -drx workaround, ibus is almost unusable (at least with ibus-libpinyin). ibus will freeze all keyboard inputs frequently, which requires ibus-daemon is restarted.
In some cases, the ibus-daemon restart will cause budgie-wm to crash.

Since there isn't any progress in fixing the problem in ibus, I decided to switch to fcitx. Spent a full day building fcitx packages, and the result is absolutely worth it.

Ibus may be the orthodox input framework for gnome, but the user experience is too bad, for me and I believe for many other users.

This is unfortunate since IBUS is the only input method for east Asian (Chinese, Japanese, Korean) languages in the Solus repo at the moment. A workaround is here, but for many users, it is unlikely they will find the info in this thread to implement it. Moreover, as previous commenters have said, using this with Budgie is rather unstable and will freeze all inputs sometimes.

Also related to this issue: if you select these languages during Solus install or add the input method under Settings/Region&Language, you'll get the standard Latin (i.e. English, etc.) keyboard inputs without character candidate selection drop-down window, making it practically useless.
For example, if you select Japanese, you will still need to install the Anthy (ibus-anthy) package, remove Japanese from "Input Sources" and then add Anthy under that section in "Region & Languages." Same is true for Chinese (ibus-pinyin and/or ibus-zhuyin) and Korean (ibus-hangul).
Afterwards, you'll need to run 'ibus-daemon -rdx' command in order to actually type anything in these languages.

I know all this has been said before, but I wanted to reiterate in case this comes up in a web search. Hopefully, when Josh and the devs have more time to work on Budgie, it'll get fixed in the future. Thanks anyway for taking a look at it. Perhaps somebody should request and add 'fcitx' to the Solus repo. I haven't used it myself, so those who prefer it over IBus, please do so.

@jeos fcitx works well for me (Chinese input). It had been proposed for inclusion in #T1298 but rejected.