Desktop Integration

Sweets speaks the standard wlroots desktop protocols, so external clipboard managers, screenshot tools, idle daemons, color-temperature tools, and screen lockers work without compositor-side configuration.

Clipboard Managers and Primary Selection

Sweets supports normal Wayland clipboard selection, primary selection, and the data-control protocols used by clipboard managers.

Advertised globals:

• wl_data_device_manager
• zwlr_data_control_manager_v1
• ext_data_control_manager_v1
• zwp_primary_selection_device_manager_v1

# smoke tests
printf 'hello from sweets\n' | wl-copy
wl-paste

printf 'primary hello\n' | wl-copy --primary
wl-paste --primary

Clipboard managers that use either legacy wlr-data-control or newer ext-data-control can observe and restore selections.

Drag and Drop

The same wl_data_device_manager global powers client drag-and-drop. You can drag files, text, or other content between native Wayland applications — for example dragging a folder out of a file manager and dropping it into a browser upload field or a text editor. Both pointer drags and touch drags are supported, and the drag icon (when the source provides one) follows the cursor or touch point above all windows.

Keyboard focus does not change while a drag is in progress; the window that was focused before the drag keeps focus once you drop.

Sweets implements the standard wlroots screen-capture protocols, so external tools work without any compositor-side configuration:

• Legacy wlr-screencopy (zwlr_screencopy_manager_v1) — grim, slurp, wf-recorder, older OBS.
• Modern ext-image-copy-capture with an output capture source — current versions of grim, hyprshot, and other up-to-date screenshot tools.
• Per-window capture via ext-foreign-toplevel-image-capture — lets a client capture a single application window (paired with ext-foreign-toplevel-list) instead of a whole output, for window-only screen sharing.

grim screenshot.png                          # whole output
hyprshot -m region --raw | satty --filename - # region into an editor

Idle tools

Sweets implements ext-idle-notify-v1 and idle-inhibit-v1, so tools such as swayidle can observe user inactivity and apps such as video players can block idle behavior while they need to stay active. Keyboard and pointer input reset the idle timer.

Sweets also implements wlr-output-power-management-unstable-v1. Tools such as wlopm can power outputs directly, and sweetctl exposes the same behavior for scripts:

sweetctl output DP-1 power off
sweetctl output DP-1 power on
sweetctl output all power off

A simple idle recipe:

swayidle -w \
  timeout 300 'sweetctl output all power off' \
  resume 'sweetctl output all power on'

Display Configuration

Sweets implements wlr-output-management-unstable-v1, so output configuration clients can inspect and apply a complete monitor layout. wlr-randr is useful for terminal-driven changes, while wdisplays provides a graphical editor.

# confirm the protocol and inspect the current layout
wayland-info | rg zwlr_output_manager_v1
wlr-randr

# open a graphical layout editor, if installed
wdisplays

The protocol validates a complete requested configuration with the backend before applying it, so unsupported combinations are rejected without a partial monitor rearrangement. Successful changes update the live output state and sweetctl outputs immediately.

Night Light and Gamma

Sweets implements wlr-gamma-control-unstable-v1, so tools such as wlsunset and gammastep can adjust output color temperature.

# smoke test
wayland-info | rg zwlr_gamma_control_manager_v1

Screen Lockers

Sweets implements ext-session-lock-v1, so screen lockers such as Veila can take over the session securely. While locked, Sweets covers every output with an opaque black scene, routes keyboard and pointer input only to lock surfaces, and keeps newly mapped normal windows behind the lock.

Save dialogs and screen sharing (xdg-desktop-portal)

Tools like satty open a Save dialog through xdg-desktop-portal, and browsers/OBS use it for screen sharing. Sweets wires this up automatically, but only for a real session started through sweets-session (display manager or sweets-session on a TTY):

• The session launcher exports XDG_CURRENT_DESKTOP=sweets and SWEETS_SESSION=1.
• On startup Sweets syncs WAYLAND_DISPLAY / XDG_CURRENT_DESKTOP into the D-Bus/systemd activation environment and starts sweets-session.target, which brings up graphical-session.target (the portal requires it).
• sweets-portals.conf routes the portal to backends for the sweets desktop: file dialogs to xdg-desktop-portal-gtk, 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 (file dialogs) and xdg-desktop-portal-wlr (screen sharing) installed. Nested/dev runs deliberately skip all of this so they never disturb the host session's portals.

Sandboxed applications (security context)

Sweets implements security-context-v1. Sandbox runtimes such as Flatpak attach a security context to the nested Wayland socket they give a sandboxed app, which lets Sweets recognise that client as sandboxed.

Sandboxed clients are denied the privileged Wayland protocols — screen and window capture, clipboard data-control, layer-shell, the session locker, gamma and output management, virtual keyboard/pointer input injection, input-method, and the window-management protocols. A sandboxed app therefore cannot silently screenshot your screen, read your clipboard, inject input, or spoof a lock screen. Ordinary protocols (app windows, outputs, scaling) stay available, so normal Flatpak apps keep working.

This is enforced compositor-side and needs no configuration. Screen sharing from a sandboxed app still works through xdg-desktop-portal, which brokers capture on the app's behalf with your consent rather than handing it the raw protocol.