To us about why and how to use KDE frameworks in non-KDE apps. Take a look. All right.
Hello, I'm Javier. And one second, let me push this mic a little bit better over here.
Testing, testing, mic check.
All right. Right, so I'm going to be giving this presentation,
Why and How to Use KDE Frameworks in Non-KDE Apps.
Who's this for? Well, this is for the canonicus Linux programator futurum,
or the Linux developer of the future, and for the peritus fanaticus codex elite,
that professional in the lookout for cool libraries.
By the end of this talk, you'll have learned how about KDE frameworks the KDE community has to offer.
You'll be able to use KDE frameworks in your own projects and you'll have some
guidance on how to make apps that you can distribute using these frameworks.
Who am I? I'm a software engineer at KDAB. My name is Javier.
I have background in computer science and mass media communications and I develop
an application called QPrompt.
It's a teleprompter app used in mass media communications and it's made using
Kirigami and other KDE frameworks.
So, about the frameworks. These are a collection of libraries and add-ons that
you can essentially use them to program with Qt and make your experience better, add more features.
They're made primarily to satisfy the needs of the KDE community,
but you're welcome and free to use them.
Let's see these frameworks in action first, but let's see them in action in
applications that are not KDE's.
Here we have one that needs no introduction. This is Qt Creator and it's using K syntax highlighting
for its syntax highlighting this
one is subsurface it's a
application that linux linux storables created it has a mobile user interface
that works on kirigami works on ios and android and it has a desktop user interface
that one is made with cute widgets It's they share a common backend.
This is QPrompt, my application. I'm using Kirigami, K-Crash,
K-Icon themes, and Breeze icons.
My goal with choosing Kirigami was to make a native Linux app.
This is Comics Reader, a random app I found on GitHub, and it's also using Kirigami.
And this is Astra, developed by my colleague Joshua.
He chose Kirigami because he felt like it was... I forgot the exact words on Riff, I'm sorry.
It essentially helps him do with QML the things that you can't do with QML alone.
I'm sorry, that was very butchered, but anyways.
And he's also using KConfig and KArchive. KConfig is essentially a library that
will allow you to have settings in a structured manner.
So it's like QSettings, but on steroids.
And the KArchive allows compressing and decompressing files.
Here we have, this is how the KDE community organizes the frameworks.
They're divided into tiers. The first tier are applications that are libraries
that don't have many dependencies.
You simply can start using them in most cases.
In some cases, there will be dependencies, but those will be third-party dependencies,
and they're not that many.
Tier 2 are KDE libraries that depend on Tier 1 libraries.
And tier 3 have more complex dependencies, sometimes depending on tier 1 and
tier 2, and also external libraries at times.
Tier 4, according to the documentation, can be safely ignored by application
developers. So I'm going to do just that.
Now, if you ask me, I will say that in practice, there's also a tier 0.
And that tier contains this build framework called extracemic modules,
which every single KDE framework depends on.
Only for building, not for runtime.
But extracemic modules is something that you need to embrace if you're going
to be using KDE libraries.
And there's a few small libraries here and there that will also belong to this
tier. and they're not big enough to be considered an actual framework or they're
not listed on the frameworks list that you will access with this link.
This is what that page looks like. This is the actual page.
And as you can see, they're all divided into tiers.
And it tells you the operating system that is supported by each of the libraries.
This is QPrompt. Here I have a little video comparing the use of Kirigami.
To the left is the desktop interface.
To the right we have the mobile version. It's the same, but some layout changes
happen automatically. That's all thanks to Kirigami.
Over here we have Sonnet. Now I'm just showing a random KDE frameworks that I find cool.
This one is for spell checking.
KNotifications, you can use it for creating pop-up notifications.
Solid will give you information about the hardware that your system is running.
And KUser feedback can be used to create, to collect telemetry in a way that is trustworthy.
For other KDE frameworks, please check out the website and check out how they're
employed, how they're used in KDE gear.
Okay, so let's talk about pros and cons.
The pros of KDE frameworks are that they expand Qt functionality.
They give you support for multiple platforms.
Nevertheless, iOS support is very limited, and the WebAssembly support is practically
non-existent, unfortunately.
But it's still possible to deploy to these platforms if you put in the effort.
The frameworks are well-documented, implemented and they have open governance,
which means that one can help steer the future of these frameworks if one is
willing to participate in the community.
The only con in my eyes with KDE frameworks is that tight integration with the
KDE infrastructure can make it inconvenient for using non-KDE apps.
Another pro is that it's free software and open source.
But in the eyes of some people, strong copyleft licenses require consideration.
So, let's talk about licenses. The frameworks are licensed under LGPL, BSD, or MIT licenses.
KDE apps use the GPL.
About those licenses, the LGPL is probably the one that is of most concern to
those people for whom it requires consideration.
Consideration and to address those concerns I want to talk briefly about the
four freedoms and the findings I've had from reading the license.
I'm not a lawyer, that's a disclaimer, but if we look at the freedoms there's
two things that stand out to me in freedoms three and four.
Or the freedom to redistribute copies so you can help others,
and the freedom to distribute copies of modified versions so you can give the
whole community a chance to benefit from your changes.
If you keep this mindset of this is so you can help others and allow others
to benefit when making use of the library.
You'll essentially have a good time making use of the library itself.
These are some general findings and some common misconceptions.
The most notable one is that under the LGPL, non-GPL family programs can be
distributed under any terms if they are not derivative works.
For a program to not be considered derivative, certain requirements must be
met, and for those, please read the license.
The more relevant section for an application developer who will make use of
LGPL libraries is this section, section 4 on combined works.
What's in bold is a summary, and out of that summary, that's a summary of the
requirements that you must meet.
Of course, you must comply with the entire license, but this is the section
that's most relevant for application developers.
And the easiest way to compile is to use this one that I marked in the section
D says, do one of the following.
And option number one is use a suitable shared library mechanism for linking with the library.
This is the easiest one, the easiest approach in my opinion.
It's the default when creating applications with CMake and the default that
KDE uses themselves as well.
So I highly advise going that route.
Now, how do we make use of these frameworks? works. Well, let's prepare our
development environment.
There are four options when it comes to that we can take if we want to create
a development environment that we can also reuse as a distribution environment.
Libraries, the way that they're installed for development is closely tied to
how the package gets distributed later on.
So what I've done is,
here we have the four approaches that are probably the easiest or that can be
used for both things at the same time,
both developing and distributing.
So first approach is to build ourselves. We build each of the dependencies and
that sounds like a lot of work, requires the most mastery.
But it covers the most platforms. If you want to deploy on a platform like iOS,
you will probably need to do this.
We can use our Linux, FreeBSD, Haiku OS distributions packages.
That is, in my opinion, one of the most user-friendly approaches towards developers
making use of the libraries.
We could also use KDE Builder or KDE Source Build. this is the way if you're
going to develop a KDE app for KDE.
I personally have found it unsuitable for third-party because of the integration
with CI but honestly I didn't go very deep into it so there's a good chance
that I might have missed something.
Please give it a try and especially go this
route if you're going to make a KDE app and then there's
craft this is another tooling that is developed by KDE for the purposes of the
developing the packages creating the packages that get distributed on windows
mac os freebsd the linux app images and the android packages as well,
Pros about using Craft. It's a robust packaging system written in Python and
it's honestly far easier than packaging the apps yourself.
The cons is that it constantly keeps changing and it's a little hard to keep up.
Old versions of KDE frameworks are removed
as new versions are added and that might
make it so that your application if you suddenly
cannot build it with the framework that you used originally if you're just going
to fix the bug on it you will need to update to the latest framework and sometimes
that's not an option so unless you're going to follow KDE's release cycle I
think it's probably better to go a different route.
I have had a good experience with Craft, minus the not being able to build stuff
at times, but yes it's an excellent tool.
The Android build scripts however are tied to the CI and that makes it impossible
to use for third-party stuff.
The other option, distribution packages, is actually very easy to get started.
All you need to do is install the libraries, the frameworks,
with their respective "-dev-" or "-devel-" suffixes.
Devel is for RPM, dev is for Debian, and yeah, it's very easy to make these
packages. I will show a little bit about that later on.
And the only con is that some distributions versions update these packages sporadically.
Ubuntu 24.04, for example, shifts with version 5.115 of KDE frameworks,
and that version is already duplicated.
So if you're going to be using this in a developer environment,
I suggest going with KDE Neon.
And when you're targeting for distribution, I suggest choosing the oldest,
still active, version of Debian.
I haven't talked about universal packages. I didn't put them on this section.
And the reason for that is universal packages, they can't really be used for
both purposes, development and distribution.
Essentially, you do your development and then you use this pipeline for distributing
the universal packages.
Still thought it was worth to mention. it because KDE provides these runtimes
that you can use for flat packs and snaps,
and all you need to do is to include those in your YAML files and configuration files,
and you'll essentially use a part of that CI infrastructure to create packages
that satisfy the framework requirements.
So now about building everything yourself. The advantages are that you can develop
at your own pace and you can target architectures that are not currently supported
by KDE, such as RISC-V and ARM64 bits on Windows.
And you can distribute on platforms that are currently limited,
such as Android and WebAssembly.
The disadvantage is that for each platform, you have to build all the libraries
manually, install them, and then create the packages and installers for each of those platforms,
which can be a lot of work, but there's a script for that, at least the first two parts here.
All right, so now let's talk about CMake. I bet most people here are familiar
with this, but this is a build system for C++ code.
It's what's used for Qt. It's what's used by KDE.
It's been used by KDE for a long time, and it's excellent.
There's this feature, the generators, that is essentially what CMake outputs.
It outputs project files that can be used by compilers in different environments
to create your application.
And there are defaults for each system that we can use.
So relying on the defaults, here is... We'll go back into CMake a little bit
later. This is actually CMake code, but here is how we use CMake to make use of KDE frameworks.
This part in particular is no different for a third-party app than it will be for a KDE application.
We essentially find the package
for extra CMake modules and then we find
each of the add-ons that we want
and then we create
we do the linking to those to the
different modules that were found in these packages so essentially find packages
searches a file and I'll show which one that's later and once the packages have
been found you can link your binaries to them in this step using this.
So, although other packaging methods for locating libraries exist in CMake,
I recommend FindPackage because it's what KDE themselves is using.
And all the libraries depend on extra CMake modules if you're going to compile them.
So, at the very least, extra CMake modules need to be installed.
And if you're able to to install extra-semic modules, then you should be able
to install all other libraries.
Due to sometimes there being hard-coded paths in the CMake files of KDE frameworks,
these might not compile if you attempt to add them using add subdirectory.
And if you use external project add, this might not work for CI environments
such as the one for flatpaks.
So just stick to find package and you'll be fine.
Okay, so I've said, I said extra CMake modules a bunch of times in the last slide.
These are a set of build script for CMake that Katie is using.
Okay, and they is building.
This is what's actually extra CMake modules. It's just those folders and they
contain a bunch of modules.
You could actually load those files directly in CMake and you wouldn't even
need to use the find but use the find because that you'll need them for the dependencies okay.
Again this is CMake I think I repeated
the slide okay so these are some commodities that you get at from ECM.
I'll skip those for now.
Now let's build the packages.
Okay. In order to build the KDE frameworks on any operating system,
you'll need to get a script language of your choice.
I'm using bash here and a Python.
On Mac, you'll need to run this command. On Ubuntu, you'll need these dependencies.
And the script begins, create a build folder, set these configuration types.
This is what can be built. We want a debug and a release at the very least.
And this is what will be built. These are all variables.
And we have this CMake prefix path.
This is a very important path because this is the path that gets searched by
this find instruction, this find package over here.
So with those variables all set, we have the install prefix path,
which is where once you install, you go to install the framework,
where will this get stored?
I'm just storing it on the same folder as the prefix, and then everything will
be in there all pretty together.
But you can do it wherever you want.
So now we have all of those variables set.
Let's call CMake. You call CMake, pass the variables, you will also need for
a third-party app development, you will also need to set build testing to off and build QCH to off.
And with all the variables set, go ahead and tell it to build the build directory.
And it will build from the source code in the current directory.
And that's essentially it runs CMake, which gets everything ready.
And once everything is ready, the next command, cmake build,
that one will do all of the building using the generator that was used in the
previous step, which in this case is just the default for every system.
And once the build completes, run cmake install, point it to the build directory,
and it will install your KDE framework to the install prefix.
So this is how I'm doing it in my application QPrompt.
I download every dependency to a sub-module using getSubModuleAdd.
You can add them from either invent.kde.org directly or from GitHub.
Then I go and check the operating system, and depending on the operating system
and its architecture, I set a series of values like the compiler and the platform.
Then I update the submodules.
For Python, I did mention Python was required. This is, you'll need to install things and reuse.
These are the commands to automatically install those things and load the local
installation folder that we create here for a virtual environment in Python.
And I did mention that some KDE frameworks have dependencies.
Unfortunately, if we're taking this approach of building everything ourselves,
that means we also need to build those dependencies.
And those are not KDE dependencies, which I have streamlined here.
Each one of those can be something completely different. So,
I tried to find a common denominator between all of them, and I found that VCPKG
can satisfy most of KDE's third-party dependencies.
So, what I do is I take VCPKG installable dependencies in classic mode,
which puts them all in a central folder,
and then I take that folder and copy it over to the install prefix.
Why not use vcpkg for installing KDE frameworks?
Well, there's no one actively maintaining the KDE packages on vcpkg,
but if that were maintained, you could use vcpkg for everything.
So I add vcpkg as a submodule, same as all the other packages,
and then initialize it with this command. It will generate a JSON like this one.
Then automatically build and then we continue with the build script.
This is the build script that I was showing earlier.
It continues here. This is the vcpkg section, where essentially I run the bootstrap,
which sets up vcpkg and installs all of the dependencies that I have listed in a folder.
No, I just list them right here. And package name goes here,
put all the names of the packages there, and it will get installed.
Those get copied in this step.
All right. And now with all of the third-party dependencies taken care of,
we can automatically go through each of the tiers in KDE frameworks.
This is a list of paths in Bash.
And we do a for loop and go through all of those lists.
And out of there
i essentially do the same thing
that i showed you earlier run cmake to
generate all of the run the cmake command on on those each of those frameworks
then we build them and we install them and then we do the same thing one more
time for our own application we don't necessarily install it in this case but we do it and we're done.
So that's for building. Then we have a dev environment just a launch configure
Qt Creator to use the prefix and you'll be able to access all of your KDE frameworks
from there and develop very comfortably.
When we go towards making the applications the distributable installers,
we can use CPAC, which is a part of CMake.
For using CPAC, what we need to do is enter the build directory and then run the CPAC command.
Of course, we need to set up a few things before that in the CMake itself.
These are just screenshots from QPrompt.
Here I have the instructions for the Debian package. You can use that as is, it works.
Works. These are for... this is more of the Debian and the RPM.
The RPM isn't fully working, so don't copy that.
These are for Windows. These aren't tested yet, it's still in development.
And these are for iOS and Android.
These are mostly working. I've yet to do the signing part which I'll talk about in a moment.
And this is for FreeBSD.
So, the thing I just said, I'll talk in a moment, is this.
When you package the application, it may not contain all the libraries within it.
And that's because, well, you just packaged your application,
not necessarily the libraries.
And these are dynamically linked, not statically linked.
So, what we want to do is use some tooling like WinDeployQt,
MacDeployQt to, in the cases of those platforms that need it,
we collect all of our libraries and have them in a search central folder before we run CPEC.
In the case of Windows, we also want this command that says install required
system libraries. We want to set this to on.
And yeah if it's a
windows an app image a mac
or android you want to include all the libraries and if
it's a wm package an rpm a snapback a haiku
os flatpak all of those you do not
want to include the packages that's also true for freebsd and
last but not least some platforms will
require you to sign these packages and this
is a bit annoying because you don't only need to sign your program you also
need to sign KDE libraries themselves so yeah you'll sign both the binary and
the package in the case of distributing on the Microsoft Store you'll just need to do the Microsoft,
here are some additional resources that I recommend for learning about CMake
The first three are playlists in YouTube, and they are amazing.
Thank you very much for your time.
Any questions?
Hello. Is it okay?
So I have been using KDE frameworks so far in my application,
and I feel like one of the most problem for me is that it couples very tightly with K initialization,
but I use another framework for translations.
Is there any way around that?
So you're talking about KI-18, the translations framework?
I don't use K. Right. I don't use that. Yeah, I use Fluent. Right.
My personal advice is to avoid it if possible.
If another dependency requires it, then use it in that case.
But in in your personal application i will
try to avoid it simply because um it's one of those that requires third-party
dependencies and the technique that i showed you to satisfy those dependencies
will work um but you also need to copy one file and it's an additional step
that i have in my MyScript, the one, the actual app.
But the thing is, most of the value that a K internationalization provides is for the KDE community.
And if one is outside, working from the outside, unless you intend,
like I do in my case, to to distribute that application eventually as a KDE app,
then you'll probably have a better time working with Qt's own internationalization
API, which didn't exist, and that's why K-internationalization was created,
but now we have one, so I will use that instead.
Okay, we have time for just one more question.
You mentioned early on that one of the cons of KDE frameworks is the tight integration
with the KDE infrastructure.
The KDE what? The tight integration of KDE frameworks with the KDE infrastructure for third parties.
Then you mentioned issues with craft specifically, but do you have any other
examples or the extent of it?
I mean, in my personal experience, the main issue has been that since the libraries
are deprecated, I mean, yeah, they're removed from one being able to build them with craft.
I'm essentially forced to update constantly to the more recent version.
Besides that, the other issues I've had have been honestly small,
and I've been able to reach out to the team, and they've addressed them all.
So that's the only notable one.