Read the default browser once, and recognise one that registered itself

[VykosMolt]

With no arguments omarchy-default-browser answers with the short name for the current browser, and every row of Defaults > Browser runs it in its checked guard. It ran xdg-settings get default-web-browser twice: once for the case, and again in the unmatched arm to echo the raw value.

The unmatched arm is not the rare one. A browser that registers itself through xdg-settings rather than shipping a packaged desktop entry gets a generated id — Zen installs userapp-Zen-81ROQ3.desktop, which matches none of the seven cases. So the common path was the one paying twice, once per row of the menu.

The same mismatch is a second, quieter bug. The unmatched arm echoes the raw desktop id, so the menu compares userapp-Zen-81ROQ3.desktop against zen and the Zen row can never show as checked, whichever browser is actually default.

A generated entry names the browser in its Exec rather than in its filename, so the unmatched arm now opens the entry and maps the program it runs back to the name this command answers with. That is read out of the entry rather than guessed from the filename, because the filenames are not reliable: matching *hrom* would claim Chrome for Chromium. Anything still unidentifiable falls back to the raw id, which is what the command answered before.

Testing

On this machine, whose default browser is Zen installed through xdg-settings:

                    answer                        10 runs
quattro   userapp-Zen-81ROQ3.desktop               83.3 ms
patched   zen                                      42.4 ms

The answer on the left is why the Zen row is never checked; the time on the right is paid once per menu row.

default-apps-test.sh gains six assertions: the seven packaged ids still read as their own names, a single xdg-settings call on the unmatched path, a single call on the packaged path, a generated Zen entry reading as zen, a generated entry resolved without a second call, and an unidentifiable id still reporting itself. The single-call assertion on the unmatched path fails on quattro, where the count is two, and the generated-entry assertion fails there too.

./test/shell — 217 of 221 files pass, 2898 assertions; the four failures (config-test, runtime-smoke-test, snapper-test, unowned-system-paths-test) fail identically on unmodified quattro on this machine.

This comes out of https://github.com/VykosMolt/omarchy-desktop, where I have been running the Quattro shell as a plain Arch session and fixing what turned up.