[GRASS-dev] New installation for wxPython GUI

[twiens]

----- Original Message Follows -----
From: Michael Barton <michael.barton at asu.edu>
To: Trevor Wiens <twiens at interbaun.com>, Glynn Clements
<glynn at gclements.plus.com>
Cc: Developers List <grass-dev at grass.itc.it>,
grass at grass.itc.it
Subject: Re: [GRASS-dev] New installation for wxPython GUI
Date: Tue, 15 Aug 2006 08:21:04 -0700

> See comments below.
> 
> 
> ...lots snipped...
... more snipped...
> versions of these too? This is a lot of work. If the CLI
> could simple recognize existing GRASS commands, it would
> save a lot of coding.
> 
... more snipped ...
> It sounds like you are proposing more of a CLI-based
> cartography module (conceptually along the lines of LaTex
> perhaps?). If so, why not work with improving the existing
> CLI cartographic module, ps.map? Make it easier to use so
> that it can be realistically be controlled interactively
> from the CLI. Just a thought.

Good idea, but from my point of view, it is awkward to have
one environment in which you work with your maps for
analysis and then have to switch to another environment to
lay it out for printing. The classic case is ArcView where
you place you labels in one environment and then have a
separate layout environment. Invariably the final output
sucks. and use is awkward. Instead one should be simply
working with the different layers and when you are ready to
go to print it, you just do it. This is one of the reasons I
had asked about using postscript directly because one would
be continually working with the final output which is the
ideal from a cartographic point of view. However as Glynn
pointed out, this would be very slow, and thus not viable.
I'm not sure of the slowdown is due to postscript generation
or display. At this point, in my conceptualizing about this,
I would want to abstract the commands sent to ps.map and to
d.* into a single supper set which would then either
generate d.* or ps.map commands to give the desired output.
Thus users would only have to use one set of commands, not
two and certainly not three. 

If this concept isn't viable at this time, I'm happy to
write a simple wrapper for d.* commands as a short term
solution, but I think this would not represent the kind of
leap forward in GRASS ease of use and functionality that I
would like to achieve. It is nice to get critical feedback
however, because if I'm just creating stack of d.* commands
then the design would be quite different.

T
--
Trevor Wiens
twiens at interbaun.com

--
Trevor Wiens
twiens at interbaun.com