Re: im-config | Use im-config on Wayland without uninstalling IBus (!5)
Hi,
I am not smart enough to remember everything mentioned here.
Gaps among us may not be as big as you think.
On Mon, 2020-07-13 at 16:36 +0900, Changwoo Ryu wrote:
> 2020년 7월 13일 (월) 오전 10:39, Gunnar Hjalmarsson <gunnarhj@ubuntu.com>님이
> 작성:
> > On 2020-07-12 05:42, Changwoo Ryu wrote:
> > > Let's not repeat that again.
> >
> > I summarized and clarified my arguments in response to Osamu's
> > question.
> >
> > > "The UI" is actually the Ubuntu settings UI which is only in
> > > Ubuntu
> > > and not in Debian.
> >
> > It's both of course. Even if the confusion your proposal may lead
> > to is
> > of greater importance in Ubuntu for a couple of reasons, my
> > arguments
> > apply to Debian as well.
> >
> > > We are not working on im-config for compatibility with a derived
> > > distro's settings UI.
> >
> > I thought Debian and Ubuntu cooperated. Maybe a misconception on my
> > part.
>
> In general, I'm OK with Ubuntu specific changes in Debian packages as
> long as they don't break anything. But your Wayland change breaks how
> im-config has worked (even though you don't agree) and I think fixing
> it is more important than keeping UI compatibility.
I agree.
> > Let me point out that im-config offers an API with the explicit
> > purpose
> > to allow im-config to be controlled from other programs. Ubuntu
> > does
> > nothing but making use of that API.
>
> This is not true. im-config never offers an API.
Not quite. CUI's -l -m -n options are meant to be used used by
external program. Most of the code were there when I originally
designed im-config but I certainly added some features later to help
Ubuntu develop user environment set-up GUI after discussion with Ubuntu
folks. I was hoping Ubuntu will make such program available in Debian.
(So far it didn't happen.)
> im-config has its own
> CUI and GUI interfaces and it is not used as an API by other packages
> in Debian.
True for "it is not used as an API by other packages in Debian" at this
moment.
> The Ubuntu language selection UI just executes im-config
> command and reads its output. See the source code:
> https://git.launchpad.net/ubuntu/+source/language-selector/tree/LanguageSelector/ImConfig.py
>
> OK I think it is a clever use of im-config. But reading command line
> output can not be a stable "API". Its syntax and semantics can be
> changed in any time for any reason and then the Ubuntu UI needs to be
> modified to follow the change.
So far, I kept this text output a stable "API". I have no intention to
change this "API" to break its user programs by changing text output
format etc. randomly.
The most important raison d'etre of im-config over previous im-switch
is that this im-config infrastructure allows to use locale setting and
other user environment parameters as a part of setting priority factor.
So decision is not made by a simple update-alternatives mechanism with
priority values. You can see locale setting is used for "cjk".
The default install state on Debian is defined in "auto". So Debian
needs to have absolute control on heuristics implemented in it. If
Korean keyboard input with ibus is impossible and you can identify
software availability of alternative Korean keyboard input method and
Korean locale was chosen, "auto" should promote such alternative Korean
keyboard input method over ibus. I don't think this cause any real
problem on Ubuntu even if Ubunts uses "auto".
> > > Whatever breakage the Ubuntu UI would have, it can be handled by
> > > updating the Ubuntu UI or making an Ubuntu version of im-config.
> >
> > Let's not jump the gun.
> >
> > > We are talking about the Debian version of im-config and we
> > > should talk in the context of Debian, not Ubuntu.
In principle, correct statement. But, I see no technical conflict on
UI.
> > Not sure what you want to say with that. Yes, this discussion is
> > about
> > the design of im-config in the Debian archive. But Ubuntu uses the
> > thing
> > as well. Are you saying that Debian development should not take
> > into
> > account how downstream is affected? If you are, it's a bit
> > remarkable IMHO.
We can always check distribution to change "auto" behavior to
accommodate Ubuntu needs. I am open for such patch and I think we are
talking now to come up with such mutually agreeable solution.
If you look at debian/rules, you see my attitude to accommodate
distribution choices as much as possible without conflict.
> Breaking downstream SW is not a happy thing. But if there's no better
> solution, yes, doing it is better than making the upstream do an
> inconsistent behavior.
Let's first come up with a solid Debian solution and identify gap for
Ubuntu. Then work on a solution to close gaps. Let's keep open mind.
...
Good night for now. I need time to review below ....
> > > And there seems to be no new argument why this GNOME/Wayland
> > > conditional should be in the "ibus" choice.
> >
> > Right. The previous arguments still stand.
> >
> > > And I gave enough reasons why some users do not want this GNOME
> > > Wayland input default and why the choice should be kept.
> >
> > A choice that does not exist can't "be kept".
>
> This repeated argument is started by mixing two related-but-different
> changes in one commit. As I said earlier, it's a typical pattern of
> feature removal.
>
> If you still think that removing GTK_IM_MODULE settings does not
> break
> anything as the Wayland setup is newly introduced, you also have to
> say that there's no Ubuntu UI breakage in my proposed change as
> Ubuntu
> in Wayland is new.
>
> > As far as I understand, the only Korean specific issue you
> > mentioned is
> > the ibus-hangul/mutter bug which is about to be fixed. Given that,
> > how
> > is the Korean special case configuration still motivated?
>
> There is another issue (preserving preedit style set in ibus-hangul)
> but it's not important. The Korean specific workaround in my proposed
> im-config change can be removed with GNOME 3.38.x release.
Reply to: