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@lmco.com
-----Original Message-----
From: Glynn Clements [SMTP:glynn.clements@virgin.net]
Sent: Monday, February 04, 2002 11:35 AM
To: Bob Covill
Cc: Markus Neteler; GRASS List
Subject: Re: [GRASS5] XDRIVER and redraw - suggestionBob 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.2would 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@virgin.net>
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5