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.
