[GRASS-dev] GUI platforms

Tue May 23 13:49:50 EDT 2006

On Tue, 23 May 2006, David Finlayson wrote:

> >> Is the goal to eliminate the GRASS dependency on a Unix environment?
> 
> > Yes. GRASS should also work on Windows (with neither Cygwin nor an X
> > server) and MacOSX (without an X server) as well as it does on Unix.
> 
> As I said, that IS throwing the baby out with the bathwater.

David,

I agree fully with your arguments below. Shell scripting and modularity
are of fundamental importance, and keep the bugs just in the modules they
affect. On the other hand, I understand Glynn's position to be that
cleaning up the way modules interact with the shell is good, and
additionally is good for any GUI that might be added "on top". The
scriptable shell and CLI is a great benefit to everyone in the
Kernighan/Plauger and software tools tradition. The mess in ArcGIS 9 is 
quite improbable and distinctly scary, probably (no evidence, IANAL) 
leading to multiple wrong decisions (like Moran's I with row 
standardisation being way out). 

I don't think GRASS developers are that GUIey, it's a matter of horses for
courses, and both CLI and GUI are vitally needed. The current TclTk push
does not, I think, threaten the CLI at the "Software Tools" foundation of
GRASS, though a GUI in C++ would scare the life out of me. If anyone wants
C++, try Terralib, very well written, well thought through, but a
different and complementary animal.

GUIs can be nice, take Plan9's 8½ ...

Roger

> 
> GRASS on Unix is more than just a collection of GIS programs. It is
> also 50 or more Unix commands, a powerful shell, and a philosophy
> about how to integrate those tools seamlessly. None of those things
> exist on Windows, and they only exist in OS X if you go out of your
> way to activate the Unix underpinnings of the OS.
> 
> Frankly, Unix IS primitive in some ways. All modules communicate by
> text strings. But it is a lot easier to pepper a new program with
> print statements than to implement an entire RPC infrastructure such
> as IDispatch on Windows. A crappy programmer like me can get things
> done. Something more sophisticated will reduce the pool of programmers
> accordingly.
> 
> Eliminate Unix and in one fell swoop every script in GRASS is
> unusable. All 50+ of the official scripts will need to be rewritten in
> Python or whatever the script language de jour is. Some things that we
> take for granted today (like grep, sed, awk, head, tail, cut...),
> stuff I use every day, is going too. Every one of them will need an
> OS-specific replacement or complete recode in a portable language.
> 
> The most compelling reason not to go down this road is ArcGIS itslef.
> They did EXACTLY this 10 years ago. Dumped Unix and went to an all GUI
> infrastructure. I can hardly call it an unsuccessful move...ESRI is
> the 900 lb gorilla of GIS now. But have you ever tried to automate it?
> Its a nightmare.
> 
> Now they are bolting on a model builder and trying to get
> COM-compliant scripting languages like Python to work with their API.
> There is a lot of boilerplate code for each script that needs to be
> written because of the RPC needed between tools. Frankly, they are
> reinventing what they lost when the dumped the command line and they
> are having a difficult time of it. IT is hard to program and the
> enormous API is difficult to debug, so the whole thing is buggy,
> fragile and slow.
> 
> What you guys are proposing with the GUI change is really much more
> than that. It is a fundamental re-architecture of the GRASS program. A
> few of us have been alarmed by it. Maybe a lot more people are
> relieved. But at any rate it seems like that decision should be more
> transparent to the community of GRASS users.
> 
> A good OS X program is not a good Unix program (though it might be
> more popular with more people).
> 
> David
> 
> On 5/23/06, Michael Barton <michael.barton at asu.edu> wrote:
> > This flexibility will make it easier to switch to a different GUI platform.
> >
> > Michael
> > __________________________________________
> > Michael Barton, Professor of Anthropology
> > School of Human Evolution & Social Change
> > Center for Social Dynamics & Complexity
> > Arizona State University
> >
> > phone: 480-965-6213
> > fax: 480-965-7671
> > www: http://www.public.asu.edu/~cmbarton
> >
> >
> >
> > > From: Glynn Clements <glynn at gclements.plus.com>
> > > Date: Tue, 23 May 2006 08:50:29 +0100
> > > To: Michael Barton <michael.barton at asu.edu>
> > > Cc: Trevor Wiens <twiens at interbaun.com>, grass developers list
> > > <grass-dev at grass.itc.it>
> > > Subject: Re: [GRASS-dev] GUI platforms
> > >
> > >
> > > Michael Barton wrote:
> > >
> > >>> Do you envision something that would be a plugin replacement for
> > >>> g.parser that would possibly allow for more interactive dialogues, but
> > >>> would allow existing modules to work without modification. If so I
> > >>> think this would be ideal, but not being familiar with that code I
> > >>> don't know what is possible.
> > >>
> > >> I'm talking about functionality at a conceptual level, not implementation.
> > >> How to do this might vary depending on the platform chosen. Since (I think)
> > >> g.parser is specific to TclTk, a new version would need to be written that
> > >> is not--either in the GUI platform or in GRASS functions/libraries.
> > >
> > > "g.parser" isn't specific to Tcl/Tk. G_parser() includes functionality
> > > to output a description of the command-line options in Tcl/Tk syntax.
> > > This can still be used by a non-Tcl/Tk GUI in one of two ways:
> > >
> > > 1. Use the --ui switch, which spawns "wish" and feeds the Tcl/Tk code
> > > to it (gis.m uses the --tcltk switch, which just writes the Tcl/Tk
> > > code to stdout).
> > >
> > > 2. Parse the Tcl/Tk code. The generated code is extremely restricted
> > > in its form, and could easily be parsed by a C program.
> > >
> > > Alternatively, a C module could use the XML generated by the
> > > --interface-description switch. Or G_parser() could easily be extended
> > > to generate a different format (e.g. XML usable by the Glade library).
> > >
> > > --
> > > Glynn Clements <glynn at gclements.plus.com>
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev at grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass-dev
> >
> 
> 
> 

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no