When compared to GNOME and its derivatives, the integration of input method frameworks is severely lacking in KDE. While IBUS is seamlessly integrated and readily available in GNOME, Unity and Cinnamon, it takes several hoops in KDE 4.x series across different settings to get it configured on somewhat usable level. While all it takes in GNOME is to enable certain non-latin language such as Chinese in inputs (three clicks) after which it is ready to be used in all applications with users physical keyboard layout intact underneath for easy switching, this is what needs to be done in KDE: https://wiki.archlinux.org/index.php/Ibus#Kimpanel and like said YMMV. It may work in all programs, or it might work differently in Qt compared to GTK applications or not at all in wx-applications and so forth.

The alternative Fcitx is not much better in that regard, as it also requires external configuration panel and few hoops to tackle to get it working at all. The situation for both is quite archaic in lack of better word. Kubuntu is the closest to get it right, and even there enabling the support runs script requiring few OK's and password to get input method for non-latin languages via IBUS up and running, and then manually wander around multiple setting places and manually put kimpanel. Far cry from what GNOME and its derivatives does.

Here is deplist for Fcitx, which looks like it would be better suited candidate for integrating into KDE:

[~]$ yum deplist fcitx.x86_64
/bin/sh
/usr/bin/env
/usr/sbin/alternatives
fcitx-data = 4.2.8.4-1.fc20
fcitx-gtk2 = 4.2.8.4-1.fc20
fcitx-gtk3 = 4.2.8.4-1.fc20
fcitx-libs = 4.2.8.4-1.fc20
imsettings
libc.so.6(GLIBC_2.8)(64bit)
libdbus-1.so.3()(64bit)
libdl.so.2()(64bit)
libfcitx-config.so.4()(64bit)
libfcitx-core.so.0()(64bit)
libfcitx-utils.so.0()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
rtld(GNU_HASH)

FYI, here is also deplist for IBUS. It has more dependencies in GTK and GNOME technologies, but is vastly superior and more mature.

[~]$ yum deplist ibus.x86_64
/bin/sh
/usr/sbin/alternatives
dbus-python >= 0.83.0
dbus-x11
dconf
desktop-file-utils
ibus-gtk2(x86-64) = 1.5.7-2.fc20
ibus-gtk3(x86-64) = 1.5.7-2.fc20
ibus-libs(x86-64) = 1.5.7-2.fc20
ibus-setup = 1.5.7-2.fc20
ibus-wayland(x86-64) = 1.5.7-2.fc20
iso-codes
libX11.so.6()(64bit)
libXi.so.6()(64bit)
libatk-1.0.so.0()(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libcairo-gobject.so.2()(64bit)
libcairo.so.2()(64bit)
libdconf.so.1()(64bit)
libfontconfig.so.1()(64bit)
libfreetype.so.6()(64bit)
libgdk-3.so.0()(64bit)
libgdk-x11-2.0.so.0()(64bit)
libgdk_pixbuf-2.0.so.0()(64bit)
libgio-2.0.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libgthread-2.0.so.0()(64bit)
libgtk-3.so.0()(64bit)
libgtk-x11-2.0.so.0()(64bit)
libibus-1.0.so.5()(64bit)
libnotify.so.4()(64bit)
libpango-1.0.so.0()(64bit)
libpangocairo-1.0.so.0()(64bit)
libpangoft2-1.0.so.0()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
librsvg2
pygobject3-base
python(abi) = 2.7
python(abi) = 3.3
python3-gobject
rtld(GNU_HASH)
xorg-x11-xinit
xorg-x11-xkb-utils

I tried posting this issue to kde-usability mailing list but since I'm not recognized developer, I can't communicate with developers either, so it didn't get published. Are any plans to make the situation better in KDE 5.x (using it as abbreviation for Frameworks 5 + Plasma 5 here), bringing the user experience of non-latin users on same level as other desktops currently enjoy? There definitely should be, and I feel like integrating some IME is the right thing to do. There are, what, three billion people on this planet not using latin characters in daily life.

When compared to GNOME and its derivatives, the integration of input method frameworks is severely lacking in KDE. While IBUS is seamlessly integrated and readily available in GNOME, Unity and Cinnamon, it takes several hoops in KDE 4.x series across different settings to get it configured on somewhat usable level. While all it takes in GNOME is to enable certain non-latin language such as Chinese in inputs (three clicks) after which it is ready to be used in all applications with users physical keyboard layout intact underneath for easy switching

For KDE, you just install fcitx and it works. Tools to setup environment variables are provided by distributions.

this is what needs to be done in KDE: https://wiki.archlinux.org/index.php/Ibus#Kimpanel

This is what you need to get kimpanel works with IBus. For fcitx, it works by default.

The alternative Fcitx is not much better in that regard, as it also requires external configuration panel

By externel you mean the integrated kcm configure module?

few hoops to tackle to get it working at all.

If by that you mean enviroment variables, it should really be provided by the distributions.

The situation for both is quite archaic in lack of better word. Kubuntu is the closest to get it right, and even there enabling the support runs script requiring few OK's and password to get input method for non-latin languages via IBUS up and running, and then manually wander around multiple setting places and manually put kimpanel. Far cry from what GNOME and its derivatives does.

For Fcitx, you don't have to use kimpanel either. It comes with auto start desktop file so it should starts automatically when you login again. The proper configure interface is also launched in a DE dependent order if you have installed any. The classic ui (default UI when there's not Kimpanel) also come with status notification support meaning it will work nicely with Unity and KDE system tray without using the old XEmbed protocol.

So in order to get Fcitx works, all what you need is installing the pacakges. For distributions like OpenSUSE, and Debian based ones, this also allows you to select fcitx as input method and the enviroment variable settings will be taken care of too. There are a few optional components that might not be installed by default on some distributions like kcm-fcitx and kimpanel and if that is your problem, you should rather talk to the distribution maintainer.

yyc1992 wrote:For KDE, you just install fcitx and it works. So in order to get Fcitx works, all what you need is installing the pacakges.

So far for the theory. I am working mainly in pure CJK environments, and AFAICS Fcitx is not at all better integrated nor does it work more reliable than iBus. On the last system (kubuntu) I installed I also tried to use Fcitx, but it didn't work at all. Uninstall Fcitx, install iBus and reconfigure was the only option. config files seemed fine but switching to iBus was the fastest solution in that case.

Fcitx from the above mentioned system seemed to work flawlessly in a non-CJK environment but not when I tried to use it in a CJK environment, which seems to be one of the problems. Most of the code is written by people who do not(!) live in East Asia, so they check programs under their system. The result they get might differ from what people living in East Asia get. And there is still a small fraction of users who use a CJK environment but also need western input other than plain Ascii (French, German, Spanish, ...) and there the real problems start...