The Qt helpers have been marked as deprecated for a long time now. Unfortunately, there’s no alternative for classic snaps or any desktop app that needs to support platforms other than amd64. With the growing popularity of arm64, and with Qt 6 now well and truly the current major release to target for current apps, this fairly glaring hole is getting increasingly problematic.
This has again come up in the CMake project, where we are revisiting what Qt version we base our release packages on. Right now, the CMake snap is unable to move to Qt 6 because of the above-mentioned problem. With no real solution in sight, there’s a very real risk that we won’t be able to provide newer CMake releases as snaps due to being unable to build the CMake GUI. If we get to that point, there’s very little motivation for me to continue maintaining the CMake snap, so I’d probably pull it from the snap store. With about 45k active installs and steady growth, that’s a lot of unhappy users if things come to that.
I’ve pinged @kenvandine about this… While we have the kde maintained kde-framework extension I think it is not suitable for a lot of qt apps and that we really need a fully-supported native-qt-without-kde extension.
Perhaps we could create a qt-6-2204 build and content snaps, similar to gnome-42-2204, and a snapcraft extension that makes those easily consumed by app developers. The question is could future kde content snaps utilize qt from another content snap. This would ease packaging of non-kde Qt apps while minimizing duplication of effort in maintaining Qt in multiple content snaps. @jriddell any thoughts on this from a KDE perspective?
Qt 6 snap would be good. Qt is very ABI sensitive so any new bugfix release will need a new Snap made. One quetion is where to get the Qt builds from, you could build it as part of the Snap but Qt is massive and takes an age to build. You could get it from the Ubuntu archives but then it’s probably an old version. You can get it from KDE neon which is what we do now with the kde-framework content snap but the issue there is it’s a moving target so that limits minor fixes being done when KDE neon has moved on to a new version.
I’m happy enough to have a Qt snap and a KDE frameworks snap that uses the Qt snap (or just has another copy of Qt).
We don’t yet have a fully built Qt 6 in KDE neon and my priority is Jammy/22.04 packages there which I don’t think Snaps use yet.
Putting the desktop setup scripts, the common plugs (e.g. icons), and the usual layouts etc. into a new, shared extension
Agreeing on a common fs layout so that the setup scripts can work with different content snaps.
Creating Qt-specific extensions that mostly only add the plug(s) for the content snap and set up the build environment. E.g. kde-neon or qt-6-2204.
If possible, developing the content snaps (Canonical & KDE Neon) in a shared repo to encourage knowledge-sharing
I’m just brainstorming here, but I think having a Qt or even just desktop-specific extension that isn’t coupled to a specific content snap would already be very helpful for many use cases.
I agree that the current extension for Qt apps is not ideal. I’ve got a bunch of Qt SDK snaps (repo) that may be able to provide a head start for a revised Qt extension? They contain Qt built from source with Webengine being built in a separate snap that gets staged into the SDK snap if available (this is done due to Webengine taking ages to build). I took my inspiration for the repo from the GNOME-SDK repo, where the repo gets mirrored to launchpad and a recipe exists for each branch. Build times for the different architectures are roughly: amd64 = 1 hour, ppc64el = 1 hour, arm64 = 3hours 43 mins, armhf = 3 hours 42 mins.
I wonder if it would be possible for a Qt snap to serve as the base layer containing just the Qt libs, with KDE libs and plasma-integration being in their own snap which would be fetched if the detected desktop environment is KDE. If the detected desktop is GNOME then a snap with QGnomePlatform is fetched instead. Is it possible to chain content snaps together in this way and conditionally fetch based on DE?
GNOME apps can run in a KDE desktop session, and vice versa. You would not be able to fetch conditionally based on the desktop environment. I don’t think you could/should conditionally fetch anything. I think those decisions would need to be made when installing a snap.
I’d be in favour of separating out the purely Qt parts to a separate snap, with KDE things using that as a dependency. That would benefit the wider Qt app community, but I’m not seeing anyone stepping up to actually do that work. And given the scope for a Qt snap that other apps pull in being relatively attractive to supply chain attacks, there would need to be a pretty well-respected entity responsible for publishing it.
Would we have a generic extension for setting up layouts, command-chain and such + two extensions that merely plug in the correct content snap (one for KDE Neon, one for Qt straight from the repos)?
