Files
craft-launcher/apps
Jeremy 67aefb33c0 Install new Windows apps for everyone in Program Files\ArtCraft, and show that folder as the default (#972)
* fix(installer): install new Windows apps for everyone, in Program Files\ArtCraft\<App>

A fresh MSI install now asks Windows Installer for the machine-wide context
(ALLUSERS=1) instead of taking the package's own default, which for a
dual-scope package is per-user (%LOCALAPPDATA%). Updates are unchanged: they
keep the context of the copy they replace. README row restored to Program Files.

* fix(ui): show the real default install folder, not just "System default"

The install-folder fields (the per-app Install dialog and Settings'
Default install folder) now show the folder a fresh install really
uses: Program Files\ArtCraft for a Windows MSI (machine-wide, from
the ALLUSERS=1 scope), the launcher's own apps folder for a portable
ZIP, /Applications on macOS. The host answers through the new
Host::default_install_folder, computed by native install::default_folder;
where no single default exists (web build, Linux system packages,
FreeBSD) the field keeps saying "System default". The same value is
the start folder of Browse, so it no longer starts at a literal
"System default" string.

* fix(review): the default folder follows the package and the installer

CodeRabbit review of #972: the Windows default now follows the selected
package's architecture (an x86 MSI picked because a release ships no
x64 one installs under Program Files (x86)), and answers nothing when
the architecture is unknown, so the field says "System default"
rather than guessing. The macOS default comes from the installer's own
applications_dir, so a machine where /Applications is not writable
shows ~/Applications. Browse now starts at the nearest folder that
exists, so a default created only by the first install
(Program Files\ArtCraft) no longer falls back to the picker's
unrelated start location. The desktop host memoises its answer because
the macOS path probes the disk and the fields redraw often.

* fix(review): keep the Linux and macOS builds of default_folder warning-free

The ubuntu Clippy gate caught what the dev machine cannot check (ring
needs a Linux C compiler): the Arch import is Windows-only, the macOS
arm consumes its unused parameters, and the Linux test calls the
three-argument signature.

* fix(ci): import Arch on every target, default_folder's signature uses it everywhere

0f5bd68 gated the import to Windows but the signature names Arch on all
targets, so the Linux clippy job failed with E0425.

* fix(review): the folder hint matches the real install and touches nothing

CodeRabbit review of #972.

- The install dialog's default follows the package the backend will really
  install: the preferred formats first, then every other format this
  platform installs, as choose_kinds does. A Portable ZIP preference with a
  release that ships only an MSI now shows Program Files, not the apps
  folder. The choice lives in the new install_target module.
- Settings covers every app, so it shows a folder only when every app that
  can be installed shares one; a 32-bit-only app beside a 64-bit one leaves
  it at "System default" instead of using the launcher's architecture.
- The macOS hint no longer borrows the installer's probe, which wrote a
  fixed-name file in /Applications (following a planted link) and created
  ~/Applications when it fell back. Both now use write_probe (fresh name,
  create_new), and only the installer creates ~/Applications.
- The desktop host caches each question, since Settings now asks per app.
2026-10-28 21:50:54 -04:00
..