On Fri, 25 Feb 2022 05:32:31 +0100, Marguerite Su wrote:

[1 <text/plain; UTF-8 (quoted-printable)>]

Hi,

the update-alternative approach needs to adjust every ibus/fcitx/fcitx5 package and write their own generator scripts…it may be too hard for an input method framework maintainer to know everything about systemd…

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, too.

Currently my generator supplements systemd and a dummy “inputmethod” package, so any package provides “inputmethod” can use this generator.

The $LANG and .i18n can be added later, it’s easy actually.  After these works, I think maybe we can remove Provides: lang(zh:ja:ko) tags from packages too.

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. In anyway, this is a bit irrelevant with the IM choose mechanism itself, IMO. thanks, Takashi

actually this time I made the request  just to split the generator from fcitx5 to benefit others, with no other further design/considerations, and I know the generator is just a skeleton now :-)

Marguerite 

Fuminobu TAKEYAMA <ftake@geeko.jp>于2022年2月24日周四23: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

On Fri, Feb 25, 2022 at 4:50 AM Marguerite Su <i@marguerite.su> wrote:

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 Just to point out, making the IMF a systemd service can be very tricky for wayland. To use the wayland based input method protocol, certain wayland compositors (weston, kwin) may pass a socket file descriptor for the wayland connection for authentication and only such clients can be used to talk to wayland.

Unless they are handled in some special away (I implemented a special tool for fcitx5 to pass over the file descriptor https://www.csslayer.info/wordpress/fcitx-dev/fcitx-5-and-multiple-wayland-c... ), the compositor is expected to launch the input method framework server by themselves.

On Fri, 25 Feb 2022 13:49:57 +0100, Marguerite Su wrote:

Takashi Iwai <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

Let's try to implement some example cases and see how much work would be needed. An rpm macro usage I suggested can be done at any later point as a cleanup once after the stuff starts working, too.

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

It's a mechanism that is used by zypper and YaST, and it should still work (otherwise we need to report a bug). With those meta data, the packages will be selected automatically on YaST when you enable the corresponding locale in YaST language module. That is, if you install the system from the beginning in Japanese locale, the packages with lang(ja) will be automatically added as recommended packages. I don't know of any documentation about it, as this being a very long-standing feature. Takashi