On Feb 28, 2008, at 1:56 PM, [EMAIL PROTECTED] wrote:
Date: Fri, 29 Feb 2008 00:04:59 +0600
From: Ivan Shmakov <[EMAIL PROTECTED]>
Subject: [GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as
wxgui is a shell script
To: [email protected]
Cc: Ivan Shmakov <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Michael Barton <[EMAIL PROTECTED]> writes:
[...]
I thought the whole reason to have a C-based g.gui was to avoid the
use of *nix specific bash shell scripts for launching GUI's. That way
they would work on all systems without the hack of having to rewrite
*.sh as a *.bat. Why can't the C-code just do the job of the old
shell scripts and directly launch the GUI code in TclTk or wxPython.
The shell scripts are only a convenience anyway, as these could be
launched from the GRASS command line with a bit more complicated
command--e.g., python "$GISBASE/etc/wxpython/wxgui.py" &
The name of the initialization module for each GUI (e.g., wxguy.py in
wxPython) could be set to a variable in init.sh (or its successor) to
avoid hard coding it in C.
It may be a stupid question, but what scripting language is
proposed to replace POSIX Shell in GRASS? The GRASS environment
seems to benefit a lot from relying on a Shell-like language.
E. g., I could hardly imagine using any language other than
Shell for the following:
$ g.mlist type=rast pattern=2008-\*-temperature \
(while read r ; do
s="$r"-celsius ; r.mapcalc "\"$s\" = \"$r\" - 273.15" ; \
done)
(Surely, there's an Olin Shivers et al work [1, 2], but it seems
to me that Shell is a bit easier to explain to a non-programmer
than Scheme [3, 4].)
[1] http://www.scsh.net/
[2] http://www.scsh.net/resources/commander-s.html
[3] http://www.r6rs.org/
[4] http://www.schemers.org/
For the foreseeable future, Linux/Unix systems will continue to have a
shell available to do the operation in your example. One of the
important features of GRASS is that many operations can be performed
in a variety of scripting environments--including bash or other shells.
However, Windows does not have a shell. If GRASS is to be truly cross-
platform, then all basic GRASS functions need to operate on all
supported platforms. This poses a significant problem for Windows
users. Cygwin has been quite difficult to install for most users, very
difficult to use in a shared classroom/lab setting, and (in my
experience) somewhat unstable. There is now a 'native' Windows build
of GRASS, but it requires custom hacks for bash scripts and other
bashisms common in GRASS--and installing msys--and these have been the
most problematic part of running GRASS in Windows so far.
Also, many users are not particularly comfortable with arcane bash
shell commands--like in your example above--although I know others who
have a special fondness for bash.
The current plan is ultimately for all core GRASS functions to run as
binaries in a cross-platform compiled language (C for most things) OR
in Python as a cross-platform scripting environment for GUI and
'permanent' scripts (i.e., those that are distributed as part of
GRASS). I'm not familiar with Olin Shivers; I've heard of Scheme, but
don't know it. However, IMHO, Python is much easier to teach someone
and to work with than bash.
Nevertheless, for those on *nix systems, bash will continue to be a
scripting platform for GRASS into the near future.
Michael
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
