The Qt Company Announces Its New High-Level 3D API - Qt Quick 3D

[phoronix]

Phoronix: The Qt Company Announces Its New High-Level 3D API - Qt Quick 3D

Continuing on from the recent technical vision for the Qt6 tool-kit, The Qt Company has now announced their new high-level 3D API they are developing for this next major release of Qt...

http://www.phoronix.com/scan.php?page=news_item&px=Qt6-New-Qt-Quick-3D-API

[skeevy420]

Some of those screenshots make me wonder how well the QT framework would work to make games without using Godot, etc.

[eydee]

Qt is like sytemd. It grows and grows and grows and eventually it's gonna become an OS all by itself.

[skeevy420]

Qt is like sytemd. It grows and grows and grows and eventually it's gonna become an OS all by itself.

I can't tell if you like that or not, but I consider that to be a good thing. One way to manage the low level, one way to manage the desktop. I know I can't be the only one that "really liked" having to learn all the different ways to manage various daemon on boot or "still really likes" configuring three or four GUI toolkits to try to look similar enough so the desktop doesn't look like a fustercluck.

[rene]

Qt is like sytemd. It grows and grows and grows and eventually it's gonna become an OS all by itself.

yeah, I was thinking the same. -ETOOMUCHBLOAT https://www.youtube.com/watch?v=jGhTPHpnIgc

[kpedersen]

I can't tell if you like that or not, but I consider that to be a good thing.

It grows and grows, and then fails causing you to not only have to port the GUI aspect of your software, but now also everything else!
These monolithic approaches are a tad old fashioned; I find they also work exceptionally poorly for long running projects in a volatile environment such as Linux.

Again, I am probably just a bit cynical because I have had the experience of starting with a very early version of Qt (2.x) many years ago and watching the whole codebase need a rewrite because even the older Qt build system was impossible to run on a modern platform, let alone the library / framework itself.

My big issue with Qt Quick is that they keep trying to move away from C++. That is all well and good and easy to use and stuff but then connecting it back to your C++ code (you know... to actually solve your requirements) then means that you need to spend 90%+ of the project pointlessly writing bindings to whatever DSL they are forcing you to use. Homogeneous codebases are honestly so much easier to expand and maintain.

[josh_walrath]

I can't tell if you like that or not, but I consider that to be a good thing. One way to manage the low level, one way to manage the desktop. I know I can't be the only one that "really liked" having to learn all the different ways to manage various daemon on boot or "still really likes" configuring three or four GUI toolkits to try to look similar enough so the desktop doesn't look like a fustercluck.

The problem is you need to be a lawyer or have deep pockets to use it with peace of mind (unlike GTK).

[chriswyatt]

[R41N3R]

Why not going Vulkan only? For Metal there is already MoltenVK and for OpenGL ES there is Angle. The other platforms usually support Vulkan directly, so there is no need to invest a lot of time in a separate solution, at least I can't see it.

[Luke_Wolf]

Qt is like sytemd. It grows and grows and grows and eventually it's gonna become an OS all by itself.

Qt is a Platform Framework, not a library. Always has been. It's most appropriate to think of it like the Base Class Libraries of .NET or Java. The goal of such things is literally to abstract away the underlying OS Platform so that the developer doesn't have to concern themselves with it as stated by their tag line: "Write Once, Run Anywhere", and given that Qt is a high quality framework with best in class documentation it's not really a bad thing.