[GRASS5] XDRIVER and redraw - suggestion

[Wallace, Beverly T]

Hello GRASS developers,

Back in 1995 I made a GUI that displays maps via GRASS.  We are still using
and improving it.  We use a combination of the GRASS executable programs
(for very fast development) and GRASS library functions (when fast response
is needed).

We wanted the GRASS output of d.rast and d.vect to appear in our window.  So
we converted the XDRIVER into a set of subroutines, and disabled the window
creation and event processing.  We created a library to communicate with
GRASS that was largely based upon XGRASS.

We use multiple mapsets to allow concurrent use and can start tcltkgrass in
the users' default mapset.

The main GUI program uses C++ and Motif.  It creates the Xwindow that is
passed down to the XDRIVER.  The GUI controls lists of raster maps, vector
maps, icons, lines, and polygons.  All output is stored in multiple pixmaps.
The GUI interactively zooms, pans, shows position, and queries raster and
vector maps.

This was developed with GRASS 4.1 and works with the GRASS beta5 libraries
and executables.  It doesn't work with the GRASS pre3 FIFO version, I am in
the process of finding out why.  I plan on upgrading to the socket XDRIVER.

My vote:
I am in favor of keeping the XDRIVER and d.* commands as "dumb" as possible.

I hope GRASS stays with C because of the C++ portability problems.

--
Bev Wallace
Lockheed Martin in Sunnyvale, CA, USA
beverly.t.wallace at lmco.com


> -----Original Message-----
> From:	Glynn Clements [SMTP:glynn.clements at virgin.net]
> Sent:	Monday, February 04, 2002 11:35 AM
> To:	Bob Covill
> Cc:	Markus Neteler; GRASS List
> Subject:	Re: [GRASS5] XDRIVER and redraw - suggestion
> 
> 
> Bob Covill wrote:
> 
> > Sorry about wading into this one a bit late, but I have been away for 
> > the last week.
> > 
> > A couple of questions that I have for the auto-redraw (which is a great 
> > feature) are:
> > 
> > (i) Is it possible check for duplicate draw commands and only execute 
> > the last one. For example I often draw rectified air photos repetitively
> 
> > on top of each other to examine changes. If I then resize the monitor it
> 
> > then re-executes each of the draw commands, even though they are
> identical.
> 
> Can we be sure that consecutive identical command strings are always
> redundant? Suppose that d.zoom could be run non-interactively; the
> sequence:
> 
> 	d.zoom zoom=1.2
> 	d.zoom zoom=1.2
> 
> would be equivalent to "d.zoom zoom=1.44" and not "d.zoom zoom=1.2".
> 
> > (ii) The solution to all of this might simply be some sort of cancel 
> > command (d.cancel) that kills the current draw execution. In Markus's 
> > example of drawing a large image, the draw could be cancelled saving a 
> > bit of time. Currently if I want to kill a draw command I have to get 
> > the procees ID and execute kill. This may be over-complicated but worth 
> > considering??
> 
> Actually, I think that the solution is to scrap the auto-redraw. It
> was a quick hack which has created more problems than it solved. My
> initial instinct was that this was a bad idea; I guess I should have
> followed it.
> 
> A better approach might be to add a "resize" opcode to the monitor
> protocol, and write a "d.resize" program. Such a program could
> implement various optional behaviours regarding what happens to the
> window after resizing, e.g. erase it, blindly redraw it using the
> results from d.save, or attempt a more intelligent redraw.
> 
> It would also eliminate the problems regarding WM bugs, as the window
> wouldn't support interactive resizing. And it would work on all
> drivers, not just XDRIVER.
> 
> More importantly, it decouples the monitor from the session in which
> it was started, and from GRASS in general. GRASS (i.e. libraster)
> would still need to know about monitors, but the monitors would return
> to the state of not needing to know anything about GRASS.
> 
> Beyond that, I think that there really needs to be some form of user
> interface, with persistent state. Spawning a shell doesn't really seem
> to work, and most of what has been done to try to make it work just
> messes things up. In turn, this just makes it harder to build
> something useful on top it.
> 
> A more useful command line interface would have its own "display
> state", consisting "layers" (i.e. arbitrary d.* commands), with
> commands to add, remove, replace, move (change the order of) and
> enable/disable layers, save/load the state, etc.
> 
> The monitor drivers and the d.* commands would then just be "dumb"
> programs, which makes them significantly more useful to other
> programs; trying to control "intelligent" programs from another
> program is a lot harder than controlling "dumb" ones (compare writing
> "expect" scripts to conventional shell scripts).
> 
> -- 
> Glynn Clements <glynn.clements at virgin.net>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5