Hi all,
I'm happy to inform you that Phil (main PyQt maintainer) just announced
that QtXml is going to be reincluded in the PyQt5 bindings.
You may therefore happily continue to use QDomDocument and friends as
much as you like and ignore my original request.
Sorry for the noise
Matthias
On
Hi Régis,
On 12/04/2014 05:18 PM, Régis Haubourg wrote:
Slowness is painfull also on project save, and I guess this is mainly the xml
issue there.
I'm with Marco there. On project save there is also a lot of code
involved apart from XML and to attribute performance responsibility we
need good
Hi Matthias,
On Wed, 03. Dec 2014 at 16:46:11 +0100, Matthias Kuhn wrote:
I didn't look at it in detail and just based this recommendation on the
one from the QtXml documentation linked at the end of the original message.
Is there something in particular you think we will be missing? If so, it
On 4 December 2014 at 19:25, Jürgen E. j...@norbit.de wrote:
Hi Matthias,
On Wed, 03. Dec 2014 at 16:46:11 +0100, Matthias Kuhn wrote:
I didn't look at it in detail and just based this recommendation on the
one from the QtXml documentation linked at the end of the original message.
Is there
Thank you Jürgen and Nyall,
On 04.12.2014 09:44, Nyall Dawson wrote:
On 4 December 2014 at 19:25, Jürgen E. j...@norbit.de wrote:
We could just keep using it and fork it if need be. Any idea why it was
discontinued?
This link [1] suggests that it hasn't been discontinued, it's just
QtXml is really, damn slow. PyQt with QtXml is worst then lxml, just to
make a comparison. Switching to a streamlined xml parser would be
advisable, but I know it would a deep refactoring for a lot of QGIS's code.
Maybe it should be considered within the next big refactorings (geometry,
composer,
On Thu, Dec 4, 2014 at 10:04 AM, G. Allegri gioha...@gmail.com wrote:
QtXml is really, damn slow. PyQt with QtXml is worst then lxml, just to make
a comparison. Switching to a streamlined xml parser would be advisable, but
I know it would a deep refactoring for a lot of QGIS's code.
Maybe it
On 04.12.2014 10:04, G. Allegri wrote:
QtXml is really, damn slow. PyQt with QtXml is worst then lxml, just to
make a comparison. Switching to a streamlined xml parser would be
advisable, but I know it would a deep refactoring for a lot of QGIS's code.
Maybe it should be considered within the
Considering a sponsor: it might be packaged in a proposal of a native
project file format that also supports storing layers.
You could potentially consider using a GeoPackage container as a base for that
:
- http://www.geopackage.org/spec/
- http://www.gdal.org/drv_geopackage.html
It would
Hi,
agreed it's awfully slow on large project save (about 1 min sometimes for
about 200 layers)
+1 for refactoring qgs into a container able to store layers. That would
give us a storing solution for memory layers, discussed previously.
Cheers
Régis
--
View this message in context:
It's also worth noting that QtXml is very
slow, which is noticeable on project load/save.
Is it really the xml parsing which is slow? I would have expected that
xml parsing only is fast and the things QGIS is doing on project load
are slow (e.g. restoring connections, creating print
On Thu, Dec 4, 2014 at 1:44 PM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Is it really the xml parsing which is slow? I would have expected that xml
parsing only is fast and the things QGIS is doing on project load are slow
(e.g. restoring connections, creating print composers,
Slowness is painfull also on project save, and I guess this is mainly the xml
issue there.
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/QtXml-is-no-longer-maintained-in-Qt5-tp5176248p5176498.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
Hi,
As of Qt5, QtXml is no longer actively maintained [1]
PyQt5 does not even support it.
It will be a reasonably big undertaking to migrate any occurrence of
QDomDocument etc. to QXMLStreamWriter and QXMLStreamReader (our whole
project saving and loading engine is based on this). And when we do
Hi Matthias
It will be a reasonably big undertaking to migrate any occurrence of
QDomDocument etc. to QXMLStreamWriter and QXMLStreamReader
From a quick look, it seems QXMLStreamReader is more like a SAX parser.
If so, it is not a full replacement for the DOM classes.
Regards,
Marco
On
Hi Marco,
I didn't look at it in detail and just based this recommendation on the
one from the QtXml documentation linked at the end of the original message.
Is there something in particular you think we will be missing? If so, it
might be good to start looking for alternative ways to go.
16 matches
Mail list logo
