Open links in a webapp window instead of a browser tab

[shmall03]

Summary

All panel links funnel through openUrl() in Panel.qml, which launched omarchy-launch-browser. This switches it to Omarchy's omarchy-launch-webapp, so notifications, review requests, pull requests, assigned issues, workflow runs, and repositories open in a dedicated app-mode window (chromium --app=<url>) instead of a new browser tab.

Notes

• omarchy-launch-webapp ships with Omarchy and targets Chromium-based default browsers (falling back to chromium.desktop). On systems whose default browser is not Chromium-based, behavior would differ — happy to gate this behind a bar-widget setting if you would rather keep browser-tab behavior for those setups.
• Verified with omarchy plugin validate . and all bundled tests (helper-test.sh, panel-source-test.sh, service-source-test.sh).

[ujo4eva]

Thanks for this — works as described on my system. Rather than swapping unconditionally, would you consider making it configurable? A few thoughts:

1. Setting: add an enum to manifest.json's schema, e.g. "Open links" with options "Browser tab" (default) / "Web app window". That preserves current behavior for existing users and non-Chromium default browsers (the caveat you flagged), while letting web-app users opt in.
2. Focus existing window: repeated clicks currently spawn a new --app window each time. An optional third mode, "Web app window (focus existing)", could use omarchy-launch-or-focus-webapp GitHub <url> so clicking links reuses/focuses the running GitHub window instead of accumulating windows.
3. Implementation is small: one openUrl() branch in Panel.qml reading the setting via the existing setting() helper, plus schema/defaults entries in manifest.json.

Happy to push commits to that effect here if useful, or happy to review whatever shape you land on.

[shmall03]

Thanks again for testing and for pushing on configurability — it's in much better shape now. Open links is a proper setting with three options: Browser tab (default, unchanged), Web app window, and Web app window (reuse) (7977b20 + b2c51d1).

Your point 2 took a detour though: I implemented it with omarchy-launch-or-focus-webapp as you sketched, but it turns out that helper only focuses — when a matching window exists it never runs the launch command, so the URL gets dropped entirely. Clicking a new notification just bounced focus onto whatever page was already open. Since there's no clean way to make an existing Chromium app window navigate from outside on Wayland, I swapped the mechanism instead: Web app window (reuse) now ships a tiny helper (omarchy-github-open, bundled alongside omarchy-github-fetch like the plugin's other executable) that closes any open GitHub web app windows and opens the clicked link in a fresh one. Same net effect — one window, no pile-up — except the content is actually what you clicked.

Default stays Browser tab per your compatibility point, so existing users see zero change, and the two webapp options flag the Hyprland/Chromium requirements in their descriptions.

Would you mind taking another look?

[ujo4eva]

Thanks for iterating so quickly — the three-mode setting reads well and the Quattro dispatch handling (hl.dsp.window.close(...) with the legacy fallback) is correct on my system.

One substantive problem in omarchy-github-open:

The window-class pattern only matches Google Chrome. The script uses:

pattern='chrome-github\.com__'

Chromium-based browsers derive the app-window class from their own binary name, so the same URL produces different classes per browser:

• Google Chrome: chrome-github.com__-Default
• Brave: brave-github.com__-Default
• Chromium: chromium-github.com__-Default
• etc.

I confirmed on my system (Brave is the default browser): running web app windows appear as brave-web.whatsapp.com__-Default, brave-x.com__-Default, etc. So with any non-Chrome default browser, "Web app window (reuse)" never finds the existing GitHub window, skips the close step entirely, and piles up a fresh window per click — which is exactly the behavior this mode exists to prevent. Given Omarchy defaults to Chromium, this will bite a lot of users, so I think it needs fixing before merge.

Suggested fix — match on the origin rather than the browser prefix:

pattern='github\.com__'

or, slightly tighter:

pattern='[a-z-]+-github\.com__'

Minor nit: Qt.resolvedUrl("omarchy-github-open")...replace(/^file:\/\//, "") breaks if the resolved path ever gets percent-encoded (spaces/unicode in $HOME); decodeURIComponent() on the stripped result would make it robust. Not blocking.

[shmall03]

Both fixed in 6c5670a — thanks for catching the class issue, and you were right that it would have bitten a lot of users. Amusingly it worked on my setup by pure luck: /usr/bin/chromium happens to produce chrome- prefixed classes here, same as Google Chrome.

I went with your first suggestion (github\.com__) rather than the tighter variant — matching the origin alone also catches binary names the [a-z-]+ prefix would miss (digits, uppercase), and the false-positive surface is essentially nil since only app-mode windows derived from github.com URLs ever contain that string. Verified against chrome-, brave-, chromium-, msedge-, vivaldi-, and opera- prefixed classes plus a pile of unrelated ones.

Also applied your decodeURIComponent() point — including to helperPath() in Service.qml, which turned out to have the same latent pattern for omarchy-github-fetch.

Ready for re-review whenever you get a chance!

[robzolkos]

Thanks for this. I've combined it with #9 and merged it in #10 — your first commit is the behaviour I've settled on, and it's in main unchanged with your authorship intact.

What landed:

• de5ed11 — the one-line swap to omarchy-launch-webapp, now the unconditional behaviour
• b2b4213 — the decodeURIComponent fix in helperPath(), which I pulled out into its own commit under your name. That one was a genuine find and had nothing to do with the rest of the PR: the plugin couldn't launch its fetch helper from a path containing spaces or non-ASCII characters. Easy to have missed.

I merged rather than squashed specifically so those stayed yours.

What I dropped, both to keep the surface small:

• The linkBehavior setting. Once I'd decided the app window is the behaviour I want, a three-way enum is a setting I'd have to support forever to preserve a default I no longer prefer. You offered in your notes to gate it behind a setting — I appreciated the instinct, it just turned out not to be needed.
• Web app window (reuse) and omarchy-github-open. This is the one worth discussing, because the problem it solves is real: click five notifications, get five windows. I dropped it because closing windows via hyprctl and sleeping 250ms before reopening is fragile, and it hard-codes a Hyprland dependency into a plugin that otherwise doesn't have one. I'm running the merged version on my own bar now to see how much the pile-up actually bothers me. If it does, I'd rather solve it by reusing the existing window than by closing and reopening one — happy to have that conversation in an issue if you're interested.

Closing as merged via #10.