[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop



Hi,


On Thu, 2021-03-04 at 11:43 +0100, Gunnar Hjalmarsson wrote:
> On 2021-03-04 04:54, Osamu Aoki wrote:
> > 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.
> 
> Thinking aloud.
> 
> GNOME favors IBus. That's hard to change.
> 
> im-config also favors IBus. How about letting im-config fall back to 
> IBus instead?

I was a bit lost what exactly was discussed.  As I re-read this bug
report from Yoshino-san, its objective is automate ibus setting
specific inputmethod (be it anthy or mozc).  I don't have time to check
its goodness, but its intent is step in right direction.   I don't
understand why we need to worry about fcitx or uim here.

> More specifically: rename 21_ibus.{conf,rc} to e.g. 49_ibus.{conf,rc}

??? This puts ibus in lower priority.  Why?  I don't understand the
exact motivation.

If anyone wish to use uim or fcitx, then you should explicitly chose it
via im-config command.  If the installation of ibus package interfare
functioning of im-config, fixing it via adding more complicated hooks
etc. is too fragile.

If the issue is package dependency of GNOME pulling in ibus package
which causes trouble, cleaner solution may be intruducing dummy ibus-
fake package which provide ibus for dependency.  fcitx and uim may be
made to depends on this ibus-fake package.  Something like this seems
simpler fix.

> That would still make im-config let GNOME configure IBus for most
> GNOME 
> users. But if uim is present, im-config would configure uim, and if 
> Fcitx is present, im-config would configure Fcitx. Even if IBus is 
> installed.
> 
> Such a change would be based on the idea that if a non-IBus framework
> is 
> present, the user is assumed to prefer it over IBus. (The choice of 
> framework can still be changed by the user.)
> 
> What do you think?
> 
> I think that such a tiny change would compensate - from an IM POV -
> for 
> the fact that gnome-shell started to recommend ibus.



Osamu


Reply to: