Qt 6.0 Officially Released

[Awesomeness]

Does that mean kdelibs 6.0 is starting now?

kdelibs is dead since many years.

[reavertm]

QtBluetooth ?!
A bluetooth stack in a GUI Toolkit?

Qt is not GUI toolkit. It's applications framework. You can write completely headless applications with it.
In has databases API, threads, synchronisation, sockets, Dbus, XML support, to name some. GUI is just one part of it, therefore your KISS doesn't apply here.

[Ivan Dimitrov]

So what does it mean for KDE??

Not much for now. There has been some planning and code cleaning for the QT6 transition but I guess they are far away from moving to QT6. Heck Plasma 5.20 was the first release to officially support 5.15.... so do the math when QT6 is coming. I would say end of 2021/22.

[Charlie68]

So what does it mean for KDE??

It means nothing, Kde moving to Qt 6 but with relative calm, as they always have with the major Qt releases.

https://www.volkerkrause.eu/2019/10/12/kf6-road-to-kde-frameworks6.html

[flashmozzg]

That was the reason given for Qt 3.3 --> Qt 4.0 and it caused problems for everybody who were under the impression that Qt 4.0 was a complete release.

That's more due to the amount/type of the breaking changes in 3 -> 4. 4 -> 5.0 was wthe same (with some features only coming back in 5.1/2/3...), yet was much smoother. since many codebases compiled with Qt5 just fine with minimal changes.

[ed31337]

Qt is such a piece of shit lately.
The offline installers for Qt6 are just the source code.
The online installer requires you to sign up with their company.
What A Joke.

As long as they provide source, I'm happy. Since I'm presumably a developer, compiling from source seems like no big deal, and I get a properly optimized build for my particular hardware platform. At this point, I wouldn't install it any other way.

[geearf]

kdelibs is dead since many years.

I meant KDE Frameworks.

[WonkoTheSaneUK]

I meant KDE Frameworks.

I direct your attention to the blog post linked above by Charlie68

[lowflyer]

Qt is not GUI toolkit. It's applications framework. You can write completely headless applications with it.
In has databases API, threads, synchronisation, sockets, Dbus, XML support, to name some. GUI is just one part of it, therefore your KISS doesn't apply here.

For the "completely headless applications", yes, this is absolutely possible. But the otherwise quite well done documentation is seriously lacking in this area.

Well, the KISS applies in all other cases:

databases API	This is the only area where I see some value in having a Qt API. But as soon as you do something other than "Tables", use the respective databases' API directly which already is cross-platform
threads	use `std::threads` which is wherever your compiler is
synchronisation	use `boost::interprocess` if you are on C++ or the synchronization library of your language.
sockets	use the sockets directly. No other part of software has been that much cross-platform as the sockets.
Dbus	Dbus is mostly linux-only and currently under life support there. What's the point in being cross-platform here?
XML	Why on earth use Qt::XML? It's slow, it's buggy and it wont be fixed. Use any of the other available cross-platform libraries: tinyxml, pugixml, xerces etc.

[geearf]

I direct your attention to the blog post linked above by Charlie68

Thank you!