Add appimagecraft config

[TheAssassin]

This PR adds an appimagecraft build config. appimagecraft is an easy-to-use build script generator that allows building AppImages using short declarative configuration files. It can be used by users to build AppImages with relative ease, but you could also add it to your release cycle.

In my fork I added a GitHub actions configuration to automatically build AppImages for every commit, creating a so-called continuous release using pyuploadtool. The AppImages are built on Ubuntu 20.04 (which provides a suitable Qt release out of the box), meaning that the AppImage works on most newer distros (tested Ubuntu 22.04 and Fedora 36). In the long term, compatibility may be increased by building the AppImage on an older distro with some custom Qt build following AppImage's best practices. (Side note: the AppImages built in my repository already support AppImageUpdate.)

In case you're interested, I can send a follow-up PR once this one has been merged. I highly encourage you to test the AppImages provided in the continuous release.

References: #350, #20.

P.S.: the appimagecraft config rewrites the desktop file to give the resulting AppImage a sensible file name and make it easily accessible in the user's app launcher (when using some desktop integration tool like, e.g., AppImageLauncher). Can be removed if you don't like it, but it seemed like a good idea to me.

[TheAssassin]

If you want to test this, just get the branch, download appimagecraft and call it to build an AppImage. See https://github.com/TheAssassin/rpi-imager/blob/qml/.github/workflows/main.yml#L25-L27. Note: it took me a little to figure out which QML modules I needed to install from Ubuntu using trial and error.

[tdewey-rpi]

Closing this as stale. There are a few additional items to consider:

1. In this repo we're only including build and packaging infrastructure that we intend to maintain - and I cannot claim to use AppImages on a regular basis.
2. There's nothing to stop you maintaining a decoration-fork if you want to keep packaging this way - I'd note that's likely how Choco, homebrew, etc operate. For the sake of your users, though, I'd encourage you to keep changes to the core program to a minimum, and note that if a user flags that they have installed through this mechanism and we believe the installation mechanism is the root of their issue, I'm likely to close the issue.

[TheAssassin]

AppImage is an easy-to-use upstream packaging format. If you don't want to maintain it, I won't either. It makes little to no sense. The maintenance effort is rather low, so I was hoping you'd consider it, maybe as an alternative or replacement to existing packaging.

[TheAssassin]

P.S.: This still seems to work fine, I just built a working AppImage. It could easily be integrated into CI. I could add that if you'd merge that then.

[tdewey-rpi]

Looks like this PR is pulling a Lazarus.

As I've said in numerous issues and PRs across this project - I'm open to changing my mind if new data comes in. In this case, AppImages have become the front-runner for Imager 2.0, pending some more internal reviews.

[TheAssassin]

Please don't hesitate to reach out if you need assistance with this.

[tdewey-rpi]

Finally getting around to this - I'm going to make AppImages the primary distribution format for Linux targets with 1.9 in order to include a more recent version of Qt than is shipping in Bookworm.

Raspberry Pi OS will get a convenience deb meta-package that will put the AppImage and launcher files into appropriate places, but otherwise it'll be the Same Thing (tm).

One thing that's not immediately clear to me is how to support aarch64 native-building using AppImageCraft - it looks like I might need to give you a PR for another target?

[TheAssassin]

appimagecraft currently does not have a use case and thus lacks support for 64-bit ARM. Some of the tools in the linuxdeploy environment do not support it either due to various reasons. It's on the roadmap.

[tdewey-rpi]

I believe I've been able to generate the AArch64 build I was looking for - but only with some fairly ugly hacking around in linuxdeploy-plugin-qt: https://github.com/linuxdeploy/linuxdeploy-plugin-qt/compare/master...tdewey-rpi:linuxdeploy-plugin-qt:master

And a small series of expansions of appimagecraft's permitted architecture list.

There are two major issues I can see with the packaging:

1. Rendering speeds feel a little slower than before - this might be a missing platform plugin
2. WRONG: OS customisation is completely broken - this might be an issue with the QSettings class expectations.

Edit: Turns out I'd destroyed my OS customisation settings - OS customisation is apparently working as expected.

[tdewey-rpi]

Confirmed the changes to linuxdeploy-plugin-qt now package the Wayland client support, and this materially improves UI fluidity on Raspberry Pi 5.

While there is further fettling that could be done to reduce the image size (I'm looking at you, imageformats), the size is comparable to the Windows and macOS distributions, and I consider this an acceptable state for release.

@TheAssassin Would you like a PR against your upstreams?

[TheAssassin]

Sure. But I wonder whether you can push to this branch already.

[tdewey-rpi]

For the record - I'm not going to update this PR - instead I'm going to merge v1.9.0 once we've fixed up the Windows Qt6 build.

As such, I'm closing this, but I'm incorporating your change (and some minor edits) into the next release.