[Development] [EXTERNAL EMAIL] Re: Removing Qt 3D from release configuration in dev branch
Volker Hilsheimer
volker.hilsheimer at qt.io
Mon Apr 8 16:57:55 CEST 2024
Hi,
As Harald and Mark correctly say, deciding which library to use is a strategic technical decision. And the message here is that we do not want users to select Qt 3D for new 3D rendering use cases. Neither KDAB nor The Qt Company plan to take it further. With Qt Widgets, we have a lot of active contributors and many, many users; we have just introduced e.g. a Windows 11 style in Qt 6.7, we work on many improvements to mixing Widgets and Quick UIs (and this way the new Qt Graphs module has support for widgets), and we fix a large number of bugs with each release.
Whether Qt Quick 3D or some other 3rd party library is the right choice for a new project depends on the use case. And whether Qt 3D is good enough as it is depends on your use case as well. If you can’t live with a Qt 3D that gets no new functionality and probably only critical bug fixes, then you need to consider options.
One alternative is fortunately to contribute to Qt 3D. If it is a critical component in your technology stack, then that might be the best option. In the end, if and to what extent Qt 3D will continue to be usable beyond Qt 6.8 depends on whether someone is willing to invest the time, at the very least by maintaining the status quo while the rest of Qt continues to evolve.
With the change discussed so far, this would mostly mean:
- follow up on submodule updates and make necessary adjustments to Qt 3D to follow up on changes in other modules
- decide if/how to “release” Qt 3D; branching and tagging and making it easy to build from source might be good enough
Anyone is of course welcome to make that easier than `qt-cmake; ninja` by contributing some build system infrastructure and other improvements.
One thing to point out in that context is that maintenance will have to include some of the activities that are driven by the EU CRA [1], as discussed at the Qt Contributor’s Summit last year [2].
[1] https://www.european-cyber-resilience-act.com/
[2] https://wiki.qt.io/Qt_%26_Cyber_Security_(Discussion)
Qt 3D deals with untrusted and potentially malicious data (e.g. loading meshes from a URL) and at the very least needs to have documentation in place about what users of the Qt 3D APIs are expected to do, and what Qt is expected to do when dealing with untrusted input. Also, creating Software Bill of Materials documentation, monitoring security issues in 3rd party libraries, and managing respective processes is work.
On 6 Apr 2024, at 14:04, Mathias Hasselmann via Development <development at qt-project.org> wrote:
[…]
Or even more exaggerated:
Keep everything as it is, except for the Qt users' convencience?
That's what it looks like to me from the very outside.
How does this step help the users, the customers, the project, the product?
Yes, compared to getting a pre-build binary it will be a bit inconvenient to use Qt 3D in a project. But it helps users avoid making a strategic choice for a technology that is getting sun-set; and it allows us to focus our time and energy (for instance in the context of the EU CRA) on those parts of Qt that bring value to most users.
Cheers,
Volker
On 8 Apr 2024, at 16:15, David C. Partridge <david.partridge at perdrix.co.uk> wrote:
I agree 100% with the sentiments below and in other emails to this list.
I'm not impacted by Qt3D, but as a user of Qt Widgets primarily, I'm starting to worry that this too might get pulled or left to rot on the vine rather than being extended and enhanced - we've put a lot of effort re-writing our code to use Qt for portability ...
David
-----Original Message-----
From: Development <development-bounces at qt-project.org<mailto:development-bounces at qt-project.org>> On Behalf Of Frank Hemer
Sent: 08 April 2024 14:56
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] [EXTERNAL EMAIL] Re: Removing Qt 3D from release configuration in dev branch
Hi all,
I also want to backup these thoughts - even though our company has no cards in the qt3d play, we had the same impact by being hit from abandoning QtWebKit (in a minor release!!!) and QScriptEngine. Every product with a lifetime of decades gets shaken in its foundations from such decisions. On the one hand, it puts a question mark an all those that support Qt, that positively affected the decision for Qt, and their reliability. On the other hand there is the immense effort going along with finding a replacement. Or in the worst case a complete rebuild (which most likely would not be qt based any more).
For sure you can build yourself, maintain the affected modules/parts yourself ... but for products with long lifetime, these efforts are added on top and in general are neither expected nor part of the plans.
Please take this into account for further decisions ... usually there is a saying 'the customer is king', but in this respect I start to feel the qt customer is the looser:-(
Best regards
Frank - Head of development
On Montag, 8. April 2024 13:23:27 CEST Mark De Wit wrote:
Hi everyone,
Also a Qt3D user here, and I would like to echo Harald’s sentiments–
and a big thanks to Harald for saying my thoughts out loud.
I had already privately tried to communicate my thoughts to Tuukka on
this subject, but here is my public take…
As the Qt champion inside my organisation, and someone who decided to
take the leap of faith and build our latest 3D visualisation renderer
on Qt3D, this is both a kick in the nuts with regards to how I see Qt,
but has also (once again*) undermined my credibility within my
organisation and our desire to use Qt.
My use case for Qt3D is an architectural visualisation tool. The
rendering pipeline is deeply integrated into our C++ back-end, based
inside a CAD-type QtWidgets application. I’m sorry, but I just cannot
envision rewriting any of this in QtQuick or QtQuick3D, nor can I
justify any of this to my employers.
Like Harald, I was hoping to see some communication about ongoing
commitment with regards to Qt3D. I’d also expect to see some sort of
detailed porting guide to QtQuick3D, at least so that I could assess
the impact (but I won’t consider it at this stage). The simple
statement that QtQuick3D is a viable replacement does not help people like me.
BR,
Mark
* it’s happened before with the whole QtWebKit vs QtWebEngine
transition which also blocked upgrades for several years as WebEngine
was nowhere near feature compatible to QtWebKit for our use cases
From: Development <development-bounces at qt-project.org> On Behalf Of
Harald Vistnes
Sent: 07 April 2024 12:07
To: Mike Krus <mike.krus at kdab.com>
Cc: Qt Project Development <development at qt-project.org>
Subject: [EXTERNAL EMAIL] Re: [Development] Removing Qt 3D from
release configuration in dev branch
Hi,
For what it's worth, here is my feedback as a long time Qt3D user.
I've been using Qt3D from the start when it was actively rewritten by
Sean, Paul, Mike and others at KDAB. The promise then was that Qt3D
would be the main 3D solution for Qt in the coming years. The API was
nice, it was of course
C++, it was LGPL and it seemed like a good fit for our project. So we
C++used
it. It had its issues, of course. I made a few contributions for
missing features and bug fixes over the years.
For users like us, the choice of libraries is very important, as we're
developing a tool that will have a lifetime of decades. So, we must be
able to trust that the library will be available and maintained in the future.
We also use QWidgets, which is stable and works great even if it has
not been updated for years. That's OK, it's working nicely and it
seems it will not go away.
Early in our development we made the mistake of starting with a
promising 3D graphics library from Nvidia. That was suddenly no longer
maintained and we had to rewrite our 3D code. The Qt3D promise at the
time made us go for that.
I have to admit that this discussion made me think "fuck, now I have
to rewrite the 3D code again". I've started to look for alternatives,
even if it will be very painful. And it will not be QtQuick 3D! We
have a complex use case, not just a static mesh that we want to have a
nice visualization of on an embedded device with a few lines of QML.
Why create this uncertainty for users? Why not keep Qt3D in a "stable"
state like QWidgets, available even if it is not actively developed
anymore. It will be a big loss for C++ and LGPL developers to use Qt for 3D graphics.
Sure, I can build Qt and Qt3D from source in the future. I do now, already.
But when I lose trust, I feel bad.
Have you any count of the number of projects or products that use Qt3D
today? Are KDAB making any commitments to keep Qt3D running in future
versions of Qt, like Qt 7 and beyond?
- Harald
søn. 7. apr. 2024 kl. 09:33 skrev Mike Krus via Development <
development at qt-project.org<mailto:development at qt-project.org><mailto:development at qt-project.org>>:
Hi
There’s no relationship crisis!
The topic is a legitimate thing to discuss and it was brought up here
to get as much feedback as possible from the community.
Mike
On 6 Apr 2024, at 13:04, Mathias Hasselmann <
mathias at taschenorakel.de<mailto:mathias at taschenorakel.de><mailto:mathias at taschenorakel.de>> wrote:
I am really confused by this thread.
If I read Jani's mail correctly, the plan is:
Keep everything as it is, except for adding Qt3D to the installers?
Or more exaggerated:
Keep everything as it is, except for the official endorsement.
Or even more exaggerated:
Keep everything as it is, except for the Qt users' convencience?
That's what it looks like to me from the very outside.
How does this step help the users, the customers, the project, the
product?
Am I exaggerating? Am I confused? Or is this all really just Qt
Company and KDAB living out a relationship crisis at the expense of
users and customers?
Regards, and sorry if I misunderstood things,
Mathias
Am 05.04.2024 um 07:11 schrieb Jani Heikkinen via Development:
Some comments below
-----Original Message-----
From: Development
<development-bounces at qt-project.org<mailto:development-bounces at qt-project.org>><mailto:development-bounces at qt-project.
org> On Behalf Of Mike
Krus via Development
Sent: torstai 4. huhtikuuta 2024 17.14
To: Tuukka Turunen <tuukka.turunen at qt.io<mailto:tuukka.turunen at qt.io>><mailto:tuukka.turunen at qt.io>
Cc: Qt Project Development
<development at qt-project.org<mailto:development at qt-project.org>><mailto:development at qt-project.org>
Subject: Re: [Development] Removing Qt 3D from release configuration
in dev
branch
Hi everyone
Disclaimer: I'm one of the contributors to Qt3D, and a KDAB employee.
As mentioned, early discussions have taken place between KDAB and tQtC
around this issue, although much needs to be clarified as to why, how
and when
this happens.
As mentioned by Tuukka, Qt3D was introduced in Qt4 timeline, but
didn't make it
into Qt5.
KDAB invested a lot of time in a complete rewrite of the module (don't
think it
shares anything with the original) and it was made available sometime
in the Qt 5
timeline. Many contributions have been made since then, including in
Qt6 with
the introduction of an RHI based backend (although to this day this
doesn't have
feature parity with the GL backend due to limitations of RHI).
But since then things have settled down in the Qt6 branch, no major
features have
been added. KDAB has continued to contribute bug fixes, and small
features in
support of our clients. So development has indeed been very slow.
So hence came the discussions on retiring Qt3D. KDAB is ok on the
principle and
committed to keep maintaining Qt3D in the same manor.
But there's a lot of implications.
So what does "removing qt3d from release configuration" mean for
contributors?
- if CI remains, gerrit continue to check commits right? If so, the
version of qt this
is built against
remains controlled by the dependencies.yaml file?
Yes, that's possible and I think that's the idea behind Tuukka's proposal.
- but I also presume
qt5.dev<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feu-west-1.protection.sophos.com%2F%3Fd%3Dqt5.dev%26u%3DaHR0cDovL3&data=05%7C02%7Cvolker.hilsheimer%40qt.io%7C07023329f2404b6ccc8a08dc57d70575%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638481828233392163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=YdFc5cM4%2BsbSfcGoaf0%2BUjfgqGgOrb8zdNnn9l%2Bmyz8%3D&reserved=0<https://eu-west-1.protection.sophos.com/?d=qt5.dev&u=aHR0cDovL3>
F0NS5
kZXY=&i=NjM4Nzc2ODAyOGY1OWYxM2ViNDUzNjg5&t=VWRDN3o4cjMrZGdjVHoxSW9pbm9
2Qnl6S
2VPYWM0TUhvR1M0VEdUTVI0TT0=&h=6732fc908e63417581806659df247f02&s=AVNPU
EhUT0N
FTkNSWVBUSVaM5lEqADF9ZMzPJ0-3rStdp8yX-Ec4ffDBndxFeZ7rI9MnQT0x7fMSrum7p
TwOihA
integration will no longer affect qt3d? ie there will no
automated checked that
qt3d continues to build against the rest qt when that changes and
the
dependencies.yaml won't be
updated automatically?
Not necessarily, we can add qt3d in the dependency update round as
extra module if we want to do so. That way qtd3 would be checked
pretty much like it is done today. The difference is that it won't
block the dependency update round, release etc and won't be part of qt
release (binary packages, src packages, git tags etc)
- no more automatic branching?
If we want to keep automatic branching we can still enable it.
- so how does versioning work? Would it be up to maintainer to decide
when to
do branches, tags, releases?
If we remove qt3d from release configuration we don't add tags or
include it in the release packages. If maintainer wants to "release"
new version from qt3d I think it is possible but it shouldn't follow
qt releasing schema etc. But what release means in this context? Git
tag? src packages somewhere? From the releasing point of view I would
not like to see that we remove qt3d from the official release
configurations but then start releasing qt3d as its own release; it would just increase our workload...
And what would be a good strategy for that?
- module life cycle in general needs to be defined.
And what does "removing qt3d from release configuration" mean for
users/developers?
- no longer in the installer, or tarballs?
True
- probably no longer in linux distributions?
- do ABI/API compatibility rules still apply?
- for new projects, no more C++ 3D scene graph API, and no more LGPL
licensed
module to do 3d.
At least not bundled with Qt?
- only way to get the code would be to check it out and build it?
I think this is the way to go.
br,
Jani
- given qt3d is a proper qt module (as opposed to a simple library),
including qml
(and it's own) plugins, and
that it was up to now installed along the rest of Qt, how much work
will it be for
existing users to change
their build to continue getting new versions of Qt3D?
- and finally, how do we warn users of the upcoming change?
While I have no problems with the aim of this, we need to figure out
the
important details first before
pulling the trigger.
Mike
On 27 Mar 2024, at 08:39, Tuukka Turunen
<tuukka.turunen at qt.io<mailto:tuukka.turunen at qt.io>><mailto:tuukka.turunen at qt.io> wrote:
Hi,
We have been discussing with KDAB about the future maintenance of Qt
3D
module. It is a quite large and complex module, which has for most use
cases by
now been superseded by Qt Quick 3D. Since Qt 3D has been available for
a long
time, it should continue to be available for those who still need it.
It is also part of
all currently supported releases, which would continue to have it in
upcoming
patch level releases.
After discussing with KDAB (maintainer of Qt 3D) on how to proceed,
we came
up with the following and also agreed that I'll summarize it for the
Qt project
development list:
* Qt 3D module is removed from official release configuration in
the dev
branch, i.e. no longer part of the releases from Qt 6.8 onwards
* Qt 3D continues to be part of Qt project, it continues to be
covered by CI,
and available in the repository for those who want to use it
* Even though not part of the release configuration, intention is
to keep Qt 3D
working also with Qt 6.8
* Qt 6.7 and older releases continue to have Qt 3D module in the
upcoming
patch releases
Qt 3D module was initially developed for Qt 4 and then received a
major
overhaul for Qt 5. It was also brought forward to Qt 6. Initially the
idea was to
offer Qt 3D as a separate item in Qt 6.0 via package manage
(https://wiki.qt.io/Qt_6.0.0_Modules<http://wiki.qt.io/Qt_6.0.0_Modules><https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feu-west-1.protection.soph%2F&data=05%7C02%7Cvolker.hilsheimer%40qt.io%7C07023329f2404b6ccc8a08dc57d70575%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638481828233411474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ScWOaU6fpCHIsTw%2FIZcnDh6cwgbuasBgHw2EBJU4gL8%3D&reserved=0<https://eu-west-1.protection.soph/>
os.com<http://os.com/>
?d=qt.io<http://qt.io/>&u=aHR0cHM6Ly93aWtpLnF0LmlvL1F0XzYuMC4wX01vZHVsZXM=&i=NjM4Nzc2
ODAyOG
Y1OWYxM2ViNDUzNjg5&t=N3BqZ2swQVpjV2JCdFJ0aHk4SXZRTE9HTjJkdnF0SFpiQW9lb
ENJZ3h
4QT0=&h=6732fc908e63417581806659df247f02&s=AVNPUEhUT0NFTkNSWVBUSVaM5lE
qADF9Z
MzPJ0-3rStdp8yX-Ec4ffDBndxFeZ7rI9MnQT0x7fMSrum7pTwOihA>), but since we
MzPJ0-3rStdp8yX-Ec4ffDBndxFeZ7rI9MnQT0x7fMSrum7pTwOihA>were
not able to make this
modularity successful, it was included to the release configuration
along with the
other add-on modules. Qt Quick 3D is a later addition to Qt,
originating from the
contribution from NVIDIA
(https://www.qt.io/blog/2017/02/20/introducing-qt<http://www.qt.io/blog/2017/02/20/introducing-qt><https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feu-west-1.pr%2F&data=05%7C02%7Cvolker.hilsheimer%40qt.io%7C07023329f2404b6ccc8a08dc57d70575%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638481828233426277%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AZhTKtkKi7zo1TLnAyQbBjl7PbQKxzJQ2HOCgHBOenA%3D&reserved=0<https://eu-west-1.pr/>
otect
ion.sophos.com<http://ion.sophos.com/>?d=qt.io<http://qt.io/>&u=aHR0cHM6Ly93d3cucXQuaW8vYmxvZy8yMDE3LzAyLzIwL
2ludHJ
vZHVjaW5nLXF0&i=NjM4Nzc2ODAyOGY1OWYxM2ViNDUzNjg5&t=NU9XZ1p1dndDeForMXN
keGV1c
kNSQldZVzNoaklGUjE2NFpJeGhKRGhhST0=&h=6732fc908e63417581806659df247f02
&s=AVN
PUEhUT0NFTkNSWVBUSVaM5lEqADF9ZMzPJ0-3rStdp8yX-Ec4ffDBndxFeZ7rI9MnQT0x7
fMSrum
7pTwOihA>-
3d-studio), initially as a separate runtime, then refactored into Qt
Quick 3D for Qt
5 to achieve better alignment with Qt Quick 2D and after that
completely
reworked to be fully aligned with Qt Quick in Qt 6.
Yours,
Tuukka
-
Mike Krus | mike.krus at kdab.com<mailto:mike.krus at kdab.com><mailto:mike.krus at kdab.com> | Senior
Software Engineer & Teamlead
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44 1625 809908 Mobile +44 7833 491941
KDAB - The Qt Experts, C++, OpenGL Experts
--
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org><mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development<http://lists.qt-project.org/listinfo/development><https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feu-west-1.pr%2F&data=05%7C02%7Cvolker.hilsheimer%40qt.io%7C07023329f2404b6ccc8a08dc57d70575%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638481828233439961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FuB5DF7wn7zjAeltzgtJAFbe%2B0eqWEt3Cmhce%2FaLt%2Bo%3D&reserved=0<https://eu-west-1.pr/>
otecti
on.sophos.com<http://on.sophos.com/>?d=qt-project.org<http://qt-project.org/>&u=aHR0cHM6Ly9saXN0cy5xdC1wcm9qZWN0Lm9yZ
y9saXN
0aW5mby9kZXZlbG9wbWVudA==&i=NjM4Nzc2ODAyOGY1OWYxM2ViNDUzNjg5&t=SWQ3T0V
EbVFBd
FFicUVYM0FVODZXQjAvQ244SWQvdm5vRy9yV01Sb1Z4QT0=&h=6732fc908e6341758180
6659df
247f02&s=AVNPUEhUT0NFTkNSWVBUSVaM5lEqADF9ZMzPJ0-3rStdp8yX-Ec4ffDBndxFe
Z7rI9M
nQT0x7fMSrum7pTwOihA>
--
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org><mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development<http://lists.qt-project.org/listinfo/development><https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feu-west-1.pr%2F&data=05%7C02%7Cvolker.hilsheimer%40qt.io%7C07023329f2404b6ccc8a08dc57d70575%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638481828233452181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2BT4mc3FynUJxwhhCqiMROwmTA5I2z%2BV7IsDPcPaMZIs%3D&reserved=0<https://eu-west-1.pr/>
otecti
on.sophos.com?d=qt-project.org&u=aHR0cHM6Ly9saXN0cy5xdC1wcm9qZWN0Lm9yZ
y9saXN
0aW5mby9kZXZlbG9wbWVudA==&i=NjM4Nzc2ODAyOGY1OWYxM2ViNDUzNjg5&t=SWQ3T0V
EbVFBd
FFicUVYM0FVODZXQjAvQ244SWQvdm5vRy9yV01Sb1Z4QT0=&h=6732fc908e6341758180
6659df
247f02&s=AVNPUEhUT0NFTkNSWVBUSVaM5lEqADF9ZMzPJ0-3rStdp8yX-Ec4ffDBndxFe
Z7rI9M
nQT0x7fMSrum7pTwOihA>
--
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
--
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240408/90b965cc/attachment-0001.htm>
More information about the Development
mailing list