[Qgis-developer] Merging of incompatible changes

[Larry Shaffer]

Hi Martin,

On Mon, Oct 22, 2012 at 1:17 PM, Martin Dobias <wonder.sk at gmail.com> 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.

This sounds excellent. Are those newer APIs going to significantly
increase the base Qt version install requirement (like to 4.7)?

> 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?

If the new APIs are to be used, maybe QGIS master (2.0) can use a
different plugins directory, e.g.

~/.qgis/python/plugins_v2

This would allow any version 2 plugin repository to be loaded into the
installer and work independent of any already installed <=1.8
versions. (Similarly, it might be a good idea to change the app name
for QSettings to ensure two different settings files, as well.) The
plugin installer for master could maybe also show (and note) plugins
from the 1.8 repository, so those plugins could be installed in the
plugins_v2 directory for testing/migration purposes.

Often with major API changes like this, it is very beneficial to offer
a 'sniffing' script that plugin authors can run statically on their
code to log line/column numbers (and maybe line content) for potential
areas of incompatibility. This might help authors move their plugins
to version 2 quicker, assuming such a script can be crafted. Maybe
Phil Thompson has some ideas?

Larry

>
> 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