It would be nice if the MSIX packages from the nightly builder can be installed without affecting other builds.

Package Identity

Name

A different package identity (name) is needed to allow multiple installs to coexist. We can use 49800KritaProject.Krita.Next and 49800KritaProject.Krita.Plus.

Display Name

Should contain the commit hash and Jenkins build number.

Version Number

Windows does not allow "reinstalling" a package with the same version number but different content. To make version numbers unique, we can use the Jenkins build number (available as environment variable %BUILD_NUMBER%) as the 4th part. (TODO: what happens when we move to GitLab CI?)

Signing

We can probably set the "publisher" attribute to match the KDE code signing certificate, but getting the right value isn't exactly straightforward. This is what Craft does: https://invent.kde.org/packaging/craft/-/blob/master/bin/Packager/AppxPackager.py

There are reports that, when the certificate changes it will also change the package identity, which makes it impossible to do a direct update without first uninstalling the old package: https://github.com/microsoft/msix-packaging/issues/365

Settings Location

I recently figured that we can use SHGetKnownFolderPath with KF_FLAG_FORCE_APP_DATA_REDIRECTION to get the private app data storage locations (not the redirected AppData), i.e. C:\Users\USER\AppData\Local\Packages\49800KritaProject.Krita.xxx_xxxxxx\LocalState and C:\Users\USER\AppData\Local\Packages\49800KritaProject.Krita.xxx_xxxxxx\RoamingState, so we can have real per-application settings storage instead of the redirected AppData amalgamation that Desktop Bridge forces upon us. If we use these private locations, then the nightly MSIX packages can run without affecting the settings and resources of other installs.

• The safest way to achieve this would be to patch Qt to override QStandardPaths. We can perhaps add a custom function to QWindowsWindowFunctions for toggling this behaviour, so that the Microsoft Store stable release can continue to use the old redirected AppData pattern.
  • That is, unless we actually want to change the Microsoft Store release to do the same also. This may be a good idea in the long run, but implementing migration of existing settings and resources correctly is going to be tricky...
• Alternatively, we can change our usages of QStandardPaths to use our custom functions instead. But this may not work fully as some dependencies and KDE frameworks may also rely on QStandardPaths (needs verification).