This week I took part on the KDE Onboarding Sprint 2019 (part of what's been known as Nuremberg Megasprint (i.e. KDEConnect+KWin+Onboarding) in, you guessed it, Nuremberg.
The goal of the sprint was "how do we make it easier for people to start contributing". We mostly focused on the "start contributing *code*" side, though we briefly touched artists and translators too.
This is *my* summary, a more official one will appear somewhere else, so don't get annoyed at me if the blog is a bit opinionated (though i'll try it not to)
The main issues we've identified when trying to contribute to KDE software is:
* Getting dependencies is [sometimes] hard
* Actually running the software is [sometimes] hard
Dependencies are hard
Say you want to build dolphin from the git master branch. For that (at the time of writing) you need KDE Frameworks 5.57, this means that if you run the latest Ubuntu or the latest OpenSUSE you can't build it because they ship older versions.
Our current answer for that is kdesrc-build but it's not the most easy to use script, and sometimes you may end up building QtWebEngine or QtWebKit, which as a newbie is something you most likely don't want to do.
Running is hard
Running the software you have just built (once you've passed the dependencies problem) is not trivial either.
Most of our software can't be run uninstalled (KDE Frameworks are a notable exception here, but newbies rarely start developing KDE Frameworks).
This means that you may try to run make install, which if you didn't pass -DCMAKE_INSTALL_PREFIX pointing somewhere in your home you'll probably have to run make install as root since it defaults to /usr/local (this will be fixed in next extra-cmake-modules release to point to a somewhat better prefix) that isn't that useful either since none of your software is looking for stuff in /usr/local. Newbies may be tempted to use -DCMAKE_INSTALL_PREFIX=/usr but that's *VERY* dangerous since it can easily mess up your own system.
For applications, our typical answer is use -DCMAKE_INSTALL_PREFIX=/home/something/else at cmake stage, run make install and then set the environment variables to pick up things from /home/something/else, a newbie will say "which variables" at this stage probably (and not newbies too, I don't think i remember them all). To help with that we generate a prefix.sh in the build dir and after the next extra-cmake-release we will tell the users that they need to run it for things to work.
But still that's quite convoluted and I know from experience answering people in IRC that lots of people get stuck there. It's also very IDE unfriendly since IDEs don't usually have the "install" concept, it's run & build for them.
Solutions
We ended up focusing on two possible solutions:
* Conan: Conan "the C/C++ Package Manager for Developers" (or so they say) is something like pip in the python world but for C/C++. The idea is that by using Conan to get the dependencies we will solve most of the problems in that area. Whether it can help or not with the running side is still unclear, but some of our people involved in the Conan effort think they may either be able to come up with a solution or get the Conan devs to help us with it. Note Conan is not my speciality by far, so this may not be totally correct.
* Flatpak: Flatpak is "a next-generation technology for building and distributing desktop applications on Linux" (or so they say). The benefits of using flatpak are multiple, but focusing on onboarding are. "Getting dependencies is solved", dependencies are either part of the flatpatk SDK and you have them or the flatpak manifest for the application says how to get and build them and that will automagically work for you as it works for everyone else using the same manifest. "Running is solved" because when you build a flatpak it gets built into a self contained artifact so running it is just running it, no installing or environment variable fiddling is needed. We also have [preliminary] support in KDevelop (or you can use Gnome Builder if you want a more flatpak-centric experience for now). The main problem we have with flatpak at this point is that most of our apps are not totally flatpak-ready (e.g. Okular can't print). But that's something we need to fix anyway so it shouldn't be counted as a problem (IMHO).
Summary
*Personally* i think Flatpak is the way to go here, but that means that collectively we need to say "Let's do it", it's something we all have to take into account and thus we have to streamline the manifest handling/updating, focus on fixing the Flatpak related issues that our software may have, etc.
Thanks
I would like to thank SUSE for hosting us in their offices and the KDE e.V. for sponsoring my attendance to the sprint, please donate to KDE if you think the work done at sprints is important.
4 comments:
Like you said, I'm afraid that until we collectively say "Let's do it" we won't see any major progress or contribution from other people in the Flatpak adoption. There is lot of work which cannot be done in just few people (like it was until now, me working on the portals in Plasma and Qt, Aleix pushing the KDE runtime and Discover and you pushing the apps on Flathub). Also many apps need to be properly tested and changes need to be made to make them fully work in Flatpak without any limitations. All the work is totally worth it, there is a huge potential in Flatpak and it will make life much easier for new contributors, especially if we have better integration in KDevelop. Have you seen gnome-builder in action? From what I remember, you pick an app, it already provides Flatpak manifest and you can do all the changes you want and simply build it and test it, without messing with your system or thinking about dependencies.
Flatpak for development really only works if you have a simple app like Okular or Dolphin. It becomes annoying when the Flatpak'ed app bundles additional dependencies, because once you touch one of the dependencies, Flatpak will rebuild everything - using Flatpak for KDE PIM development for instance is not doable at all, since if you touch e.g. KIMAP library just to fix a small bug, you would have to wait for ages for Flatpak to recompile everything that's listed below KIMAP in the manifest file (which is a *lot* of things :-)). Same would likely go for Plasma (if that can even be Flatpak'ed).
For PIM we have a dedicated Docker image, which contains the latest Frameworks (from Neon nightly), pre-configured kdesrc-build, ccache, the environment variables are all set up, it even has KDevelop and QtCreator installed inside and there are some additional shell scripts (build.sh, run.sh) to make it easy-to-use even for people without any Docker knowledge. If you need newer Frameworks you just rebuild the image. I find that more flexible than Flatpak for development, since it's basically the same as developing on your system, but everything is sandboxed inside the container - although I have to admit I doubt that you could print from Okular inside the container either :)
Usually if people are fixing applications, the app is listed at the end of the manifest (after the dependencies), which means only the app needs to be rebuild. But you are right that if you end up fixing issues deep down in the dependency chain, you can end up building everything over and over, which is not a good experience either.
@Dan yes i know for PIM you have a docker image, talk to Volker he was there on the sprint and he agreed that isn't the solution.
Also, no idea why you say Okular is simple, you have to build gs to make it work ;)
As far as I understand there's flatpak ways of not having to rebuild everything all the time.
@Jan yes, i've tried Gnome Builder, it's easier to use, problem is, it's also a bit more useless since it only works as "flatpak builder", not as a regular IDE like KDevelop.
Post a Comment