[Qgis-developer] Merge of refactoring branch

[Martin Dobias]

Hi devs,

today I've ported all commits from trunk to Lib-refactoring branch, so
it gets ready to be merged back to SVN. I'd like to ask you if you
won't mind to merge it tomorrow.

Notes regarding the status of the branch:

= Build system =

To build it, you will need CMake (version 2.4 or preferably later). It
has been tested and builds and runs well under Linux and Windows. I
have no access to Mac, so I couldn't test there. I'm all for using
CMake as the only make system as it's universal, flexible and easy to
understand.

Thus I also suggest removing autotools and qmake files as they are not
needed anymore and might confuse people. As not much people know CMake
so far, we could make a wrapper 'configure' script that will help
users with the transition.

= API Changes =

Nearly all work in the branch has been focused on improving QGIS API.
I'm not going to list all changes here (as the list is quite long),
they're briefly listed this wiki page:
http://wiki.qgis.org/qgiswiki/Splitting_Into_Libraries
(gives also introduction how to build with CMake)

= New features =

Probably the only new features are addition of Python bindings,
support for Python plugins and addition of spatial index to QGIS API
(not yet used by providers).

= Stability =

This branch has in comparison with trunk some additional bugs, some of
them I'm aware (just didn't have time to fix them so far) and for sure
there are new problems caused by the great amount of changes. There
are some bugs related to removing very tight connections between map
layers, legend, attribute table and map canvas.

Recently we've discussed development cycle for QGIS. The conclusion
was: let's develop new features in branch and merge once it's stable.
I must say that this merge will violate this rule a bit. The reason of
merging now is that maintaining this branch is quite time-consuming
due many API changes. This branch lives many months already and has
been receiving from trunk mostly bugfixes - porting new features would
be absolute time killer.

= Future =

Refactoring of QGIS API is by no means complete for me, but the
biggest changes have been done already. It would be great if we
improved the API further - because also adding new features and
bugfixing will be easier. Here are the places where I see much
potential for improving:
- raster layers support - QgsRasterLayer should be definitely
refactored and we should develop good raster data provider interface
- vector layers support - splitting QgsVectorLayer to presentation and
data class, filtering, caching and indexing for data providers,
support for variant types in attributes, manipulation with geometries

I'd like to see 0.9 version as release with polished API rather than
with many new features. In my opinion QGIS code base is getting bigger
and bigger - without maintenance of old code will be adding new
features a nightmare instead of fun.


Please share your opinions :-)
Thus if noone objects I'll proceed with the merge.

A rather technical question: in IRC logs I've seen a mention of a
utility called svnmerge.py - I'm wondering whether it could be helpful
with such a great merge... any ideas what are the benefits to using
just "svn merge" ?

Regards,
Martin