# SUMMARY `qdbus org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read org.freedesktop.appearance color-scheme` is not correctly reporting the user's preferred theme (dark/light) after startup. Only after manually restarting `xdg-desktop-portal-kde` (`systemctl --user restart plasma-xdg-desktop-portal-kde.service`) does it work correctly. See here (https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/52#note_691671) for how I ran into this problem + initial triage. # STEPS TO REPRODUCE 1. Make sure `xdg-desktop-portal` and `xdg-desktop-portal-kde` are installed 2. Set your KDE theme to `Breeze Dark` 3. Restart your OS 4. Run `qdbus org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read "org.freedesktop.appearance" "color-scheme"` 5. Run `systemctl --user restart plasma-xdg-desktop-portal-kde.service` 6. Repeat step 4 # OBSERVED RESULT The dbus query (step 4) prints 2. Then after restart, the same query (step 6) prints 1. # EXPECTED RESULT They should both print 1. # SOFTWARE/OS VERSIONS - OS: EndeavourOS with all updates (as of 2023-06-02) - Kernel: `6.3.5-arch1-1` - Display server: X11 - Plasma: `5.27.5` - Framework: `5.106.0` - Qt: `5.15.9` - xdg-desktop-portal: `1.16.0` - xdg-desktop-portal-kde: `5.27.5` # ADDITIONAL INFORMATION I tested this on several different systems at my disposal. The results are somewhat curious. - Both of my EndeavourOS KDE laptops have this issue - Neither of my two tested VMs have this issue, including: - EndeavourOS KDE - Fedora 38 KDE - I also have Debian 11 but it only has KDE `5.20.5`, so I was not able to test it Related bug: https://bugs.kde.org/show_bug.cgi?id=458865
Cannot reproduce on master, where we have radically refactored code though.
> - Neither of my two tested VMs have this issue, including: > - EndeavourOS KDE Is the VM fully updated to the same release as your laptops? If yes, then there might be something in the configuration of your machines that is causing early startup. If not, then what happens if you do update it, without changing anything else?
Also cannot reproduce on master, when following the exact steps indicated.
(In reply to Bharadwaj Raju from comment #2) > Is the VM fully updated to the same release as your laptops? If yes, then > there might be something in the configuration of your machines that is > causing early startup. Yep they are all fully updated. Fedora 38's KDE version (and version of related components) are all up to date with Arch. I'll run `systemd-analyze plot` on Monday on all my machines to look for any startup order differences.
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.
Oh and, before step 5, obviously you should install `ibus` using whatever package manager it is on your distro. I forgot to mention that.