[Qgis-developer] Merging of incompatible changes

[Marco Hugentobler]

Hi Martin

In your changes, are there also other api-breaking things besides the 
Python changes ( related to 1) enable introduction of threading )?

Regards,
Marco

On 22.10.2012 21:17, Martin Dobias wrote:
> 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
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee