On Sat, 4 Sept 2021 at 17:56, Richard Duivenvoorde <[email protected]> wrote: > > On 9/4/21 8:45 AM, Ludovic Hirlimann wrote: > > On 9/3/21 00:46, Nyall Dawson wrote: > >> Hi PSC, devs, > >> > >> I'd like to kick start some discussion on how best to handle the > >> situation with upstream Qt and their (lack of) support for Qt 5. As a > >> quick summary of the situation: > >> > >> - Qt Co effectively ended open source support of Qt 5 at the 5.15.2 > >> release, and have moved all focus to Qt 6. > >> - While some preliminary work has been done, QGIS doesn't currently > >> support Qt 6 based builds, and likely won't be ready for this for some > >> time (even completely ignoring all the stable API questions a Qt 6 > >> build raises entirely!) > > > > Wouldn't it be wiser to devote resources to moving to QT6 and do that > > faster than > > > > wait on potential unsuported 5x fixes ? > > That was also my thought, though no clue about the amount of work for it. > > 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. > > 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. > When people have to fiddle with LD_LIBRARY paths, my guess is they will > break... > 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.
I'd never make the KDE fork a requirement for a bulid -- we'd always have to ensure that users can build using the official releases. They'd just potentially suffer from upstream Qt bugs which have since been fixed in the community fork. (And if we do nothing, they'd be in exactly the same situation!!) > 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? See https://github.com/qgis/QGIS-Enhancement-Proposals/issues/198 for my proposal on how we handle this. I'd suggest that (when we're ready) we do a "soft break" and support Qt 6 builds of QGIS 3.x, with the intention of moving the Windows and Mac builds to Qt 6. We don't allow ANY api breaks which aren't directly related to making QGIS qt6 compatible, so that plugins will only have to make very minimal changes (if any) > What is the Qt6 status in Fedora or Suse? Fedora has qt 6.1 packages from Fedora 34 (we use these on the CI to test builds of the core/analysis library on Qt 6). Not sure about SUSE personally. Nyall > > Glad to see Riverbank at least has PyQt6 already.. (and yes I'm aware Qt now > also has bindings itself :-) ) > > Anyway, thanks Nyall for this forward thinking, but ... hard decisions to > make. ... > > May the QGIS Force be with us..., > > Richard Duivenvoorde > > [0] https://tracker.debian.org/pkg/qtbase-opensource-src _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
