v0.9.1

[0.9.1] - 2026-07-14

Fixed

• Reinstalling after a non-purge uninstall now repopulates the app menu instead of opening to an empty first-run screen. A non-purge uninstall removes the app .desktop entries but keeps the config, so a reinstall was detected as an "already current" migration and only re-applied the guest fixes — it never re-ran discovery, leaving the menu empty until the GUI self-healed. The migrate path now detects an empty app menu on the "already current" branch and queues discovery (the same mechanism a cross-version upgrade uses), so the apps come back automatically on the next launch.

• A non-purge uninstall.sh no longer deletes the Windows VM disk (#716, thanks @munir-abbasi — data-loss report). The default VM storage lives under the app-data dir (~/.local/share/winpodx/storage/data.img), and the "remove app definitions" step did a plain rm -rf ~/.local/share/winpodx — so a non-purge uninstall (documented as keeping the VM data), especially via the package-manager postrm re-entry where it runs unattended, recursively wiped the Windows VM out from under storage/. Uninstall now canonicalizes both paths and, when the storage dir is DATA_DIR itself or nested beneath it and --purge was not given, preserves the storage subtree and removes only the other app-data entries. It also reads the real storage_path from winpodx.toml (a relocated --storage-dir disk is protected at its actual location, not just the default), requires an absolute path, and always keeps a top-level storage entry. A custom WINPODX_STORAGE_PATH outside the app-data dir is untouched as before, and --purge still wipes everything. Regression-tested via the uninstall smoke harness (nested-storage, external-storage, and purge cases).

• uninstall.sh --purge now actually purges on a package-managed install (#716 audit). It used to print "Mode: FULL PURGE" and then exec the package manager, replacing the process so none of its own purge steps ran — the container, volumes, storage/data.img, and the config holding your RDP password all survived while the banner claimed a full wipe. --purge now runs every user-side purge step first and removes the package last (apt remove → purge so dpkg drops conffiles too); non-purge still hands off as before.

• Package removal (deb/rpm/AUR) now actually cleans up (#716 audit). Every post-remove hook delegated to helper scripts under /usr/share/winpodx/ that the package manager had already deleted, so apt/dnf/pacman removal left the container, VM disk, config, desktop entries, autostart, and tray listener behind. Cleanup moved to the pre-remove stage (Debian prerm + a staged copy for the purge wipe, RPM %preun gated on erase, pacman pre_remove); an in-place package upgrade never touches user data or the VM. Per-user cleanup now runs with a scrubbed environment (no root XDG_*/D-Bus leak).

• install.sh upgrades are now atomic and honest about failures (#716 audit). An upgrade builds the new tree + venv at a staging path and swaps it in only after the build succeeds, so a mid-install failure no longer leaves you with nothing (and the rollback message reflects the real state instead of always claiming "not touched"). It also honors XDG_CONFIG_HOME, backs up (never deletes) a pre-existing pip/pipx winpodx entry point before symlinking, and reports a failed winpodx setup instead of printing the success banner unconditionally.

Added

• Launching a Linux app directly from its "Linux Apps" shortcut on Windows now runs it (#616, thanks @notnotno). The reverse-open shims placed under Windows' Start Menu / Desktop "Linux Apps" folder are primarily "Open with…" chooser entries, but clicking one directly (with no file) used to do nothing — the guest shim silently exited because it required a file argument. It now emits a launch-only request (origin: "launch", empty path) and the host runs the Linux app with no file (the %f/%u placeholder is stripped rather than filled), so the shortcuts double as plain app launchers. Requires the updated guest shim (re-provisions on the next winpodx guest sync / apply-fixes).

Fixed

• The GUI's libxcb-cursor0 dependency is now auto-installed on a minimal desktop (#712, thanks @numericOverflow). Qt 6.5+ (PySide6) refuses to start its xcb platform plugin without libxcb-cursor.so.0 — "could not load the Qt platform plugin 'xcb'" — and it isn't pulled in transitively on a fresh minimal install (e.g. Linux Mint 22). install.sh now installs it (distro-mapped: libxcb-cursor0 on Debian/Ubuntu/openSUSE, xcb-util-cursor on Fedora/Arch) when the GUI is enabled and the runtime lib isn't already present. Presence is detected by probing the real .so on disk across the standard lib dirs rather than ldconfig -p — on openSUSE the library lives in /usr/lib64 but is absent from the ld.so cache, so an ldconfig probe re-prompted every run even with the package installed.

Contributors

Thanks to everyone who reported issues or contributed to this release: @notnotno (#616), @numericOverflow (#712), and @munir-abbasi (#716 — the data-loss report).