1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
# Feature gap survey: srdwm vs. comparable Wayland compositors
Requested directly: compare srdwm against similar projects and note what
else is worth having. Compared against niri (cloned at
`~/reference-wms/niri`, smithay-based like `crates/wayland`, the closest
architectural sibling per `docs/PRIOR_ART.md`) plus general knowledge of
Hyprland and sway, since neither is cloned locally. srdwm is dynamic/
floating-first with opt-in tiling (`crates/core/src/layout.rs`), not
tiling-first - comparisons below are scoped to what a daily-driver desktop
user would actually notice, not "does it tile as well as sway."
## Already comparable
Confirmed by reading the actual code, not by trusting `docs/TODO.md`'s own
claims:
- **Session lock** (`ext-session-lock-v1`) - full implementation
(`crates/wayland/src/lock.rs`), verified live with a purpose-written
protocol test client, not just against a real locker binary.
- **Tiling** - a real dwm/i3-style master-stack layout
(`crates/core/src/layout.rs`), opt-in per srdwm's dynamic-first design,
not the only layout.
- **Global menu / app menu export** - `com.canonical.AppMenu.Registrar`
and dbusmenu (`crates/platform/src/appmenu_registrar.rs`,
`crates/wayland/src/appmenu.rs`). Neither niri nor sway ship this at all;
it is a GNOME-HUD/Unity-era convention most compositors dropped.
- **Right-click desktop/icon context menus** - real, compositor-owned
floating UI (`crates/wayland/src/desktop_menu.rs`,
`crates/wayland/src/context_menu.rs`). niri and sway have no desktop
icons at all; this is closer to what Hyprland users get from a separate
panel, but srdwm draws it itself.
- **Gamma control** (`wlr-gamma-control-unstable-v1`, night-light/redshift-
style color temperature) - `crates/wayland/src/gamma_control.rs`. Same
protocol niri implements.
- **Idle handling** (`ext-idle-notify-v1`, `zwp-idle-inhibit-manager-v1`)
- `crates/wayland/src/protocols/idle.rs`, `crates/wayland/src/
output_power.rs`. Screen-dim/DPMS-on-idle and an app's ability to
suppress it (a video call staying awake) both work.
- **Layer-shell** (bars, docks, launchers, notifications) - full, with
exclusive-zone handling on fractionally-scaled outputs (a genuinely hard
case niri and sway both get right too, and srdwm has now independently
fixed the same class of bug on its own scale-below-1.0 feature).
- **Output management** (`wlr-output-management-unstable-v1`) - real,
plus srdwm's own layout persistence (`crates/wayland/src/
monitor_layout.rs`) that neither waits on nor depends on a panel to
restore monitor position/enabled-state across a restart.
- **XWayland** - full, with WM_TRANSIENT_FOR-based dialog detection,
clipboard bridging, and EWMH.
## Genuine gaps, ranked by how much a daily user would notice
1. **No screen-sharing / video-call screen capture.** `grep -rn pipewire`
and `grep -rn portal` across `crates/wayland/src` return nothing. niri
ships real PipeWire-backed screencasting (`src/screencasting/
pw_utils.rs`) so `xdg-desktop-portal-wlr`/`-gnome` can hand a window or
output to Zoom, Discord, Google Meet, OBS, etc. srdwm has
`zwlr_screencopy_manager_v1` (one-shot capture, what `grim` uses) but
nothing a portal can wire to for a *live* video stream. This is the
single most likely thing a daily user hits and can't work around --
worth scoping as real work, not a one-line addition (needs a PipeWire
dependency and an `xdg-desktop-portal` backend, or at minimum wiring an
existing generic wlr backend against srdwm's own screencopy).
2. **No `zwlr_virtual_pointer_manager_v1`.** Already flagged in `docs/
TODO.md`'s own protocol-gaps section: `ydotool` and any UI-automation
tool that wants precise synthetic clicks has no real protocol path here
(`zwp_virtual_keyboard_manager_v1` exists; the pointer half doesn't).
niri implements this (`src/protocols/virtual_pointer.rs`). Directly
relevant to this project's own testing methodology, independent of
whether any real user-facing app needs it.
3. **No `ext-workspace-v1`.** srdwm's workspaces are real and queryable
(`srd workspaces`), but only through its own bespoke IPC - a
third-party panel/switcher that speaks the standardized
`ext-workspace-v1` protocol (what niri and sway both also implement
for exactly this reason) has nothing to bind to. Low-impact today only
because AGS is a first-party shell built against `srd`'s own IPC
directly; would matter the moment someone wants to run a generic
workspace-switcher widget unmodified.
4. **No touchscreen support (`wl_touch`).** Zero matches for
`TouchHandler`/touch-slot handling anywhere in `crates/wayland/src`.
Both niri and sway support it. Not clearly a gap worth closing blind --
see `docs/TODO.md`'s own "decide scope first" note on this: a
touchscreen on a device with no on-screen keyboard/gesture layer is a
different, larger product decision than just wiring the protocol.
5. **No accessibility tree (AccessKit or similar).** niri ships a real
`a11y.rs` exposing window/workspace state to assistive tech via
AccessKit. Nothing comparable exists in srdwm. Niche for this specific
user's own daily-driver use case, but worth naming since sway has had
growing accessibility interest too.
6. **No live/animated wallpaper support in the compositor itself.** Not
actually a gap versus niri or sway - neither of them render wallpapers
either; that is `swaybg`/`swww`/`mpvpaper`-style external clients'
job, and srdwm already has exactly that split (`awww`, a swww fork,
launched from `~/.config/srd/autostart.sh`, with the compositor just
compositing whatever that client draws via layer-shell). If "live
wallpapers" means something *animated* rather than just a static image,
that is an `awww`/wallpaper-daemon feature request, not a compositor
one - worth confirming with whoever owns that tool before treating it
as an srdwm gap at all.
## vs. full desktop environments (KDE Plasma, GNOME, XFCE, macOS, Windows), requested directly (2026-08-27)
A different comparison than the rest of this file: niri/sway/Hyprland are tiling-WM peers at the same layer srdwm occupies (compositor + window management), while KDE/GNOME/macOS/Windows are full desktop environments bundling a shell (panel, launcher, notifications, quick settings, wifi/bluetooth applets, alt-tab UI) *on top of* a compositor (KWin, Mutter) or platform windowing system. Since AGS is this project's own shell, most "full DE" features are AGS's scope, not srdwm's - the honest comparison is srdwm against the compositor *underneath* those shells (KWin/Mutter/Explorer's own DWM/macOS's WindowServer), not against the shell chrome itself. Verified by reading the actual code before listing anything, not assumed either way:
**Already real, contrary to what a surface-level comparison might assume:**
- **Clipboard/copy-paste between apps.** `delegate_data_device!(CompState)` (`crates/wayland/src/protocols.rs`) wires smithay's own real `wl_data_device` support - Ctrl+C in one app, Ctrl+V in another already works, the same as KWin/Mutter/every comparable compositor. What's *not* built (see `docs/TODO.md`'s own desktop-icons entry) is dragging a *desktop icon* into a real app window specifically - desktop icons are compositor-drawn pixels, not real Wayland surfaces, so they can't be a drag-and-drop source through the protocol without new, real work to make them one.
- **Drag-and-drop between real windows** (a browser tab torn into a new window, a file dragged from one app to another) - real, already fixed this session's own history (`docs/TODO.md`'s "not being able to drag a tab from one window onto another" entry).
**Genuine gaps a full-DE comparison surfaces, beyond what's already tracked above:**
1. **No compositor-level blur-behind.** KDE Plasma's own Blur effect and GNOME Shell's panel/overview blur both composite a real backdrop blur behind translucent UI (a panel, an overview, this project's own context menus if `opacity` were used for one) - srdwm has no GPU blur shader anywhere; `crates/wayland/src/decoration.rs`'s own menus/panels are plain flat fills. Real, scoped GPU work (a fragment shader pass over the region behind a surface), not attempted here.
2. **Fractional-scale correctness gap has a real user-facing cost KDE/GNOME don't have.** Already tracked in detail in `docs/TODO.md` ("wl_pointer motion/button coordinates are delivered unscaled... on a non-1.0-scale output") - KWin/Mutter both get this right via their own per-client scale handling; srdwm's own fix needs a real `PointerTarget` reimplementation, already scoped there as large, not re-litigated here.
3. **No screen-casting/remote-desktop portal backend** (PipeWire + `org.freedesktop.impl.portal.ScreenCast`/`RemoteDesktop`) - confirmed zero references to PipeWire anywhere in `crates/`. KWin and Mutter both ship real backends; niri and sway don't either (already the #1 item in this file's own niri-comparison section above) - a full-DE comparison just raises how much *more* daily-relevant this gap is (Zoom/Discord/OBS screen-share, not a niche feature).
4. **No accessibility stack** (AT-SPI/AccessKit) - already listed above against niri; KDE/GNOME's own screen-reader, magnifier and high-contrast support is considerably deeper than niri's partial AccessKit tree, widening rather than changing this gap.
**Explicitly AGS's scope, not srdwm's, listed here only to draw the line clearly:** notifications daemon/UI, quick-settings/wifi/bluetooth/volume applets, an app launcher, alt-tab/window-switcher UI (built on `zwlr_foreign_toplevel_handle_v1`, which srdwm already exposes - `crates/wayland/src/foreign_toplevel.rs`), a screenshot-tool UI (srdwm exposes the real capture primitive, `zwlr_screencopy_manager_v1`; `grim` or a custom AGS tool is the UI on top), on-screen keyboard, do-not-disturb. None of these are compositor gaps; conflating them with srdwm's own scope is the actual mistake a naive "vs. Windows/macOS" comparison would make.
## Deliberately out of scope / not real gaps
- **Multi-GPU.** Documented and accepted (`docs/IMPLEMENTATION_STATUS.md`):
only the primary GPU's connectors are driven, a GPU appearing/
disappearing is logged and ignored. Neither a laptop-daily-driver nor
this machine's real hardware needs it.
- **A native GUI settings app.** Never existed even as working code in
the legacy C++ project; Lua config plus `srd` CLI covers the same
ground niri's own KDL config file does, and neither niri nor sway ship
a GUI settings app either - this would be an srdwm-specific addition,
not catching up to a peer.
- **Hardware DRM cursor plane / direct scanout / VRR / HDR.** Real,
ranked gaps against niri and Hyprland specifically (both do real
GPU compositing with these), but already tracked in `docs/TODO.md`'s
own "Render pipeline - researched, ranked, not started" section as
large, sequenced architectural work, not something this survey adds
anything new to.
- **"Different monitor modes combined in one," phone-monitor/VM special
workspace, optional AGS/srdwm phone mode.** None of niri, sway, or
Hyprland have anything resembling these - they are not features to
catch up on from a peer project, they are net-new product ideas
specific to this user's own workflow. Out of scope for a feature-parity
survey; each needs its own real design pass (see `docs/TODO.md`/the
night's parked questions for what's still undecided about them).
|