Given the discussions about this list, I would like to have a discussion
about broad direction. While we are changing basic structures in the
display code, I would like to make a suggestion.
I work (unfortunately) in ArcView. I did my academic work in GRASS. At
work, I have a frustrating, expensive, buggy thing to code scripts in
for other people to marvel at. Doing my academic work, I had a free,
emminently scriptable, not very buggy environment in which to work, with
limited visual support (think back before XDRIVER24, the first
version...).
I like the concepts that lie behind ArcView. I like the concept of
having a map view where the objects represented in that map view redraw
whenever you zoom, pan, etc. I like the scriptability (annoying
language, but it is scriptable). I like the idea of extensions that a
user can install for themselves, without threatening the larger
structure of the program.
What I like about GRASS is the fundamental stability, and the freeness.
The fact that I have to pay more than an arm and a leg for the use of
what I need from ArcView is faintly ridiculous. If I want to do the same
things as are done by d.3d, I need an expensive extension (or two). If I
want to do a photomosaic, I have to resort to an expensive addon, and
then I still need to do some coding just to make it go...
I wonder if there is any support for the following idea...
I propose a two-pronged approach to developing a GUI-based,
shell-scriptable GIS, exposing GRASS features through a fundamentally
more approachable interface.
The first prong is to change the parser. The parser should detect
whether of not the GRASS program is being run in a GUI mode. If so, and
there are missing/wrong/etc command line elements, then a GUI window
pops up, containing the required elements that were already passed into
the parser. Once the command has been run, any output goes to a common
log file, and then the next command can be run.
The second prong is to develop a GUI that spawns the appropriate shell
scripts or commands, and which has an integrated pan/zoom built into it,
and automatic map drawing.
I know that this is somewhat similar in principle to tcltkgrass, except
for the nature of the parser changes, and perhaps the automatic map
doodler. This could be a development on tcltkgrass, for that matter.
The required changes to the system are primarily restricted to the
parser. A whole new system would have to be developed for the GUI. There
would be follow-on changes to all programs that do not simply take a
look at the command line and produce something else. Interactive
programs like i.vpoints could continue to be used, but some programs
like s.menu might need some work.
At the very lowest level, the GUI could intercept stdin/stdout/stderr
and push those out through a terminal window of some sort. This is a
detail, however.
The last question I suppose is needed is WHY?
Why bother changing a system that seems to work so well already?
I think that GRASS is a good program, and I appreciate that it doesn't
often require the mouse. I like that in a program. On the other hand,
simply looking around in your data can be frustrating to say the least.
I spend a significant quantity of time in both GRASS and in ArcView,
just panning around, looking for things. This is annoying in GRASS, and
only mildly annoying in ArcView.
I won't bother with "aging interface" discussions, because I don't think
there is anything inherently wrong with the command line. The interface
as it stands should be kept, except for the interface for viewing data.
While that is being changed, there is the opportunity for a better
product that has the best elements of both styles of interfaces. Fine
control (Command line), scriptability (Command line) and simple
visualization/browsing (GUI).
Anyway, what are people's thoughts?
Does anyone really care?
What are people's thoughts about where we should go with GRASS in two
years (after all the floating point fuss has calmed down)?
Angus Carr.