[Qgis-developer] new_vector_api merged

[Borys Jurgiel]

Big thanks for all that job!

Is there any short document for plugin authors, describing which methods 
should be replaced? The [1] doesn't contain any word about select(),
nextFeature() nor featureAtId() yet. I remember you post some information last 
weeks.

[1] http://hub.qgis.org/wiki/quantum-gis/API_changes_for_version_20


Dnia sobota, 26 stycznia 2013 o 19:48:41 Martin Dobias napisał(a):
> Hi everyone
> 
> I'm pleased to announce that new_vector_api branch has been merged to
> master. From user's point of view there should be ideally no change -
> everything should work as before, except for various plugins that will
> need update to support new API. With such extent of refactoring of
> vector layer code it is possible that some new bugs have been
> introduced - I hope there won't be any serious problems. I would like
> to ask people to test master branch with various data providers and
> report any regressions related to vector handling (e.g. access to
> data, editing or joins).
> 
> I have also created a tag "Before-merge-new_vector_api" that points to
> the last commit on master before the merge - in case someone would
> like to stick with pre-merge code for some reason.
> 
> What's next?
> osm, mssql and sqlanywhere providers are currently disabled - but they
> should be adapted to new API and re-enabled soon by their respective
> authors. QgsVectorLayer still has old API methods (select(),
> nextFeature() and featureAtId()). There are more than a hundred of
> these call just in QGIS code base. I have marked them as deprecated
> now - we should slowly get rid of them and finally remove them before
> 2.0.
> 
> Of course the most awaited feature is the threaded rendering -
> experimental support should be coming in the following months, so
> please stay tuned.
> 
> One of the next steps will be already mentioned move to newer sip/PyQt
> APIs for common classes like QString and QVariant that will simplify
> plugins' code and make them more ready for python3 (where the new APIs
> will be default). I would also like to look into support of python3,
> so that ideally QGIS 2.0 could be built either with python2 or
> python3. I expect that QGIS 2.0 will stick to python2 and QGIS 3.0
> will use python3.
> 
> Looking forward to the feedback from testing!
> 
> Regards
> Martin
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer