What even are Breeze, QtQuick, QtWidget, Union..?

I can’t question your experience, but I’ll offer my own.

I have tried writing Qt in Python, which was a surprisingly messy affair between many versions all incompatible with each other, and functionality that was straight up missing in various ones. (I was a noob, but isn’t the price of entry the topic here?). It also made very strong opinions about how I need to structure my software, which was intended to be pretty basic but then I had to care about async and event loops and other weird things- it just brought in a lot.

Then I tried again when I was writing Go, and that was a lesson in pain at the time.

I tried again later in Rust; that was also extremely painful. Moreso than python and Go.

Then I finally tried in C++, and that was an amazing experience.

I guess the concepts map cleaner onto a C++ codebase.

Same, I would take building a UI with Qt over web tech any day. I just wish Qt was more usable outside of C++ and Python.

I've used both, although I'm not quite "as fluent" with QtQuick (which I've used less, and mostly for hobby projects) as I am with QtWidgets (which I've used more -- since it's older -- and in a professional setting, too). I think you're massively overestimating both the difficulty of getting "native" looks with QtWidgets (I'll get back to the scare quotes in a moment) and how much easier things are with things like Electron.

If you use QtWidgets alone, you don't end up touching QStyleOptionTabWidgetFrame. Qt wraps around a lot of native functionality. There are some quirks, and sometimes the Qt platform lags behind recent changes in native appearance, and on some platforms (Linux, in particular) there's really no such thing as "native", hence the scare quotes -- but even with all of these you still get something that's orders of magnitude closer to native than anything web-based.

The very entangled diagram you see in this blogpost is KDE's own doing and specific to their stack to some degree, because they're explicitly after two things:

1. Being able to use both QtQuick (which is very much like a React/HTML/CSS/JS stack, except for the React/HTML/CSS part -- it's similar but not literally React, HTML and CSS) and QtWidgets or application development, while
2. Maintaining native (as in KDE-themed) looks in both cases.

Now #2 is exactly as hard a problem with QtQuick as it is with Electron and for all the hate KDE gets for bloat in their theme engine (Breeze is a theme, sure, and that happens via a theme engine which literally has a goddamn D-Bus interface) I think they come closest to solving it than any other platform.

That tangled mess isn't there because somehow native toolkits are weird, it's there because KDE is trying to get both the native widget set and their QtQuick applications to look good together. KDE could just go the Electron development way -- make a cool-looking theme that looks nothing like everything else, call it the default, and get on with it -- and 90% of what you see in Aks' post goes away.

Now for the nasty part: I don't think we should let low-effort "real programmers don't use JavaScript, I like to grit my teeth on segfaults like real men do" orange site bullshit discard all the critical outlook on "non-native" (insofar as there's such a thing as native on FOSS platforms) toolkits.

Even with all the effort that went into keeping Kirigami's looks in sync with everything else, I can still immediately spot an application or component that uses QtQuick instead of QtWidgets, even though both have the same Breeze theme. The one that takes a long time to start up the first time, has weird layout quirks, and misses some basic functionality (sane color picking, for example) is the QtQuick one. That's how I spot React/Electron apps, too.

A lot of QtQuick (or Electron/Tauri/whatever-wrapped React) applications don't really try to get "native" layouts -- i.e. they're doing things closer to Spotify's very web-like UI than to, say, Dolphin's, or Windows Explorer's. That works very well. But in my experience, as soon as you try to coax them into native-like layouts, things that start with import { DatePicker } from '@mui/x-date-pickers/DatePicker' also commonly devolve into 21 story-point sagas about dropped frames, the date picker being scattered all over the screen or compressed to 2px heights and so on.

I suspect most of the hate comes from a different source. If you already know C++, you can get started with Qt Widgets right away, and you get all the benefits of a C++ environment that you know -- excellent IDE integration, static analysis tools and so on. Whereas if you try to use React (or QtQuick, too, really), none of your C++ knowledge helps, and the development experience kind of sucks compared to what you were used to. Most of that results in rage that's eventually distiled into online flamewards, but some of it just causes legit software quality issues.

It's not a coincidence that KDE is working the hardest to fix this, because they're shipping applications that use both, so it makes these problems all the more obvious. They're all within KDE, so nobody can point fingers and say look WE'RE fine, it's the unwashed masses of Electron developers who are ruining this. That's also why they're the ones getting flak for the tangled mess: they're trying to reconcile two very different types of frameworks instead of saying oh sure no two apps look alike but HAVE YOU SEEN HOW GOOD THE BRANDING IS NOW??? -- and that's bound to add to the complexity, not take away from it.

You very very rarely have to even think of something like QStyleOptionTabWidgetFrame, only when creating super custom things, or when creating a complete 100% custom QStyle (even Breeze relies on some default values).

QtQuick makes this easier (IMO) because of QML. In there you use templates of main components if you want to create something new, or inherit the default component and modify it.