[Qgis-developer] Merging of incompatible changes

Martin Dobias wonder.sk at gmail.com
Mon Oct 22 12:17:20 PDT 2012


Hi all

recently I have been brewing some backwards incompatible API changes
that will 1) enable introduction of threading, 2) simplify API for
developers. I would like to merge the changes soon to master branch in
order not to drift too much from master.

The changes will break lots of plugins, if not all of them... as a
part of the changes I would like to switch PyQt4 to use to QString API
2 and QVariant API 2. Basically that means:
1. all QString instances will be automatically translated to 'unicode'
python type and vice versa.... e.g. layer.name() will return 'unicode'
instead of QString. This removes the headache from distinguishing
between QString and native string api in python plugins. It also
avoids the common error of converting QString to 'str' type which
represents 8-bit strings (Qt equivalent is QByteArray) and so there
should be fewer errors in plugins related to handling of international
characters.
2. QVariant instances from Qt are converted automatically... to get an
attribute of a feature, you would write feature[0] to get 'int'
instead of having to write f[0].toInt()[0] - definitely less clumsy.
Also let me note that the above mentioned API v2 are defaults in PyQt4
for Python3, so once we choose to move from Python v2 to v3 there will
be less porting necessary. For more details please refer to:
http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/incompatible_apis.html

In general this means with these changes we will split everything into
two worlds: 'legacy' (QGIS 1.x release) and 'future' (QGIS 2.x). Until
now you can run all (most) plugins for 1.x also on QGIS from master
branch - but that will definitely change. What I am worried about:
1. plugin repository - is it ready for QGIS 2.0? Is it possible to
keep a plugin in two branches of development: 1.x vs 2.x? Right now
you can distinguish just between stable/development version, right?
Maybe we should create another instance of the repository for plugins
for 2.x to keep them clearly separated?
2. python plugins in QGIS source repository - mainly SEXTANTE - we
will probably need to create a branch to allow continuous development
of the plugins for QGIS v1.x and then port them to master.
3. it will no longer be a good idea to recommend users to use qgis-dev
version because all the cool plugins they have downloaded will break
apart. But that's the cost of incompatible changes, right?

What do you think, any ideas?

Regards
Martin


More information about the Qgis-developer mailing list