Hi thanks for lots of reply.

But since the update alternative approach involves many different files, I don’t think any rpm macro is possible. And again, rpm macro for all IMFs needs another new package.

I don't think it involves so many files, and we don't need rpm macro for that. https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines

You don’t need to heavily touch other existing IMF packages. I don’t think a new package + heavy modifications for all existing packages works better than my approach.

I don't think its heavy touch to IMF packages. Just add some files and run some commands postin and postun. And, now, only 3? IMFs are active. Sometimes, each IMF need different environment variables.

But still, like the name says, an user environment generator can not work as the 100% replacement for the xim script.

Maybe so but we don't have to create 100% replacement for the xim script anymore. I also think we can replace /etc/X11/xim* with update-alternatives.

We still need to write lots of systemd stuff (targets and etc) to achieve the goals that were done via the LibreOffice/gsettings hacks, if you want to end up to an IMF systemd service

Do we still need LibreOffice hack? We have collaborated with the upstream maintainer, and now, LibreOffice KDE supports Qt IM Module. I'm not sure gsettings hack is still working. The reason I stop chameleon-tongue is there's almost nothing to do.

And I can not find any documentation about the $HOME/.i18n usage on openSUSE, except this slide:

https://www.slideshare.net/ftake/redesigning-inputmethod-launcher-and-manage... Please check the changelog of x11-tools. ``` * Tue Jun 23 2015 werner@suse.de - Xim script: Allow background processes in ~/.profile and ~/.login (bsc#934720) also use ~/.i18n of exist instead of ~/.profile or ~/.login ```

So I wonder do we really have any real usage of “.xim” or “.i18n”?

I think only a few.

It seems you defined lots of place where we can declare the INPUT_METHOD env. But which ones should I take it seriously? The sysconfig? the “.xim”? The “.i18n”? Or the /etc/X11/xim.d? And what’s the priority if I declare that nev everywhere?

Well, please don't misunderstand. I said it's bad idea to have many places to configure. So the new tool do not need to share the same configuration with the xim script. If I took two, they would be ~/.i18n and sysconfig. # Honestly, I don't like ~/.i18n. It should be somewhere XDG's config dir. `update-alternative` approach also provides a simple rule `update-alternative --config` but it does not support per-user setting, which nobody may use. So what will the new tool will provide? On 2022/02/25 22:02, Marguerite Su wrote:

sorry I forgot to CC our mailing list.

---------- 转发的邮件 --------- 发件人： *Marguerite Su* mailto:i@marguerite.su> 日期：2022年2月25日 周五21:00 主题：Re: Proposal: Using update-alternative to switch input method 收件人：Takashi Iwai mailto:tiwai@suse.de>

And I can not find any documentation about the $HOME/.i18n usage on openSUSE, except this slide:

https://www.slideshare.net/ftake/redesigning-inputmethod-launcher-and-manage... https://www.slideshare.net/ftake/redesigning-inputmethod-launcher-and-manage...

So I wonder do we really have any real usage of “.xim” or “.i18n”? It seems you defined lots of place where we can declare the INPUT_METHOD env. But which ones should I take it seriously? The sysconfig? the “.xim”? The “.i18n”? Or the /etc/X11/xim.d? And what’s the priority if I declare that nev everywhere?

Marguerite Su mailto:i@marguerite.su>于2022年2月25日 周五 20:49写道：

Takashi Iwai mailto:tiwai@suse.de>于2022年2月25日 周五20:05 写道：

I guess this could be simplified if we provide some rpm macro. Basically a similar setup has been done for /etc/X11/xim.d (even manually), and we may combine even both stuff in a single macro

I begin to understand your approach now. If you make the generator itself as update alternative, the generator script will be very very easy: you just need to print INPUT_METHOD=<your input method framework name>. But since the update alternative approach involves many different files, I don’t think any rpm macro is possible. And again, rpm macro for all IMFs needs another new package. I added this new package to automatically transfer the existing XIM works to systemd/wayland since Xorg will not go away in the foreseeable future. You don’t need to heavily touch other existing IMF packages. I don’t think a new package + heavy modifications for all existing packages works better than my approach.

But still, like the name says, an user environment generator can not work as the 100% replacement for the xim script. We still need to write lots of systemd stuff (targets and etc) to achieve the goals that were done via the LibreOffice/gsettings hacks,  if you want to end up to an IMF systemd service

Hm, then the question is whether we want to user leaving without language-specific IM when user installs in CJK locale (or anything else).  Of course, they can install the stuff later at any time, but the point of having lang(x)-Provides or whatever meta data is just to "recommend" the installation of those packages for specific locales. A similar stuff could be implemented in patterns as well, but I feel that locale(x) makes maintenance easier.

OFF TOPIC: where can I find how these Provides are used? In which package? I used to investigate lots of packages and OBS settings, but I didn’t find any clue about this mechanism :-( So I wonder maybe these Provides are useless, but the person who sees them made it happen by manually adding those packages to ISOs :-)