[GRASS-dev] GUI platforms

[David Finlayson]

First, I am not trying to be combative at all. I wish we could sit
down at a coffee shop and discuss over a latte...

I agree that the current incarnation of GRASS and probably for the
near future there will be no major changes to GRASS. What I am
thinking about is GRASS 7 (or maybe GRASS 8).

The problem is not the particular shell used (though there are
advantages to establishing a standard), it is the missing toolbox on
Windows. Windows out-of-the-box doesn't provide the tools to do
anything useful. Everything needs to be provided. There are several
options:

1. You can supply a Unix emulation layer and bash as Cygwin does
(there are others) and all scripts run cross-platform across the three
architectures. This is what is being done today.

2. You supply a tool set and allow Windows to use a native shell (cmd
or whatever). I think in this case the obvious easy path is to supply
the tools already available on Unix systems, but recreating a new tool
set isn't inconceivable. Care needs to be taken to make this all work
cross-platform without crippling one system or the other. I can't
imagine that true cross-platform scripting can be achieved this way
without essentially duplicating what Cygwin already provides.

3. You code to the lowest common denominator making no assumptions
about a Unix toolbox or a scripting environment. Here is where you
will probably need to supply grass with its own "shell". Maybe a
Python interpreter with an object model for communication with GRASS
(like ArcGIS has done).

IMHO, option 3 ends GRASS as a real Unix program.

Part of the issue is that 99% of tools designed for native use on
Windows (and GUI Mac) are not programmed to use text streams. The only
way to communicate with them is through remote procedure calls. That
is why Windows provides the Windows Scripting Host (WSH). Python and
Perl use COM, etc. GRASS's shell will need to support this world view.

If you've done much scripting in Windows using native tools, you'll
find it is a very different monster than on Unix. Your code becomes
boiler plate procedure calls to the scripting host and you work with
the back-end API of things like MS Office applications. One line of
bash with a few pipes turns into dozens of lines of object-oriented
goop, even in Python.

Certainly, if we are going down that route I would rather see it in
Python than almost any other scripting language. But I think this
approach has long-term implications for the GRASS architecture that go
well beyond the GUI issues we are dealing with today.

It's something to think about.







On 5/23/06, twiens <twiens at interbaun.com> wrote:
> ----- Original Message Follows -----
> From: "David Finlayson" <david.p.finlayson at gmail.com>
> To: "Michael Barton" <michael.barton at asu.edu>
> Cc: Trevor Wiens <twiens at interbaun.com>, Glynn Clements
> <glynn at gclements.plus.com>, grass developers list
> <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] GUI platforms
> Date: Tue, 23 May 2006 10:13:23 -0700
>
> > >> 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.
>
> David,
>
> Shell environments are available on other platforms. FYI, M$
> is currently planning on doing a serious upgrade of the
> shell environment for their upcoming Vista release. If
> however that actually happens.... who knows. Also, FYI, I
> only use Linux and like it, but that doesn't mean I don't
> want to provide GRASS to others if it can be done without
> loss of functionality that I need and use.
>
> The point is creating independence from X11 and providing a
> shell does not in any way compromise the use of sed, awk,
> etc. What we can't count on is an xterm or equivalent being
> open, thus we need to provide an integrated shell. This
> simply could take the form  of an xterm or something more
> involved like Cedric's recent work with gis.m.
>
> I had simply asked a question about what was being planned.
> Michael clearly stated that Bash is NOT scheduled for
> removal. If you read Radim's responses you would find that
> all these tools can be setup and called from Windows.
>
> All the shell scripts written for GRASS will still work in
> the future. Hopefully we will be able to provide a more
> sophisticated scripting environment in the future for those
> who choose to use it, but it is simply too much work to
> rewrite all the shell based stuff.
>
> What Windows won't have is the low cost of spawning
> processes, but that is a Unix (os not shell) design issue
> over Windows.
>
> No one wants to abandon the simplicity of the fundamental
> principle of one program for one task. To do that would be
> starting over from scratch and no one wants to do this.
> Please read the queries posted by Russ Nelson about wanting
> to rewrite GRASS from scratch. NO ONE WANTS THAT. As Glynn
> clearly stated, nothing is being thrown out. No
> functionality will be lost and your replies do not in any
> way demonstrate how the move to independence from X11 will
> cause any loss in functionality.
>
> > snip....
> > done. Something more sophisticated will reduce the pool of
> > programmers accordingly.
>
> Absolutely false. Providing a modern scripting language will
> increase the number of programmers not reduce it. Since
> shell and all that comes with it will still be available you
> will still be able to get things done.
>
> >
> > 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.
> >
>
> This is not planned and has never been suggested.
>
> > snip....
> > 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.
>
> Since NO drastic change is happening what would users be
> asked?
>
> "Would you like the GUI to be nicer?" __YES / __ NO
> ...
> ?
>
> T
> --
> Trevor Wiens
>
>
>


-- 
David Finlayson