The pre-signing check matched any folder named Program Files, so it rejected
a valid MSI when Windows resolves Program Files elsewhere, accepted the 64-bit
root for an x86 package and accepted a different app name. Build the expected
folder from the package architecture's resolved root and the policy name.
Real msiexec runs (per-user and all-users, silent and wizard) found two defects
that the metadata fixtures cannot see:
- "Only for me" published ALLUSERS=2, so FindRelatedProducts treated the run as
per-machine and skipped the existing per-user copy. An interactive upgrade
left two registered products and uninstall left files behind. The page now
leaves ALLUSERS unset for a per-user choice.
- Windows Installer resolves Program Files once, for the context it started in,
so choosing "Everyone" in the wizard installed into the user profile with a
machine-wide registration. The wizard now sets the new-install folder itself
after the choice (Program Files, Program Files (x86) for 32-bit, or the
per-user Programs folder). Silent installs are unchanged.
check-install-policy.ps1 now fails if either regresses.
The package is dual-scope, so the separate -windows-user MSI was the same package under a
second name. Build and policy-check the single plain-named MSI before signing, which is the
name every sibling app, the launcher and the shared windows-arm64 workflow use. Replace the
loop test with one that checks the MSI is policy-checked once, before it is signed.
Build wordcraft.wxs a second time as a dual-purpose package
(Scope=perUserOrMachine: ALLUSERS=2, MSIINSTALLPERUSER=1), shipped as
wordcraft-<ver>-windows-user-<arch>.msi. Registry keys move from HKLM to
HKMU so the same components land in HKLM per-machine and HKCU per-user.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Packaging: pin the Windows signing client and check its hash
* Packaging: pin appimagetool and check its hash
* Packaging: pin the AppImage runtime and stop clearly when an architecture has no pinned tool
* Packaging: empty hashes are quoted
* Open Word documents with WordCraft from the system (#295)
Register WordCraft for Word, RTF and ODT files on Windows and Linux without
taking over anyone's defaults, and add File > Options > General > "Make
WordCraft the default for Word documents..." where the system allows it.
- Windows MSI: a ProgId per type (.docx .docm .dotx .dotm .doc .dot .rtf
.odt, plus .md and .txt as Open With candidates only) with the app icon
and `"wordcraft.exe" "%1"`, OpenWithProgids, Applications\wordcraft.exe
SupportedTypes, and Capabilities + RegisteredApplications so WordCraft
shows in Settings > Default apps. New component with its own GUID.
- Linux: the desktop entry declares the macro-enabled, template and legacy
Word types and text/rtf; AppStream lists the media types. deb, rpm,
AppImage and both Flatpak manifests use this same file.
- macOS: Info.plist also lists legacy .doc.
- The Options button runs `ui.makeDefaultApp` through a new
Services::make_default_app hook: Windows opens
ms-settings:defaultapps on WordCraft's page; Linux and BSD run
`xdg-mime default ai.storyteller.wordcraft.desktop <types>` (refused
inside Flatpak or without an installed desktop entry); macOS shows the
Finder Get Info hint; the web shows nothing. The status bar reports the
outcome. Strings translated in every catalog.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Review fixes for #304: keep Make default out of programmatic dispatch
ui.makeDefaultApp is refused when run programmatically (control channel, MCP, macros,
scripts); only a click on File > Options > General > Make WordCraft the default… reaches
the host's hook, so no agent can change the user's system default apps or open system
settings. Test: programmatic_calls_cannot_change_the_default_apps.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Default-app strings in the newer catalogs; the button's test looks for a General-pane label
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
The MSI had no UI, so Windows Installer showed only its basic progress box and closed
without saying the install had worked. It now uses WiX's standard WixUI_Minimal dialogs:
a welcome page with the license (MIT or Apache-2.0, built at packaging time from
LICENSE-MIT and LICENSE-APACHE), progress, and a finish page with an optional
"Launch WordCraft" checkbox. The release and Windows ARM64 workflows install the WiX
UI and Util extensions the build now needs. UpgradeCode and component GUIDs are unchanged.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
wordcraft.wxs shipped with DesignCraft's UpgradeCode and app component
GUID. Windows Installer treats packages that share an UpgradeCode as one
product, so with DesignCraft 0.2.1 installed the WordCraft 0.1.0 MSI was a
"downgrade" and refused to install ("A newer version of WordCraft is
already installed"), and installing DesignCraft after WordCraft would have
removed WordCraft.
Give WordCraft fresh GUIDs, drop the header comment copied from PhotoCraft,
and make packaging-lint fail if the .wxs reuses a sibling Craft app's
UpgradeCode/component GUID or repeats a GUID.
Fixes#4.
Claude-Session: https://claude.ai/code/session_019FczntrDNYd6DupyBdpbL5
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Jeremy