Comment by kdefanqth8er | Hacker News Reader

Comment by kdefanqth8er | Hacker News Reader

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.

As @ahartmetz said:

> 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

> The entire experience would not be so bad if I could write my app entirely in Cpp.

You can.

Qt + KDE libraries are really nice.

You can’t, you must use Qml.

You used to be able to with QtWidgets but a modern KDE app cannot be written with QtWidgets. And QtWidgets are in life support.

What's the source for this?

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.

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.

It is plain wrong. Most KDE applications are written in QWidgets.

Seems like some use XML to compose the UI?

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.

> The entire experience would not be so bad if I could write my app entirely in Cpp.

What I wish is that I could write KDE stuff using Python (PyQt or PySide).

PySide is supported. The KDE Frameworks Python bindings work on top of PySide.

Python KDE Framework bindings are anemic: https://invent.kde.org/teams/goals/streamlined-application-d...

Ok yeah that was my impression. In theory they exist but they're not kept updated to allow comprehensive access to all of KDE.

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.

Strange that so many of our customers at Qt use Qt Quick if it’s as useless as you say it is

> serious app will need C++

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 could combine it with Rust instead?

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.

OK, but not sure why QML is a bad thing.

You didn’t read my comment entirely or what?

Perhaps try building a KDE app and see how far you get.

Reply on news.ycombinator.com