[Qgis-developer] What will be in QGIS 2.0

[Martin Dobias]

Hi Tim!

On Wed, Jul 11, 2012 at 1:26 PM, Tim Sutton <lists at 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