Complex text input in Plasma

[Heinz Wiesinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170407/150a9035/attachment.sig>