[Development] [EXTERNAL EMAIL] Re: Removing Qt 3D from release configuration in dev branch

[Frank Hemer]

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 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>>:
 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>> 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> 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>
> 
> Cc: Qt Project Development
> <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://eu-west-1.protection.sophos.com?d=qt5.dev&u=aHR0cDovL3F0NS5
> kZXY=&i=NjM4Nzc2ODAyOGY1OWYxM2ViNDUzNjg5&t=VWRDN3o4cjMrZGdjVHoxSW9pbm92Qnl6S
> 2VPYWM0TUhvR1M0VEdUTVI0TT0=&h=6732fc908e63417581806659df247f02&s=AVNPUEhUT0N
> FTkNSWVBUSVaM5lEqADF9ZMzPJ0-3rStdp8yX-Ec4ffDBndxFeZ7rI9MnQT0x7fMSrum7pTwOihA
> > 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> 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<https://eu-west-1.protection.sophos.com
> ?d=qt.io&u=aHR0cHM6Ly93aWtpLnF0LmlvL1F0XzYuMC4wX01vZHVsZXM=&i=NjM4Nzc2ODAyOG
> Y1OWYxM2ViNDUzNjg5&t=N3BqZ2swQVpjV2JCdFJ0aHk4SXZRTE9HTjJkdnF0SFpiQW9lbENJZ3h
> 4QT0=&h=6732fc908e63417581806659df247f02&s=AVNPUEhUT0NFTkNSWVBUSVaM5lEqADF9Z
> MzPJ0-3rStdp8yX-Ec4ffDBndxFeZ7rI9MnQT0x7fMSrum7pTwOihA>), but since we 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<https://eu-west-1.protect
> ion.sophos.com?d=qt.io&u=aHR0cHM6Ly93d3cucXQuaW8vYmxvZy8yMDE3LzAyLzIwL2ludHJ
> vZHVjaW5nLXF0&i=NjM4Nzc2ODAyOGY1OWYxM2ViNDUzNjg5&t=NU9XZ1p1dndDeForMXNkeGV1c
> kNSQldZVzNoaklGUjE2NFpJeGhKRGhhST0=&h=6732fc908e63417581806659df247f02&s=AVN
> PUEhUT0NFTkNSWVBUSVaM5lEqADF9ZMzPJ0-3rStdp8yX-Ec4ffDBndxFeZ7rI9MnQT0x7fMSrum
> 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> | 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>
> 
> https://lists.qt-project.org/listinfo/development<https://eu-west-1.protecti
> on.sophos.com?d=qt-project.org&u=aHR0cHM6Ly9saXN0cy5xdC1wcm9qZWN0Lm9yZy9saXN
> 0aW5mby9kZXZlbG9wbWVudA==&i=NjM4Nzc2ODAyOGY1OWYxM2ViNDUzNjg5&t=SWQ3T0VEbVFBd
> FFicUVYM0FVODZXQjAvQ244SWQvdm5vRy9yV01Sb1Z4QT0=&h=6732fc908e63417581806659df
> 247f02&s=AVNPUEhUT0NFTkNSWVBUSVaM5lEqADF9ZMzPJ0-3rStdp8yX-Ec4ffDBndxFeZ7rI9M
> nQT0x7fMSrum7pTwOihA>
 --
> Development mailing list
> Development at qt-project.org<mailto:Development at qt-project.org>
> https://lists.qt-project.org/listinfo/development<https://eu-west-1.protecti
> on.sophos.com?d=qt-project.org&u=aHR0cHM6Ly9saXN0cy5xdC1wcm9qZWN0Lm9yZy9saXN
> 0aW5mby9kZXZlbG9wbWVudA==&i=NjM4Nzc2ODAyOGY1OWYxM2ViNDUzNjg5&t=SWQ3T0VEbVFBd
> FFicUVYM0FVODZXQjAvQ244SWQvdm5vRy9yV01Sb1Z4QT0=&h=6732fc908e63417581806659df
> 247f02&s=AVNPUEhUT0NFTkNSWVBUSVaM5lEqADF9ZMzPJ0-3rStdp8yX-Ec4ffDBndxFeZ7rI9M
> nQT0x7fMSrum7pTwOihA>