Package: ibus-anthy
Version: 1.5.11-2
Severity: important
Tags: patch

Dear Maintainer,

On the GNOME desktop, manual set-up in GNOME Settings is required
in order to make ibus-anthy to work.

I have prepared an XDG Autostart .desktop file which should be installed to
/etc/xdg/autostart/ibus-anthy-gnome-initial-setup.desktop
and its corresponding script to be installed to
/usr/share/ibus-anthy/ibus-anthy-gnome-initial-setup.sh
to automatically set-up ibus-anthy immediately after each user's next login.

Sorry for the tight schedule, but hopefully this should be included in
the bullseye release
(See also Bug#983653.)

Thanks in advance,

Package: ibus-anthy
Followup-For: Bug #983695

Dear Maintainer,

I have created a merge request on salsa at
https://salsa.debian.org/input-method-team/ibus-anthy/-/merge_requests/2

Thanks in advance,

在 2021-03-01星期一的 00:19 +0900，YOSHINO Yoshihito写道：

This patch looks suboptimal and personally I am not in the position of
merging it. It would be great if Japanese users and Anthy users could
review the current condition. Meanwhile I will upload ibus-anthy 1.5.12
without this patch first.

Thanks,
Boyuan Yang

Right. But does that differ in any way from other IBus input methods?

Hi,

Yesterday I filed Bug#983623 to ibus-mozc for a similar change and it
has been uploaded to unstable.

gnome-shell now Recommends: ibus, which breaks a fresh bullseye installation of
Japanese (and probably Chinese) default desktop (that is, GNOME desktop.)
In order to work around this issue, in Bug#983653 I have proposed a patch
to add "Recommends: ibus-mozc | ibus-anthy" to task-japanese-gnome-desktop.

Buster Japanese GNOME desktop uses uim, which has worked out of the box.
By adding auto set-up to at least those two ibus-* packages
bullseye Japanese GNOME desktop on any architecture should work out of
the box again.

Regards,

But wait now...

In <https://bugs.debian.org/983653> you write:

As far as I understand that is not correct, at least not any longer.

We did have an issue with im-config where the presence of IBus disabled
im-config and prevented you from configuring some non-IBus input method
framework. That issue has been fixed, and in Bullseye you will be able
to configure e.g. Fcitx or UIM via im-config.

https://salsa.debian.org/input-method-team/im-config/-/commit/c2055cc4

It's true that GNOME favors IBus over other frameworks, and it may be
motivated to default to IBus on GNOME for e.g. Japanese. However, right
now I fear that you are about to make a few last minute changes for the
wrong reason.

I may well have missed something here, but it would be good if you could
try to explain exactly how the mere presence of IBus breaks the previous
setup for Japanese users.

(I do realize from your merge request that you want to spare the users
from the trouble of going to Settings and add an input method.)

Hi,
Its default is found in /usr/share/im-config/data/:
21_ibus.rc
22_fcitx.rc
23_fcitx5.rc
24_uim.rc
...
where ibus is most preferred.
(IMO this ordering itself is carefully managed and good.)
This used to be able to be overridden by IM_CONFIG_PREFERRED_RULE in
/etc/default/im-config, while it is no longer possible,
as long as DESKTOP_SETUP_IBUS contains "GNOME".
(IMO this variable itself is reasonable because gnome-shell
unconditionally starts /usr/bin/ibus-daemon if it is found and then
it sometimes interferes with another IM framework.)

So once ibus is installed on the GNOME desktop for some reason,
ibus is always preferred by default.
On the GNOME desktop, "non-ibus IM framework is installed and used by
default, switch to ibus if you want it" is no longer possible.
I wrote "breaks" in this sense.

By the way ...

Yes I saw your commit several months ago.
Now that DESKTOP_SETUP_IBUS variable exists, non-ibus users are
already warned:
"When ibus is installed, another IM system is not preferred by default,
which may be interfered by ibus"
So IMO this commit is now reasonable.

Regards,

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.

Now I understand better. Thanks for explaining!

The current design of im-config is not set in stone, of course, but OTOH
there is a reason for the limitation you mention.

GNOME relies on IBus, and IBus is the only IM framework supported by
GNOME. So when you use a non-IBus framework you do it at your own risk.
For that reason I think it makes sense that the user needs to actively
select a framework to be able to use a non-IBus framework on a GNOME
desktop.

It would be possible to change im-config so IM_CONFIG_PREFERRED_RULE is
effective also with GNOME. But by doing so, Debian would make a choice
behind the scenes resulting in a combination which is known to be
fragile and break certain aspects of the desktop.

If I understand it correctly, your conclusion is to switch to IBus on
GNOME by adding recommends to task-japanese-gnome-desktop and keep
recommending uim packages in task-japanese-desktop. Personally I think
that makes sense.

As regards your proposal in this bug report, it may be worth mentioning
that Ubuntu uses another method to enable certain input methods out of
the box. We do so via a patch in gnome-settings-daemon:

https://salsa.debian.org/gnome-team/gnome-settings-daemon/-/blob/ubuntu/master/debian/patches/ubuntu_ibus_configs.patch

Can't tell if a similar approach would make sense in Debian, but in any
case it's too late in the cycle to consider it.

Your proposal, OTOH, seems possible to get in.

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.

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

I agree on the lack of cross team communication in this matter. If that
had worked better, we wouldn't have sit here in freeze time and conclude
that some line of actions are probably too late.

Hi,

Let me recall my memory ....

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.

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.

Debian is a collection of efforts.  It's a consolidation platform.
Each component and each contributor need to contribute.

Osamu

GNOME favors IBus. That's hard to change.

im-config also favors IBus. How about letting im-config fall back to
IBus instead?

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

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.

Hi,

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.

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



Osamu

While the direct purpose of this bug report is a proposal to add an auto
setup script to ibus-anthy, the background is that gnome-shell has
started to recommend ibus which makes it hard to set up a non-ibus IM at
installation via tasksel meta packages.

[ @Osamu: I reviewed the MR:

https://salsa.debian.org/input-method-team/ibus-anthy/-/merge_requests/2

and noticed an issue. It would be good if you could take a look. ]

Yes, that's it.

That might also address the problem. Not sure about cleaner/simpler,
though. :)

