The error itself is caused because imsettings runs ibus-demon.
If you delete imsettings, the error should not happen.

As I said, imsettings should run `ibus start` command.

Unfortunately ibus causes a SEGV in Fedora 44 LXQt because ibus-wayland tries to connect the Wayland input-method V2 but lxqt-session returns a signal of the Wayland input-method V1. I will investigate it later.
Seems LXQt uses miriway compositor and I

But your issue would be imsettings and you can choose im-chooser to disable ibus and invoke `ibus start` by manual.

Unfortunately lxqt-desktop group includes lxqt-x11-session package so ibus-xinit is installed in the spin.

(In reply to Akira TAGOH from comment #0)
> ibus warns it should be setup by systemsettings on KDE. Even though it isn't KDE and there are no systemsettings nor similar equipment.

The message also mentions about other DEs besides KDE.

Now I compiled the LXQt configuraiton.
https://github.com/ibus/ibus/wiki/WaylandDesktop#lxqt

Sorry for bothering you, but just to make sure, we still need this bug to keep open. We still have two things to do for this. One still in ibus. Another one is in imsettings depending on the case.

For ibus, you may want to update ibus-xinput file in dist-git to have IMSETTINGS_IGNORE_SESSION=*-wayland (in case ibus doesn't need imsettings for wayland anyway. otherwise better adding desktop name there you don't want) because imsettings could be installed like this case and be a problem.

For imsettings, may I ask you, does ibus on wayland work without settings proper environment variables setup from imsettings like GNOME? If not, I need to update something in imsettings too. I'll open another one for that if any.

(In reply to Akira TAGOH from comment #3)
> For ibus, you may want to update ibus-xinput file in dist-git to have
> IMSETTINGS_IGNORE_SESSION=*-wayland (in case ibus doesn't need imsettings
> for wayland anyway. otherwise better adding desktop name there you don't
> want) because imsettings could be installed like this case and be a problem.

I think it's not relative with the original bug description directly and I think it would be good to open a new bug instead of reopening this bug if your request is really it.
I could discuss your thoughts and suggestions here even if this bug would be closed.

I wonder why you ask the change to the ibus side for the general Wayland setting.

As I noted, imsettings could check if the current display is Wayland or X11.
If users wish to the common configuration tool, I assume:
1. Runs `ibus start` but not ibus-daemon - I think it works for both X11 and Wayland
2. Sets [GTK|QT]_IM_MODULE to 'ibus' for X11 sessions 'wayland' for Wayland sessions

If imsettings does not implement them, Is it better not to install imsettings by default for the Wayland enabled Fedora spins instead of the new keyword '*-wayland'?

> For imsettings, may I ask you, does ibus on wayland work without settings
> proper environment variables setup from imsettings like GNOME? If not, I
> need to update something in imsettings too. I'll open another one for that
> if any.

IBus itself won't configure the default im-module for the sessions. I think any sessions won't invoke ibus-daemon except for GNOME.
The default of GTK_IM_MODULLE is 'wayland' for GTK4. Currently XMODIFIERS=@im=ibus is still needed for both X11 and Wayland sessions.
I think a new option might be needed for im-chooser "None" not to set [GTK|QT]_IM_MODULES and XMODIFIERS but not GTK_IM_MODULE=gtk-im-context-simple

I think you don't have to open a new bug since you already filed bug #2402659.

Tested Fedora-LXQt-Live-44-20260404.n.0.x86_64.iso

(In reply to fujiwara from comment #4)
> I wonder why you ask the change to the ibus side for the general Wayland
> setting.

Because that is only what IMEs has an option to control the behavior in imsettings. imsettings has a dedicated code for desktops though, no dedicated code for IMEs. it is exported as configuration file, such as ibus.conf.

> As I noted, imsettings could check if the current display is Wayland or X11.
> If users wish to the common configuration tool, I assume:
> 1. Runs `ibus start` but not ibus-daemon - I think it works for both X11 and
> Wayland
> 2. Sets [GTK|QT]_IM_MODULE to 'ibus' for X11 sessions 'wayland' for Wayland
> sessions

I see your position but:

> If imsettings does not implement them, Is it better not to install
> imsettings by default for the Wayland enabled Fedora spins instead of the
> new keyword '*-wayland'?

This isn't that simple until all the desktops drops X11 support. both X11 and wayland sessions can be mixed up as the installation and freely switch them on a display manager. This issue isn't controllable in packaging level.
That is why I'm asking you for updating ibus.conf.

> IBus itself won't configure the default im-module for the sessions. I think
> any sessions won't invoke ibus-daemon except for GNOME.
> The default of GTK_IM_MODULLE is 'wayland' for GTK4. Currently
> XMODIFIERS=@im=ibus is still needed for both X11 and Wayland sessions.
> I think a new option might be needed for im-chooser "None" not to set
> [GTK|QT]_IM_MODULES and XMODIFIERS but not
> GTK_IM_MODULE=gtk-im-context-simple

Thank you for the information. What if no GTK_IM_MODULE is set on X11?
Also, given that no GTK_IM_MODULE is set, how does ibus work for gtk3 applications then? (on GNOME and on non-GNOME if it makes any difference)

There are still 1016 packages on Fedora though, it looks like not trivial:

$ cat /etc/fedora-release
Fedora release 45 (Rawhide)
$ dnf repoquery --whatrequires gtk3 | wc -l
1016

(In reply to Akira TAGOH from comment #6)
> Because that is only what IMEs has an option to control the behavior in
> imsettings. imsettings has a dedicated code for desktops though, no
> dedicated code for IMEs. it is exported as configuration file, such as
> ibus.conf.

I think it does not depend on each IMFs to have different environment variables between Wayland and X11 and it could be handled by imsettings instead of updating each the conf file.

> This isn't that simple until all the desktops drops X11 support. both X11
> and wayland sessions can be mixed up as the installation and freely switch
> them on a display manager. This issue isn't controllable in packaging level.
> That is why I'm asking you for updating ibus.conf.

I think it could be simple to implement them in imsettings and we don't have to wait not to support X11 and my suggestion is to support the Wayland in imsettings.

Basically I don't think it's a good idea to load xinit files in the Wayland environment.
Currently /usr/bin/imsettings-boot.sh loads /etc/X11/xinit/xinitrc.d/50-xinput.sh in Wayland but I think it's better to prepare a new script likes /usr/bin/imsettings-wayland-boot.sh and imsettings checks the current display is Wayland or X11 to select the script.

I'm thinking it's not good to load xinit files in Wayland session in case the files does not work in Wayland while some Wayland DEs load xinit files as the back compatibility.

My idea is to check /usr/share/wayland-sessions/init/inputrc and it has the Wayland specific settings.
I updated ibus.conf in the latest ibus-xinit package which has the different environments between Wayland and X11 but checking WAYLAND_DISPLAY is a workaround. Seems GDM drops X11 sessions by default and gdm-x-session always sets XDG_SESSION_TYPE=wayland and probably I will try to make a patch for GDM later.
But if imsettings could the current display, the workaround won't be needed.

Also /usr/share/wayland-sessions/init/inputrc supports new keyword to have a daemon interface command likes XIM_START_COMMAND=`ibus start`.
Current the conf file specifies the daemon execution path directly but the IBus interface commands exit immediately after ibus-daemon runs.

The `ibus start` command updates the KDE configuration file and imsettings side does not have to mind each DE configuration.
However if you're planning to deprecate imsettings for Wayland, probably it's also fine with me.


> Thank you for the information. What if no GTK_IM_MODULE is set on X11?
> Also, given that no GTK_IM_MODULE is set, how does ibus work for gtk3
> applications then? (on GNOME and on non-GNOME if it makes any difference)

I mean the settings for the Wayland. Both GTK_IM_MODULE and QT_IM_MODULE is "wayland" and I mean it would be good to disable enviroments if imsettings has some problem for the workaround.

> There are still 1016 packages on Fedora though, it looks like not trivial:

The latest ibus.conf defines GTK_IM_MODULE.

Current my suggestion is not to install ibus-xinit by default if a Fedora Spin provides both the Wayland and X11 sessions until imsettings supports the Wayland environment. And if users wish to have the previous behavior in X11, they need to install ibus-xinit by manual since our suggestion is to use Wayland.

Sorry, let me fix some typos as I'd take a lunch time after I wrote it.

(In reply to fujiwara from comment #7)
> Currently /usr/bin/imsettings-boot.sh loads
> /etc/X11/xinit/xinitrc.d/50-xinput.sh in Wayland but I think it's better to
> prepare a new script likes /usr/bin/imsettings-wayland-boot.sh and
> imsettings checks the current display is Wayland or X11 to select the script.

and for imsettings to check if the current display is Wayland or X11 to select the script.

> My idea is to check /usr/share/wayland-sessions/init/inputrc and it has the
> Wayland specific settings.

My idea is to check /usr/share/wayland-sessions/init/inputrc to have the Wayland specific settings.

> But if imsettings could the current display, the workaround won't be needed.

But if imsettings could check whether the current display is Wayland or X11, the workaround would not be needed.

> Also /usr/share/wayland-sessions/init/inputrc supports new keyword to have a
> daemon interface command likes XIM_START_COMMAND=`ibus start`.
> Current the conf file specifies the daemon execution path directly but the
> IBus interface commands exit immediately after ibus-daemon runs.

Also I'd suggest /usr/share/wayland-sessions/init/inputrc supports a new keyword to have a daemon interface command likes XIM_START_COMMAND=`ibus start`.
Currently the conf file specifies the daemon execution path directly with XIM_PROGRAM but the IBus interface command exits immediately after ibus-daemon runs.

> The `ibus start` command updates the KDE configuration file and imsettings
> side does not have to mind each DE configuration.
> However if you're planning to deprecate imsettings for Wayland, probably
> it's also fine with me.
> 
> 
> > Thank you for the information. What if no GTK_IM_MODULE is set on X11?
> > Also, given that no GTK_IM_MODULE is set, how does ibus work for gtk3
> > applications then? (on GNOME and on non-GNOME if it makes any difference)
> 
> I mean the settings for the Wayland. Both GTK_IM_MODULE and QT_IM_MODULE is
> "wayland" and I mean it would be good to disable enviroments if imsettings
> has some problem for the workaround.
> 
> > There are still 1016 packages on Fedora though, it looks like not trivial:
> 
> The latest ibus.conf defines GTK_IM_MODULE.
> 
> Current my suggestion is not to install ibus-xinit by default if a Fedora
> Spin provides both the Wayland and X11 sessions until imsettings supports
> the Wayland environment. And if users wish to have the previous behavior in
> X11, they need to install ibus-xinit by manual since our suggestion is to
> use Wayland.