Re: im-config | Use im-config on Wayland without uninstalling IBus (!5)
Hello, all.
2020년 5월 25일 (월) 오전 5:51, Gunnar Hjalmarsson <gunnarhj@ubuntu.com>님이 작성:
>
> Hi again,
>
> I'll start with giving a concrete example of how the proposed change may
> lead users into setting a bad configuration. After that replies to parts
> of Changwoo's message follow.
>
> On Ubuntu we make use of the im-config API to provide a simpler UI
> component for user settings. The options we show are the options which
> "im-config -l" output plus "none". The attached image shows what it
> looks like.
>
> With Changwoo's MR, and if you enter an Ubuntu on Wayland session with
> no ~/.xinputrc file, the current value of that UI is "none". If a user
> wants to use some IBus input method, it's not unlikely that they will
> change it to "IBus", since that's the intuitively right setting, and
> with that unconsciously break other things on the desktop.
Yes, it will be set as "none" and everything will be fine without
explicitly setting "ibus". And yes, even though it works well without
settings anything, some curious users may touch that UI and break
their OSK. I think the UI needs an update to be more clear. But please
don't insist to change underlying software for a frontend UI.
> There is also a myriad of tutorials and answers on the web which
> recommend just that. These are two examples:
>
> https://sites.google.com/site/xiangyangsite/home/technical-tips/linux-unix/common-tips/install-ibus-for-chinese-input-on-ubuntu
>
> https://askubuntu.com/questions/59356/how-do-i-get-chinese-input-to-work/667295
Public misinformation shouldn't be a ground for decision. And the
above pages were written 10 and 8 years ago.
>
I think I have stated my position enough about why I'm against
changing "ibus" choice in the previous mail.
>>> 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.
>
> The only example AFAIU. And the mutter bug is well identified. Why don't
> you make an effort to have that bug fixed instead? You shouldn't
> establish an unintuitive UI in order to work around a bug!
That's a wrong argument. You inserted a workaround into im-config
first. How about making an effort to fix the Ubuntu UI and public
misinformation instead?
And I'm not talking about "a" bug. The mutter issue affecting Korean
input is the most serious open one, but the GNOME Wayland input
feature has always had problems since it has been released and still
has important open problems. I'll explain more below.
Just give users the freedom to choose one buggy choice to another
buggy one, if they think OK. Gunnar's change removed that choice which
im-config has given to users.
> > 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.
>
> "Don't want"? Under normal conditions (the mutter/ibus-hangul issue
> being an exception) setting GTK_IM_MODULE=ibus on GNOME on Wayland is
> bad configuration. And the UI we provide should not lead users into
> choosing a bad configuration. It should help them do The Right Thing.
Gunnar think it as a bad configuration because of the on-screen
keyboard issue. Yes, OSK is an important a11y feature but, like other
a11y ones, most users just don't care. Actually the on-screen keyboard
provided by gnome-shell is currently quite useless for CJK languages.
Enabling the OSK is not an advantge for the users who need an IM in
daily use.
Let me tell you why some users don't really want the current GNOME
default Wayland input and it is important to have the choice to set to
use GTK_IM_MODULE=ibus.
I have tried/used this gnome-shell Wayland input feature since it has
been introduced in gnome-shell 3.28 in 2018. In technical aspect I
think it is an ideal way of using IM in an universal API and it's
better than inserting an executable code in every app. It's a software
so there have been numerous issues on it and some of which rendered
this feature unusable. I contributed on fixing some of the bugs and
will do in the future. But I know still there are issues. Due to its
complexity, there is a high possibility of problems. Here is some of
the open issues:
- The gnome-shell Wayland input is much slower than
GTK_IM_MODULE=ibus. It is obvious why; gnome-shell does some sort of
relaying between apps and ibus-daemon. It will never be faster than
GTK_IM_MODULE=ibus. (But I hope it be improved to be "fast enough" in
future.)
There has been attempts to improve the speed but one attempt leads to
a great regression in GNOME 3.34...
- https://gitlab.gnome.org/GNOME/mutter/-/issues/948
The most annoying mutter issue affecting Korean input. For those who
don't understand it, it's like typing "One two three four" randomly
makes "On etwo thre efou r". It completely breaks the Korean locale.
- https://gitlab.gnome.org/GNOME/mutter/-/issues/203
Incorrect repeat keys. It's for Chinese but I guess it's the same
issue with the above.
- https://gitlab.gnome.org/GNOME/mutter/-/issues/941
gnoms-shell freezes on typing fast. Another serious issue. I also
have encountered it.
- https://gitlab.gnome.org/GNOME/mutter/-/issues/280
Affects terminator
- https://gitlab.gnome.org/GNOME/mutter/-/issues/153
And it lacks some of ibus features by design.
These issues affect all languages and common applications. And some of
them are not likely to be improved in near future.
I'm not just complaining bugs. In spite of such problems, I think
GNOME Wayland default can be a reasonable default in most cases. But I
won't recommend this default to my friends if they are Korean or they
experience IM problems in that setting. Just give users the choice to
take the risk. Selecting an IM in im-config have given that choice to
users for a long time and I'm against removing that semantics.
--
Changwoo Ryu
Reply to: