[Pkg-ime-devel] Bug#716945: fcitx starts on KDE4/GNOME3 despite im-config settings

Aron Xu happyaron.xu at gmail.com
Fri Aug 9 06:51:52 UTC 2013


On Mon, Jul 15, 2013 at 3:48 PM, Osamu Aoki <osamu at debian.org> wrote:
> Package: fcitx
> Version: 1:4.2.7-2
> Severity: normal
>
> 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.
>

Yes, it is indeed caused by Fcitx.

> I saw the following in http://bugs.debian.org/716898 for im-config:
>
>> > 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.
>> >m
>> >  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.)
>
> 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?
>

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.

>
> 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.
>

I think this is because we still don't have xdg autostart support in im-config?

> 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
>




-- 
Regards,
Aron Xu



More information about the Pkg-ime-devel mailing list