[GRASS5] QGIS + GRASS

[Radim Blazek]

On Friday 04 July 2003 15:02, Paul Kelly wrote:
> I thought someone would have replied to this by now but they haven't so I
> will. Radim- do you think QGIS could be *the* GUI for GRASS? 

It will be one of GUIs for GRASS, and it could be *the* GUI at least 
for X-Windows. But this I would left to natural evolution.
GUI was discussed many times in this list, without any conclusion. 
If the right toolkit is not obvious, we can try more. It is not 
my suggestion for future development, it is just the situation
we have now, short summary:
- grass/unused/tcltkgrass (it is realy viewer, not menu for commands)
- d.dm/d.m
- GRASS/Qt
- I know about people working on Java based interface. Are you here? 
- GUI for iPAQ written by Carl Worth
- once I have seen a screenshot of complete nice GUI for GRASS,
  but it was not released as open source yet (can we see the screenshot Marcus?)
- I started Java interface 2 years ago, it was pure java (no c code)
  (http://mpa.itc.it/radim/g50/gratia.jpg)
- QGIS+GRASS

This is one of a few (dis)advantages in OS development, you don't need 
to follow what strategists say.

> Now there is
> GRASS++ for reading GRASS vectors and already libgrass for rasters. Of
> course closer integration would be more desirable.

Occasionally I am working on rasters in GRASS++ and QT. I think that 
applications using libgrass could use directly shared libraries
from grass51.

> One of the things I don't like about GRASS 5.1 (from my very limited
> experience testing it) is that there are GUI boxes popping up everywhere
> and they are all Tcl/Tk which is very clunky and slow and not as nice to
> look at as modern GUIs like Gtk or Qt. In fact I don't like GUIs at all and
> prefer to do most of my work from the command-line. 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.
>
> 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).

GUI boxes everywhere? No, I cannot believe. Are you running all commands
without options? d.what.vect should open GUI only if run without parameters
and no map is displayed in monitor. Anyway, you can disable automaticaly 
generated GUI by setting enviroment variable GRASS_UI_TERM=1. Then remain
 v.format, which you can avoid by editing 'frmt' in text editor 
           or using g.gisenv.
 v.digit, but here I insist that it is more productive with GUI 
          than with old text interface, and time spent by editing is 
          always much longer than startup.
 g.mapsets, use command line options
 d.m, don't run it 

Yes, I have never seen anybody using GRASS GUI, it is there only
for marketing (I am using d.m, g.mapsets and v.digit). 
Idea is that beginner gets GUI and experienced user like you can go around.

If you think that s.* should be in 5.1, put it there. I would prefere
binmix, but it can be in source as well. But we should decide
if it is temporary solution, to be replaced by v.* or if 5.2 will be released
with s.*.

> 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.

5.1 is separate tree because it was made a decision to change 
directory structure (grass/documents/new_directory_structure.txt).
And it is there so long because, when we started with David to work
on new vectors, we needed some system to share the code.

> 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?

I think that QGIS should be only used to display/query/edit GRASS maps
and should not be mixed with interface for GRASS commands. 
This could be other project integrating GUI startup, menu and GUI for commands,
QGIS and command line.

Radim