I fear that around every framework some people will start to create a new desktop. Like Qt with KDE and Gtk with Gnome.
1 Like
KDE is created in its own reason, and uses Qt. Qt is not its motivation.
So are GNOME and XFCE regarding GTK.
A DE is not created for a toolkit. A new toolkit only provides one more choice when someone already decided to create a DE.
And often a toolkit is created for a DE.
3 Likes
I think embracing the possibility of using Python with Qt is a perfect way to achieve the concerns of this thread re accessibility. And as people have said, since it’s mostly C++ under the hood, the apps can be reasonably performant, especially combined with QML – and it wouldn’t be used for the core of KDE anyway.
This tutorial is great and is exactly the kind of thing that’s needed 
Can I ask why the decision was made to use PyQt for it rather than PySide? Qt has great support, docs, and active development for PySide these days, plus it’s the “official” bindings so to say.
PyQt came first so it’s more mature and while the PyQt5 docs aren’t great, the PyQt6 docs are okay. The PySide docs are mostly autogenerated from the C++ docs and are often missing the important stuff, like import statements or code examples.
But the real reason is that there’s a flatpak Baseapp for PyQt, so it’s trivial to distribute a PyQt + Kirigami app via flatpak. PySide doesn’t have that yet, and its absence causes the flatpak packaging of the original PySide tutorial to become overly complicated in Qt6, as it needs to build PySide and Shiboken together with the app.
I do want to switch to PySide once it’s in better shape with docs and flatpak, though. It’s especially important because if KDE is going to make bindings from C++ KDE Frameworks, it will probably be best to use PySide’s Shiboken2 binding generator.
3 Likes
This is amazing 
I should try making a tiny app with the help of this just for funsies.
At the risk of necroposting, I’d like to chime in here with my two cents.
My personal unfiltered opinion is that KDE should stick with C++ because it’s familiar. However, having got that out of the way, I legitimately think that KDE should not be rushing to replace C++.
Despite its general reputation as a dinosaur, C++ is changing with the times. As a good example, somebody mentioned modules earlier in this thread. However, C++ is also moving towards memory safety [1] [2], which would render this discussion mostly obsolete. If KDE sits tight, we end up with a win-win situation: if C++ adds memory safety, it saves a ton of porting work on KDE’s end; if memory safety is not adopted in C++, KDE still wins by allowing Rust/Qt bindings to mature farther before attempting a port.
Additionally, KDE should not rush to adopt “next-gen C++” in the form of either Carbon or Cppfront. Neither of those projects are in a state where they can be used for complex Qt software, or even non-trivial software in general.
7 Likes
It has changed quite a bit already. Once you start learning it as its own language rather than learn it like you’d learn C, and you focus on modern (C++17 and later) features, it is SO much nicer to write C++. It gets way closer to what other languages considered modern do.
C++20 ranges, C++20 concepts, C++20 abbreviated function templates, C++17 class template argument deduction, C++17 optional, C++20 span, C++20 designated initializers, C++23 contains, C++23 copyable/movable, these things add up. I’d dare say modules is one of my less interesting changes in modern C++.
KDE has defaulted to C++17 so a lot of these are missing, but still. I hear some projects are actually using C++20 already.
Ranges is my favorite. It ends that terribly annoying use of begin() and end() iterators that 90% of the time you don’t really need, turning convenience functions like fill(), find(), sort(), replace(), count(), remove() way more pleasant to use with containers. It lets you do some “chaining” using transform/filter that’s closer to the filter chaining you’d do in Python or Rust. Among other niceties.
6 Likes
About safety, including “memory safety”:
Static Analyzer Rudra Found over 200 Memory Safety Issues in Rust Crates.
Developed at the Georgia Institute of Technology, Rudra is a static analyzer able to report potential memory safety bugs in Rust programs. Rudra has been used to scan the entire Rust package registry and identified 264 new memory safety bugs.
CVEs (Common Vulnerabilities and Exposures) in Rust programs:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
The quote from your link points out the advantages of Rust
In C/C++, getting a confirmation from the maintainers whether certain behavior is a bug or an intended behavior is necessary in bug reporting, because there are no clear distinctions between an API misuse and a bug in the API itself. In contrast, Rust’s safety rule provides an objective standard to determine whose fault a bug is.
Advantage for the library user, but it places a greater burden on the library writer, especially when the library contains unsafe code.
What might be documented as “this usage leads to undefined behavior” in a C/C++ library, now has to be expressed either via the type system, or some runtime check, and often unconventional design of the library interface.
Advantage, with a significant cost.
2 Likes
My greatest issue with being a collaborator is there’s a lot to learn for a C++ newbie, we have to learn C++, Cmake, Qt, KDE frameworks, QML…
Problems with C++ is it has too much baggage!! You often come across conflicting recommendations that’s confusing to a beginner.
Then we have another elephant which is Cmake (Build systems), this also takes a chunk of the learning process.
Another elephant is Qt/QML. I don’t know about you guys but Qt website makes me feel dizzy each time I visit it. It’s too bulky and you’re left with different options to choose from.
Kirigami, I don’t even know what to say about this since I just know it’s a framework.
All these things add up for beginners. I don’t really mind learning C++ for KDE but like I have said previously, it’s ecosystem is too bulky.
2 Likes
You can start by treating them as black boxes. Just copy and modify other’s code. CMake, Qt, QML, you can go quite far without a systematic understanding of them, as long as you are not doing something unique.
1 Like
That’s still what I do 
2 Likes
This might work for an open-source project. In industry this would not be accepted after a couple of weeks.
About safety, including “memory safety”:
Static Analyzer Rudra Found over 200 Memory Safety Issues in Rust Crates .
Developed at the Georgia Institute of Technology, Rudra is a static analyzer able to report potential memory safety bugs in Rust programs. Rudra has been used to scan the entire Rust package registry and identified 264 new memory safety bugs.
CVEs (Common Vulnerabilities and Exposures) in Rust programs:
CVE - Search Results
Curiously:
Blazingly 
fast 
memory vulnerabilities, written in 100% safe Rust. 
GitHub - Speykious/cve-rs: Blazingly 🔥 fast 🚀 memory vulnerabilities, written in 100% safe Rust. 🦀
Ya. I tried doing that to Kholiday.
Added my countries holidays and followed the read me but I couldn’t find a way to see those changes graphical.
The changes seemed fine but now I’m left wondering how do I see my changes in the calendar widget?
You should build kholidays (e.g. kdesrc-build --no-src kholidays) then restart plasmashell (e.g. systemctl --user restart plasma-plasmashell.service).
(If you logged into the KDE dev session, that is. Otherwise, system packages won’t pick up your custom-built kholidays lib.)
1 Like
whitehouse.gov just posted this: PRESS RELEASE: Future Software Should Be Memory Safe | ONCD | The White House
I wonder if things like that will drive Qt to support more memory safe languages or use a more memory safe version of C++ like those discussed in this thread previously. That would likely have a huge effect on whether or not KDE adopts a new programming language. The average KDE program isn’t being designed for situations where a crash could mean someone literally crashes IRL, but Qt might want to support programming for those types of situations.
2 Likes
Dev session?
Could I just build and run it without the system one’s being updated?
As mentioned, Python is totally okay for app development and has first class support by Qt. Then rust is even faster and more safe than C++ for core components where security and speed are crucial, and at the same time Qt is not important.
I think this is a very good take! Python is easy, interpreted and verbose, it is perfect for beginners to learn.
Rust is a modern low level language that can be extremely optimized and be extremely fast, while sparing memory safety bugs i.e. annoying maintenance in the future