Wayland raise viability spike

[jonocodes]

Part of #116

Question

Can the GNOME Shell extension reliably raise an arbitrary window on Wayland? Hack a RaiseApp(app_id_or_wm_class) D-Bus method into deckd-focus@local using Main.activateWindow (or equivalent) and drive it via busctl / the existing dbus: action dispatch — no daemon changes. Verify: raises across workspaces, works for flatpak vs native app-ids, behavior with multiple windows of the same app, and what failure looks like when the app isn't running. Outcome is a go/no-go plus observed constraints that feed the matching-semantics ticket.

[jonocodes]

Verdict: GO — Main.activateWindow reliably raises on GNOME 50 Wayland

Spike: throwaway extension deckd-raise-spike@local (owns org.deckd.RaiseSpike, exposes ListWindows + RaiseApp), driven with busctl, human-observed on a live Wayland session. Captured on branch spike/117-wayland-raise (do not merge); full log in that branch's FINDINGS.md.

Observed (all cases confirmed on screen)

• Cross-workspace raise: YES — raising a window on workspace 1 from workspace 0 visibly switched the active workspace (workspace_switched:true, 0→1).
• Multi-window same app: YES — two Firefox windows share one pid (138311), so pid cannot disambiguate; sorting by get_user_time() picked the MRU window, human-confirmed. Raise target must be keyed by window id (Meta.Window.get_id()), MRU as tie-break.
• Minimized window: YES — a minimized flatpak un-minimized and came to front; Main.activateWindow is not a no-op on minimized windows.
• App-not-running: CLEAN — matched:0 no-op, unambiguous.
• Flatpak: YES — DBeaver reports wm_class:"DBeaver", app_id:null, sandboxed_app_id:"io.dbeaver.DBeaverCommunity"; raised by matching the sandboxed id.

Identity keys — THREE, not one (feeds #119)

get_wm_class() is present on every window (reliable primary). get_gtk_application_id() is null for Firefox/Thunderbird/Telegram, set only for well-behaved GTK apps (Tilix=com.gexperts.Tilix). get_sandboxed_app_id() carries the flatpak id. #118 assumed gtk app-id; reality on 50 is wm_class-primary, with app_id/sandboxed_app_id as sometimes-present secondaries.

Constraints for the build

1. Raise keyed by window id, MRU disambiguation on multi-match.
2. Identity is wm_class-primary, with gtk-app-id + sandboxed-app-id as secondaries.
3. Stage-0 regression: deckd-focus@local is dead on GNOME 50 — Gio.DBus.session.own_name(name,flags,null,null) no longer exists; the 6-arg Gio.bus_own_name(BusType,name,flags,…) is required. Fix ticket spawned.
4. Dev loop: Wayland needs a full logout/login per extension code change — disable/enable does NOT re-run enable(). Feeds the testing-story fog.
5. GNOME 50 is already past GNOME Shell enumeration & activation API research #118's researched 40–48 range — the shell-version support policy is a live build decision.

raise: as a first-class primitive is viable. Unblocks #119.

[jonocodes]

Resolved GO. Spike on branch spike/117-wayland-raise; findings folded into #119's inputs and the map.