Desktop Portals

Tools like satty open a Save dialog through xdg-desktop-portal, and browsers and OBS use it for screen sharing. Sweets wires this up automatically, but only for a real session started through sweets-session.

Save dialogs and screen sharing

What happens on startup:

• The session launcher exports XDG_CURRENT_DESKTOP=sweets and SWEETS_SESSION=1.
• Sweets asks dbus-update-activation-environment to sync WAYLAND_DISPLAY, XDG_CURRENT_DESKTOP, and XDG_SESSION_TYPE into the D-Bus activation environment.
• On a systemd boot with a live user manager, that sync also updates systemd. Sweets then starts sweets-session.target and refreshes existing portal services. If the activation updater is missing, Sweets starts the target but skips the portal refresh rather than restarting portals with stale state.
• sweets-portals.conf routes file dialogs to xdg-desktop-portal-gtk and screenshot/screencast to xdg-desktop-portal-wlr.

Install these with dev/install-local or meson install. You need xdg-desktop-portal plus xdg-desktop-portal-gtk and xdg-desktop-portal-wlr. Nested and dev runs skip all of this so they never disturb the host session.

On runit, OpenRC, dinit, and other non-systemd systems, Sweets never invokes systemctl or systemd-run. Portable D-Bus activation syncing still runs when dbus-update-activation-environment is installed. Starting portal services is left to the user session or service manager. The log reports which integrations were requested and which were skipped.

If you share a single window and then switch workspaces, the share can freeze on a still image: a window that is on screen nowhere stops drawing. Add render_unfocused to the rule for the window being shared — the browser or the game, not OBS.

Keyring and secrets (optional)

Most password storage does not involve the compositor. Native apps talk to a keyring daemon over the Secret Service D-Bus API (org.freedesktop.secrets) directly. Install and start gnome-keyring or KeePassXC and it works — Sweets is not in that path.

The org.freedesktop.impl.portal.Secret portal only matters for sandboxed apps that reach a keyring through the portal instead of raw D-Bus. Sweets deliberately does not pin a Secret backend, so xdg-desktop-portal auto-selects whatever keyring is installed and the default stays portable.

To force gnome-keyring, add the line in your user portal config at ~/.config/xdg-desktop-portal/sweets-portals.conf:

[preferred]
default=gtk
org.freedesktop.impl.portal.Screenshot=wlr
org.freedesktop.impl.portal.ScreenCast=wlr
org.freedesktop.impl.portal.Secret=gnome-keyring

gnome-keyring must be installed, running, and unlocked to serve secrets.