Fwd: Proposal: Using update-alternative to switch input method

sorry I forgot to CC our mailing list. ---------- 转发的邮件 --------- 发件人： Marguerite Su 日期：2022年2月25日 周五21:00 主题：Re: Proposal: Using update-alternative to switch input method 收件人：Takashi Iwai 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... 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 于2022年2月25日 周五20:49写道：

Takashi Iwai 于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 :-)

...