[GRASS-dev] GUI toolkits

[Trevor Wiens]

On Sun, 28 May 2006 16:15:20 +0200
Paolo Cavallini <cavallini at faunalia.it> wrote:

> At 05:51, domenica 28 maggio 2006, Trevor Wiens has probably written:
> 
> > 1. QGIS and GRASS have different goals and target different audiences.
> > Thus abandoning a GRASS specific GUI reduces the ability of GRASS
> > developers to guide and develop the tools they want and need.
> 
> I do not understand this. GRASS is very much about powerful GIS analyses. QGIS 
> is especially aimed at geobrowsing. The integration of the two makes the easy 
> yet powerful freeGIS most user (actual and potential) want and need.

I like them separate. QGIS if I need a quick look at something and
GRASS if I want to do something serious.

> 
> > 2. GRASS is primarily written in C so if we want to use a compiled
> > language, C would be the natural choice.
> 
> Right, but do you think separating analysis (in C) from GUI (in C++/Qt) would 
> cause problems?
> 
> > 3. C++ would reduce the number of contributors. Establishing a nice
> > interpreted environment could increase the ease of development for
> > future modules.
> 
> Tapping from the relatively large and very active developer base of QGIS 
> actually increases the number of contributors, leaving grass developers to 
> concentrate on analysis (see e.g. recent discussions on rater data format, 
> and the TODO list on vectors sent by Radim) rather than reinventing the 
> wheel.
> 
> > Personally, I use QGIS as viewer of shapefiles or PostGIS files, but not
> > for anything else; I prefer GRASS.
> 
> GIS is very much about interoperability, so being able to use shapefiles and 
> postgis and grass in the same environment is a big plus. Have you tried e.g. 
> printing a simple map recently?

Don't even get me started on this one. Ha, ha,... too late. 

rant begins

I've worked as a consultant for over 15 years using most of the
different commercial GIS available, and I'll tell you straight, that
they mostly suck when it comes output. I can't even begin to calculate
the number of hours I've spent f***ing around with labels and colours
in drawing programs because the output from the GIS programs was so
bad. In the realm of free software, generating a quality map is
similarly difficult if not worse. psmap is not bad, but it doesn't do
process colours, so it can't be used for publishing without extra
processing. GMT does generate process colours but it's understanding of
file formats is so primitive that xy files have to hand edited to
prevent islands within lakes from being shaded in. QGIS, etc, don't
even begin to address to problem of cartography from the right
approach, IMAO, so will never be able to generate publication quality
output. Over the years after using many different programs, including
some dedicated just to cartography, I think I have a pretty good idea
about what features are needed to make something right the first time
quickly and easily. The old Atlas GIS program was pretty decent in most
aspects before it was bought and castrated by ESRI. 

end rant

So my response at this point in time is to become involved in the GRASS
GUI project. The GRASS community is wonderful; even heated discussions
on lists are polite and small contributions are appreciated. This is an
environment in which I feel I can contribute in a meaningful way. Over
the last 3 years as I have worked more and more with GRASS I have begun
to really like the way it works, even though I can see need for
improvement in some areas (eg. memory management in the vector
libaries) where I don't have the time to contribute. A GUI interface,
especially if it is built using straight C or Python is something where
I can help with coding.

gis.m has come a long way, and unlike Jachym, I don't think it is over
blown. I do however like the separation between the gui and the
underlying functionality and I like the idea of being able to create
good tools for the job that can be run independently without a heavy
front end. The basic architecture of QGIS is the monolithic
application, or to put it in ESR terms (cringing...) it is NOT the Unix
approach of many small applications doing one thing well. d.m, gis.m
and whatever are to follow will take this many small applications
approach which lends a flexibility to the end user through the
expressiveness of the CLI, but will also provide the ease of use to the
naive user and hopefully provide some implicit education about how
GRASS works so they will be able to migrate to CLI and scripting for
more advanced work gradually.

Perhaps that more clearly defines my position. I am however just one
voice, although perhaps a bit too loud sometimes considering how little
I've actually contributed to GRASS, and I will contribute as I am able
with whatever direction is chosen.

T
-- 
Trevor Wiens 
twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)