[GRASS5] QGIS + GRASS

[Bernhard Reiter]

On Fri, Jul 04, 2003 at 02:02:36PM +0100, Paul Kelly wrote:
> 
> On Tue, 24 Jun 2003, Radim Blazek wrote:
> > I have written GRASS extension for QGIS, which can display GRASS 5.1
> > vectors and attached attributes. It can work outside GRASS session,
> > with maps from more locations/gisdbases:
> > http://mpa.itc.it/radim/qgis/

I've asked Radim in personal mail what his technical evaluation was
to decide to add it to QGIS and not Thuban. 
But we refused to answer this question so far
fearing that I would only try to convince him 
that his arguments are wrong.. :)

> If the extensive GUI was a totally separate project 
> (e.g. part of QGIS) it would be such a much
> tidier interface I think. It would also be easier for developers who want
> to work on the GUI to do it without having to become completely familiar
> with GRASS first. And the GRASS developers could just concentrate on the
> core capabilities and algorithms etc.

A vision like this for GRASS has been debated a couple of times before
as I remember. Of course it is a good vision, but there also might
be reasons why it did not become a reality in one form or another.
My attempts to exlain this:
	- The approaches to general cartographic or geographic
 	viewers were not very advanced. The FreeGIS project
	led to quite some synergic effects in that respects.

	- GRASS was not designed to be an interactive application.
	This structure will always be visible and is a reason
	why interactive geo viewers tend to use their own approach.

	- Nobody was willing to long term commit to the work.
	This is understandable as a new gui in GTK or QT 
	would for some parts just be a reimplementation of the
	working tcl/tk Gui unless the GRASS structure would be
	majorly changed.


> This ties in with Markus' e-mail about release branches: it would be nice
> to have the capabilities of the new vector engine in GRASS 5.1 without all
> the 'side-effects' of GRASS 5.1, e.g. the GUIs for d.what.vect and
> d.where etc., having to work with a different build system and the awkwardness
> of the 'make mix' system, not having sites format in 5.1, the lack of testing
> of everything on OSs other than Linux (although I suppose that is just the
> way things are going these days).

As written before we want as some time make real 5.1 releases
as tarballs without make mix. Then we also want to switch to 5.1
as main development branch.

Lack of testing on other system then just GNU/Linux
only depends on the offered help. As with many Free Software projects
GRASS is driven by volenteers contributions and subsequently their needs.
If nobody stand up to help with ports and testing on other platforms,
the support will naturally decline. This is not a drawback, but an advantage.

> One reason I wanted to see the old developers mailing list is that I was
> wondering what discussion there had been and why GRASS 5.1 is in a
> separate CVS module and not just a branch in the GRASS module. I have
> never been able to find much justification for that.

Being seminal in introducing CVS for the GRASS development
I can give you the short or the long story.
The short one is that people wanted to reorganise a lot,
GRASS is a huge pile with only parts that have active maintainers,
code duplication and all that.
If you want to clean up things CVS does not preserve history well.
Moving and renaming is not really supported in CVS, thus you loose
the history and the ability to really have different branches.

Additionally we needed a place for highly unstable changes for a while
and most developers are not so accustomed with CVS that 
it happened a couple of times that commit would destabilise the CVS version.

So having a stable and develpment tree makes a lot of sense. 

> Anyway I suppose it depends on QGIS being good enough and people thinking
> it is heading in the right direction, but perhaps even the QGIS people
> would like to link to GRASS for back-end data processing?

Thuban would be another candidate (thuban.intevation.de)
as I would suggest wxPython or wxWindows in general 
if a new GUI should be written for GRASS.
The main advantage about wxWindows is that is is a cross-platform
Free Software application framework 
(GTK only starts to be cross-platform and QT is not free software
on most platforms.)

	Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20030704/6bf7b018/attachment.bin