#716945 fcitx starts on KDE4/GNOME3 despite im-config settings

Package:
fcitx
Source:
fcitx
Submitter:
Osamu Aoki
Date:
2013-08-10 07:51:05 UTC
Severity:
normal
#716945#5
Date:
2013-07-15 07:48:21 UTC
From:
To:
This is somewhat continuation of closed bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714914
It was unreproduceble for environment parameters but annoying unintended
start of fcitx under GNOME3 was another side of the problem.

I had similar issue under new jessie KDE.  When broken ibus package is
installed and im-config selects ibus, ibus is started but fails.  When
there is no ibus running, fcitx starts automatically despite environment
parameter etc.  It was strange but at least it was not caused by
im-config. So let's keep this under fcitx.

I saw the following in http://bugs.debian.org/716898 for im-config:
                     ^^^^^^^^^^^^^^^^^^^^^^^

It seems fcitx has special autostart using dbus.  When fcitx was started
unintentinally, I saw it was initiated by dbus via "ps aux".  Is this
the right approach to start IM?


If such autostart mechanism is loaded, it should be selectable among
 ibus fcitx scim.

Or it should mention im-config to disable starting IM is not usable in
README.Debian of fcitx at least.

We do not need to rush to close this bug.  We can wait for how things
turn out for im-config compatibility layer for KDE and GNOME3.  I was
thinking to impliment blacklist for im-config.  But this kind of
behavior by fcitx may interfere with such implementation.

Osamu
#716945#10
Date:
2013-08-09 06:51:52 UTC
From:
To:
Yes, it is indeed caused by Fcitx.

It is because fcitx installs an xdg autostart file, so that if a
desktop environment supports this mechanism, a script under
/usr/bin/fcitx-autostart is executed. There is a mechanism to detect
if there is already an fcitx instance runing, or another application
is holding XIM (i.e. ibus). If it believes no others is running, fcitx
will continue to initialize.

I think this is because we still don't have xdg autostart support in im-config?
#716945#15
Date:
2013-08-09 06:51:52 UTC
From:
To:
Yes, it is indeed caused by Fcitx.

It is because fcitx installs an xdg autostart file, so that if a
desktop environment supports this mechanism, a script under
/usr/bin/fcitx-autostart is executed. There is a mechanism to detect
if there is already an fcitx instance runing, or another application
is holding XIM (i.e. ibus). If it believes no others is running, fcitx
will continue to initialize.

I think this is because we still don't have xdg autostart support in im-config?
#716945#20
Date:
2013-08-10 07:46:39 UTC
From:
To:
Hi,
...

Yes, I see it now.
intentionally to ensure older environment not following freedesktop
standard can also get proper IM support.

I installed fcitx and used it with im-config with:
 * /etc/xdg/fcitx.desktop removed manually.
 * im-config sets IM to fcitx

fcitx starts nicely in sid/GNOME3.

Please let me know the advantage over current start method.  I mean what
does fcitx loose if it were started from im-config hook script?

If there is any advantage, I will add support.
(But without advantage, there is no reason to make things more
complicated than needed.)

If we see advantage of using XDG autostart, this is what is needed.  And
that is why I mentioned.

Even then, please note fcitx should not place file at
/etc/xdg/fcitx.desktop.

It should be im-config placing file there.  Then that starts selector
script based in im-config setting.

This is relatively simple to implement.

If we do this, we need to disable current im-launch script for all XDG
compliant DM.

Osamu