Page MenuHomeSolus

Ibus input candidate window does not display
Closed, WontfixPublic

Description

For alternative input methods under ibus (Anthy, Pinyin, etc.) a candidate window should display the possible conversions for the inputted text. As of right now, no candidate window is displayed which severely cripples the usability of these IMEs. I couldn't find any options to turn this feature on, nor have I ever had to turn this feature on in any other distribution.

For reference;
Without candidate window:


With candidate window:

joguSD created this task.Mar 27 2017, 11:42 PM

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

seb added a subscriber: seb.Apr 11 2017, 6:07 AM
ikey closed this task as Resolved.Apr 16 2017, 3:15 AM
ikey claimed this task.
ikey added a subscriber: ikey.
ikey reopened this task as Open.EditedApr 16 2017, 3:22 AM

Nope ibus-daemon is trash by default and breaks NON ibus layouts to US.....

ikey closed this task as Resolved.Apr 16 2017, 3:58 AM

Alright now it's fixed :P

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.

ikey reopened this task as Open.Apr 16 2017, 5:11 PM

Sigh. I've had to revert this as it breaks more than it fixes.

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

seb added a comment.Jul 18 2017, 12:48 AM

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.

whenkek added a subscriber: whenkek.Aug 8 2017, 6:36 AM

Adding the following autostart command seems to fix the issue:

ibus-daemon -r -d
tzhao11 added a subscriber: tzhao11.Sep 8 2017, 3:26 AM
timc added a subscriber: timc.Sep 21 2017, 2:04 PM

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?

seb added a comment.Oct 4 2017, 4:44 AM

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.

jemin_jeon added a comment.EditedDec 28 2017, 2:57 PM

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!

jeos added a subscriber: jeos.Aug 22 2018, 5:38 PM

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.

DataDrake triaged this task as Normal priority.Oct 16 2018, 4:41 PM
DataDrake moved this task from Backlog to System and Configuration Fixes on the Software board.
JoshStrobl closed this task as Wontfix.Feb 9 2019, 8:23 PM
JoshStrobl added a subscriber: JoshStrobl.

Closing as wontfix. The ibus icon stuff is persistent even when it is not necessary. I'll see about improving the state of IBUS and maybe have a conditional showing of the ibus dialog / tray icon for specific locales for Budgie 11.

jeos added a comment.Feb 10 2019, 3:26 PM

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.