[FEATURE] Launcher: optional run-or-raise for plain application results (design proposal)

[liamwh]

Submission checklist

• I have searched existing issues and confirmed this has not been requested before.
• I have checked existing pull requests for similar changes.

Feature type

New functionality

Feature summary

Optionally make activating a plain application result in the launcher
focus/raise an existing window of that application instead of launching a
new instance — macOS/Raycast-style run-or-raise. Proposed as an opt-in
setting, default off:

[shell.launcher]
run_or_raise = true

Motivation / use case

Today, launching an app from the launcher that is already running depends
on the app's own single-instance behaviour. Where that is missing (or
slow), Super+Space → type → Enter hands you a duplicate window, and the
user has to hunt for the old one. The dock already solves the equivalent
problem for pinned entries; the launcher is the other half of the same
muscle memory.

Proposed solution

• Opt-in [shell.launcher] run_or_raise, default off (current
  behaviour preserved; also consistent with the caution in the feat(translations): add "focus existing window" option to multiple la… #3937
  review about changing activation defaults).
• Plain application results: if a matching toplevel exists, activate it
  through the existing compositor activation path; otherwise launch
  exactly as today.
• Desktop-entry actions ("New Window", Shift+Enter context entries)
  always launch explicitly — an action is an explicit request for a new
  thing, not an app focus.
• Matching: reuse the dock's per-entry window-lookup-key derivation
  wholesale rather than writing a second matcher — one canonical
  application↔window matching implementation (StartupWMClass,
  identity-key normalisation, app-id tails covering reverse-DNS ids like
  KeePassXC/Nextcloud, Flatpak/Electron ids). The launcher and dock must
  never grow subtly different matching algorithms.
• Multiple matching windows: activate the most recent, using the same
  selection rule the dock applies after a launch — so launcher and dock
  agree on which window "the app" means, including mixed ext/wlr
  ordering on Hyprland (the ordering concern raised in the feat(translations): add "focus existing window" option to multiple la… #3937 review).

I have a working implementation of exactly these semantics running
locally (extracted the dock's lookup-key derivation into a shared
function used by both buildDockSnapshot and launcher activation, going
through enrichedWindowsForApp + activateToplevelInfo) — happy to send
the PR promptly; opening this first because the design deserves a
maintainer yes before code.

Open questions:

1. Is [shell.launcher] run_or_raise the right key/shape, or would
   maintainers prefer a different config surface (e.g. per-result
   modifier: Enter = raise-if-running, Shift+Enter = always launch)?
2. Should feat(translations): add "focus existing window" option to multiple la… #3937's extracted window_activation.h seam be the shared
   foundation for this too? Happy to build on whichever shape lands
   first to avoid churn/conflicts.
3. Preferred multi-window rule: most recent (dock launch-focus parity)
   vs next-activatable (dock cycling parity)?

Alternatives considered

• Doing nothing: the dock covers pinned apps, but launcher-first users
  (keyboard-driven) get duplicates.
• Always-on: rejected — activation semantics changes affect toggle-style
  apps, as the feat(translations): add "focus existing window" option to multiple la… #3937 review notes.

References / related projects

• feat(translations): add "focus existing window" option to multiple la… #3937 — tray "focus existing window" (adjacent activation work and
  the source of the matching/ordering cautions above)
• [FEATURE] Tray: focus the app's already-mapped window on left click (v5.0.0-beta.7 repro; SNI Activate is a no-op for Slack) #3859 — the tray-side motivation (SNI Activate no-op on Wayland); the
  launcher side has the same Wayland reality but a cleaner fix path
  since the shell already owns the launch decision

Additional context

Disclaimer: AI-assisted tooling was used.