[Qgis-developer] Merging of incompatible changes

[Andreas Neumann]

 Hi,

 For me it is ok to go ahead and break the API. That was our goal for 
 version 2.0.

 But perhaps we can especially mark the version before those big changes 
 in github and create a parallel version in OSGeo4W that still works. I 
 don't ask to work on two versions in parallel, just to keep a working 
 version around for those who already work with master and want to 
 continue using their improvements and plugins.

 Jürgen, can we organize a "frozen" parallel version in OSGeo4W before 
 the big breaks? We can remove it again, once the situation gets 
 stabilized in master.

 Andreas

 On Mon, 22 Oct 2012 21:17:20 +0200, 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

-- 
 --
 Andreas Neumann
 Böschacherstrasse 10A
 8624 Grüt (Gossau ZH)
 Switzerland