[Qgis-developer] new_vector_api merged

[Matthias Kuhn]

Hi Martin,

Nice too see this changes merged.

A minor question, regarding the discussion about the cache we had 
already. Would it be ok for you to rename QgsVectorLayerCache to e.g. 
QgsGeometryCache? I think this would more precisely reflect the purpose 
of your implementation and keep the rather bold name QgsVectorLayerCache 
free for a more generic approach.

Regards,
Matthias

On 01/26/2013 07:48 PM, Martin Dobias wrote:
> 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