Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

On 2021-06-07 08:51, Shengjing Zhu wrote:

On Mon, Jun 07, 2021 at 08:04:14AM +0200, Gunnar Hjalmarsson wrote:

How about uploading the "fcitx5" -> "fcitx" change to experimental
for now? And possibly upload to bullseye soon after the release of
Debian 11.


Yes, please. And after release, the change could be updated in
unstable ASAP to get more feedback from users.


I sync'ed im-config 0.47-1 to Ubuntu impish (coming 21.10), and asked 
the Ubuntu Kylin folks to test fcitx 5 and report back if they run into 
issues.


https://bugs.launchpad.net/ubuntu/+source/im-config/+bug/1928360/comments/27

--
Gunnar

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

Hi Osamu!

On 2021-06-07 09:38, Osamu Aoki wrote:

I have no idea which is better but here is a technical implementation idea.

Add one optional commented out parameter to /etc/default/im-config
  , e.g.: FCITX_IM_ENV

Make im-config use it to override internal default.

So anyone got in to trouble can work around situation easily.

Add this fact to README.Debian...


Oops.. I saw your message only after having uploaded to experimental.

My thought now is that your idea is excellent if the uncertainty remains 
after we have received some user feedback. At this time we don't know if 
we have a situation which motivates another config option.


Does that make sense?

--
Gunnar

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Osamu Aoki]

Hi,

I have no idea which is better but here is a technical implementation idea.

Add one optional commented out parameter to /etc/default/im-config
 , e.g.: FCITX_IM_ENV

Make im-config use it to override internal default.

So anyone got in to trouble can work around situation easily.

Add this fact to README.Debian...


On Mon, 2021-06-07 at 14:51 +0800, Shengjing Zhu wrote:
> On Mon, Jun 07, 2021 at 08:04:14AM +0200, Gunnar Hjalmarsson wrote:
> > On 2021-06-07 07:08, Shengjing Zhu wrote:
> > > On Sat, Jun 05, 2021 at 11:58:14PM +0200, Gunnar Hjalmarsson wrote:
> > > > What's the conclusion then as regards this bug? Is it time to
> > > > change to "fcitx" in im-config in unstable (and somehow also in
> > > > bullseye) without worrying about users who have both fcitx 4 and
> > > > fcitx 5 installed?
> > > 
> > > We eventually need to align with upstream for the IM_MODULE env. But
> > > I'm not sure what should be done before bullseye release.
> > 
> > How about uploading the "fcitx5" -> "fcitx" change to experimental for now?
> > And possibly upload to bullseye soon after the release of Debian 11.
> > 
> 
> Yes, please. And after release, the change could be updated in unstable ASAP
> to get more feedback from users.
> 
> > FWIW I have tested to have both fcitx 4 and fcitx 5 installed, and didn't
> > notice any issues when running fcitx 5 with IM_MODULE=fcitx.
> > 
> > -- 
> > Gunnar
> 

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Shengjing Zhu]

On Mon, Jun 07, 2021 at 08:04:14AM +0200, Gunnar Hjalmarsson wrote:
> On 2021-06-07 07:08, Shengjing Zhu wrote:
> > On Sat, Jun 05, 2021 at 11:58:14PM +0200, Gunnar Hjalmarsson wrote:
> > > What's the conclusion then as regards this bug? Is it time to
> > > change to "fcitx" in im-config in unstable (and somehow also in
> > > bullseye) without worrying about users who have both fcitx 4 and
> > > fcitx 5 installed?
> > 
> > We eventually need to align with upstream for the IM_MODULE env. But
> > I'm not sure what should be done before bullseye release.
> 
> How about uploading the "fcitx5" -> "fcitx" change to experimental for now?
> And possibly upload to bullseye soon after the release of Debian 11.
> 

Yes, please. And after release, the change could be updated in unstable ASAP
to get more feedback from users.

> FWIW I have tested to have both fcitx 4 and fcitx 5 installed, and didn't
> notice any issues when running fcitx 5 with IM_MODULE=fcitx.
> 
> -- 
> Gunnar

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

On 2021-06-07 07:08, Shengjing Zhu wrote:

On Sat, Jun 05, 2021 at 11:58:14PM +0200, Gunnar Hjalmarsson wrote:

What's the conclusion then as regards this bug? Is it time to
change to "fcitx" in im-config in unstable (and somehow also in
bullseye) without worrying about users who have both fcitx 4 and
fcitx 5 installed?


We eventually need to align with upstream for the IM_MODULE env. But
I'm not sure what should be done before bullseye release.


How about uploading the "fcitx5" -> "fcitx" change to experimental for 
now? And possibly upload to bullseye soon after the release of Debian 11.


FWIW I have tested to have both fcitx 4 and fcitx 5 installed, and 
didn't notice any issues when running fcitx 5 with IM_MODULE=fcitx.


--
Gunnar

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Shengjing Zhu]

On Sat, Jun 05, 2021 at 11:58:14PM +0200, Gunnar Hjalmarsson wrote:
> On 2021-06-05 22:51, Shengjing Zhu wrote:
> > Situation has changed since fcitx5 5.0.4, which includes a compatible
> > frontend for fcitx4 module.
> > https://salsa.debian.org/input-method-team/fcitx5/-/commit/7780c8f7f9bcde2fcff6ae7fc3ce5ab2c40ebe63
> > 
> > The origin purpose is to support property software which only ships
> > with fctix4 modules, as well as snap, flatpak, etc, which can't use
> > the system library.
> 
> Ah, so that's why my trivial Chromium snap test worked with
> GTK_IM_MODULE=fcitx. :)
> 
> What's the conclusion then as regards this bug? Is it time to change to
> "fcitx" in im-config in unstable (and somehow also in bullseye) without
> worrying about users who have both fcitx 4 and fcitx 5 installed?
> 

We eventually need to align with upstream for the IM_MODULE env. But I'm not
sure what should be done before bullseye release.

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

On 2021-06-05 22:51, Shengjing Zhu wrote:

Situation has changed since fcitx5 5.0.4, which includes a compatible
frontend for fcitx4 module.
https://salsa.debian.org/input-method-team/fcitx5/-/commit/7780c8f7f9bcde2fcff6ae7fc3ce5ab2c40ebe63

The origin purpose is to support property software which only ships
with fctix4 modules, as well as snap, flatpak, etc, which can't use
the system library.


Ah, so that's why my trivial Chromium snap test worked with 
GTK_IM_MODULE=fcitx. :)


What's the conclusion then as regards this bug? Is it time to change to 
"fcitx" in im-config in unstable (and somehow also in bullseye) without 
worrying about users who have both fcitx 4 and fcitx 5 installed?


--
Gunnar

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Shengjing Zhu]

On Sun, Jun 6, 2021 at 4:51 AM Shengjing Zhu  wrote:
>
> On Sun, Jun 6, 2021 at 4:06 AM Gunnar Hjalmarsson  wrote:
> >
> > If both fcitx 4 and fcitx 5 are installed, the IM_MODULE value "fcitx"
> > would result in a fcitx 4 im module being loaded when using fcitx 5. We
> > have so far assumed that that would be a problem, if I understand it
> > correctly, and that's the reason why the fix of this bug was postponed.
> >
> > Question: How would it be a problem?
> >
>
> Situation has changed since fcitx5 5.0.4, which includes a compatible
> frontend for fcitx4 module.
> https://salsa.debian.org/input-method-team/fcitx5/-/commit/7780c8f7f9bcde2fcff6ae7fc3ce5ab2c40ebe63
>
> The origin purpose is to support property software which only ships
> with fctix4 modules, as well as snap, flatpak, etc, which can't use
> the system library.

Correct: better support. As without fcitx4front, it also has
ibusfront, which means using ibus modules in these software, then
fcitx5 can talk to them.
But you always need a proper env to tell these software to choose an
input module. You can set IM_MODULE to fcitx, or ibus. But setting
fcitx5 just makes these software fail to find the right input module.

-- 
Shengjing Zhu

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Shengjing Zhu]

On Sun, Jun 6, 2021 at 4:06 AM Gunnar Hjalmarsson  wrote:
>
> If both fcitx 4 and fcitx 5 are installed, the IM_MODULE value "fcitx"
> would result in a fcitx 4 im module being loaded when using fcitx 5. We
> have so far assumed that that would be a problem, if I understand it
> correctly, and that's the reason why the fix of this bug was postponed.
>
> Question: How would it be a problem?
>

Situation has changed since fcitx5 5.0.4, which includes a compatible
frontend for fcitx4 module.
https://salsa.debian.org/input-method-team/fcitx5/-/commit/7780c8f7f9bcde2fcff6ae7fc3ce5ab2c40ebe63

The origin purpose is to support property software which only ships
with fctix4 modules, as well as snap, flatpak, etc, which can't use
the system library.

-- 
Shengjing Zhu

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

If both fcitx 4 and fcitx 5 are installed, the IM_MODULE value "fcitx" 
would result in a fcitx 4 im module being loaded when using fcitx 5. We 
have so far assumed that that would be a problem, if I understand it 
correctly, and that's the reason why the fix of this bug was postponed.


Question: How would it be a problem?

I'm asking since we have an ongoing discussion at Ubuntu about fcitx 5 
and snaps. [1] A snap is an application package in a confined 
environment, and at this time only fcitx 4 im modules are installed in 
that environment. The situation seems similar to the issue with some 
proprietary Qt software as described at 
.


I tested to use fcitx 5 on a gtk based snap (Chromium as snap), and it 
failed with the default configuration, but worked fine when setting 
GTK_IM_MODULE=fcitx. Well, "worked" with a caveat: Me being able to 
input "北京" in the search field may not be the most comprehensive test 
you can imagine.


But can it be that it was a mistake to postpone the fix of this bug? Are 
there any significant adverse side effects if using fcitx 5 but loading 
a fcitx 4 im module? Has anybody really tried to find out?


[1] https://launchpad.net/bugs/1928360, starting with comment #19

--
Rgds,
Gunnar

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Shengjing Zhu]

On Tue, Dec 15, 2020 at 9:24 PM Gunnar Hjalmarsson  wrote:
>
> On 2020-12-12 15:19, Gunnar Hjalmarsson wrote:
> > On 2020-12-12 14:48, Shengjing Zhu wrote:
> >> According to
> >> https://github.com/fcitx/fcitx5/pull/161#issuecomment-735234080
> >> Upstream wants people to use "fcitx" in *_IM_MODULE environment.
> >
> > This was commit by Boyuan Yang a while ago:
> >
> > https://salsa.debian.org/input-method-team/im-config/-/commit/0dc20c88
> >
> > and reverted a few weeks later:
> >
> > https://salsa.debian.org/input-method-team/im-config/-/commit/2515d3db
> >
> > Are you sure this time? :)
>
> I would like to upload im-config soon, and it would be good if someone
> could confirm whether this really should be done now.
>
> Maybe we should await the outcome of ,
> i.e. if you choose to let fcitx and fcitx5 conflict, the variable value
> should be changed to "fcitx" and otherwise it should keep being "fcitx5".
>
> Please clarify your position on this matter.

We can postpone it to bookworm.

-- 
Shengjing Zhu

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

On 2020-12-12 15:19, Gunnar Hjalmarsson wrote:

On 2020-12-12 14:48, Shengjing Zhu wrote:
According to 
https://github.com/fcitx/fcitx5/pull/161#issuecomment-735234080

Upstream wants people to use "fcitx" in *_IM_MODULE environment.


This was commit by Boyuan Yang a while ago:

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

and reverted a few weeks later:

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

Are you sure this time? :)


I would like to upload im-config soon, and it would be good if someone 
could confirm whether this really should be done now.


Maybe we should await the outcome of , 
i.e. if you choose to let fcitx and fcitx5 conflict, the variable value 
should be changed to "fcitx" and otherwise it should keep being "fcitx5".


Please clarify your position on this matter.

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

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

On 2020-12-12 14:48, Shengjing Zhu wrote:

According to https://github.com/fcitx/fcitx5/pull/161#issuecomment-735234080
Upstream wants people to use "fcitx" in *_IM_MODULE environment.


This was commit by Boyuan Yang a while ago:

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

and reverted a few weeks later:

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

Are you sure this time? :)

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

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Shengjing Zhu]

Package: im-config
Severity: normal
X-Debbugs-Cc: z...@debian.org

According to https://github.com/fcitx/fcitx5/pull/161#issuecomment-735234080
Upstream wants people to use "fcitx" in *_IM_MODULE environment.


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

Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages im-config depends on:
ii  gettext-base  0.19.8.1-10

Versions of packages im-config recommends:
ii  whiptail0.52.21-4+b3
ii  x11-common  1:7.7+21

im-config suggests no packages.