fix: link systemd user units so the settings portal activates - #3
Open
p134c0d3 wants to merge 1 commit into
Open
fix: link systemd user units so the settings portal activates#3p134c0d3 wants to merge 1 commit into
p134c0d3 wants to merge 1 commit into
Conversation
The portal backend's systemd user unit installs under $prefix/lib/systemd/user, a path systemd --user does not scan for non-standard prefixes (e.g. /opt/local). D-Bus activation of the Settings portal backend then fails, so libadwaita apps never receive the color-scheme/accent and fall back to light regardless of the desktop dark-mode preference. Link the shipped user units from the session at startup so systemd can find and activate them whatever the install prefix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
libadwaita apps render in light mode even when the desktop is set to dark. The Settings portal backend (
xdg-desktop-portal-singularity) reports the correctcolor-scheme, but it never runs: its systemd user unit installs to$prefix/lib/systemd/user, andsystemd --useronly scans/etc/systemd/userand/usr/lib/systemd/user. For non-standard prefixes (e.g./opt/local) the unit is invisible, so D-Bus activation fails withServiceUnknown: not activatable. Sandboxed (Flatpak) libadwaita apps readcolor-schemeonly through the portal, so with no value served they fall back to light.Fix
Link the shipped user units from
$LIB/systemd/userat session startup anddaemon-reload, so systemd can find and activate them regardless of install prefix. Preserves the existing systemd-managed lifecycle (the D-BusSystemdService=activation path). On standard-prefix installs the units are already on systemd's search path, so the link is a harmless no-op (guarded with|| true).Testing
On an
/opt/localinstall with the desktop set to dark:gdbus call ... org.freedesktop.appearance color-scheme→ NotFound; Flatseal (Flatpak/libadwaita) opens light.color-scheme = 1; Flatseal opens dark and follows live dark/light toggles.