[GRASS-dev] GUI platforms

[David Finlayson]

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

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
>


-- 
David Finlayson