Drop orphan .desktop entries when their backing command is gone

[stefanomainardi]

Summary

Fixes #5933. omarchy-refresh-applications now reconciles top-level applications/*.desktop entries instead of just copying them, and omarchy-pkg-remove triggers a reconcile after pacman -Rns so orphan launcher entries disappear immediately on uninstall.

Symptom

Reproduction from the issue:

1. Omarchy ships with typora in install/omarchy-base.packages (preinstalled).
2. User: Remove → Package → typora. omarchy-pkg-remove runs pacman -Rns typora.
3. ~/.local/share/applications/typora.desktop stays — pacman didn't put it there, omarchy did via omarchy-refresh-applications.
4. Walker still lists "Typora". Clicking it shows App failure: Command not found: "typora".

Same shape affects every preinstalled package that omarchy ships a .desktop override for. Today that's just typora in the visible set, but the bug class is general.

Fix

1. bin/omarchy-refresh-applications — reconcile instead of copy

Before:

cp ~/.local/share/omarchy/applications/*.desktop ~/.local/share/applications/

After:

for src in ~/.local/share/omarchy/applications/*.desktop; do
  dest=~/.local/share/applications/$(basename "$src")
  cmd=$(sed -n 's/^Exec=\([^ ]*\).*/\1/p' "$src" | head -1)
  if [[ -n $cmd ]] && command -v "$cmd" &>/dev/null; then
    cp "$src" "$dest"
  else
    rm -f "$dest"
  fi
done

For each shipped entry, look at the Exec= command:

• present on PATH → copy the entry (current behaviour)
• not present → remove any stale copy at the destination

The same symmetric cleanup is added to the existing alacritty conditional, which had the same latent issue.

applications/hidden/*.desktop is intentionally untouched — those are NoDisplay overrides that should ship regardless of whether the upstream command is currently installed (they exist to suppress generic vendor entries, not advertise installed apps).

2. bin/omarchy-pkg-remove — trigger the reconcile

echo "$pkg_names" | tr '\n' ' ' | xargs sudo pacman -Rns --noconfirm
+ omarchy-refresh-applications
  omarchy-show-done

Without this, the fix only kicks in on the next omarchy update or manual refresh. With this, removing typora from the Remove menu immediately drops the orphan and walker reflects the change after its own refresh.

Why generic rather than typora-specific

Hardcoding typora would be a smaller diff but would leave the same trap for the next preinstalled-then-removed app (any future addition to applications/*.desktop of an optional preinstall would hit the identical bug). The Exec= introspection is 5 lines and uses primitives already present in the codebase (sed, command -v, the basename + cp/rm pattern). It also matches the spirit of the existing omarchy-cmd-present alacritty conditional — generalising it rather than adding a new special case for each app.

Master backport

Both files are identical between master and dev (verified with git diff origin/master:bin/omarchy-{refresh-applications,pkg-remove} origin/dev:...). Happy to open a parallel PR if you want it backported.

Test plan

• bash -n clean on both modified scripts
• Dry-run the Exec= extraction against the current applications/*.desktop set (foot, imv, mpv, typora) — sed correctly pulls out the bare command in each case, and command -v resolves the ones present on PATH
• Inspected the existing alacritty pattern, which also lacks cleanup; same fix applied there for consistency
• No machine here with the exact "typora was preinstalled, user removed it via the Remove menu" state to live-verify, but the reproduction is the linear path described in Typora still being visible in the application launcher after uninstallation. #5933. If a reviewer can confirm on a fresh stock install that does have typora, that closes the loop.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.