[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: QGIS 2.14 & Qt5



Hi Dmitry,

Thanks for the feedback.

On 11-03-16 16:01, Dmitry Shachnev wrote:
> On Sat, Feb 27, 2016 at 05:13:37PM +0100, Sebastiaan Couwenberg wrote:
>> The first build of 2.14 with Qt5 failed due to errors in the
>> spatialite provider ('DetachFromResultSet' is not a member of
>> 'QSqlResult'), this looks like an incompatibility with
>> libqt5sql5(-sqlite).
> 
> That's https://code.qt.io/cgit/qt/qtbase.git/commit/?id=fc15a1d5e2cb064d.
> 
> You may steal the changes to qsql_sqlite.{cpp,h} from that commit and
> apply them to your qsql_spatialite.{cpp,h} files — they are very small.

It looks like that switches to the new Qt5 method losing backwards
compatibility with Qt4. Since QGIS 2.16 will support dual Qt4/Qt5, we
should ifdef that to support both. For Debian we need that too for the
backports which will keep using Qt4 in jessie, otherwise we'll need a
bunch of Qt5 backports.

>> The second build failed due to errors in the globe plugin because
>> it doesn't have /usr/include/x86_64-linux-gnu/qt5/QtOpenGL in its
>> include path for QGLWidget, the Globe plugin has likewise been
>> disabled. The third build failed due to errors in QGIS server because
>> QtNetwork/QFtp is no longer available in Qt5, also disabled for now.
>> These changes allow the build to succeed with Qt5.
> 
> If we package https://code.qt.io/cgit/qt/qtftp.git/, will it help you?

I think it will help.

I've added Matthias Kuhn to the CC who has been doing a lot of Qt5 work
in QGIS upstream. I hope he can give a better answer what they need from
Qt5 packagers.

>> Because packages in unstable will be synced into Ubuntu I don't want a
>> severely feature reduced qgis in Debian unstable just to close the RC
>> bug. I'd rather downgrade the severity to important as long as the new
>> python-qt4 without the Webkit module hasn't been uploaded to unstable.
> 
> Yeah, it's my fault that the new python-qt4 hasn't yet been uploaded.
> But it will be definitely in Stretch (as we want to get qtwebkit removed
> for Stretch).

While I would like to get the new QGIS 2.14 LTR into jessie-backports, I
think we'll have to keep it in unstable only for the time being. We
should be able to switch to Qt5 with QGIS 2.16, expected to be released
24 June 2016.

> Also, Ubuntu is now in a sync freeze, so no autosyncs will happen until
> the 16.04 release.

The xenial release is scheduled for April 21st, so I expect autosyncs to
happen again by the end of April too. There will only be a two month gap
until the QGIS 2.16 release. So if they drop Qt4WebKit at the start of
the cycle, we should be able to get

>> I should probably file bugs for the Qt5 related build failures if they
>> haven't been reported yet.
> 
> If you need any help with Qt 5 porting, please contact me :)

Thanks for the offer, it's much appreciated. I'm very able to help with
the porting effort, but I try to do what I can. I haven't been able to
sit down and look into the Qt5 issues again, but the issue with the
globe plugin may be easy to fix. The CMakeLists.txt already uses
find_package(Qt5OpenGL), but /usr/include/x86_64-linux-gnu/qt5/QtOpenGL
is not added to the include paths. Adding Qt5OpenGL_INCLUDE_DIRS to
include_directories for the plugin may be sufficient.

I hope to find time soon to look into the Qt5 issues more extensively.
Getting the Python bindings to build with Qt5 is most important,
preferably without having to switch to Python 3 at the same time.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: