----- Original Message Follows -----
From: Glynn Clements <glynn@gclements.plus.com>
To: Trevor Wiens <twiens@interbaun.com>
Cc: Developers List <grass-dev@grass.itc.it>,
grass@grass.itc.it
Subject: Re: [GRASS-dev] New installation for wxPython GUI
Date: Tue, 15 Aug 2006 07:30:34 +0100
... snipped ...
And, unless you manage to abstract the d.* layer away
perfectly (which is likely to be harder than it seems),
users will need to learn two sets of commands.
That is my intention, and I realize it won't be easy.
IMHO, it would make more sense (and reduce code bloat) if
a GUI layer was simply an arbitrary d.* command. At least,
any other approach would appear to require justification
as to its benefits.
Please refer to my reply to Michael about cartography.
Regardless as to the merits of a GUI, the need to be able
to perform all tasks (including viewing maps) from a shell
remains. In order to be able to remove the existing
monitors, it is necessary to have a suitable replacement,
which means the ability to use the GUI as nothing more
than a monitor.
That was of the central ideas of the IDE GUI concept in my
mind when it was first discussed.
bash sucks as a programming language. It's a perfectly
good interactive shell, and will remain the primary
interface to GRASS for a signficant proportion of its user
base.
That is why I'm considering sockets in the first place so
that the GUI can embed a terminal of any kind (bash, windows
[which was scheduled for significant improvement in the next
interation of windows but you never now with M$], IPython,
etc) and still function.
T
--
Trevor Wiens
twiens@interbaun.com
--
Trevor Wiens
twiens@interbaun.com