To introduce Carl Schwan. He's going to be talking to us about the KDE apps initiative.
CARL SCHWANNENBACHER- OK, yeah. Well, actually, I won't talk exactly about KDE
apps initiative because there's no goal, which does almost the same thing.
So there's no point to have an initiative and a goal at the same time.
But I will still talk about the app ecosystem, the KDE app ecosystem,
and what we can do to make data, to improve it, and the current state of it.
Oh, no, it's like the sun is split up.
Okay, so a bit about me. I've been contributing for a long time. I started in 2018.
I've evolved in many, many apps.
I love apps. So like, for example, NeoChat, Tokodon, Macro, Caligra,
Contrast, Coco, and a lot, lot more.
I mean, this is mostly like a lot evolved, and there's also a lot of applications
where I'm a bit less involved, but still involved.
And maintaining key gaming add-ons, and a lot of our part of the infrastructure
for the AppleApps.key.org to do a bit of promotion for apps.
Yeah. Yeah, so let's talk a bit about what is an application ecosystem.
I try to find some definition on the internet, but there is not one definition.
There is multiple keywords, which might be interesting to talk about.
It's inspired by natural ecosystem, like with multiple actors,
and which are a bit of a relationship between each of us.
And I think that's, yeah. And there's a bit of scalability, You cannot go alone,
you need many actors in the system to grow and to, um,
uh, uh, the ability, which is as a related, like alone, you cannot create an
application ecosystem.
You need many people, many different companies, uh, just hobbies.
It needs to be like many different things. things, and this also ensures that
the system is resilient.
And there's also collaborations.
You are working on the same goal together.
But there is a bit of competition, which is also good.
It's a healthy balance between collaboration and competition.
You might have some multiple music applications, which all try to reach a different niche.
And they might reuse a lot of codes.
And also iterability, integration with APIs.
It's also something that we have a lot in KDE. For example, if you use Caligra,
you will be able to read your document files as in Okula because Caligra provides Okula generators.
And we have a lot of that in KDE with Kapparts.
And that's a good thing, I think, that each application extends each of us.
Yeah, so my goals were to close the feature gap between proprietary application ecosystems.
With that, I mean Windows, macOS, iOS, Android,
they have a lot of applications, which covers many, many use cases.
And if you want to get more users for BASMA and Linux in general,
we need to close these gaps so that users can do the same thing that they did
with some property systems and do that with a liberal open-source system we
think is to close these gaps we need to increase the number of applications,
designed for plasma and plasma mobile and this is not something we can do with
the current number of contributors so we need to as well get more contributors.
And, yeah, and, and as well, like increase the number of users in other platforms,
because that's why it's cool, but we need to ensure, but as we're working on
Gnome on Windows and macOS,
Android, and I saw some people talking about iOS in the last few days, so yeah.
And this also leads to increase adoption of Qt and KDE frameworks,
which is super important for us like the more users of the frameworks we have
the better it will become,
yeah and but we don't only need to create new applications we have a lot of
applications already and a lot of these applications um.
Um i mean we have a lot of applications which are maintained well maintained
but we as well have some applications which didn't receive
any updates in a long time uh like some
example like calica which i just tried to revive recently but
carwave i mean we have a lot of or a
lot of educational applications for example which might need
a small push um yeah and
the good thing is like every time we have a new application or
we improve application to other new things we also improve
our frameworks like i see that with for example add-ons like every time i create
new applications or try to get involved in the new applications um it leads
to a lot of improvements to kia add-ons which is a good thing and these improvements
as a benefit also of our applications,
applications, which is good. And then basically the end goal is to see the core
of the KDE project as both in terms of applications, but as well as the community.
Yeah. Let's look a bit at the current state. We have over 200 first-party applications. Yeah.
And we have 60 frameworks, over 60 frameworks.
With KF5, we had like over 80s, and had to revisit a bit the numbers.
We get rid of a few of them, which is good because these were like all frameworks,
which are not really maintained like HTML, like you know, you choose GitHub engine.
And we have a really good set of adoption of KF6 and KDE, KDE 6 and KDE 6 in KDE.
We see like a few applications using KDE 5, five, but we managed in a really
short time to migrate most of them to 3DS6, which is good.
Yeah. But there is a bit of a negative thing, is that we only have very little
third-party applications.
I mean, we managed to convert every third-party application through first-party
applications, which is in some way good.
But we don't, outside of the KDE bubble, like the inner KDE bubbles,
we don't see a lot of third-party applications.
I mean, there is a few of them. We had that at a previous presentation.
I learned a few new names, which is good.
But even third-party applications are often maintained by KDE people.
I mean, for work, I also have maintained two third-party CAD applications and, yeah.
And the maintenance level of each of our, even of first-party applications,
it really depends on the application.
Like for example, games, well games, games are mostly done, which is good.
So they don't need a lot of maintenance. But there's like, for example,
education applications.
Some of them might need a bit more maintenance.
Yeah, and why I'm talking about that is I did this sort of graph to analyze with the KDE community.
And we can see that we had a peak around 2012, 2014. 14 and then it go a bit
down, go a bit up, but it's mostly stagnant.
Um, like, and this is like the number of authors, contributors.
Um, I also have the same thing with the number of commits, which is maybe not
the best metrics, but still it's quite telling.
It's mostly flat and we want to have a bit of core.
I mean, it's still improved a bit, like, it's last few years we had a bit of
more improvement, which is good.
Yeah, let's talk a bit about what we have. Currently, there's always this debate
about widgets and QdQuick.
I think both have their place. Like, if you had talked with me like two years
ago, I would have said let's port everything to QML.
Meanwhile, I discovered QdWidgets because I use that for work and yeah,
it's actually not that bad, Qt Widgets.
There is a few things I think it's easier to do with Qt Quick and a few things
I think is easier to do with Qt Widgets.
We will live with both of them for a long time.
We have a desktop bridge, a Quick Controls style bridge which fix most of the
styling issues choose between the two worlds.
But I still think Qt Quick is vital if you want to do mobile applications for Plasma Mobile.
And yeah, but I mean, the thing is often like Kigami is more mobile-centric,
and Qt Widget is more desktop-centric, and we need to try to bridge that.
And I tried to do that with Kigami Addons. I already added a lot of features
for doing more desktop applications,
like a comment bar where you can find all the actions available,
shortcut editor, and stuff like that, which are quite vital for desktop applications,
for getting really productive within applications.
And as well, I could do a lot of more stuff for mobile, like form cards,
who have a layout for it, which work for mobile with good enough touch surface.
Yeah, we have a quite good CI CD in Caddy.
It's super easy to get our applications deployed for other platforms,
mostly thanks to the people like Volker, Ben, and Ovas, and Anna, and Julius too.
It's really good. Like you can see, you can deploy for AppImage,
macOS, Windows, Flatpak.
It's quite good. We have one issue is that for continuous integrations,
we do have a lot of platforms.
For delivery, we are a bit less good.
We produce packages, but we don't expose them to the users.
We only have a few applications in the Windows Store.
Event Talk, we have a lot of applications which compile, so Windows.
And there's a last step which we need to finish so that our applications are deployed.
Like on Flatpak. For Flatpak, every time we get an update,
a few days later, one week later, we get all these updates to the users.
And for other platforms like Windows, I had to take a look at the NeoShad version,
but I think it's a bit outdated already in the Windows Store.
And we need to make that a bit easier.
Yeah, release tooling. I've been pushing a lot to move more applications to
the release service, which is a really great thing for us to be able to release
all of our applications all the time.
Because we had a lot of issues with some applications that were not released for years.
And ensuring that we get to release regularly with some bug fixes,
some translation updates is good.
And we need to do that more. There are some talks about modifications of the
release cycles uh there's a buffer of that uh soon and yeah we are get we already
got the automatic updates and we need to do that with more platforms i think
android as well have that.
And not just Natalie Wills. Yes, translation toolings, it's still based on SVN.
And it's mainly based on Contribution Overflow. But for applications,
we want applications to be translated in many languages.
And we might want to think about how to make it easier to get more contributors in these areas.
I tried some prototype. I mean, basically two ways to work with.
Either we try to migrate completely to something new, like WebLates,
or we try to build something which works with the current way.
We are doing it, at least some prototypes with some web front-end for SVN.
And yeah, it's some ideas that we might want to explore more.
Yeah, user documentation. I don't know if you look at your user documentation
for applications. applications, it's not that good. It's often really updated.
The tooling for that is based on XML, which is not the best format if you want to get contributors to.
And we also have some wikis which store a bit of information,
which was basically used as a way to to do that in the wikis,
and now we have a documentation split between two platforms.
And the website for documentation is slightly a bit outdated.
I mean, you can see the Caddy 4 logo there.
Yeah, something to improve if you want to get really good applications,
We also need sometimes to have at least a bit of documentation,
maybe not complete manual like we used to do that, but at least a bit of documentation.
Yeah, developer tooling. What is the set?
Like we have a lot of developer tools in KDE, which might be explained by the
fact that we are a lot of developers there.
I mean like, for example, like Kate, KDEvelop, from IDE or text editors,
Clazy to do static analysis,
KDE source build to build all the software we want, Craft to deploy the software on many platforms.
Ibtrack to do some memory usage analysis.
F-Inspector to analyze the binary size of executables.
Commit to do some git management.
Compare to compare to display divs.
CodeVis, to do architectural analysis of the whole software.
You can see all the components.
It's super fancy. It's quite new.
CarbTemplate, to create a new application. It's like a small workflow.
You want to start a new application, or you start it, you open CarbTemplate,
and just take the template, and done.
You have a basic structure of it.
RCPT Inspector, if you want your application to be accessible,
So it's good to have some tooling there, too.
And whether it's not KDE from the KDE itself, but still bit KDE related,
GameAway and Hotspot, which were developed by KDE developers,
and are also open source.
And I mean, speaking of Kerab templates, the first thing that changed is that
it's now using Kigami, which is good.
It was completely ported to Kigami. And I started to add more examples.
So if you want to do multimedia management applications, basically you have
a template for that, which gives you all the basic structure to do that.
If you want to do a video games launcher, where you can see all your video games
and you click on it and then it launches. It's nice.
And maybe like Swift, for example, like Apple developed a lot of Swift playgrounds,
which is basically sort of mixed between IDE and,
IDE and live preview with a lot of tutorials or to interactively create an application
and learn to program with that technology.
And maybe something we should be inspired by that.
I mean, there's a Gnome Workbench, which is a Gnome equivalent for that.
And I try to do, like, as a smart prototype. Like, you see, can we do that?
Can we do, like, some live previews? You can just edit your QML code,
and then you see the results and then provide some examples.
Samples, basic components of the interactive HFS.
One issue is that the text editor is QML, which is not so good.
So maybe it's a good idea to try to use a text editor for that instead of doing
that in QML and just use QML for live view.
Some ideas. Just try to explore some ideas where we could go,
try to make it easier for people to get started with this technology.
Yeah um like c++ i love c++ but not everyone does that and there's some inspiration about bindings,
um there was a talk about joshua yesterday i was
a host which i missed because i was in the other but there is also Darshan Paldesay
who is working on some 6xQt binding space for the KDE frameworks, which is cool.
And for Phyton, there is also talk from Christian yesterday about what they
are doing in Qt. and we have a G-SARC project which is ending now,
I think today is the last day,
for doing the same thing, I mean, parasite-based bindings for the KDE framework,
so we can also have that as an option.
And there's maybe like other languages to consider. I mean, I think the Qt people
are looking at C Sharp, maybe Swift, since Swift also has a good,
Good story about C++ integrations.
And yeah, things that we need to explore to see how people could build a new KDE application with.
And we also need to do a bit more KDE developer outreach.
Like we recently launched a KDE for developers web page, which is really cool.
Thanks for everyone in the pro team for helping with that. And yeah,
I mean, a set of marketing sites, I mean, there's a developerkit.org website,
which is like, there's also a bit of promotion material,
but also like a lot of documentations,
for technical documentation about how to use KDE frameworks,
how they interact with Qt, what features you can add to your application based on the KDE frameworks.
I'm quite happy with that. I mean, I started to work there in 2019, I think, or 20.
And I'm happy that I'm not doing that much anymore there. And there's new people
going there and helping with that.
So that's a nice project, which worked quite well, I think. Could be better,
but I'm really super happy with the results there.
I also have a mission to consider is what I do with Kigami add-ons is that every
time I do a new release, I try to.
What the blog post about the new features there or to use these new features with some code examples,
and we should probably probably consider doing that with um the kd frameworks
too because currently kd frameworks is basically just uh and that's i don't
think anyone here with them,
and we might want to spend a teeny bit more time to at least point out one a
few big change a few big additions to the KDE framework so that people know about this change,
and can make use of them.
Because you only know about this change if you either maintain the frameworks,
or you contribute the features.
And yeah.
Maybe it's a bit of effort, but I think it's worth it.
What I've been doing a lot is to try to do social media Every time there is
a challenge that affects developers, I try to post about it on social media.
Mostly Macedon, because I only use Macedon, but if people use other platforms,
they can also post there.
Something that might be good for others to do the same.
So, I mean, I do a lot and I'm hoping that other people could try to do more in that direction.
Maybe we also could consider a third-party app program, a bit like Gnome Circle,
where there's Gnome Core applications,
which are not a lot of them, and then we have a lot of third-party applications,
which can be used beyond GitHub, beyond the GitLab, basically basically anywhere where they want.
And we have a few requirements, but it's less difficult to be part of the program
than to be like a real first-party application for Gnome. And maybe we need the same thing.
We just need to find a good name, decide on the process to add these applications
to that program and see what advantages these applications have.
Like, we should try to promote them, these first-party applications,
on our official channels, even if they are not official applications.
I've already been doing a bit of that. that, if you look at the KDE for page,
like KDE for developers or KDE for artists or anything,
you will always see at the bottom a list of other open source applications which
are not KDE applications, but we recommend to users if they want to.
I mean, that's part of the ecosystem. You don't need to promote your application.
You will need to promote other applications to make it core.
Yeah. But I think something we need to decide to, yeah.
So if there are some people interested in that, let me know.
OK. But outside of developer outreach, we also maybe want to do a bit of user
outreach, more weekly news about applications.
Like, currently, there's a this week in Cade thing, which mostly is about Plasma
and a few selected applications, like Dolphin, Okula, Kate, which is,
I mean, it's understandable.
Net doesn't have enough time and energy to do that for every application.
Okay, it's not Plasma. No, only Plasma. Okay. But yeah, we might need to do
something for applications and spread the workload.
It's a thing. It shouldn't not only be Net or me.
It should be like a community thing with a group of people taking responsibility for that.
And yeah. And maybe we should adopt something like TGP matrix or TGP sync norm
where it's basically every developers which post their update on that blog post
which is like maybe like two lines of text was that enough and as maybe social
medias to try to promote our applications,
more there or maybe probably both actually like we should probably do both and
go in a bit of every direction and see which what works most and what works
less yeah i mean like for example for the social media,
created that my personal account,
which post, I mean, the idea was to post regularly about new applications.
Uh, for the moment I only did that once, but there's some post plant.
I mean, I really like, uh, just like promote like bit of more niche applications,
like Ktorrent, um, which is like one of the big KDE applications,
but it's actually super powerful.
Like if you look at it, there's a lot of plugins where you can search for torrents
with a web browser embedded. I mean, it's super powerful.
But yeah, not many people know about it.
Yeah yeah and also on flattop there's a quality program where applications which
meet the standard requirements for
quality are then promoted to their own homepage of flattop and i've been,
doing a lot of polishing there towards upstream metadata um again would be nice
if it wouldn't be only me there.
I mean, for example, just ensuring that the screenshot is updated,
making sure that the text is there, that we have some good information.
It's not a lot of work, but it's 200 applications where we need to do the work,
so if we could spread the workload, out will be nice yeah and let me ask some
questions to the audience um who here is using dolphin,
that of you that's good uh who here is using falcon or angelfish ah a few okay that's good.
Camel or mackerel? Oh, I actually caught a bit of you. That's more than I expected.
Caligra? Oh, there is a few. That's interesting.
I mean, this presentation was done with caligra? her?
Yeah. And who is using Plasma Mobile? Oh, well, that's more than expected.
Yeah, I wish we would try to use our application more to dog food train,
like, how can we convince our users to use these applications if,
who says we are not using them?
And, I mean, I'm Me doing my presentation with Kaliha, I found numerous bugs there.
No crash, which is good. But still, numerous bugs, like the PDF export is not good,
if you saw the exported PDF in the channel.
But it's fixable. And if you try to use more other stuff, like,
for example, Android, like there's There's a lot of KDE applications.
You don't need to use PaaS Mobile to try to use these Android applications.
It's really great. If you want to scan QR code, there's QRCR,
which also do a lot of cool things there.
And the more we use the application, we might be tempted to fix a few things
and to improve them. And yeah.
Yeah, and I mean, this thing, like, try to improve the KDE ecosystem is related
to, basically, I saw the list of goals from the previous years,
from three years, and it's basically related to all the goals.
Even Wayland, like, having good support for Wayland in the application is also important.
Consistency, accessibility, really,
like, it's all, I mean, all the goals are related to make the
application ecosystem of KDE better and yeah
yeah that's it if you want to contact me these are my contact details um yeah
and you can also talk with me um in academia or in class,
Yes. Questions. We have questions.
A lot of questions.
You said about KDE applications and third-party applications.
So if you want to use the third-party applications, you can use the third-party
applications. If you make an application tightly related to KDE,
what are the benefits to market as a third party and not as a KDE software compilation?
That's a good question. I mean, originally we had the brand KDE Applications,
which was used for the release.
We tried to distance that a bit because it was not even all the applications,
released by KDE, all of them were included in that release cycles thing.
So we tried to distance that a bit.
Um, yeah.
I mean, if you are using KDE frameworks and not part of KDE.
Yeah, so if I create an application that is very related to KDE,
it's better to include it into KDE Suite instead of marking this,
okay, it's a third-party application, we are not related to KDE.
I mean, the thing with KDE applications is that there is a lot of requirements.
You need to use all translation systems, You need to pass KDE review.
There's a lot of requirements.
And these requirements might not be for every application. I mean,
even if you want to do a sort of dual licensing model,
there's some really good reasons why you don't want to have applications as KDE applications,
but still use KDE technologies, technologies and still be promoted to the KDE
community as these applications works well with Plasma and that's something
we try to promote these for the applications,
not completely as a KDE applications, so we don't take too much responsibility
for them, but see like their path.
Hey Carl, so simple question, obviously you're into apps and you've created
a butt-ton of them. When are you going to finish them all?
Yeah, I'm quite good to start new applications. I'm a bit less good to finish them.
I mean, as a state where I'm happy with applications and for ARIANA,
for example, I think the application is mostly done, where it's just a project
to change the rendering,
but all the basic features are there. I'm happy with that.
And then it doesn't need a lot of maintenance work just to keep it working,
keep it putting away from the latest applications, maybe tweak a bit the UI,
get some feedback for the users, fix the bugs.
But at some point, there are some applications which are done.
And like really i like to do those more applications which yeah yeah.
Okay so um one thing
i've seen in kdfs is that there are some applications emerging that that seems
to do the similar things as already well-established app.
I think one of the examples is Angelfish.
I think we already have a web browser,
Conqueror, and I really like the UI design of Conqueror and the functionalities
of Conqueror is very rich, including a very important aspect,
that is, it allows you to customize.
My shortcuts um but you
know there's angelfish which got started and it
doesn't use k parts it doesn't allow
you to customize shortcuts i feel that
might you know i don't
think it's a very good thing
to like rewrite things from scratch that
uh you know doesn't make use of
existing knowledge and I feel
you know the time and
resources might be used to make say make concord better for like mobile users
or etc yeah I mean I think that's part of my first idea with ecosystem you have
some cooperation and competitions.
And I think if you have a wide balance, it can be quite healthy for the ecosystem.
I think a good example for that is Mercuro, which is like a KDE PIM representation in Qt Quick.
But it's using, basically, all the libraries of the existing stuff.
Like it's using ,, it's using to pass events.
It's using all the ecosystem already.
And having these two applications which compete a bit, like,
I try to not market it as a competition, but it is a competition. I mean, it is what it is.
But having Merkur in the ecosystem has improved a lot of Equality,
which results in improvement to Camel and to Karganizer.
And I think as long as you try to reuse components and to try to make them,
it's fine to have competitions even inside the community.
And for EngineFish, I mean, the reason why EngineFish exists is because of mobile.
You cannot just conquer on mobile phone and you need a browser on your phone. So that's it.
All right, testing, testing, one, two, three, okay.
So I wanted to make a comment on one of the earlier slides and that is on how
to get more contributions, more young blood into the projects.
In QPrompt, I've had a.
I haven't been able to, I can't expect people to go into the code and contribute
very often because most of the people in the particular target audience,
that community, they are not developers.
So what I've done is put some web platforms that are very accessible.
For example, in the translations website, I'm using WebLate,
and with WebLate, it's integrating directly to K-internationalization,
and all of the translations are done through there, and it's a great experience.
And I think you could do the same, like look into how I did the setup with WebLate
and copy it over, and feel free.
And I've also done something similar for documentation. presentation there,
it's a, I forgot its name, I think it's a, essentially people just write Markdown
and they get a PDF. Works great.
Yeah, I mean, I think we need more translators, like to reach more people with
applications, we need more translators.
I'm not happy with the QN workflow. I don't think anyone is really happy with that.
It's just a lot of work and you need to be, try to be compatible with the QN1.
One, the equation is a bit complicated, that's why I try to do like a sort of
web thing based on the existing stuff.
I mean, we need to discuss that at some point and I don't think there's a perfect solution.
And yeah, but yeah, like if you want to get more users, we need to be available
in more language and that needs more translators and you need to make the job
for the translators as easy as possible.