Create the Windows launcher entry only once the VM is running

[Chessing234]

Fixes #7943.

install_windows wrote ~/.local/share/applications/windows-vm.desktop at the top of the function — before the RAM, CPU, disk, username and password prompts, and about 120 lines before the final confirmation. The launcher uses that file as its installed-state marker, so from that moment the menu shows Launch Windows and Remove Windows and hides Install Windows.

Every exit after that point leaves it behind:

• answering No at "Proceed with this configuration?" (exit 1);
• Ctrl+C, via the INT trap installed at the top of the function;
• docker-compose up -d failing, which also exit 1s.

In each case no compose file, container, image or ~/Windows exists, but the menu insists a VM does — and offers no way to install one.

The entry now lives in create_launcher_entry, called after docker-compose reports the VM started. Nothing before that claims an install exists. mkdir -p "$HOME/.local/share/applications" moved with it, since that directory is only needed to write the entry.

Evidence

New test/shell.d/windows-vm-launcher-test.sh:

• the call to create_launcher_entry comes after both the gum confirm and the docker-compose up -d success check;
• windows-vm.desktop is written in exactly one place — a range check over the function, so re-adding an early tee fails even if the ordering assertions still pass;
• create_launcher_entry is evaluated on its own and asserted to produce an entry with a usable Name= and Exec=.

Against the current script the test fails with windows vm install still has the landmarks this test relies on, so it is genuinely pinned to the new structure.

bin-style-test passes.

What I could not run

The install flow can't execute here: check_prerequisites requires /dev/kvm, and the prompts are gum, so the ordering is asserted against the source rather than by cancelling a real run. Someone on Linux answering No at the confirmation and checking that Install > Windows is still offered would confirm the user-visible half.

I did not touch remove_windows. It still runs a bare rm on the marker, which now has one more way to be absent — but that path is only reachable from a menu entry that requires the marker, so I left it rather than widen the diff.

This was AI-assisted.

[Copilot]

Pull request overview

Moves Windows launcher creation until after successful VM startup, preventing cancelled or failed installs from appearing installed.

Changes:

• Extracts launcher creation into create_launcher_entry.
• Calls it only after docker-compose up -d succeeds.
• Adds regression coverage for ordering and launcher contents.

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.

File	Description
bin/omarchy-windows-vm	Defers launcher creation until VM startup succeeds.
test/shell.d/windows-vm-launcher-test.sh	Verifies creation ordering, uniqueness, and launcher contents.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Chessing234]

rebased onto quattro; launcher still only written after the vm actually starts

[Chessing234]

folded into #12264 for easier review.