KDE is pretty good for developer documentation and help offered in their IRC chats as long as you’re diligent and provide detail of your problem and can get someone’s attention.
What is a huge learning curve is C++ but even worse is Qt Qml (essentially object embedded javascript, capturing js warts and all of callback hell in single swoop) slapped on top of C++. Any serious app will need C++ and short comings of separating the ui layer to an uncontrollable compiled language engine just adds a huge hurdle. Now combine this nearly useless abstraction with attempting to dig into using a library like kdepim/akonadi and you’re entering a world of pain.
The entire experience would not be so bad if I could write my app entirely in Cpp.
Another hurdle is using kdesrc builder takes a very long time and is error prone if you don’t account for identifying which 47 of the dependencies require release/6.x branch or a framework/15.x.x branch, or whatever the branch naming convention is across applications and libraries.
> QML is absolutely not JavaScript. It's a markup language to describe user interfaces, spiced with JS for certain interactions. All heavy lifting behind the scenes is done in C++ - the QML runtime as well as the application logic and data models.
How's QML useless? It's incredible language for UI. I described how I developed my Block Editor (like Notion) in Qt QML and C++: https://rubymamistvalove.com/block-editor
When you say "cannot be written", what do you mean?
You are free to write one, and it works. I have a few internal tools that do not touch QML or the XML ui system, and it still builds just fine with then latest libraries on Arch.
Of course an upstream KDE application might not be written that way, if that's what you are complaining about.
Qt Designer .ui files I guess, these are used to generate C++ (QWidgets) code that isn't substantially worse than hand-written. There is also KXmlGui, but that is a rather particular thing IIRC mostly about merging menus from plugins and about permissions.
Edit: just browsed some of the docs for current KDE libs and I see a lot of QWidget-derived custom widgets in there. I don't see how this stuff couldn't be used in a pure C++ codebase.
Outside of deeply integrated KDE apps, I'm shipping QML + Python apps and IMO it's a nice experience.
It's not at all like you're writing JS apps a la React or jQuery, JS syntax is used for expression eval at minimum, but you don't have to use it beyond some single handlers, formatting/convenience functions, or whatever.
I'm looking at a smaller app, with 5k lines of QML and 10k of Python. It's got 250 lines of JS according to tokei, and quickly poking at the QML for JS leads to an additional 200 lines, so let's double to 500 lines. That's like 3% JavaScript.
That said, modern KDE is centered around QML, UI frameworks like Kirigami are built using it, but it lacks comprehensive QML, Python, Rust, etc bindings for KDE frameworks.
At minimum, you will at some point be reading C++ docs and to use your bindings. If you get in the weeds with it, you will be writing your own bindings or wrappers eventually. If you want to avoid that, you will likely be writing C++ for more complicated applications.
It's complex, but I figured with QML Plasmoids they were going for a QML-first approach to future development, but that's been walked back in favor of compiled Plasmoids in recent releases.
What does this even mean? This is not 1980 or whatever, even a device the price of a coffee (RPi Zero ~$10) can handle a LOT, like an entire OS. I'm not saying resources don't matter but for most people doing normal computing (so not weather simulation, 4K video editing of 4hrs long content, 3D modelling of high res models...) pretty much anything in any language is equivalent.
You still can’t control the Qml code via Rust or whatever interop language you use. Swapping out C++ does not fix the issue. You must use QML to be considered for a modern KDE app.
What is a huge learning curve is C++ but even worse is Qt Qml (essentially object embedded javascript, capturing js warts and all of callback hell in single swoop) slapped on top of C++. Any serious app will need C++ and short comings of separating the ui layer to an uncontrollable compiled language engine just adds a huge hurdle. Now combine this nearly useless abstraction with attempting to dig into using a library like kdepim/akonadi and you’re entering a world of pain.
The entire experience would not be so bad if I could write my app entirely in Cpp.
Another hurdle is using kdesrc builder takes a very long time and is error prone if you don’t account for identifying which 47 of the dependencies require release/6.x branch or a framework/15.x.x branch, or whatever the branch naming convention is across applications and libraries.