I’d like to propose a reworked approach to the kde-neon extension and KDE Frameworks and Qt content snaps, namely:
- Decouple the current content snap to being a Qt content snap and KDE Frameworks content snap
- Building the libraries from source instead of the neon apt repos (I believe KDE follows this approach with their Flatpak runtimes)
- Include QGtkStyle as part of the extension to improve theming on GNOME/GTK desktops
- Support the full range of architectures Qt and KDE can be built for
Architecture:
Rationale:
Build from source:
- Quicker migration to new bases without needing to wait for Neon to use a new LTS
- More control by being able to experimentally patch libraries if changes are needed to work within the snap sandbox, which can then be upstreamed to either Qt or KDE depending on the library
- Ability to patch/rebuild previous content snap releases with security fixes which is tough to do with the current moving target of Neons repo
Decoupling Qt and KDE:
- Qt could release a new major version but it takes time for KDE Frameworks to migrate to this new version, which limits other apps using Qt being unable to use the newer version. This has been the case with Qt6 and while KDE will soon complete the transition to Frameworks/Plasma 6 it does highlight it being an issue in the future with a possible Qt7.
Improved theming on GNOME:
- Currently snaps built with the kde-neon extension look good on KDE but there can be problems on GNOME when the platformtheme is changed to gtk.
Support more architectures:
- At present only amd64 and arm64 can be built using the extension, which isn’t ideal if a developer/packager wants to target ppc64el or armhf and in the future riscv. Launchpad would be used for builds making use of snapcraft remote build
I have used this approach with some of the snaps I maintain and have found it to work quite well. Essentially I ended up emulating the gnome-sdk and content snaps (https://github.com/ubuntu/gnome-sdk ) the result of my efforts, which should be able to be repurposed for the extenson can be found here:
- https://github.com/Nightmayr-snaps/nightmayr-qt-sdk
- https://github.com/Nightmayr-snaps/nightmayr-qtwebengine.git
- https://github.com/Nightmayr-snaps/plasma-integration
The Qt SDK snap has the part logic in branches that are have -sdk at the end of the name, the content snap is derived from the SDK snap by staging the SDK snap and removing things like header files, pkgconfig, cmake etc. The Qt components are built from upstream Qt but this can and likely will need to be changed to KDE’s Qt forks to pull in patches.
The qtwebengine snap is only really built to be staged back into the qt snap as it takes ages to build and causes problems timing out launchpad jobs. It does require building the Qt SDK snap initially without webengine and then building webengine with the SDK snap and finally staging webengine back into the Qt SDK snap to have a complete Qt SDK in one snap.
The plasma-integration snap contains Plasma Integration and only the dependencies it requires but this would obviously be expanded to include all KDE frameworks and renamed to reflect that. This snap also uses the qt-sdk snap to build the parts.
Hopefully I’ve made a convincing case for improving the kde-neon extension and content snap, I’m keen to see what others think of this proposal 
.
Thanks,
Umayr
