The go-to language for UI with Qt has become QML. Anything else is torture.
Have a look into the approach from Cpp2. Similar to TypeScript that can be used just in addition to JavaScript, Cpp2 can generate C++ code that helps to write better code from the first line switched to Cpp2. No complete rewrite necessary. Carbon makes similar statements, but on a file level.
Never heard of that. I’m a idiot whose really bad at c++, that’s why I try to code gui’s in c with gtk(torture). But that was a while ago. Great to see things changed 
I’m skeptical about replacing things going anywhere. Making more things in other supported languages would go somewhere though.
Python is treated as first party with Qt (whether it’s PySide or PyQt honestly), and if KDAB’s CXX-Qt crate for Rust gets mature enough, having those three as options should cover quite a bit.
A tutorial for PyQt is on the way and I’m pretty certain we have KDE people in KDAB working on/with CXX-Qt.
Personally, having learned Qt with modern C++ first (and loving it) and then trying PySide/PyQt and CXX-Qt, the Qt knowledge transfers extremely well. It felt like The Qt Way was common ground enough for me to get started with them.
GUI applications rarely have to count from one to a billion, where python is indeed slow.
Calling a Qt function implemented in C++, or doing a dbus call which will spend most of its time doing IO, is not much slower in python than in C++, though. That’s why python can work for quite some apps as they will be wrappers over C++ dependencies anyway. It will absolutely not work for all of KDE, of course.
Thank god. I thought for a minute they were discussing rewriting kde in python
Yes, but you are supposed to use QML (and js) for these. (And KDE is doing so.)
QML’s JS implementation is incomplete compared to modern browsers or node.js and you can’t access many OS APIs from it. It’s meant for self-contained UI logic, anything else is supposed to be to be written in C++ (or Python given that it has official support) and integrated with QML using QObjects and models.
Something that could help people write quick little apps with KDE/Qt in mind would be somekind of packaging feature for Python apps.
The main reason I’ve found Python difficult to use for GUI apps is packaging: It doesn’t really exist, except in 3rd party solutions, and it gets really messy.
Solving Python packaging problem is not easy and I doubt anyone has time to create that, but if KDE had somekind of “Python Module Runner” that would create the user shortcuts and such, then create neat lil packages for all the KDE-Python apps, I could see it happening.
Although that sounds a lot like remaking flatpak, so maybe flatpak is the solution for python gui apps?
We can just support the official third party one: setuptools.
Yeah. You still need to create a package with setuptools, but it’s pretty easy to distribute a PyQt that way since it has a Baseapp.
I had to convert Dimitris’ PySide + Kirigami tutorial to it because of that (PySide doesn’t have a Baseapp, so packaging PySide apps is a pain).
You are not joking. The academic world has spent an incredible amount of time and money trying to make python fast for high performance computing… it mostly amounts to writing libraries in C and calling them from python. I like python but I dont think it fits the KDE use case at all.
-a random internet guy
Gnome has some apps written in Python like Tweaks. Don’t tell me you need high performance to click some buttons and write in some files. People should be able to write simple apps recognized as « KDE apps » that would attract others in the ecosystem.
I don’t think KDE needs to adapt a new programming language, which would be quite a tedious project.
There has been mentions of Zig, which I do not believe it quite fits our needs right now. It does not have official bindings for Qt unless its cross-compatibility with c++ is so good, that there are no issues using it.
Python on the other hand, with a large community behind it (including companies) is not going anywhere and will continue to get performance improvements. It even has official Qt bindings, which I doubt are getting ditched.
Do you want to get more developers to work on projects? Good.
Since I talked about python, KDE could host tutorials on how to use Python with KDE frameworks (python bindings for KDE frameworks when?) and package example apps.
@Hunter said that python is slower than other non-interpreted languages. Stating the obvious with a very bad comparison (usually, real applications don’t count from 0 to 1 billion) but they do a lot of other stuff which often requires other libraries (which Python has plenty of and Qt frameworks has the cpp side covered on the most parts). If you believe it’s impossible to make Qt+Python programs with a large codebase, then check out orange data mining program, which uses PyQt5 for its GUI.
tl;dr: We don’t need a new language. We need improved tooling and documentation and better support for Python in the KDE world because it isn’t going anywhere.
It’s an interesting topic of discussion - thanks @gruenich for writing it up well in your blog post.
Some thoughts from my head:
There are at least two major areas with different goals up for discussion here. One is the KDE core stuff, like Plasma and core desktop apps (Dolphin, Konsole, Okular, Gwenview, etc). These have large code-bases and need stability and performance.
However, there’s also a large suite of extra apps that could be written in anything without impacting the main KDE experience, I’m thinking things like Konversation, Ktorrent, Kcalc. It feels like these apps would probably be a good place to try integrating a new language and gain experience.
If any established app has a new language added to it, it will likely mean developers need to know BOTH C++ and the new language, not just the new one. This may actually make it harder to get into? This is probably a good argument for an incremental language like Cpp2 rather than a whole new language that will need lots of bindings built.
There’s certainly an argument to stick with whatever QT does, as if they continue with C++ as their primary language it will always be the best supported option, I suspect.
I think Zig is an interesting language to watch, although I doubt it has a place in KDE directly. I feels like it’s a close analogue to Cpp2/C++, where Zig is trying to allow in-place upgrades of C to a better language. I’m not familiar with how well it does that, though.
KDE frameworks for Python would be so great, a lot of people would write KDE apps just like they do for Gnome.
I think this sums the discussion up pretty well. I wish I could simply ask Qt what plans they have. Probably they are waiting how the market reacts to the new languages Cpp2 and Carbon.
Even if you consider Python to be fast enough for some kind of KDE apps. It comes with a higher energy consumption, countering our eco-friendly approaches in other areas.
Do you have some proof of it the more energy consumption? I would think it would be a insigificant amount. And it would be useful to give that to KDE Eco.
There is a research paper about it.
I just gave a quick look and didn’t read but isn’t this paper about algorithms and benchmarks where performance matters?
Like this isn’t applicable to programs like https://apps.kde.org/kteatime/ ?
Also I would add that making a micro benchmark with a few hundreds lines of code is different than a project that is a few hundred thousand or million lines of code.
Gnome/Gtk is written in C and is not exactly known for its performance (while having not even half the features of Plasma or covering the fast array of kde applications).
We are discussing on a forum which is written in Ruby, not in C++ and no one is complaining that you are not eco-friendly.
Discourse was probably chosen because it was the most popular/user-friendly option and thanks to that, it attracted people (myself included) to the KDE community which is probably bigger than ever.
Python is the most popular/user-friendly option as programming language and even if KDE core apps are in QML/Qt (is QML eco-friendly since it’s Javascript ?), I think there is room for community KDE apps just like Gnome has circles to attract people to their ecosystem.