[GRASS-dev] New installation for wxPython GUI

[Glynn Clements]

Trevor Wiens 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?

Generating PostScript is simple enough. The main issue is that, if you
don't give sufficient consideration to the wider context, you are
likely to end up continuously re-writing all of the d.* modules. Then
re-writing them again when you decide to use SVG instead.

In the long run, you're much better off abstracting out the details
into a library, so that the modules simply make a sequence of calls
which directly correspond to the nature of the data. Then, you only
need to re-write the library.

It should also be borne in mind that using PostScript for an
interactive GUI is likely to be slow. A module which can only output
PostScript is only likely to be useful for generating "finished"
artwork.

The main problem with the existing R_* API is that it requires
individual modules to process the data into a form suitable for the
driver. E.g. raster maps are re-scaled client-side so that the driver
can display them pixel-for-pixel, which is entirely the wrong way
around.

> > 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. 

ps.map is entirely the wrong approach for a GUI (and it's mostly the
wrong approach for what ps.map is trying to do).

> 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 ?

I'm not entirely sure what you are proposing. The way that I would
approach it would be to make all of the fundamental GUI operations
(add/remove/show/hide layers, zoom/pan, etc) available as external
commands, so you would be able to do e.g. "g.ui add d.rast foo" to add
a new layer containing the output of "d.rast foo".

It would be fairly straightforward to modify the raster library so
that executing a d.* command would send a command to the GUI to add
that command as a new layer.

-- 
Glynn Clements <glynn at gclements.plus.com>