 Hello and welcome. Good morning, good afternoon, good night. I'm Albert and I'm going to talk about Flatpak, FlatHub and KD. So, let's start quickly. What's Flatpak? Flatpak.org says, Flatpak is the future of apps on Linux, which is all nice but doesn't really mean anything. The next sentence is, Flatpak is a next-generation technology for building and distribution desktop apps on Linux. That says a bit more. It says it's for desktop apps, it's for building and distributing them. They also have this nice kid band with boxes, so that's good for them. The building part, forever in KDE we've been used to basically build a tarball, throw it over the fence and then somebody, mainly Linux distributions would build it, send it to users. That doesn't exist anymore. In Flatpak, the Flatpak author is responsible for building everything the application needs and then basically giving it to the user. We're cutting the middleman here. So, that's a bit annoying because if you have to build everything, you would have to build Zlib. So, we don't want to do that. So, there's something called runtimes in Flatpak that are kind of things you can base your app on. So, for KDE, we have the KDE runtime that basically builds all of the KDE frameworks and almost all of Qt. I think the only thing not included is WebEngine and then your app doesn't really have to build the 20 frameworks it depends on. Then the next app has to do the same, which is always, I would think, less things build, the better. So, as I said, in KDE we have the platform and the SDK. So, there's the runtime and the SDK. The runtime is the thing you run. You use to run the application. The SDK is the thing you use to compile the application. It's an event in that URL listed down there. So, the main thing your app needs to be built on Flatpak is a manifest. So, in a manifest you say, hello, I'm Causium. I'm going to be using the KDE platform runtime and the KDE SDK to build. I'm going to be using the version 5.14. That's the versioning we decided for the KDE runtime. It's basically the tight to the Qt version it uses. So, every time we update the Qt version, we give it a new name. Then we get the command, which is like the binary it has to run when running Causium. So, it's the user, the thing in user bin, it's the thing to run. And then you say, please build me with CMake and with Ninja, which is a bit faster. In an archive, please build me from this URL. There's a few things more that didn't fit into the slide. There's a few hashes to make sure the archive is fine. And there's some other flags you have to give to Flatpak to make sure that acceleration and whatnot are available. But that's the main thing, right? You give it a URL to build from and it builds. Done. Well, not really, right? This is very easy for Causium because it doesn't really have any dependency outside the KDE frameworks, but most of our applications actually do have dependencies, right? So, something that has quite some dependencies like ocular ends up with a file that is 350 lines long, something like contact, which doesn't really have that many outside dependencies, but it has to build all of KDPM, right? KDPM is very separated in different libraries that contact them all, right? So, it ends up being 1200 lines, which is a lot, right? So, once you've written your manifest, you want to build it, install it and run it, right? As a developer. So, for that, you use Flatpak Builder. If you just give it a build there and the manifest file, it will build it. But that's not so useful, right? So, you want to install it as a user so it doesn't bug you for the root password. And then once you have installed it as a user, you can just run it, right? And that's good. And you can actually test it works. But as I said, this is for developers, right? For users, we don't want them to have to build everything because this is supposed to be the future of applications in Linux, right? So, building is not the future. So, for that, we have the distribution side, right? This concept of a remote, a remote is just a URL with lots of applications in it or with one, right? It doesn't matter, right? It's a URL which will have one or more applications. For example, if we list the remotes on my computer, there's five of them, right? There's FlatHab, there's GNOME, there's KDApps, there's GNOMENightly, and then there's a remote for the consume we just built, right? Okay. So, here, we introduce the other thing I wanted to talk in this talk, which is FlatHab. So, what is FlatHab? FlatHab.org says it's the home of hundreds of apps which can be easily installed on any Linux distribution. Okay. So, it's really nothing special, right? It's just another FlatPak remote. Yeah, but not just another FlatPak remote, right? The thing with FlatHab is that it's enabled by default in FlatPak. So, every single FlatPak installation has FlatHab enabled. So, when you do FlatPak search, it will search in there, right? So, we want to be in FlatHab because otherwise, well, it's harder to find when you're not on the default find list. So, yeah, FlatHab and KD, right? We have all those apps in FlatHab. There's quite a few. There's simple ones, like a few games. There's complex ones, like Dehecan and GCompre, Ocular. It's kind of complicated. Krita is also there. So, yeah. The code for these apps lives in GitHub. Everything from FlatHab is in GitHub. So, it's githab.com slash FlatHab slash the manifest name, right? So, or.kd.ocular, for example. We have a team in Invent. We used to discuss things. You're welcome to join there. So, some stats. As you can see, the numbers are not very big, right? The most installed one is GCompre with 35,000 updates since the last, sorry, 35,000 downloads since the last update. It's not a lot, but it's not too bad either. There's some apps that are almost not installed. They're very niche and development apps. So, that's also understandable. So, there's still lots of things to do for FlatHab and KD, right? We have around 50 applications now. But if you go to KD.org applications, there's 200 applications, right? So, we're missing 150 applications. Also, some of the applications like Contact, Need Some Love, like Contact, as I mentioned, is a big manifest, right? It's 1200 lines. We're stuck at 19 or further. So, yeah, help more than welcome to make it more modern. So, for the apps that are missing, we can reuse the manifest files that are in Invent FlatHab KD applications. Those are some applications that mostly a ledge built, and other people, but mostly a ledge, those built from Git every night using the binary factory and end up in this remote, right? So, this is something that we don't really want to give to users, because it's a nightly, right? It's good for testing, but it's not really something we want to give to users as a stable thing. So, yeah, as I said, join the team. Now, some technical stuff. FlatHab uses OS3. OS3 is Git for binaries. It has atomic updates and deduplications. So, even if you build Web Engine twice, it's fine. It just uses the space once. Our runtime is built on top of the free desktop SDK, which is a confusing name, but it doesn't really have any relation with free desktop at all. And the main issue with FlatHab is it's containerized, which is good, but then sometimes it's not so good because we've been writing apps for 20 years, expecting to be able to access everything, and now you can't, and that has some issues, right? So, the main help needed is there. So, I'm running out of time, so I just want to remember there's a buff on Monday the 7th in Room 1 at 16 UTC, building your first flatback. It's organized by Jan, but I'm going to be there, I guess, Valesh will also be there. So, any question you have, ask it there. Thank you.