Do KDE Gear apps need to be written in C++?

Must an app be written in C++ to become part of KDE Gear? Or are other languages with Qt bindings like Python allowed?

1 Like

I don’t think there’s a specific requirement, but lots of KDE libraries don’t have Python bindings - and if they aren’t using KDE libraries then it’s going to be tough admitting them into Gear.

if they aren’t using KDE libraries

Pure QML libraries are usable without bindings, e.g. Kirigami (Creating a Plasma Mobile application – Nico's Blog).

D-Bus can be used too.

The only thing that seems problematic is KI18n.

What about toolkit? Would Slint fit into KDE? It is not Qt but it is veery similar and if Qt is installed it looks native.

I would argue no, we really wouldn’t accept Slint applications into KDE. Nothing in KDE uses Slint, and it would be really difficult to support and also call a KDE project.

1 Like

Hm… of course understandable, but as a non programmer if I would learn a more low level language that would be Rust. And as Slint seems to be great to do that, not being allowed to use it would be a reason for me to not contribute.

I can imagine C++ is still a widely used language, but enforcing it seems like a burden to me. GNOME has a lot of Rust apps as its way easier to chain with GTK, even though not using Rust too.

To put it bluntly, KDE is all about Qt. We use it every which way, from how we write the compositor to almost every daemon on the system. The history of KDE and Qt are destined to be intertwined (literally, they are contractually obliged.) I have to ask the question: if it is not Qt, then is it really KDE? :slight_smile: There is open source outside of KDE, it doesn’t have to have the “KDE blessing”.

Trying to pry C++ from KDE is going to be really difficult, if not impossible until Qt has official bindings in that language. The closest possibility (next to Python, of course) is probably Rust, and that already has some traction in the community.

1 Like

So what are the benefits that an application becomes a “KDE Application”?

It’s here on the website: Benefits of a KDE Project - KDE Manifesto :slight_smile:


This raises a bit of a philosophical question of what a KDE app is supposed to be.

There’s not that many formal rules for that. The most liberal interpretation would be that anything that is in accordance with KDE’s vision/mission and aims to foster those could qualify.

In practice there is a huge benefit of KDE apps being technically similar to each other. It make it easier to write common tooling and allows contributors to quickly jump into previously unknown to them apps. Everything being based on C++/Qt is a huge part of that.

Introducing new languages (Python, Rust, …) or toolkits (Slint, Flutter, …) would jeopardize this consistency. Those this mean we have to stick to Qt/C++ forever? Not necessarily. It would come with challenges though.

Exploring e.g. what it would take for a Slint app to feel “native” on Plasma would be an interesting exercise though, and I would encourage people to try it.


demo image of Slint on Linux using Qt style

In parts it already looks pretty native, but for sure it would mean a divergence from the current tooling, styles etc.