[GRASS-dev] New installation for wxPython GUI

Trevor Wiens twiens at interbaun.com
Mon Aug 14 00:26:32 EDT 2006


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

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

I suspected so, but wasn't sure. 

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

What I had envisioned was not changing the underlying display
architecture in any way. I was thinking of leaving this for someone
else who is a more capable C programmer than I am. Instead I was
intending to create a frames and layers object tree in python that
would be accessible through either a single command with options (as
you've shown above) or a series of commands which would send a message
to a localhost socket. The python GUI would be listening for commands
and queueing them to allow a series of commands to be sent but not
having to wait for the system to finish. This would subsequently issue
the d.* commands and display the results in the display window of
choice. My thinking in using a socket based interface was to allow
users who wished to remain using bash or some other shell to still
access the functionality of the python GUI without having to give up
their favourite shell. Sockets are fast and from what I understand are
a good cross platform solution. In this context however the issuing of
d.* commands would pretty much disappear from CLI use. Instead users
would do something like "g.ui map1 add rast foo", "g.ui map1 redraw", or
"g.ui map1 tree" (to see the display tree in a simple text
representation). This could be later expanded to support frames with
multiple views, etc. This type of interface could be used to later
generate final output as bits were written "g.ui map1 print ps foo.ps"
or "g.ui map1 print png foo.png"

Although re-reading this message such a huge command could easily
become unwieldy and it may be simpler to consider dropping m for misc
and re-using it for map so one could have something like:

m.create, m.delete, m.draw, m.drawall, m.zoom, m.pan, m.layer, m.frame,
and m.print

I want to consider issues related to frames and the inserting of text
of other graphics in this context as I deeply dislike having to fiddle
with data in two places so would like to see a sufficiently advanced
cartographic system eventually constructed for GRASS that use of
drawing programs to pretty things up will be a thing of the past.

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)




More information about the grass-dev mailing list