Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop
Hi,
Let me recall my memory ....
On Tue, 2021-03-02 at 13:02 +0800, Shengjing Zhu wrote:
> > On 2021-03-01 15:25, Shengjing Zhu wrote:
> > > I'm not a GNOME user. But reading this, I feel it's seriously
> > > broken.
> > > GNOME shouldn't take over the responsibility of tasksel to decide
> > > what the IM engine to use.
> > > Japanese GNOME desktop users should continue to use uim if it's
> > > prefered by Japanese users.
> > > And Chinese GNOME desktop users should continue to use fcitx as
> > > their default IM engine.
> >
> > The GNOME (upstream) choice in this respect is unfortunate. A
> > flexible
> > design with support for multiple IM frameworks had of course been
> > preferable. But they made their strategic decision several years
> > ago,
> > and we won't likely make them change their mind.
We don't need to ask GNOME (upstream) to change mind to fix this
situation. This problem of GNOME hardcoding ibus is an old problem
happened during buster cycle when wayland support was added.
If I remember correctly, the initial upstream code unconditionally
overridden user settings. That was fixed but still tightly tied to
ibus. The eventual upstream allowed us to set up a mechanism for im-
config to set IM. That was buster cycle. As I posted previously, this
is a very fragile solution.
Since this worked OK, fcitx dropped its own intrusive mechanism (Ubuntu
origin?) to force using fcitx irrespective of im-config settings. So
current fcitx relyes on im-config hooks originally created by Yoshino-
san and recently updated by Gunnar. We knew this hook approach was
fragile but no one created better solution during the last moment of
buster freeze. So we added this hook as the last resort.
What we need now is not the intrusive old fcitx approach but still a
clean patch to GNOME to make default IM setting code configurable via
Gsetting etc without hook scripts. if uim or fcitx wants to be made
usable robustly. Then im-config can access it to set environment
variable and daemon cleanly. I think I mentioned offending code point
in previous related bug report. If fcitx or uim fans wishes to meke
GNOME to be friendly, they need to come up with non-intrusive mechanism
for GNOME and update im-config to use it. Patch doesn't need to be
accepted by the GNOME upstream. As long as it is carefully and non-
intrusively organized by the interested party, Debian GNOME maintainer
can accept such feature.
I am a happy ibus user and this is a non-trivial task. So I am not the
person to work on this.
> > Given the circumstances it's not obvious to me that Debian should
> > keep
> > defaulting to non-IBus IM frameworks on GNOME. A user who wants to
> > use
> > e.g. a Fcitx IM basically have the choice to
> >
> > 1. actively select Fcitx on a GNOME desktop, and with that give
> > up some features which GNOME only offers together with IBus, or
> >
> > 2. switch to some other desktop environment.
> >
> > GNOME favors IBus, and Debian should relate to that IMO.
>
> It's totally fine that GNOME only works with IBus. And there's no
> blame for upstream for their choice.
I say:
It's totally fine that GNOME as upstream only works with IBus. And
there's no blame for upstream for their choice.
It's not fine that GNOME as released by Debin only works with IBus if
fcitx or uim to be viable options on Debian. If fcitx or uim fans wish
to make fcitx and uim viable options, they need to work on it.
> But in Debian, it's a system, not just GNOME. When GNOME packager
> changes its packaging relations, they should also work with other
> teams, like tasksel, im-config, to provide users a working system.
Debian is a collection of efforts. It's a consolidation platform.
Each component and each contributor need to contribute.
Osamu
Reply to: