Re: im-config | Use im-config on Wayland without uninstalling IBus (!5)
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.
>
> 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.
> 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.
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?
> 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.
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
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.
> 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.
> 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.
> 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.
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.
>
> 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'm open to opinions.
Thanks
--
Changwoo Ryu
Reply to: