Re: im-config | Use im-config on Wayland without uninstalling IBus (!5)
Thank you for your insightful discussion.
Since it has been long since I wrote this set of code, my memory is a
bit ambiguous. Excuse me but let me recall as much and share its
history and my thought as much with you.
On Sat, 2020-05-23 at 08:43 +0900, Changwoo Ryu wrote:
> Hello,
>
> 2020년 5월 22일 (금) 오후 7:09, Gunnar Hjalmarsson <gunnarhj@ubuntu.com>님이
> 작성:
> > On 2020-05-22 06:57, Changwoo Ryu wrote:
> > > Changwoo Ryu <https://salsa.debian.org/cwryu> commented:
> > >
> > > See the MR !6
> > > <
> > > https://salsa.debian.org/input-method-team/im-config/-/merge_requests/6
> > > >
> >
> > Thanks for the MR, Changwoo.
> >
> > Needless to say, Changwoo and I have had a debate on the MR I
> > submitted
> > with the aim to make it possible to use im-config without any
> > hassle
> > also with Wayland. Our discussion has not really been about that
> > goal,
> > on which we are agreed, but about something else.
>
> Yes, Gunnar's MR was about enabling non-IBus IMs in GNOME Wayland
> without uninstalling IBus. That's an improvement. But that MR
> introduced a workaround of IBus on GNOME Wayland.
>
> > So far im-config (and previously im-switch) has been simple in its
> > basic
> > logic:
> >
> > * If you want to use an IBus engine, select IBus.
> > * If you want to use an Fcitx engine, select Fcitx.
> > * etc.
> >
> > I strived to preserve that logic in my MR.
I think we need to agree on "the agreed design principle" of im-config
which is best for "maintenability" (= least hussle for DDs) and
"usability" (= least surprize to the user). This history may help.
What is described in the above by Gunnar is more like what previously
im-switch did through the use of the update-alternatives mechanism.
The raison d'être of im-config is its robust automatic IM
configuration.
When a IM package is removed under im-switch, broken symlink in user's
home directory was created and assiciated problems were encountered by
the user without ecplicit intervention by the user via im-switch.
Also, the initial automatic IM choice by the update-alternatives
symlink mechanism was locale un-aware. (Japanese task likes "uim",
chinese task likes "fcitx". fcitx seems to provide interesting feature
to support simplified and traditional characters over ibus. I being
Japanese liked ibus.)
im-config uses shell script to parse `~/.xinputrc` and decide IM
configuration. This allows robust automatic IM choice under any
circumstances at least after restarting the system.
I intentionally designed im-config to be least insisting and humble.
Whenever im-config sees the user setting up IM related environment
variables, im-config doesn't override them.
Addressing input support to d-bus activated programs foeced me to split
support scrit into 2 phases since their parent processes are started in
X start up /etc/X11/Xsession.d .
Addressing wayland/systemd was a whole new game. I initially thought
its task is beyond the design scope of im-config. Then YOSHINO-san proposed new hook via systemd as /usr/lib/systemd/user-environment-generators/70-im-config .
2bbb1a3 ("70-im-config: Export env variables via systemd", 2019-03-
07)
This systemd.environment-generator(7) is invoked by `systemd --user'
(>= 233) to export variables to its activation environment, which is
used by gdm3 for environment variables in a new desktop session.
Unlike Xorg, Wayland does not use /etc/X11/Xsession.d/, where im-
config has exported environment variables. This generator should
compensate the lacking function for a Wayland desktop session
launched from gdm3.
I didn't want to create a monster which I can't mauntain, YOSHINO-san's
proposal seemed reasonably compact.
> > GNOME on Wayland complicates it a bit. The GNOME developers
> > prescribe
> > that the GTK_IM_MODULE environment variable should be unset (or set
> > to
> > "wayland"), or else you can expect to run into issues. One known
> > example
> > is that if you set GTK_IM_MODULE=ibus on GNOME on Wayland, the On
> > Screen
> > Keyboard (OSK), which is an important accessibility feature,
> > breaks.
I didn't know it.
> > This is not a bug but a result of misconfiguration according to the
> > GNOME devs, who have no intention to change it.
>
> The GNOME upstream assumes it and that's what upstreams often do (and
> it often annoys). The upstream just want users to use GNOME without
> setting anything or even knowing "IBus" or what an IM is. A
> configuration program like im-config or using non-IBus IMs is also
> against that assumption. I'm saying that we are not exactly following
> assumptions set by upstream. im-config should do what it does.
>
> What happens when GTK_IM_MODULE is not set, in detail? GTK apps fall
> back to the default "wayland" IM module, which is same as
> GTK_IM_MODULE=wayland. With this wayland IM module, client apps
> communicate with the Wayland compositor gnome-shell instead of
> communicating with IBus directly. And gnome-shell uses IBus APIs
> using IBus gobject-introspection interface.
I am a bit lost in technical details. Changwoo, you seem to understand
this situation much better than me.
> In other word, Gunnar's proposal of not-setting *_IM_MODULE means
> just
> to use GNOME default without setting anything. It's same with setting
> "none" in im-config. Then why should "none" choice be hidden in
> "IBus"
> choice only in GNOME Wayland, ignoring some users who want to set
> GTK_IM_MODULE=ibus?
I haven't seen Gunnar's proposed patch yet .... Oh, I see this is a
major change. c2055cc ("Use im-config on Wayland without uninstalling
IBus", 2020-05-21) We certainly need to all the side effects this may
induce.
> > The best way to deal with this IMO is to let im-config check on the
> > environment, and in case of GNOME on Wayland - unlike other
> > environments
> > - make the IBus choice result in GTK_IM_MODULE not being set. That
> > way
> > we keep it simple to the users and don't unnecessarily expose them
> > to
> > the GNOME on Wayland exception. That's what im-config is about
> > after
> > all: Make it easy to the users and let im-config set a proper
> > configuration behind the scenes.
>
> For "auto" choice, it's right and the best reasonable default should
> be provided. My MR exactly does that. "auto" checks the environment
> and set the preferred "none" in case of GNOME Wayland instead of
> "ibus". The reasonable default is important but the "ibus" choice is
> not exactly the default. If users have set "ibus" to get the best
> default, they have been misinformed.
Currently, we are assuming "Wayland" environment is always "GNOME
Wayland". We also need to pay attention to KDE side.
> im-config(8) clearly states that it sets the environment variables:
>
> The im-config hook script, /etc/X11/Xsession.d/70im-
> config_launch,
> exports following variables to X programs: $XMODIFIERS,
> $GTK_IM_MODULE, $QT_IM_MODULE, $QT4_IM_MODULE, and
> $CLUTTER_IM_MODULE
Please don't put too much value to what I wrote. Let's think what is
the cleanest and best configuration system and update documentation
accordingly.
> And when IBus is selected im-config, it clearly states it uses
> ibus-gtk and ibus-gtk3. These packages contain GTK immodule files for
> GTK_IM_MODULE=ibus.
>
> * Application platform support:
> * GNOME/GTK+: ibus-gtk and ibus-gtk3 (both)
>
> So "ibus" choice should set GTK_IM_MODULE.
I agree here.
> > But the consequence of what Changwoo now suggests is that we would
> > make
> > a change to the logic of the user interface:
> >
> > * If you want to use an IBus engine, select "none" if if you are on
> > GNOME on Wayland, or else select "ibus".
>
> Users usually don't have to set anything. The default "auto" will
> choose "none" for GNOME Wayland and "ibus" for else.
>
> When users set "ibus" explicitly, they want IBus. And IBus should be
> used as documented.
Are you suggesting to update auto mode code (also code for @ mark
placing in menu etc.) under "Wayland" to be "none". auto mode already
checks existence of IM, checking some other factor is reasonable
change.
> > This would make the user interface less intuitive and I'm pretty
> > sure it
> > would cause cause confusion. And for what reason?
>
> If users know im-config and IBus and set "ibus" in GNOME Wayland even
> if input works well without setting anything, I think such advanced
> users are less likely to get confused much and will run im-config
> again. And I added some note about GNOME Wayland in IM_CONFIG_LONG. I
> think it is much better than removing the choice of using GTK
> immodules.
I didn't update the first dialogue of im-config for buster since time
was pressing for release and providing functionality was the priority.
I think updating the first dialogue of im-config should reduce
confusion.
> > A few months ago a mutter bug was introduced which affects the use
> > of
> > ibus-hangul on GNOME on Wayland adversely. One way for ibus-hangul
> > users
> > to work around that bug is to set GTK_IM_MODULE=ibus. My
> > understanding
> > is that this bug is the reason why Changwoo started to question the
> > current logic. He wants to be able to deal with that mutter bug via
> > the
> > im-config user interface.
>
> I didn't say that. But this important issue is one example of why
> some
> users don't want the GNOME default.
>
> > My position is that the mutter bug is not a good enough reason to
> > break
> > the intuitive logic of im-config. I would prefer:
> >
> > * Keep the current simple logic
> >
> > * Make efforts to fix the mutter bug
> >
> > * If we want to use im-config to help the ibus-hangul users to
> > temporarily work around the mutter bug, there is a simpler way
> > which
> > would not result in a change to the user interface logic.
>
> Actually my MR doesn't make it complicated. I want to keep "ibus"
> choice to be simple but newly added GNOME Wayland workaround in
> "ibus"
> made it complicated. So I moved the workaround from "ibus" to "auto",
> which is better suited for conditional actions.
I just saw your patch. This makes sense. (Not tested but just a quick
view.) "ibus" and "none" should offer single simple results. "auto"
and "cjk" are better place to put heuristics. "default" was there as
extra layer to allow changing default heuristics changeable in future
as I recall how I designed this set of choices.
> It's not just matter of specific bugs. Some users don't want GNOME
> default and prefer IBus immodules even if it is buggy in some cases.
> The choices in im-config are just like that; IMs have numerious
> issues
> only in some locales and in some environments. Just let users choose
> and don't hide implicit behaviors in the choice.
Impression of hidden workaround needs to be avoided, I agree.
"ibus" should do ibus, Does your patch update the first page dialogue
and 3rd page dialogue with proper @-sign location?
> > So in summary there is a -1 from me on the new MR.
> >
> > If I'm voted down, and Changwoo's proposal is supported by the
> > majority,
> > I may have a minor improvement to the proposed code.
>
> Gunnar, you merged your MR yourself even with my objection. I don't
> need thumbs-up majority. :) Salsa voting is a useful feature to get
> peoples attention but I don't think about decision based on it.
I lacks time these days and I am giving blanket approval to merge
patches to everyone who are considered reliable and who is willing to
follow-up future maintenance. All 3 of you, Changwoo, Gunnar, and
Boyuan can merge and upload package to Debian.
> I'm open to opinions.
I vote to move heuristics from ibus to auto. Please discuss further to
address every aspects.
Regards
Osamu
Reply to: