We received some informal reports in the Microsoft Store reviews telling us that GIMP updates were deleting user data! In particular, plug-ins, themes, brushes, user settings and other add-ons were not being kept during an update from the store.

To resolve this, the updated version of GIMP from the Microsoft Store will require Windows 11 or at least Windows Server 2022 (Windows NT Build 10.0.20348.0).

Windows 10 is still supported, but only when GIMP is installed from our .exe installer.

Note that we are no longer able to support versions of Windows older than Windows 10, and can no longer support 32-bit systems running Windows.

Installing the update will prevent future data loss during upgrades.

Technical details¶

This was being caused by the way MSIX (the format of apps distributed on Microsoft Store, GIMP included) is designed, which prefers sandboxed user data (like Flatpak and Snap). We have been trying to work with this requirement when running from MSIX, but were not successful.

So, to fix this packaging limitation, we were given the special “restricted capability” unvirtualizedResources (specifically virtualization:ExcludedDirectory), to preserve user data on %AppData%\GIMP, just as the .exe installer does. This is similar to what we do on other sandbox distributions such as Flatpak and Snap.

After the update, GIMP user data will be copied on upgrades.

The update does not affect images or other resources stored outside your GIMP folder.

How to migrate the previous user data¶

This restricted capability is only available on Windows NT Build 10.0.20348.0 and later. So, users with older Windows versions will need to use the .exe installer.

Note: the binaries inside the .exe installer and the .msix are exactly the same.

For users who were using the MS Store version until now and are switching to the .exe installer, here are instructions in order not to lose your configuration data from the MS Store version:

1. Manually locate your config dir at %LOCALAPPDATA%\Packages\ (you may just copy-paste this string into the Windows Explorer).
2. Search a folder starting with GIMP (with random numbers and letters after that) at this location.
3. From there, navigating down to LocalCache\Roaming\ where you will find a folder named GIMP.
4. Copy this GIMP folder into %APPDATA% (again, just copy-paste %APPDATA% into the Windows Explorer to find the correct location).
   Note that maybe the folder %APPDATA%\GIMP\ already exists, in particular if you also used the .exe installer at some point. If so, it is up to you to decide whether you want to override the data already present with the ones from the MS Store GIMP.

This procedure is a one-time thing as a workaround to this exceptional issue. You won’t have to do it again in the future!

Earlier in April and May, we were working behind the scenes on improving our CI and build-related code. In this context, one thing that came up was: how easy it is to test a merge request on Linux? For example, on Windows, we have .zip files for each commit; on macOS, we have .app (inside .dmg). For Linux… well we had none (we have weekly flatpak builds but they are time consuming for testing purposes). So, after a brief consideration we decided to go with AppImages.

AppImage is a application package format, basically a bundle, that’s great for the development and testing workflow described above. To be clear, ⚠️ we’re not distributing AppImage as official packages yet ⚠️ (more about this later in this post). About the experiments…

Picking the “right” tool¶

AppImage doesn’t have a mandatory SDK. The creation process can be done using freely available tools, such as linuxdeployqt, appimage-builder and AppImageKit. But we decided to go with go-appimage, which is multi purpose and ours is to do a quick test build.

In our case, the tool is responsible for bundling almost every dependency and for squashing everything with proper ELF data to be executable in one click. But the tool, naturally, can’t guess the particularities of the different software (e.g. use of script interpreters), so we need to copy and set some things manually. By the way, we opened issues in the go-appimage repo in the hope of improving some things, one little example of FOSS collaboration.

Learning from past appimages¶

Of course, we didn’t start from scratch! We learned from other unofficial GIMP AppImage builds (a list of which can be found here). Maybe there are others, but we could only find these four.

We also contacted the developers of these unofficial builds for testing and feedback about a potential official appimage. Huge thanks to them! Also, other people contributed too (this info can be found in the merge request). Thanks to all people involved! 😄

Patching Wilber’s wisdom into appimage¶

We couldn’t simply take these unofficial appimages code and put it in our repo because this isn’t how software works. Our code, even the packaging code, preexists the new packaging (in this case, bundling) so the former needs to be considered in order to the proper adaptations be made into the later.

Considering our past packaging code and experiences, we defined some principles to be checked before approving a new package format. In short, the format needs to:

1. Have its scripts inside GIMP repo and using GIMP/GNOME runners for better transparency (macOS is the exception right now for historical reasons, which should ideally be fixed in the future);
2. Have its scripts building/packaging over official GIMP git source/binaries for better security;
3. Have its scripts simplified and human-readable as much as possible for better maintenance.

The last point assumes that some person is maintaining the package, and this is the main reason our appimage (bundle) is not ready for distribution yet. No person volunteered to tackle this responsibility by following these principles. So, the best that we could do, staying compliant with the principles, was a testing bundle.

Actual use and future¶

Our appimage can be used, and it’s indeed being used right now to triage issues and test merge requests on the Debian version supported by the respective branch (on master branch it is Debian 12 currently), and that has been very handy. Let us explain:

Suppose that you don’t have a very powerful machine, which is very common. Normally, you will only build GIMP natively and contribute to this specific platform, since building inside a VM is quite clumbersome. But thanks to our testing AppImage:

• a Windows user can just log into the VM, download the Debian artifact from the MR and test it. We have contributors that use Windows VM (and they can download the cross .zip artifact), now the inverse is possible;
• And this is useful for issues too: triaging them recommends the latest master so constant local rebuilding. Fortunately, this isn’t needed since our CI auto generates an .appimage for every new commit.

Of course, this is a limited use case and makes our appimage unsuitable even for being linked in the dev version download page. Not every contributor uses Debian (12) nor does every Windows or Mac contributor have a Debian (12) VM. To be fair, if the appimage displays problems that we can’t fix, it can even be dropped at any time.

So, we welcome contributions to improve compatibility with other distros (at least the oldest supported Ubuntu and newest Fedora) in order to raise it to a package level. If you are interested, talk to us.