<div dir="ltr">Hi, <div><br></div><div>as for macOS at the moment, I install pre-build Qt binaries and use them. I suppose I can build and use whichever version from whichever fork if we decide to do so, but I have never needed to use my custom Qt build so it would take some time to compile.</div><div><br></div><div>as for Qt and their (lack of) open-source support for 5.15, I am wondering if they want to force open-source projects to use a commercial Qt package for distribution?</div><div><br></div><div>P.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 6, 2021 at 1:06 AM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Sat, 4 Sept 2021 at 17:56, Richard Duivenvoorde <<a href="mailto:rdmailings@duif.net" target="_blank">rdmailings@duif.net</a>> wrote:<br>
><br>
> On 9/4/21 8:45 AM, Ludovic Hirlimann wrote:<br>
> > On 9/3/21 00:46, Nyall Dawson wrote:<br>
> >> Hi PSC, devs,<br>
> >><br>
> >> I'd like to kick start some discussion on how best to handle the<br>
> >> situation with upstream Qt and their (lack of) support for Qt 5. As a<br>
> >> quick summary of the situation:<br>
> >><br>
> >> - Qt Co effectively ended open source support of Qt 5 at the 5.15.2<br>
> >> release, and have moved all focus to Qt 6.<br>
> >> - While some preliminary work has been done, QGIS doesn't currently<br>
> >> support Qt 6 based builds, and likely won't be ready for this for some<br>
> >> time (even completely ignoring all the stable API questions a Qt 6<br>
> >> build raises entirely!)<br>
> ><br>
> > Wouldn't it be wiser to devote resources to moving to QT6 and do that faster than<br>
> ><br>
> > wait on potential unsuported 5x fixes ?<br>
><br>
> That was also my thought, though no clue about the amount of work for it.<br>
><br>
> But my argument against deciding to use a patched/forked qt5 would be that (UNLESS all our development platforms could more or less easily/package/use it), it could potentially break our (little?) "I'm not a core dev, but I compile QGIS myself" group.<br>
><br>
> My experience (with Linux users at least), is that with some guidance the average Debian/Ubuntu user is able to compile/run QGIS itself, IF all dependencies are taken care of by the distro's.<br>
> When people have to fiddle with LD_LIBRARY paths, my guess is they will break...<br>
> Off course that is 'my bubble', and I'm not even sure about the size of the group, and if they/we are helpful at all etc etc.<br>
<br>
I'd never make the KDE fork a requirement for a bulid -- we'd always<br>
have to ensure that users can build using the official releases.<br>
They'd just potentially suffer from upstream Qt bugs which have since<br>
been fixed in the community fork. (And if we do nothing, they'd be in<br>
exactly the same situation!!)<br>
<br>
> Maybe it's time for another 'big gap' in QGIS releases? As in: after 3.22 (LTR) there will be a probably not so stable 4.0 which will have a thorough api cleanup (first), while maybe partially trying to do some pre-work for Qt6? And so hopefully we will have Qt6 packaged more easily at that time?<br>
<br>
See <a href="https://github.com/qgis/QGIS-Enhancement-Proposals/issues/198" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/issues/198</a> for<br>
my proposal on how we handle this. I'd suggest that (when we're ready)<br>
we do a "soft break" and support Qt 6 builds of QGIS 3.x, with the<br>
intention of moving the Windows and Mac builds to Qt 6. We don't allow<br>
ANY api breaks which aren't directly related to making QGIS qt6<br>
compatible, so that plugins will only have to make very minimal<br>
changes (if any)<br>
<br>
> What is the Qt6 status in Fedora or Suse?<br>
<br>
Fedora has qt 6.1 packages from Fedora 34 (we use these on the CI to<br>
test builds of the core/analysis library on Qt 6). Not sure about SUSE<br>
personally.<br>
<br>
Nyall<br>
<br>
<br>
><br>
> Glad to see Riverbank at least has PyQt6 already.. (and yes I'm aware Qt now also has bindings itself :-) )<br>
><br>
> Anyway, thanks Nyall for this forward thinking, but ... hard decisions to make. ...<br>
><br>
> May the QGIS Force be with us...,<br>
><br>
> Richard Duivenvoorde<br>
><br>
> [0] <a href="https://tracker.debian.org/pkg/qtbase-opensource-src" rel="noreferrer" target="_blank">https://tracker.debian.org/pkg/qtbase-opensource-src</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>