[GRASS-dev] d.* commands

[Jachym Cepicky]

Hi
On Wed, May 24, 2006 at 10:42:11AM +0100, Glynn Clements wrote:
> 
> > 
> > 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.
> 

I wonder, how complicated would it be to send the "monitor" process to
background (fork), where it would watch over some PNG or other file and display
it or similar process? This could solve the d.rast|vect commands. 


Jachym

-- 
Jachym Cepicky
e-mail: jachym.cepicky at centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky at gdf-hannover.de
URL:    http://gdf-hannover.de
Tel.:   +49 511-39088507
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060524/6fe35d1e/attachment.bin