[Qgis-developer] organizing plugins

[Martin Dobias]

On Wed, Apr 28, 2010 at 4:34 PM, Andreas Neumann <a.neumann at carto.net> wrote:
> Micha,
>
> I don't fully agree with you. I think at least one third of the plugins
> should be moved into the core. Don't you think that a standard GIS should
> offer:
>
> * advanced labelling
> * file format conversions
> * geoprocessing
> * raster operations (resampling, merging, reclassification, etc.)
> * importing text files
> * simple CAD functionality
> * georeferencing
> * dxf reading/conversion
> * WFS support
> * GPS support
> * simple DEM calculations (aspect, slope, shading, curvature, etc.)

I agree with you that this (and other) functionality should be
available out of the box and requiring users to search for and enable
specific plugins for that functionality is not so user friendly.

Speaking for myself, I've planned to integrate advanced labeling into
core from day 1, I just don't want to do it until it has all features
and the old labeling code could be removed.

I think several plugins could be integrated into directly qgis
application. When thinking about integration of a plugin, the
following points should be considered:
1. language - if the plugin is in C++, the entry barrier is low and it
can be included easily. With python plugins, it's a bit different as
they should be rewritten into C++. However, I've started to play with
the idea that QGIS application could consist of mixture of C++ and
Python code, so the functionality that doesn't do heavy computation
could stay in Python. The advantages I see here is that potentially
new developers could start contributing to QGIS application and new
features/bugfixes could be done rapidly. I believe the plugin
installer from Borys and Carson's fTools are the obvious first
candidates for the mixed C++/Python approach.

2. consistency - a general problem with plugins is that their user
interface varies a lot since they're produced by various developers.
There is a number of plugins that do some kind of processing of data
and their needs are very similar - in a dialog, select input and
output layer(s), set few options and let it do the computation. The
plugin should ideally just provide a set of input values it needs and
GUI should be generated automatically in QGIS (as happens within
toolbox in grass plugin). Again, fTools is a good candidate for using
such unified dialogs for processing tools.

3. dependencies - some plugins have some special dependencies -
processing, plotting or other libraries. What do to with them?

4. maintenance - ideally, all functionality should have a maintainer
willing to fix the issues.

Regards
Martin