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

[Osamu Aoki]

On Tue, 2021-03-09 at 15:22 +0100, Gunnar Hjalmarsson wrote:
> Hi Osamu,
> 
> On 2021-03-09 14:58, osamu.a...@gmail.com wrote:
> > 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.
> 
> 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.


Yes.  This is probably what we want to do.

But now ibus-anthy doesn't work due to strange bug. (Bug reported but
no idea what is happening)

Osamu

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

[Gunnar Hjalmarsson]

On 2021-03-09 15:55, YOSHINO Yoshihito wrote:

On Tue, Mar 9, 2021 at 11:36 PM Gunnar Hjalmarsson  wrote:

On 2021-03-09 14:58, osamu.a...@gmail.com wrote:

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.


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.


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.


Would patching gnome-desktop3 help? Replacing "kkc" with e.g. "mozc-jp" 
wouldn't be very hard after all.



So I have proposed the auto setup script, which is IMO a much saner,
safer, and modular approach.


Maybe. I'm waiting for your response to a question I asked at your MR.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

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

[Shengjing Zhu]

Control: clone -1 -2
Control: reassign -2 gnome-initial-setup 3.38.4-1
Control: retitle -2 choice of Japanese input methods is not useful
Control: severity -2 important

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

On Tue, Mar 9, 2021 at 10:56 PM YOSHINO Yoshihito  wrote:
>
> Hi,
>
> On Tue, Mar 9, 2021 at 1:19 AM Shengjing Zhu  wrote:
> > 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:
> >
> > > GNOME doesn't set the working Korean IM by default
> >
> > 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?
>
> 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.
>
> On Tue, Mar 9, 2021 at 11:36 PM Gunnar Hjalmarsson  
> wrote:
> > Hi Osamu,
> >
> > On 2021-03-09 14:58, osamu.a...@gmail.com wrote:
> > > 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.
> >
> > 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.
>
> 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 

-- 
Shengjing Zhu

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

[YOSHINO Yoshihito]

Hi,

On Tue, Mar 9, 2021 at 1:19 AM Shengjing Zhu  wrote:
> 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:
>
> > GNOME doesn't set the working Korean IM by default
>
> 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?

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.

On Tue, Mar 9, 2021 at 11:36 PM Gunnar Hjalmarsson  wrote:
> Hi Osamu,
>
> On 2021-03-09 14:58, osamu.a...@gmail.com wrote:
> > 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.
>
> 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.

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 

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

[Gunnar Hjalmarsson]

Hi Osamu,

On 2021-03-09 14:58, osamu.a...@gmail.com wrote:

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.


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.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

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

[osamu . aoki]

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)

On Mon, 2021-03-08 at 18:41 +0100, Gunnar Hjalmarsson wrote:
> On 2021-03-08 17:19, Shengjing Zhu wrote:
> > Hi,
> > 
> > On Sun, Feb 28, 2021 at 11:12 PM YOSHINO Yoshihito
> >  wrote:
> > > 
> > > 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,
> > 
> > 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:
> > 
> > > GNOME doesn't set the working Korean IM by default
> > 
> > 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.
> 

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

[Gunnar Hjalmarsson]

On 2021-03-08 17:19, Shengjing Zhu wrote:

Hi,

On Sun, Feb 28, 2021 at 11:12 PM YOSHINO Yoshihito  wrote:


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,


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:


GNOME doesn't set the working Korean IM by default


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.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

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

[Shengjing Zhu]

Hi,

On Sun, Feb 28, 2021 at 11:12 PM YOSHINO Yoshihito  wrote:
>
> 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,

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:

> GNOME doesn't set the working Korean IM by default

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?

-- 
Shengjing Zhu

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

[Gunnar Hjalmarsson]

On 2021-03-05 16:18, Osamu Aoki wrote:

On Thu, 2021-03-04 at 11:43 +0100, Gunnar Hjalmarsson wrote:

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.


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


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 the issue is package dependency of GNOME pulling in ibus package
which causes trouble,


Yes, that's it.


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



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.


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



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.


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.


--
Rgds,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

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

[Osamu Aoki]

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

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

[Gunnar Hjalmarsson]

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?


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.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

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

[Osamu Aoki]

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

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

[Gunnar Hjalmarsson]

On 2021-03-02 06:02, Shengjing Zhu wrote:

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.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

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

[Shengjing Zhu]

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

-- 
Shengjing Zhu

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

[Gunnar Hjalmarsson]

On 2021-03-01 13:32, YOSHINO Yoshihito wrote:

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.


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.

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.


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.

--
Cheers,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

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

[Shengjing Zhu]

On Mon, Mar 1, 2021 at 1:15 PM YOSHINO Yoshihito  wrote:
>
> Hi,
>
> On Mon, Mar 1, 2021 at 3:32 AM Gunnar Hjalmarsson  wrote:
> >
> > On 2021-02-28 16:05, YOSHINO Yoshihito wrote:
> > > On the GNOME desktop, manual set-up in GNOME Settings is required
> > > in order to make ibus-anthy to work.
> >
> > Right. But does that differ in any way from other IBus input methods?
>
> 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.
>

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.

-- 
Shengjing Zhu

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

[YOSHINO Yoshihito]

Hi,

On Mon, Mar 1, 2021 at 5:56 PM Gunnar Hjalmarsson  wrote:
> In  you write:
>
> > This is caused by the change in the gnome-shell package (Bug#815050)
> > to add "Recommends: ibus", which breaks any non-ibus input method
> > framework (Bug#941624),

What I am talking about here is im-config's preference ordering.
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 ...

> 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

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,
-- 
YOSHINO Yoshihiro 

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

[Gunnar Hjalmarsson]

But wait now...

In  you write:


This is caused by the change in the gnome-shell package (Bug#815050)
to add "Recommends: ibus", which breaks any non-ibus input method
framework (Bug#941624),


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


--
Regards,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

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

[YOSHINO Yoshihito]

Hi,

On Mon, Mar 1, 2021 at 3:32 AM Gunnar Hjalmarsson  wrote:
>
> On 2021-02-28 16:05, YOSHINO Yoshihito wrote:
> > On the GNOME desktop, manual set-up in GNOME Settings is required
> > in order to make ibus-anthy to work.
>
> Right. But does that differ in any way from other IBus input methods?

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,

--
YOSHINO Yoshihito 

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

[Gunnar Hjalmarsson]

On 2021-02-28 16:05, YOSHINO Yoshihito wrote:

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


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

--
Rgds,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

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

[Boyuan Yang]

在 2021-03-01星期一的 00:19 +0900，YOSHINO Yoshihito写道：
> 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,

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


signature.asc
Description: This is a digitally signed message part

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

[YOSHINO Yoshihito]

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,
-- 
YOSHINO Yoshihito 

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

[YOSHINO Yoshihito]

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,
-- 
YOSHINO Yoshihito 

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-3-amd64 (SMP w/1 CPU thread)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ibus-anthy depends on:
ii  anthy1:0.4-2
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  ibus 1.5.23-2
ii  libanthy11:0.4-2
ii  libc62.31-9
ii  libglib2.0-0 2.66.7-1
ii  python3  3.9.1-1

ibus-anthy recommends no packages.

ibus-anthy suggests no packages.

-- no debconf information


ibus-anthy-gnome-initial-setup.desktop
Description: Binary data


ibus-anthy-gnome-initial-setup.sh
Description: Bourne shell script