[Qgis-developer] ASSERT: "smMainNAM" in file qgsnetworkaccessmanager.cpp, line 293

[Richard Duivenvoorde]

On 24-09-16 09:29, Richard Duivenvoorde wrote:

> https://hub.qgis.org/issues/13494#note-19
> 
> Where Martin Dobias says:
> 
> "In general, the QgsApplication API is extremely confusing - and I hope
> we can fix it for QGIS 3.0. It derives from QApplication (IMHO bad
> idea), it also handles init/exit and paths. The init/exit handling
> should be ideally completely automatic with PyQGIS, hopefully avoiding
> different possible ways how people init PyQGIS in the future."
> 
> So I'm also wondering if any work is done in this QGIS 3.0 respect?
> (because I think I hit this complexity now :-) )

Some more head-wall-hitting...

If I understand correct, these two lines:

    qgs = QgsApplication(sys.argv, True)
    qgs.initQgis()

Do both the starting of the QGIS/Qt machinery and the setup of the
authentication/networking system, and this is to be done in the main
thread. That is: you need to be do the right initing before you are able
to use a:

  QgsNetworkAccessManager.instance()

So my plan to create QObject-based dataproviders to be able to start
them in separate threads doing network things via
QgsNetworkAccessManager is not possible, because... to get an instance
of QgsNetworkAccessManager in a separate(!) worker thread you need the
working (inited) QgsApplication there.

BUT you cannot create an instance of it there, because it is not the
main thread :-(

Am I right?

Is there another solution possible to use the QgsNetworkAccessManager to
do data handling in separate threads?

Can I pull the main-thread environment into the worker thread or so?

Side note 1: the reason I want to use QgsNetworkAccessManager instead of
urllib2 or request based networking, is that I was at a 'corporate'
client who was behind a corporate firewall using a
kerberos-username/password authentication. And all plugins using
QgsNetworkAccessManager just worked there... while all(!) others just
fail (because both request and urllib2 do not have kerberos inside??).

But apparently I need help to get both the QgsNetworkAccessManager and a
separate thread working...

Side note 2: this proxy seems also be an issue for GDAL:
https://hub.qgis.org/issues/5212 (old issue...)

I really hope 3.0 will make things easier for users behind firewalls,
maybe by forcing plugin network traffic to use QgsNetworkAccessManager
or so. Because current situation in which plugins do not work because
they use homegrown network code, not taking proxies/usernames into
account, is not a working situation.

Thoughts?

Regards,

Richard