Description of problem: After the removal of the imsettings-systemd subpackage, the IM-related environment variables (eg. QT_IM_MODULE) are no longer set in Wayland sessions (as least for KDE). I believe this is because none of the xinput scripts are read during Wayland session initialization and things previously relied on systemd's ~/.config/environment.d/. Version-Release number of selected component (if applicable): imsettings-1.8.3-6.fc37.x86_64 How reproducible: Always Steps to Reproduce: 1. Install Fedora 37 KDE spin 2. Log into Wayland session 3. Install an input method, like fcitx5 4. Select fcitx5 with im-chooser 5. Log out and log back in (still Wayland session) 6. $ echo $QT_IM_MODULE Actual results: Environment variables like QT_IM_MODULE are not set. Expected results: The IM-related environment variables should be set. (Manually setting them allows input methods to work properly in KDE Wayland.) Additional info: n/a
Right. Because of missing xinit scripts running, plus, there are no toolkit specific configuration for Qt anymore - $HOME/.config/Trolltech.conf was available before. but it seems not working - imsettings stopped supporting Wayland. systemd environment file was required rebooting twice to apply. so that was too annoying. If there are any better way to set it up, I'm willing to implement something in imsettings to support, but I have no idea to keep running imsettings on Wayland session so far.
Thanks for the info. I hadn't heard of the rebooting twice issue. For me, on KDE Wayland, creating ~/.config/environment.d/fcitx.conf with QT_IM_MODULE/GTK_IM_MODULE took effect immediately after a log out and log in. I didn't test on other Wayland desktops though. I'm not sure if adding more desktop-specific code is a good idea, but I know KDE will source scripts in ~/.config/plasma-workspace/env/*.sh on login for both X11 and Wayland.
So is there any way to get ibus IMEs working in Plasma? I am struggling (I actually thought earlier it was working in F37)
Thanks. so if you put QT_IM_MODULE=fcitx into some file under $HOME/.config/plasma-workspace/env, logout and login, you can use fcitx on Plasma Wayland, right? That may worth trying. imsettings already has several desktop specific backend support. so that wouldn't be a big deal in that sense.
if it works in plasma, I currently have it like this # ~/.config/plasma-workspace/env/im.sh: for executing scripts at login before launching Plasma. export XMODIFIERS=@im=fcitx export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export SDL_IM_MODULE=fcitx # ~/.config/plasma-workspace/shutdown/: for executing scripts when Plasma exits. .. with sytemd # ~/.config/environment.d/im.conf # systemctl --user set-environment VARIABLE=XXXXX # only applies to the current session. systemctl --user show-environment https://wiki.archlinux.org/title/Systemd/User#Environment_variables https://fcitx-im.org/wiki/Setup_Fcitx_5#environment.d
> Thanks. so if you put QT_IM_MODULE=fcitx into some file under $HOME/.config/plasma-workspace/env, logout and login, you can use fcitx on Plasma Wayland, right? Yep, I tested a few ways and these all work for me (after a single log out + log in): 1. Setting environment variables directly in ~/.config/plasma-workspace/env/imsettings.sh export XMODIFIERS=@im=fcitx5 export GTK_IM_MODULE=fcitx5 export QT_IM_MODULE=fcitx5 2. Loading imsettings' own scripts in ~/.config/plasma-workspace/env/imsettings.sh. I also had to edit /usr/libexec/imsettings-functions so that is_{gtk,qt}_supported don't check for the systemd module in wayland. source /usr/libexec/imsettings-functions log_init setup_gtk_immodule setup_qt_immodule setup_xim 3. Setting systemd environment variables with systemd in ~/.config/environment.d/fcitx.conf XMODIFIERS=@im=fcitx5 GTK_IM_MODULE=fcitx5 QT_IM_MODULE=fcitx5 (I personally prefer 3 since it's (seemingly) more desktop-agnostic. If you'd be willing to go back to that approach, are there more details about the issues encountered with it? I'd be happy to help fix them.)
Dear developers. I have also encountered this bug and added some comments in https://bugzilla.redhat.com/show_bug.cgi?id=2131673#c11. Just for your reference. Thanks
FEDORA-2023-a13258a914 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a13258a914
FEDORA-2023-a13258a914 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-b666bfa158 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-b666bfa158
I added imsettings-plasma sub-package which contains xinput.sh shell script to set up env vars for Plasma Workspace. I didn't take a way to set env vars in $HOME/.config/plasma-workspace/env because this has a same issue to systemd and requires rebooting twice first time only, because they might be running before creating a shell script there. Anyway, input methods should works on Plasma Workspace once you install imsettings-plasma from testing repo. please test.
Thanks, Akira. I removed my local workarounds, installed imsettings-plasma, and can confirm that the new /etc/xdg/plasma-workspace/env/xinput.sh symlink works.
I guess it would be good to update comps at least with imsettings-plasma. Dunno if any KDE component should have a weak dependency on it?
I checked comps but didn't find any imsettings component found in comps except cinnamon-desktop and input-methods group. should we add imsettings-plasma to kde-desktop?
Not sure if this is the best way, but potentially something like this would work too? # In the main imsettings package Recommends: (imsettings-cinnamon if cinnamon-session) Recommends: (imsettings-gsettings if glib2) Recommends: (imsettings-lxde if lxde-settings-daemon) Recommends: (imsettings-mate if mate-settings-daemon) Recommends: (imsettings-plasma if plasma-workspace) Recommends: (imsettings-xfce if xfce4-settings) This is how fcitx5, for example, pulls in its subpackages by default.
FEDORA-2023-b666bfa158 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-b666bfa158` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-b666bfa158 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-f0a1932588 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f0a1932588
FEDORA-2023-f0a1932588 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-f0a1932588` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f0a1932588 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-b666bfa158 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-f0a1932588 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
see also https://pagure.io/fedora-comps/pull-request/822