[GRASS-dev] GUI platforms

Wed May 24 03:34:37 EDT 2006

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,

The version for Windows comes with
basename.exe  env.exe      install.exe       od.exe     tail.exe
bzip2.exe     expr.exe     install-info.exe  patch.exe  tar.exe
cat.exe       false.exe    less.exe          ps.exe     tee.exe
chmod.exe     find.exe     ln.exe            rmdir.exe  texindex.exe
cmp.exe       fold.exe     ls.exe            rm.exe     touch.exe
comm.exe      gawk.exe     m4.exe            rxvt.exe   tr.exe
cp.exe        grep.exe     make.exe          sed.exe    true.exe
cut.exe       gzip.exe     makeinfo.exe      sh.exe     uname.exe
date.exe      head.exe     md5sum.exe        sleep.exe  uniq.exe
diff3.exe     id.exe       mkdir.exe         sort.exe   vim.exe
diff.exe      info.exe     mount.exe         split.exe  wc.exe
dirname.exe   infokey.exe  mv.exe            stty.exe   xargs.exe

> a powerful shell,

Bash on Windows.

> and a philosophy
> about how to integrate those tools seamlessly.

This is missing and Windows users don't need that. We don't want
to drop anything, the version for Windows supports maximum possible
from unix version and it makes GRASS usable also for users who are not
unix experts.
Are there any reasons why we should not allow Windows users
to use GRASS?

Radim

> 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
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>