[GRASS-dev] GUI platforms

[Glynn Clements]

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

All of those tools are available for Windows, via Cygwin, GNU-Win32,
or MKS Toolkit. Whether or not to use them is up to the user; GRASS
shouldn't depend upon them gratuitously (by which, I mean things like
using system("ls") to enumerate a directory).

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

I've never even seen ArcGIS.

But, as I said before, nothing is getting dumped. GRASS will remain a
collection of modules which can be run from scripts (or compiled
programs) written in whichever language you wish.

The changes all boil down to making it /easier/ to automate GRASS
modules, i.e. getting rid of interactive prompts, curses forms and
modal mouse input (i.e. all of the things that cannot easily be
scripted). All input comes from command-line arguments or from files
specified by command-line arguments.

The GUI is a self-contained program which works by running GRASS
modules. For this to work reliably, the modules must have a clean and
consistent command-line interface, and must run to completion
(successful or otherwise) without stopping half-way through to prompt
the user (who won't exist if the command is being run by a script).

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

I know what I'm proposing, and it isn't remotely like what you
describe.

-- 
Glynn Clements <glynn at gclements.plus.com>