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