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

Osamu Aoki osamu at debian.org
Mon Jul 15 07:48:21 UTC 2013

Package: fcitx
Version: 1:4.2.7-2
Severity: normal

This is somewhat continuation of closed bug report 
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:

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

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.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages fcitx depends on:
ii  fcitx-bin      1:4.2.7-2
ii  fcitx-data     1:4.2.7-2
ii  fcitx-modules  1:4.2.7-2

Versions of packages fcitx recommends:
ii  fcitx-config-gtk       0.4.6-3
ii  fcitx-frontend-all     1:4.2.7-2
ii  fcitx-ui-classic       1:4.2.7-2
ii  im-config [im-switch]  0.22-3

Versions of packages fcitx suggests:
pn  fcitx-m17n   <none>
pn  fcitx-tools  <none>

-- no debconf information

More information about the Pkg-ime-devel mailing list