On Fri, 10 Apr 2020 at 06:45, Even Rouault <[email protected]> wrote:
> But whatever the outcome of the apparently cool discussions within the board > of the KDE Free Qt foundation between the KDE e.v and QT Company > representatives, I don't think a statement of support from QGIS.org to the > open source side of the QT project would hurt. +1 to this. I've already had one customer contact me concerned about this news, and wondering what it meant for QGIS. A blog post showing our support for the open-source/KDE side of Qt + stating the impact on QGIS would be helpful all round I think. My 2c (regarding the impact on QGIS, if this went ahead): Honestly, it's likely to be minimal. Because: 1. Qt Company really do very little maintenance on the parts of Qt the QGIS desktop/server applications use. The changelogs for the core/gui/widget libraries for new Qt releases + patches are very minimal, and bug reports filed against these components get basically no attention from Qt Company. Their priorities over the recent years have been elsewhere (in the embedded + automotive + mobile space), and all the interesting changes coming into core/gui/widgets are coming from elsewhere (e.g. KDAB were/are behind the whole qt 3d framework, and they've already stated that they'd follow a community driven fork [1]) 2. Despite one initial reply on the KDE list stating that there's insufficient manpower to support a community fork [2], the rest of the discussion on the qt mailing list is quite positive about the community's ability to maintain a fork 3. A community fork would likely end up being great for Qt (my opinion). It certainly had a huge positive impact on OpenOffice/LibreOffice. Qt is currently REALLY difficult for new contributors to contribute to, so it's possible a community driven fork with more of a collaborative focus would see a bunch of new contributors coming in. Certainly the talk on the Qt mailing lists over the last 1-2 years has shown a huge amount of dissatisfaction with the leadership and direction taken by the Qt Company, and complaints about how out of touch they are with their user's needs. 4. Our releases are generally quite slow to adopt new Qt library versions anyway, so a 12 month delay from a new release is likely to have minimal impact (e.g. our Windows builds are based on a version of qt which is nearly 2 years old). It'd be nice if we updated more often, but the current situation is reflective of the fact that there's no particular compelling reasons to upgrade to a more recent Qt version! Let me rephrase that for emphasis: **in the last 2 years, there hasn't been ANY change made in Qt which would have had big enough impact on QGIS users to warrant the effort required for the package update**. (Compare that with how far QGIS has come in the same time frame... I certainly wouldn't recommend that ANYONE even THINK of running QGIS 3.2 today!!!) The biggest impact it would have would be on the Qfield and Input mobile apps, which rely heavily on QML. Qt company **is** actively working on QML, and these updates are useful -- partly because QML still has huge feature gaps preventing it being used as a real alternative to Qt widgets, and partly because it's still buggy and they are still fixing their messes ;). Nyall 1. https://mail.kde.org/pipermail/kde-community/2020q2/006105.html 2. https://mail.kde.org/pipermail/kde-community/2020q2/006099.html > http://www.spatialys.com > > _______________________________________________ > Qgis-psc mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/qgis-psc _______________________________________________ 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
