On Wed, Aug 7, 2024 at 8:17 PM Milian Wolff <m...@milianw.de> wrote:
> On Dienstag, 6. August 2024 12:58:29 MESZ Halla Rempt wrote: > > On dinsdag 6 augustus 2024 12:46:58 CEST Volker Krause wrote: > > > On Montag, 5. August 2024 16:15:19 CEST Halla Rempt wrote: > > > > I seem to remember that there were KDE apps that could be built with > > > > both Qt6/Kf6 and Qt5/Kf5. Did I remember that right? And if so, is > there > > > > some howto or documentation for that? > > > > > > Right, that was the approach taken by many Frameworks, Plasma and Gear > > > modules. > > > > > > I'm not familiar enough with Krita's code to judge whether any of that > is > > > applicable, but here's roughly what we did there: > > > > > > (1) Require Qt 5.15 and a recent KF5, and port away from deprecated > API. > > > > > > In many cases that already was the bulk of the code changes, and it's > also > > > what supported the direct Kate port Christoph mentioned for example. > > > > Good, that's sorted, I just finished that part. Except for QLinkedList, > > because QList isn't a working replacement for that. > > QLinkedList is available in Qt6 core5compat: > https://doc.qt.io/qt-6/qlinkedlist.html > > <snip> > > > > (3) A large chunk of the remaining changes for making things build > with Qt > > > 6 can still be done without ifdefs (missing includes etc), but you wont > > > be able to avoid them entirely. Similar for conditional code in the > build > > > system. Without (1) this can get significantly more painful though. > > > > > > (4) As soon as the Qt 6 version is ready, drop Qt 5 support by removing > > > conditional code and replacing ${QT_MAJOR_VERSION} with "6" in the > build > > > system. We got to this point in early 2024. > > We recently ported KDevelop over to Qt6 and ran into issues with the > gitlab > configuration - branches must not contain more than a hundred patches, > which > you can easily end up with while porting larger applications. > > We ran into this, as we did _not_ want to try and support Qt5 and Qt6 > simultaneously. Since you want to do that, I can only recommend you to get > your porting patches into master incrementally, in smaller batches. > Otherwise > you will need to start gaming the system and workarounding the artificial > gitlab patch limitations. > For the record, this isn't a Gitlab limitation - it is an intentional decision of how our Git hooks work, and the policy around how notifications are sent. It is generally bad practice to have long running non-merged work like KDevelop and Krita have done. If you do need to do this, then it is suggested you draft the work in a personal fork repository and then submit the relevant pieces of work in the relevant chunks for merging. > > > That's going to take quite a bit of time for us, since we really needed a > > lot of patches to Qt itself to make things like HDR work. > > Are those patches not upstreamed to Qt6? > > > > This worked ok for C++ code I think, the Qt 5 code remained releasable > for > > > the entire time. A few regressions got in during the process, but also > a > > > few version-independent issues got found by stricter compile-time > checks > > > on e.g. implicit conversions in Qt 6. > > > > > > Supporting two major versions at the same time tends to get > increasingly > > > painful over time though, so I can only recommend to see this as > > > "scaffolding" for a transient phase that shouldn't be longer than > > > absolutely necessary. Apart from a few special exceptions (e.g. style > > > plugins) we also didn't release anything officially supporting both > > > versions. > > > > The most important part of our releases are our binaries, and those will > be > > Qt5 until we can be sure everything works. That's going to be pain! > > > > > What didn't work was anything involving larger amounts of QML code. > There > > > were a few attempts to support both versions as well with various > levels > > > of dirty hacks, but nothing that ended up being widely used. > > > > That is a very useful warning. We've just started using QML more in > places > > like the text tool's font properties. > > I agree with Volker. Compared to the past, porting QtWidgets applications > from > Qt5 to Qt6 is trivial. I fear you krita folks will have more trouble due > to > the low level graphics work you are doing, but I hope that the bulk of the > effort is going to be trivial. Definitely start with porting everything to > the > latest Qt 5.15 and fix deprecation warnings, then take it from there. > > Good luck! > > -- > Milian Wolff > m...@milianw.de > http://milianw.de Cheers, Ben
