This is a focused comparison of Runic's implemented portal paths with ashpd and Tmds.DBus, not certification of every desktop or a proposal to expose every portal.
Generation decision
Use Tmds.DBus.Generator with our existing Tmds.DBus.Protocol runtime, both pinned
to 0.95.1. The first pilot generates Registry and Notification proxies from
upstream 1.22.1 XML. The old reflection-oriented Tmds.DBus library and its legacy
codegen path are not needed. See the provider's Protocol/README.md for provenance
and reproduction commands.
Ashpd's update script synchronizes XML; its client also uses handwritten semantic
types and shared request infrastructure. XML only specifies many options as
a{sv}. It cannot replace platform policy, version-aware options or lifetime rules.
Findings
| Area | Runic finding | Action |
|---|---|---|
| Host identity | Owning a bus name did not associate the notification connection with a desktop ID. | Fixed before this pilot; generated Registry proxy preserves registration before portal calls. |
| Notification serialization | Envelope, property and signal readers were handwritten. | Replaced with generated proxies; semantic option dictionaries remain explicit. |
| Early notification actions | Callback can precede AddNotification's reply. | Preserve tracking before invoking the generated method; regression test covers this ordering. |
| Request/Response race | File operations subscribe before submitting, correlate returned handles and support older handle paths. | Keep existing implementation/tests during this pilot. |
| Cancellation | File requests close their request handle; notification submissions drain a bounded reply once sent. | Preserve these distinct contracts; do not blindly forward cancellation into generated calls. |
| File descriptors | Tmds owns the wrapper; Runic retains the caller's SafeHandle through a borrowed wrapper. | Keep explicit ownership and existing FD conformance tests. |
| Versions | OpenFile needs v2; chooser/reveal features need v3. Notification public features use v1. | Preserve guards; generating newer members does not enable them automatically. |
| Window parenting | GTK3/GTK4 adapters export owned X11/Wayland parents; owner changes invalidate requests. | Keep native owner adapters outside generated protocol code. |
| Notification portal restart | The session bus can outlive the portal process. | Implemented owner-bound calls and re-registration on the next notification operation; an in-flight replacement test proves no automatic replay. |
| Host identity outside notifications | Services need consistent identity without sharing unrelated resource lifetimes. | PortalApplication configures one ID for settings, notifications, chooser, URI and FD handoffs; each owned connection registers before portal calls. |
| Settings observation | Runic polls and deduplicates; ashpd offers native SettingChanged streams. | Consider signal observation with reconnect/resync if polling becomes measurable friction. |
| Activation focus | Notification ActivateAction preserves bounded activation-token and desktop-startup-id context. GTK3/GTK4 owners apply it before presenting the selected window on its dispatcher. | KDE and GNOME live and cold GTK4 focus passed; focus remains compositor-controlled. |
| Live coverage | JIT and NativeAOT protocol checks pass. KDE/GNOME Wayland notification actions and P1 file handoffs passed in reproducible guests; GTK4 live/cold focus also passed on both desktops. | macOS native providers remain implemented but untested pending Mac access. |
Interactive checks
Reuse the existing native prototype fixture instead of creating a second product
application. --native-services supports isolated Notifications, Open,
ChooseApplication and Reveal via RUNIC_TEST_SERVICE; notifications include
opt-in diagnostics and require the actual Open result callback. Supply an
installed desktop identity using RUNIC_TEST_APP_ID. The 120-second notification
wait withdraws the item when it ends, so check history before cleanup. The
portal-only test executable also supports --settings without a GTK host.
When extending this fixture, keep popup visibility, history retention, action receipt, replacement, withdrawal and cold relaunch separate observations. A successful AddNotification reply proves request acceptance only.