[GRASS-user] Re: [GRASS-dev] New installation for wxPython GUI

[Glynn Clements]

[CC list snipped; anyone who is interested reads one of these lists.]

Trevor Wiens wrote:

> Sockets are fast and from what I understand are a good cross
> platform solution.

Windows doesn't support Unix-domain sockets (Cygwin emulates them
using TCP sockets). You could either use TCP sockets (although you
would have to implement some form of access control) or named pipes.

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

In the "add" case, you may as well just specify the name of the actual
command which will be used to perform the rendering (e.g. "d.rast")
rather than creating a new GUI-specific layer. IOW, every layer would
be a "command" layer.

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

Once you have the ability to control the GUI through external
commands, it's trivial to provide backward-compatibility by extending
the raster library so that running d.* commands from a shell would
signal the GUI to add a corresponding command layer.

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

I don't think that will ever be the case. There will always be
situations where you want to perform advanced graphical processing of
a kind that is best left to general-purpose graphics software.

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