[GRASS-dev] GUI platforms

Tue May 23 13:28:54 EDT 2006

I should add this:

1. I really like the new GUI. I am not implying by the above that GUIs
are bad --- just that I feel Unix should remain a dependency of GRASS.
(How hard is it to install Cygwin?)

2. I really respect the commitment that you (Glynn and Michael in
particular) have made to GRASS and free gis. I am trying to return
something myself (how do you both find the time??)

David

On 5/23/06, David Finlayson <david.p.finlayson at gmail.com> 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.
>
> 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
>

-- 
David Finlayson