[GRASS-dev] New installation for wxPython GUI

[Trevor Wiens]

On Sun, 13 Aug 2006 01:01:04 +0100
Glynn Clements <glynn at gclements.plus.com> wrote:

> 
> The option of generating PostScript (or SVG, etc) output from the
> display architecture is a long-term goal. In order for that to happen
> in a useful way, the existing d.* modules need to be migrated to a
> higher-level API (at a minimum, using D_* instead of R_*). The
> pixel-oriented R_* API is unsuitable for generating PostScript (or
> SVG, etc).

Is it viable to consider generating PostScript directly and displaying
that in a GUI environment?

> 
> In turn, that may require some changes to the R_* API, and I don't
> intend on making significant changes in that area while separate
> display drivers (XDRIVER, PNG driver) are supported. Once the display
> drivers have been made obsolete (which basically requires a GUI which
> can be controlled from the command-line), changing the client-side API
> will be a lot simpler.

What I have in mind for my socket based GUI commands is to wrap
existing functionality in a simple to use CLI controllable series of
commands that would be identical to what the GUI would use. Or is this
approaching the problem backwards? I'm trying to provide a simple set
of user oriented commands while hiding the complexity of the back end.

However if producing PostScript directly is a viable option, then
perhaps it would be more desirable to consider writing a new GUI which
would display ps.map output and focus new display architecture efforts
around enhancing ps.map as needed. 

If this isn't viable, then would providing a new set of simple d.*
commands for both GUI and CLI use be useful because the front end would
remain constant as the back end was rewritten to drop the XDRIVER, etc ?

T
-- 
Trevor Wiens 
twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)