On Thursday, 6 April 2017 19:16:14 CEST Eike Hein wrote: > Hi, > > In the aftermath of D5301, Martin asked to compile a document on the > requirements for complex text input in Plasma, especially with the > opportunities provided by the Wayland transition. It makes sense to > share this document with all of you, to share the knowledge more widely :)
I worked a lot recently on updating the IME support in Slackware so I'll add a couple points from my experience with that as well as from a packager perspective. I evaluated both ibus and fcitx and found that, much like Eike already explained in his initial mail, initial setup is less than ideal. This is even more so the case on Slackware, since we do not have distro-specific tooling for the user to select a language or input method. = Base setup = I'll describe the raw setup of both ibus and fcitx on Slackware, as well as some of the "improvements" I made to make this a bit simpler for the user (I guess one could call that distro-specific tooling as well). a) ibus After login you execute "ibus-setup" which checks whether the ibus daemon is running and starts it otherwise before showing its configuration dialog. Once finished with the configuration it asks to add a couple entries to the user's .bashrc file: export XMODIFIERS=@im=ibus export GTK_IM_MODULE=ibus export QT_IM_MODULE=ibus After this the user still has to manually configure Qt4 to use "ibus" as the default input method (via qtconfig), as well as add some way to start ibus- daemon automatically on login. b) fcitx fcitx is a bit userfriendlier in that it already provides xdg autostart support (though most distros disable this). So if fcitx is installed it will automatically run on login, even if the user doesn't need it. It still needs similar steps though as ibus. You configure your input methods via fcitx' configuration tool and add similar entries to .bashrc: export XMODIFIERS="@im=fcitx" export XIM=fcitx export XIM_PROGRAM=fcitx export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx You also again have to set Qt4's default input method to "fcitx". c) Modifications This plain setup leaves us with some "papercuts" though. fcitx's autostart doesn't really play well with ibus. This is, if ibus is configured and used, and both ibus and fcitx are installed, both would be running. Worst case scenario this means the user has 3 input method indicators active in the system tray (ibus, fcitx and xkb) I "fixed" this by making fcitx' autostart dependent on the user's .bashrc entries, so it only starts if fcitx is configured as input method using the before mentioned entries. I added a similar autostart script for ibus, with the effect that now at least only the one configured for the user is running and the user doesn't have to worry about the autostart part of the setup. = Distro comparison = While researching this initial setup routine I looked around at what other distros are doing, only to find that mostly all of them do something different. - Debain uses im-switch, which seems to be this: https://github.com/pkg-ime/ im-switch - Opensuse uses im-config. I couldn't really find the source for that, but it looks to work similar to Debian's im-switch - Fedora uses some kind of mechanism with xinputrc and xinput.d in order to load input methods during startup. Couldn't really find too much documentation about this either though :-/ = Future = Generally I'm very happy with this effort and I'm looking forward to an improved input method integration in Plasma 5. However, putting my distro-hat on, I really think that this is a problem that goes beyond Plasma 5. I understand that desktop specific solutions need to be found, but the same issue exists on other desktop environments and it would be a shame if they have to reinvent the wheel on their end again. Eike mentioned fragmentation in the input method field and I'd say this definitely adds to that fragmentation. If whatever solution is eventually picked leaves the door open for other desktop environments to provide the same kind of integration I think this would definitely be appreciated :) Grs, Heinz
signature.asc
Description: This is a digitally signed message part.
