[GRASS-dev] GUI platforms

Thomas Adams Thomas.Adams at noaa.gov
Tue May 23 13:51:26 EDT 2006


David,

I agree completely with you. I use GRASS in both Linux and MacOS X 
environments and have absolutely no problem with the current UNIX 
underpinnings. I feel this is a tremendous strength for exactly the 
reasons you state. I believe GRASS should stay this way. Probably the 
solution is to let other teams such as JGRASS, QGIS, etc. go this way to 
attend to the needs of the opensource GIS masses. This is not to say 
that GUI improvements such as those we have seen with gism are not 
needed and welcomed (they certainly are), but the ties to UNIX and its 
scriptability are a huge plus. To abandon this would, indeed, be 
"throwing the baby out with the bath water".

Tom


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


-- 
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL:	thomas.adams at noaa.gov

VOICE:	937-383-0528
FAX:	937-383-0033




More information about the grass-dev mailing list