Not everything made by KDE uses C++. This is probably obvious to some people, but it’s worth mentioning nevertheless.
And I don’t mean this as just “well duh, KDE uses QtQuick which is written with C++ and QML”. I also don’t mean this as “well duh, Qt has a lot of bindings to other languages”. I mean explicitly “KDE has tools written primarily in certain languages and specialized formats”.
↫ Thiago Sueto
If you ever wanted to contribute to KDE but weren’t sure if your preferred programming language or tools were relevant, this is a great blog post detailing how you can contribute if you are familiar with any of the following: Python, Ruby, Perl, Containerfile/Docker/Podman, HTML/SCSS/JavaScript, Web Assembly, Flatpak/Snap, CMake, Java, and Rust. A complex, large project like KDE needs people with a wide variety of skills, so it’s definitely not just C++.
An excellent place to start.
If I can get the more pressing stuff out of the way, I really do need to get back to contributing Flatpak build manifests and do one for BasKet Note Pads. It’d really help to simplify allowing me to fix some of the big warts that showed up when porting it from KDE 3 to KDE 4 and beyond if I could use Flatpak as my go-to solution for making and installing development builds despite being on Kubuntu 22.04 LTS with all KF5/Plasma5 infrastructure.
Ill keep it short: I love KDE
I love Haiku more… but for some tasks i still have to dualboot. When proton for haiku is done, and hdmi sound works i will be using haiku only. Nah, i will still be booting up my souped up amiga 4000 with a voodoo5 5500pci and g4 accelerator board with maxed out ram. But for my internet usage i will be on haiku once the sound issues is solved.