[GRASS-dev] d.* commands

[Glynn Clements]

Moritz Lennert wrote:

> >> I think there are around 56 d.* commands for interacting with the X11
> >> terminals.
> > 
> > no, they talk to the display and raster libraries, which in turn render
> > to a display driver, which will then send it on to X11, PNG file, other..
> > 
> > e.g. a module calls R_text() to draw some text or R_polygon_abs() to
> > draw a polygon. The display drivers take care of how to actually draw
> > that. Look in grass6/display/drivers/
> > 
> > 
> >> What needs to be done to these modules so that they can communicate
> >> with the new Tk display canvas?
> > 
> > very little. e.g. in gis.m's GIS Manager window, click the "add command
> > layer" button and add a d.* command and watch it go.
> > 
> > We only have to worry about interactive modules.
> 
> I think what is at discussion here is whether one will still be able to 
> use the CLI to display things, i.e. run d.* on the CLI and see the 
> results in the monitor.
> 
> Currently, you can use the gis.m to display anything (including by 
> entering d.* commands as command layers, but if you want to use the CLI 
> to display something, you have to launch an x-monitor.
> 
> The questions are:
> 
> - Is this a problem ? I.e. how many times does one want to combine 
> display commands from the gis manager and from the CLI ?
> 
> - If it is, what needs to be done to make a d.* command typed at the CLI 
> display a map in the gis.m monitor ?

It is trivial to write a program which sends commands to a running
gis.m instance using the Tk "send" command. However, recent versions
of Tk only support the send command if the X server is using
authentication (which is a pain to set up on Cygwin). Also, I don't
know whether this feature is limited to the X11 version or works on
other platforms.

A slightly more complex (but portable) approach is to have gis.m act
as a server, i.e. create a socket and execute commands which are
received on it.

As Tcl only supports TCP/IP sockets (and not Unix sockets), you would
need to include a simple authentication mechanism, e.g. sending a
token which is stored in a non-world-readable file in the user's home
directory, the same way that X's authentication mechanism works.

As the longer-term plan is to eliminate monitor processes altogether
and have the raster library generate image files directly, there will
need to be an option to feed each new image file to a user-specified
command to display the image, so that running d.* commands from an
interactive shell continues to work (more or less) as it does at
present.

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