Qt is on a downhill slope for desktop development. Fix it while you still can! Specifically for Qt + QML the situation is utter crap.

Qt,

I'm not just disappointed here. I'm downright mad and seriously wondering why the hell i would still use the Qt + QML combination on the desktop. You sure make it super appealing to not use it anymore.

With the removal of Qt Quick Controls 1, you've effectively make it near impossible to make a normal (Qt + QML, GUI backed by the QML) desktop application that integrates well into the OS you're running. You've also made it a very labor intensive task to migrate from Controls 1 to Controls 2.

I write that in bold because that is really important!

To add more injury to this poor choice on Qt's part, you've done the following things to make porting much more complicated:

1. You removed controls 1 and renamed controls 2 to 1 in Qt6. That alone is a truly stupid decision! You basically ruined any controls v1 google results and made it this much more complicated to figure out if the answer still applies to Qt6. It doesn't. Even if an answer would specify controls 2, it still wouldn't apply because you renamed that too.
2. The styling from Controls1 to Controls2 is totally different! In a not compatible, not easy to port way. Controls2 is, despite what it's name implies, not a successor to V1. It's a whole new component library and you should've named it as such (already when it was introduced in Qt 5.x.x)!
3. To make matters worse, you still need to define "QuickControls2" in cmake/qmake. Awesome inconsistency right there. I have no good comments here for this, i would've expected some logical sense from Qt.
4. While controls might "look" native, they don't feel native (only applies to the native style, less to full styled controls like Material). One example is the text input field. On a normal text input field you could use your mouse to select text. Or scrolling on a spinbox with the mousewheel. For some magical unexplainable reason the quick controls just downright don't allow it. But they do have some form of mouse handling so this must be just (willful and intentional?) oversight. I would consider this to be a blocker bug as this is very disruptive. It ruins muscle memory too. (sidenote here, this probably isn't a problem on android/ios/embedded because you don't have a mouse there).
5. There is no more calendar component in QML (think of datepicker usecases). Apparently you are of the opinion that date pickers shouldn't exist?

Now one could say "use QWidgets"... No.

You have very clearly expressed your desire to deprecate widgets too. The public outcry of people against that move made that it's not deprecated now and just considered "done" with a minimal effort on keeping it working. Using widgets, from a developer point of view, is a waste of dev time as it takes much more time to make something in QWidgets then it does to make the same in QML. At least if QML still had proper natively integrating components which i claim it now doesn't anymore since Qt6.

To me it is very clear that Qt doesn't care about desktop usage anymore. Not being able to select text with the mouse and the general fugly look of "native looking" widgets is... proof of that. On top of that, you persist in using those dreaded font distance fields (introduced somewhere in Qt 5.x.x) who look plain ugly on the desktop at any resolution. (perhaps besides 4k on a 22 inch monitor, but that's only the high resolution saving you there).

Sure, these issues are also fixable. Fonts can be set to native rendering. Text fields can be inherited and changed to allow more proper mouse interaction. And other future desktop limitations imposed by Qt can be worked around. But the fact remains that desktop apps need to do those workarounds - and increasingly more - leading me to believe that you truly don't give a damn about desktop usage anymore.

Perhaps understandable from your point of view. Automotive probably brings in most of the funding for Qt development.

I have a few suggestions too.

1. Just freaking publicly admit in a blogpost that Qt desktop development is lacking and just ask for community contributions to get desktop development a first-class citizen again. There is no shame in this. Right now you're not admitting this. You say one (desktop dev is first-class) and do the other (don't care about it).
2. The removal of Controls 1 is, in my opinion, a huge mistake on your end. Those components were true native looking and feeling components. Unlike the abomination that Controls 2 is. I'd suggest to bring back controls V1, perhaps under a name like "ControlsWidgets" or something indicating that it's backed by QWidgets under the hood. This would give Qt5 apps that were using Controls 1 an easier upgrade path to Qt6 and is one step back in alienating your Qt desktop developers.
3. Refrain from braking any more desktop usecases! Don't forget your roots and stop slowly destroying those roots.
4. Bring back a calendar picker as that is a very normal and sane usecase! (not needed if you follow point 2).

While i made this post i fully recognize that it's hard (but true) in tone. I made it in an effort to point you to this and do something about it. I do fear it's aimed at deaf man's ears. I am at a point where i don't trust Qt's leadership to commit to desktop development as nothing - literally nothing - points to that for years now. Case in point, i went over all your blog posts of 2021. There was only one blog post regarding desktop development in particular and that's Windows 11 support. And there were at least half a dozen posts about MCU's and many more if you count it as just embedded. Which again shows your focus is on the embedded platforms. I get that money plays a role here too, for that i refer to my recommendations above to point 1 specifically.

Do something about this! It's not to late yet (i think).

Regards,
Mark

Edit.

I'm just going to edit it below the original text to keep things fair.

A few of my example complains above are not as severe as i made them out to be. These are specifically the inability to select text with your mouse in a text input field and the ability to scroll in a spinbox. These claims were false as those are properties that you now need to enable to get the behavior. It's a very bad behavior of default values that these aren't enabled by default. I suppose the focus on embedded here too shines thus another requirement for the desktop users to modify their code.  For the spinbox though, one can still not select the text with the mouse (a bug in my opinion). Scrolling by mouse does work wen setting the property for it.