Hi Tim! On Wed, Jul 11, 2012 at 1:26 PM, Tim Sutton <li...@linfiniti.com> wrote: > - Threading branch and threaded data provider refactor (a long time > ago in GSOC project far away Martin Dobias got much of the ground work > in place but the delta between his branch and master is huge now)
This is something that has been pursuing me for ages. Porting that stuff (sometimes essentially re-doing that) is quite a great task. In recent months I have not be able to allocate enough free time to do it - I have to come up with a plan how to proceed... Refactoring the access to layer data should be really done before 2.0, otherwise we will have to stay with what we have for further years. > - Raster refactor to use new renderer architecture, native WCS > support, pipelines, 'save as' support and more (this work is being > funded by the World Bank and will be available in master over the next > 3 months) Great! > - GSOC project for symbology UI redesign / improvements (how is this > work going?) As Nathan commented, the work is going well and I hope that soon we may be able to pull some nice features to master branch (once we are confident with their stability). > In terms of decrufting, it would be good to remove all the duplicated items: > > - twin labelling systems In general this means that old labeling will be disabled and new labeling dialog will be embedded in that tab of vector layer properties. > - twin symbology systems The old symbology can be slowly wiped out - in the first step we would remove the switch to/from old system (and always force new symbology), in the second step the old classes may be removed from code base one by one. > - too many toolbars / icons by default I'm quite keen to see this happening - one row of icons as a maximum in the default install... > Are there any other things that folks would like to add to the > discussion for the roadmap for version 2.0? As Alex noted, we will switch to PyQt API v2, that will be a small change code-wise, but with a great impact on plugins. That will mean that PyQt (and PyQGIS) modules will return 'unicode' type where QString should be returned, or directly the encapsulated value will be returned when QVariant should be returned. Since these classes are used all over the place, there will be a need to update plugins - but I guess the developers will like the newer, more pythonic API since it does not require them to do casts between Qt/Python representations of the same thing. Then there would be deprecation of metadata in __init__.py for plugins, but that's also nearly zero work. Apart from that, I am still dreaming of a separation of providers classes into 1.data source and 2.provider classes, in a similar way how e.g. GDAL/OGR works. This would bring us various advantages - easier sharing of connections to databases, good API for querying and management of layers etc. But that's probably a task for v3.0 :-) Martin _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
