sorry I forgot to CC our mailing list.
---------- 转发的邮件 ---------
发件人: Marguerite Su <i(a)marguerite.su>
日期:2022年2月25日 周五21:00
主题:Re: Proposal: Using update-alternative to switch input method
收件人:Takashi Iwai <tiwai(a)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-manag…
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 <i(a)marguerite.su>于2022年2月25日 周五20:49写道:
> Takashi Iwai <tiwai(a)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 :-)
>
>
>>
Hi Marguerite and all,
Thank you for working to support IM on Wayland sessions.
I see your systemd-inputmethod-generator.
https://build.opensuse.org/package/show/M17N/systemd-inputmethod-generator
It simply read a list of input methods and precedence from
(/usr)/etc/X11/xim.d/en. I think it is ok nowadays since we do not need complex
mechanisms provided by /etc/X11/xim anymore.
But I'm wondering how about using `update-alternatives` instead of reading
/etc/X11/xim.d/en. A benefit of using update-alternatives is users can choose an
input method by `update-alternatives --config` or YaST. `update-alternatives` is
also used to configure a default display manager.
To use update-alternatives, firstly, we prepare:
[1] /usr/lib/input-method/user-environment-generators/fcitx
[2] /usr/lib/input-method/user-environment-generators/ibus
And run `update-alternatives --install` during installation:
update-alternatives --install \
/usr/lib/systemd/user-environment-generators/29-input-method-generator \
input-method-user-environment-generator \
/usr/lib/input-method/user-environment-generators/fcitx \
25
The following symlink to one of above will be generated:
/usr/lib/systemd/user-environment-generators/29-input-method-generator
Note that if [1] and [2] does not contain any program, the file managed by
`update-alternatives` can be /lib/environment.d/99-input-method.conf
What do you think?
If you plan to extend your input-method-generator so that it can read
/etc/X11/xim.d/$LANG and/or ~/.i18n, etc., the current approach will be appropriate.
a related report:
https://bugzilla.opensuse.org/show_bug.cgi?id=1084804
Best regards,
Fuminobu Takeyama