@ngraham Is it intentional that ibus doesn't work well with KDE Plasma?

@ngraham Is it intentional that ibus doesn't work well with KDE Plasma?

ibus is a rather out-of-time program which works badly sometime especially on KDE. Gnome however introduces ibus as a part of Gnome Shell so that it works well. Fcitx5 is very good so today it is not recommended to use ibus unless on Gnome.
I donot know whether it is intentional, but when I told my friend who use KDE much this problem he just say that it is ridiculous to use ibus on kDE.

It's never intentional when something doesn't work or integrate well. :) It is however known. In general we don't have a great input method story in KDE Plasma, not at all like the polished experience that GNOME offers. It's something we urgently need to work on.

Are there any upstream KDE bugs or something tracking that?

Not really. It's almost too big for that. Needs some discussion about how we proceed. I can see if I can get that conversation started.

Is that on Wayland or X11?

There have been quite some fixes recently for IME things on Wayland that will be part of 5.24

There was a GSOC project on improving the IME-related configuration, however the project got stalled before we were able to integrate the work and the author is unresponsive.

The current WIP is at https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/37, but properly rebasing and integrating it will be a significant effort.

That said it it only about the configuration and setup side of things. If it was setup correctly and is still not working that would need to be addressed elsewhere in the stack

We have fcitx5 packaged in Fedora so if it works better we can ship it instead or in addition.

Does fcitx5 works on Wayland?

Does fcitx5 works on Wayland?

short answer: yes
long answer: https://github.com/fcitx/fcitx5/issues/206

We have fcitx5 packaged in Fedora so if it works better we can ship it instead or in addition.

my understanding is that the choice of ibus vs fcitx vs something else is also dependent on preferences of the individual language communities, so just swapping out one for the other is likely not going to satisfy everyone

Take anything I say with a grain of salt though. I know some things about the technical workings of input methods, but not being a user of them I have no practical experience with them

Is that on Wayland or X11?

There have been quite some fixes recently for IME things on Wayland that will be part of 5.24

My experience was on in Wayland. I try on X11 today and all fine. Maybe it is a KDE-wayland bug.

I think we need to include imsettings-systemd to get ibus working.

On Wayland IBus cannot position the pop-up window correctly for Qt applications at all. It always shows up in the top left corner of the screen instead of following the cursor. Using IBus by default with the KDE spin, where most applications are in Qt and Wayland is enabled by default, would really be a broken experience out of the box.

Currently Fcitx5 works perfectly in KDE Wayland, and also has good (if not the best) support for all environments.
See:
https://www.csslayer.info/wordpress/linux/use-plasma-5-24-to-type-in-alacritty-or-any-other-text-input-v3-client-with-fcitx-5-on-wayland/
https://github.com/fcitx/fcitx5/issues/206#issuecomment-762511291
https://www.csslayer.info/wordpress/fcitx-dev/client-side-input-panel-for-fcitx-5/

In the end it might just make sense to settle on fcitx, yeah. It's got good Plasma integration and its maintainer is a KDE contributor. Maybe we should just use it instead of our typical KDE thing of trying to please everyone by writing an abstraction layer that lets you swap out one thing for another thing.

Speaking from my experience, fcitx5 works very well on Wayland, I strongly think we should use it by default. Ibus is just broken for me on Wayland.

One thing to consider is that the extra exports in /etc/bashrc were also necessary for me to get fcitx5 working. Ideally this should be automated or done by default.

@petersen PTAL

OK, let's give fcitx5 a try given that the experience with ibus is poor right now anyway.
Is installing fcitx5 enough? What else should we do? Are those the exports that need to be set somwhere?

export QT_IM_MODULE=ibus
export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus

https://fcitx-im.org/wiki/Setup_Fcitx_5#Environment_variables maybe

OK, let's give fcitx5 a try given that the experience with ibus is poor right now anyway.
Is installing fcitx5 enough? What else should we do? Are those the exports that need to be set somwhere?

export QT_IM_MODULE=ibus export GTK_IM_MODULE=ibus export XMODIFIERS=@im=ibus

No. If want to use fcitx5, you need tp install like fcitx5 fcitx5-gtk fcitx5-qt fcitx5-chinese-addons fcitx5-autostart and so on...to make it works.
The environment should be

GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx

However, fcitx5-autostart will help to set env automatically. So you just need to preinstall right rpm for Fedora kde.
I will think of a list of recommended preinstall rpm soon.

OK, let's give fcitx5 a try given that the experience with ibus is poor right now anyway.
Is installing fcitx5 enough? What else should we do? Are those the exports that need to be set somwhere?

export QT_IM_MODULE=ibus export GTK_IM_MODULE=ibus export XMODIFIERS=@im=ibus

Vital packages (necessary):
fcitx5.x86_64 : Next generation of fcitx
fcitx5-configtool.x86_64 : Configuration tools used by fcitx5
fcitx5-data.noarch : Data files of Fcitx5
fcitx5-gtk.x86_64 : Gtk im module and glib based dbus client library
fcitx5-gtk2.x86_64 : fcitx5 gtk module for gtk2
fcitx5-gtk3.x86_64 : fcitx5 gtk module for gtk3
fcitx5-gtk4.x86_64 : fcitx5 gtk module for gtk4
fcitx5-qt.x86_64 : Qt library and IM module for fcitx5
fcitx5-qt-libfcitx5qt5widgets.x86_64 : Provide libFcitx5Qt5WidgetsAddons for fcitx5
fcitx5-qt-libfcitx5qtdbus.x86_64 : Provides libFcitx5Qt5DBusAddons for fcitx5
fcitx5-qt-module.x86_64 : Provides seperately modules for fcitx5-qt
fcitx5-qt6.x86_64 : Qt 6 support for fcitx5

lua script support
fcitx5-lua.x86_64 : Lua support for fcitx

autostart: to automatically set env and start fcitx5
fcitx5-autostart.noarch : This package will make fcitx5 start with your GUI session

KDE configtools (pnly needs for kde)
kcm-fcitx5.x86_64 : Config tools to be used on KDE based environment.

input method (whitout these packages not input method really avaliable. Majorly needs for Asian language users)
fcitx5-anthy.x86_64 : Anthy Wrapper for Fcitx5
fcitx5-chinese-addons.x86_64 : Chinese related addon for fcitx5
fcitx5-chinese-addons-data.noarch : Data files of fcitx5-chinese-addons
fcitx5-hangul.x86_64 : Hangul Wrapper for Fcitx5
fcitx5-kkc.x86_64 : Libkkc input method support for Fcitx5
fcitx5-libthai.x86_64 : Libthai Wrapper for Fcitx5
fcitx5-m17n.x86_64 : m17n Wrapper for Fcitx5
fcitx5-mozc.x86_64 : A wrapper of mozc for fcitx5
fcitx5-sayura.x86_64 : Sinhala Transe IME engine for Fcitx5
fcitx5-skk.x86_64 : Japanese SKK (Simple Kana Kanji) Engine for Fcitx5
fcitx5-table-extra.noarch : Extra tables for Fcitx5
fcitx5-table-other.noarch : Other tables for Fcitx5
fcitx5-unikey.x86_64 : Unikey support for Fcitx5
fcitx5-zhuyin-data.noarch : Data files for fcitx5-zhuyin
fcitx5-chewing.x86_64 : Chewing Wrapper for Fcitx
fcitx5-rime.x86_64 : RIME support for Fcitx
fcitx5-zhuyin.x86_64 : Libzhuyin Wrapper for Fcitx

migrator packages (not needed for most condition):
fcitx5-migrator.x86_64 : Migration tools for fcitx5

devel packages (not needed for most condition):
fcitx5-chinese-addons-devel.x86_64 : Development files for fcitx5-chinese-addons
fcitx5-devel.x86_64 : Development files for fcitx5
fcitx5-gtk-devel.x86_64 : Development files for fcitx5-gtk
fcitx5-migrator-devel.x86_64 : Devel files for fcitx5-migrator
fcitx5-qt-devel.x86_64 : Development files for fcitx5-qt
fcitx5-lua-devel.x86_64 : Development files for fcitx5-lua

@siosm
I ask author of fcitx5 and here is his recommend:
1、Which package to install
https://fcitx-im.org/wiki/Install_Fcitx_5
necessary: fcitx5 fcitx5-gtk fcitx5-qt fcitx5-configtool
Also you can see my list above to find out which package also very important

2、engines to install
https://fcitx-im.org/wiki/Input_method_engines
Engines of fcitx5 is similar to engines of ibus. If possible, you can just preinstall it just as ibus.

3、flatpak
flatpak version of fcitx5 exists. However there are two problem.
(1) not all engines available in flatpak version.
(2) You still have to install like fcitx5-qt and fcitx5-gtk by rpm or flatpak version of fcitx5 will not work.

Thanks, will give this a try

The settings requested in the OP comment are automatically set by imsettings right now on startup. However, @apol, @petersen, @fujiwara, @mfabian, @siosm, and I agreed in a meeting today that we don't actually want to rely on environment variables to force an input method, since Plasma is supposed to be able to pick things up by using the Wayland protocols.

The workaround to use the protocols correctly at the moment is to uninstall imsettings and delete the imsettings-*.conf files in ~/.config/enviornment.d that it created and reboot. Then Plasma's normal input method detection and selection system should work.

I'm being told now that starting with Plasma 5.27, it will no longer be possible at all to use ibus, and we will need to swap in fcitx5. That said, also apparently Plasma will no longer require ibus for the emoji selector, so we only need to have one IME now for everything to work.

@apol, @ngraham: is this true?

If it is, let's go ahead and make the switch for Rawhide/F38 (which will introduce Plasma 5.27).

I am not aware of any changes that would make that a thing, certainly not within Plasma.

Same. Where did you hear that?

fusionfuture said as much on the Fedora KDE Matrix room.

I'm being told now that starting with Plasma 5.27, it will no longer be possible at all to use ibus, and we will need to swap in fcitx5.

No, I didn't mean that.

That said, also apparently Plasma will no longer require ibus for the emoji selector, so we only need to have one IME now for everything to work.

Yes, I actually mean that.

https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1158

There is an update in https://bugzilla.redhat.com/show_bug.cgi?id=2076596 asking for testing.

Apparently this is fixed with https://bugzilla.redhat.com/show_bug.cgi?id=2076596#c32 in Fedora 39 so we could re-enable that for Kinoite there.