[GRASS-dev] GUI platforms

Tue May 23 13:46:49 EDT 2006

Thanks David. I hope my last response clarifies things.

There is really no issue for Mac. It IS Unix. The issue under windows is
that Cygwin is simply a problem for many Windows users. It there is a way to
run GRASS without it, it will make GRASS available to a much wider audience
that wants to run it.

It may also make them want to switch to Linux or Mac if they find they can't
do all the things that you describe to enhance GRASS ;-)

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

> From: David Finlayson <david.p.finlayson at gmail.com>
> Date: Tue, 23 May 2006 10:28:54 -0700
> To: Michael Barton <michael.barton at asu.edu>
> Cc: Glynn Clements <glynn at gclements.plus.com>, Trevor Wiens
> <twiens at interbaun.com>, grass developers list <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] GUI platforms
> 
> 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