Also, would adding a new binary, even if only a dummy, be allowed during
soft freeze?

Let me add that I'm not sure about my idea. Earlier on this bug report I
wrote:

So you can rightly say that I contradict myself. :/ Maybe it's not a
good idea to keep using tasksel to install non-IM input methods on the
GNOME desktop.

Hi,

Back to this issue only(ibus doesn't have a working default). I find
task-korean-gnome-desktop Recommends gnome-initial-setup,
And above the Recommends, it has a comment that says:

https://salsa.debian.org/installer-team/tasksel/-/blob/002c2a97/debian/control#L1547

So I think this is the workaround by Korean users. Which now GNOME
defaults ibus, and ibus doesn't pick up the right defaults for all.
Maybe we should find a universal solution?

To me that sounds as a good idea, especially given how late we are in
the cycle. I just run gnome-initial-setup, and even if it starts with a
redundant question (about locale), the second question is about typing.

So provided that the release-team approves the creation of a bunch of
new task-*-gnome-desktop packages, I suppose that adding
gnome-initial-setup as a dependency in those would be easier than adding
the proposed auto setup script to several ibus-* packages.

Hi,

For Japanese, kkc is the only choice gnome-initial-setting offers.

No anthy/no kkc/no skk/ ...

So this is not an option for Japanese.  (Probably good for Korean)

Hi Osamu,

So annoying. :( But maybe gnome-initial-setup can be patched to bypass
whatever whitelist or blacklist they use to restrict the options. So you
can choose whatever IBus IM is installed - just as you can in Settings.

Hi,

Maybe, but this is not suitable for at least Japanese users.

Actually first I tried the Korean workaround. However, unfortunately
for Japanese users it is very hard to use gnome-initial-setup.
This shows an insane ordering for Japanese input methods and keyboard
layouts. Its "入力" (Input) page shows the following choices:
- "Japanese (PC-98)", a mostly-dead Japanese keyboard layout, listed at the top
- "kkc", meaning ibus-kkc which is rarely used in a distro other than
Fedora, listed next; this default value is hardcoded in the dependent
libgnome-desktop3, so patching it is also hard:
https://sources.debian.org/src/gnome-desktop3/3.38.4-1/libgnome-desktop/default-input-sources.h/#L38
Scrolling farther down, other Japanese choices are found, but ...
- "日本語", meaning "Japanese", is listed first, which looks like "the
default Japanese input method" but is NOT an input method ...
actually a JP keyboard layout
- Other "日本語 (...)" choices including Anthy and Mozc are listed next,
either a keyboard layout or an input method, are mixed alphabetically,
where a Japanese user must select the appropriate input method.
It is practically impossible for other than GNOME experts, and this is
far from out-of-the-box.

So IMO gnome-initial-setup (at least, in the current state) must not
be installed in the Japanese GNOME desktop by default.
Perhaps this is not suitable for a language where multiple input
methods or keyboard layouts are widely used.

At least for Japanese users, the list offered by gnome-initial-setup
is severely broken, and the default "kkc" IM option is offered by
libgnome-desktop3; patching both of them is hard.
So I have proposed the auto setup script, which is IMO a much saner,
safer, and modular approach.

Regards,
--
YOSHINO Yoshihito <yy.y.ja.jp@gmail.com>

Let's at least make gnome-initial-setup maintainer aware of this chaos.

Now in bookworm gnome metapackage Recommends: gnome-initial-setup.
This means all task-gnome-desktop users in all languages including
Japanese now have to use the gnome-initial-setup window after the first
login.

The choices of input methods and their ordering are handled by
gnome-initial-setup itself, and the default choice is handled by the
dependent libgnome-desktop-4-2 package, and both are still not good.
Another bug report #1029821 handles the latter.

Regards,