[Pkg-ime-devel] Bug#716898: im-config: dynamic configuration capability of IM

[Aron Xu]

On Sun, Jul 14, 2013 at 8:04 PM, Osamu Aoki <osamu at debian.org> wrote:
> Package: im-config
> Version: 0.22-3
> Severity: wishlist
>
> This is not really about im-config itself but about life after im-config.
>
> im-config (or its previous life as im-switch included) needs to be
> activated by the starting of the X via Xsession.  This interface is used
> by by im-config (or im-switch).  Another way to start IM is from XDG
> autostart (/etc/xdg/autostart/) instead of Xsession.  So extending
> im-config (or im-switch) to use this can be done by this route for
> GNOME3 Dynamically resetting environment variable is not a part of
> design for im-config.  These are basic design issues. Switching
> different IM tools requires to restart X session even with this XDG
> autostart extension.
>
> Tago-san's im-chooser can dynamically update IM without restarting X
> so it looks better.
>
> https://fedorahosted.org/im-chooser/
>  https://fedorahosted.org/im-chooser/wiki/ImChooser
>  http://tagoh.bitbucket.org/imsettings/
>  Supported Toolkits
>     * GTK+
>     * LXDE
>     * MATE
>     * Qt
>     * XFCE
>     * X (with IMSettings XIM server; require libgxim)
>
> I do not know how im-chooser workis with GNOME3.
>

I don't think they have being worked out the problem between
imsettings and gnome-settings-daemon. And it seems that GNOME people
would like to push forward to deprecate imsettings someday. I agree
that the feature list of imsettings looks more attractive than
im-config, and I want to know your opinion that will it be an option
to use imsettings in the future?

Personally, I think starting input method by the DE is the next to go,
i.e. done by gnome-settings-daemon and kdeinit/kded. This enables the
DE to implement better integrated experience of input methods. For DEs
do not have this support, or people who don't use a DE, then tools
like im-config and imsettings are still needed. I believe this means
some detection on both sides to determine who should be responsible on
starting and maintaining IMs.

> As for GNOME3 gnome-shell related GUI configuration, I found a post for
> similar issues on Ubuntu bug list for im-switch by Ma:
>  https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/875435
>
>  A better approach of supporting IBus and other IM framework is using a
>  separate UI.  The UI can be very native to DE concerned and it
>  communicates with the IM framework concerned through DBus.
>
>  I've found four existing examples:
>  https://github.com/tualatrix/fcitx-gimpanel (DE: Unity, IMF: Fcitx)
>  https://github.com/fujiwarat/ibus-gjs (DE: GNOME, IMF: IBus)
>  http://userbase.kde.org/Tutorials/Kimpanel (DE: KDE, IMF: Multiple)
>  https://github.com/csslayer/kimpanel-for-gnome-shell (DE: GNOME, IMF: Multiple)
>

I agree that separate UI can be the best idea of supporting different
situations, and in Fcitx we are using DBus as the canonical message
bus for virtually everything. An example is that Fcitx does not have
any indicator related dependencies, but it can appear in Ubuntu's
appmenu with full functions, this is just the opposite way that what
Ubuntu uses to implement ibus's indicator patch.

(Note that fcitx-gimpanel is semi-abandoned and
kimpanel-for-gnome-shell is the recommended way of using Fcitx under
Gnome Shell.)

> (The original bug for im-switch discussed in the bug report is not fixed
> in Debian but the effectively same fix is done.)
>
> At any rate, this is something to think about.
>

Best wishes,
Aron