https://bugs.kde.org/show_bug.cgi?id=470546
--- Comment #5 from SC <k...@scheimong.net> --- Okay. After some time of forgetting about this issue, I think I found an important lead. It seems like it's somehow related to a startup failure of ibus when using `--panel=/usr/lib/kimpanel-ibus-panel` (which frankly, is just bizarre). Follow the following steps to reproduce: 1. Create a fresh Linux VM (I tested Fedora 38 & EndeavourOS) with KDE. 2. Install `xdg-desktop-portal` and `xdg-desktop-portal-kde`, and set KDE theme to `Breeze Dark`. 3. Reboot and run the colour scheme query: `qdbus org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read "org.freedesktop.appearance" "color-scheme"`. 4. Expected: `1`; actual: `1`. 5. Create `~/.config/systemd/user/ibus@.service` and write the following content: ``` [Unit] Description=Intelligent Input Bus [Service] ExecStart=/usr/bin/ibus-daemon --replace --xim --panel=/usr/lib/kimpanel-ibus-panel Environment=DISPLAY="%I" [Install] WantedBy=default.target ``` 6. Enable this service with `systemctl --user enable "ibus@$DISPLAY.service"` and reboot. 7. Run `systemctl --user status "ibus@$DISPLAY.service"` and verify that it has failed. - The reason for this failure seems to be unrelated to this issue; it seems to be some kind of "unit started too soon". Adding `ExecStartPre=/usr/bin/sleep 10` is a quick and dirty way to prevent the failure, although I am yet to find a proper fix. 8. Rerun colour scheme query. 9. Expected: `1`; actual `2`. 10. Add `ExecStartPre=/usr/bin/sleep 10` to the ibus unit to prevent the failure and reboot. 11. Run `systemctl --user status "ibus@$DISPLAY.service"` and verify that it no longer fails. 12. Rerun colour scheme query. 13. Expected: `1`; actual `1`. I was only able to notice that this is the source of this issue because I was switching back to using fcitx5 after 2 years on ibus. When I disabled this ibus service, the colour scheme problem went away. I'm keeping this issue open because IMO the failure of a completely unrelated service should not be causing the desktop portal to misbehave. And if all this is sounding ridiculous to you, trust me, I know. It's just as ridiculous and bizarre to me, which was part of the reason it took ages for me to diagnose. I will be updating the title to something more reflective of the newly uncovered information. -- You are receiving this mail because: You are watching all bug changes.
