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@virgin.net>
