openSUSE M17n February 2022

m17n@lists.opensuse.org

4 participants
2 discussions

Fwd: Proposal: Using update-alternative to switch input method
by Marguerite Su 27 Feb '22

27 Feb '22

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 :-) > > >>

2 2

Proposal: Using update-alternative to switch input method
by Fuminobu TAKEYAMA 25 Feb '22

25 Feb '22

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

4 6

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE M17n February 2022