Is Qt holding KDE back?

I was looking into writing a simple KDE application (and add features/complexity slowly) but I am already finding QT to be pretty hard to work with due to its strong ties with C++. Other language adapters exist, but they all feel very hacky to me.
I am starting to wonder whether QT is the reason the adoption rate of KDE frameworks is quite lower compared to others and what can be done to solve this. I know Kirigami exists but from what I can see it only solve the frontend UI part while the rest of the application needs C++ or something similar.

PS: I am aware about the relation and rich history between KDE and QT projects, and I am not trying to cause anything negative between them. I just want to spark discussion on how we can improve the current situation of onboarding new people and applications (and maybe even help out the QT project).

It sounds more like you have an issue with C++ than with Qt, though. :thinking:

What language did you want to use instead?

I have a tried other languages like rust (with cxx-qt and also with qmetaobject-rs) and had success making a basic application. I do not have problem with C++ (I should honestly just learn it).
Although, the point I want to highlight is the inherent complexity of using QT (not just C++) and how the overall experience can be a modernized/simplified

I’ve “learned” (still learning) C++ through QT and I can’t say that’s difficult. Especially with QML, you can have a basic app up and running in no time, and adding some logic in it is just the next step. If you’re motivated it’s not more complecated than other framework imo (can’t speak about QT Widget though)

What complexity exactly are you referring to?

I’m definitely feeling like an old man at this point, hearing about how C++ isn’t modern enough :stuck_out_tongue:

C++ is plenty modern. The tooling around C++ is complex and the pain point.

Not sure I’d say it’s holding KDE back as a whole, but it does significantly raise the barrier to contributions.

What I would love to see is a clear pathway for writing KDE apps/widgets using PyQt. Qt is usable from other languages besides C++.

Which introduction to KDE programming are you using?

The problem with Python is sharing binaries of your project. Python has to ship all the libs and the whole interpreter, so it’s a bit messy.

But I do agree that C++ can be scary to newcomers, and something like Python could work for that better. Still, Qt is C++ framework/library/ecosystem so that’s what we need to use.

I don’t think Qt is holding KDE back, at all. But maybe we could have some sort of tutorial for making KDE apps with Python, if possible. (I haven’t researched in this so I am not sure how possible it is). I am all for lowering the barrier of entry, and Python is easy for a lot of people to grasp.


I recently started to dip a toe into the water of QML (not even touching C++) by writing a plasma widget. It’s a bumpy ride.

There’s a lot I can say but one thing I want to highlight in the context of this discussion is the quality of the QT documentation (e.g. Qt 5.15).

It is superb! If you have a computer science degree and are expecting to read a paper.

It’s full of sentences like this one - which I read today … multiple times: The component scope is the union of the object ids within the component and the component’s root object’s properties. Yes, that’s technically correct, but it’s just too dense.

It doesn’t have to be Simple Wikipedia, but as a casual user I would throw my hands into the air and just leave. I can’t imagine that anyone without formal education or multiple years of programming experience ever wrote a plasma widget. But I might be wrong, who knows.

That doesn’t seem super complex to me, it’s just saying that the scope of ids within and that includes anything defined at the root component?

Programming is not what casual users do :frowning: That’s more for enthusiasts, and Qt is a pretty huge and complex framework.

I assume you’re describing what above sentence wants to say but I have an even harder time parsing yours. :wink:

After understanding the concept the original sentence is clear as day, but before that it is mostly gibberish. It’s fabulously succinct for people in the know, but fails hard teaching, esp. if you’re not familiar with the vernacular of the trade (like union).

That is kind of the point in question, isn’t it?

When I say “casual user” I of course don’t mean everybody, but someone who acquired basic programming knowledge in the past (functions, loops, if/then) - probably in a scripting language - and tries to learn how to solve a problem in their current environment.

In the scope of my comment regarding the documentation I would still argue that just acquiring domain knowledge is a significant hurdle not put up by its actual content but form of presentation.

1 Like

Kinda disagree with this. I don’t want to argue how to define casual user but imo there are definitely casual(ish) “programmers”.

For example (some) people that write Microsoft Excel VBA code or people that “maintain” ancient C or Basic code that consists mainly of If statements and function calls and so on.


I love Plasma KDE, and many times I got the desire to learn Qt to contribute to my favorite desktop and apps, but the big obstacle is that Qt restricted licensing model, which means you will learn the whole language and libraries, but you will be restricted to contribute to only open source projects.

The Qt open-source licensing is ideal for use cases such as open source projects with open-source distribution, student/academic purposes, hobby projects, internal research projects without external distribution, or other projects where all GPL and LGPL obligations can be met.

I don’t understand why Qt didn’t change its license model and make the platform completely open source and free, while maintaining paid support like how is Java (free OpenJDK) is doing it by providing paid LTS support from different providers like Amazon, Azul, IBM, Microsoft, Red Hat, Oracle, SAP…

Even if I hate GNOME desktop, but I truly love how GTK is completely open source and free and what is amazing is that GNOME developers have taken its control, and even created their customized LibAdwaita library on top of GTK widgets which fulfills GNOME desktop requirements and evolution.

I wish for the day where a true free and open source KDE Qt framework becomes available for public usage. :pray:

My trick is just imitate existing Plasma widget code, and don’t bother with the doc. QML is pretty self-evident this way.

IMHO, QML is not a “serious” GUI framework after all. It looks like a declarative language, but actually is imperative. So its order of initialization and order of updates are a mess. You use it to quickly hack together a simple GUI, and don’t care about how it really works underneath. Plasmashell produces tons of “Binding loop detected” warnings, which sugguests that KDE developers don’t care very much, either.

That’s fair, documentation is really hard to write and the Qt documentation could be pretty terse.

Yes I’m probably getting semantics mixed up, but you’re right there’s definitely a class of “casual programmers”.

I’m not sure what you’re trying to say, the Qt framework is free and open source in every way that matters. It just has the option to dual license to their own commercial license, and some modules that are only licensed under that. It’s stuff that really only businesses care about (like Qt for Automotive). This is what the Qt company has chosen to do, unfortunately.

This is simply not true, there is the possibility of developing commercial software in Qt without paying a dime. Most of the modules are possible to use via LGPL, and you must ship Qt externally to abide by the license. See this page on Qt’s website: Qt - Obligations of the GPL and LGPL.

This is a pretty baseless accusation to make, we almost certainly do care. Some developers are trying to bring down the amount of runtime errors in Plasma 6 :slight_smile:


…it uses the same license as Qt and KDE for its libraries, namely LGPL. :laughing:

The licensing isn’t holding KDE back either.

1 Like

FWIW I can think of multiple things holding KDE back in attracting newcomers, but Qt isn’t one of them.

1 Like

I don’t think so, that dual licensing is too much restricted and tricky, it actually prohibits a developer from selling his/her app via known stores.

At least GTK library can be freely used in open and commercial apps.