#2509: d.mon output overwrite
-------------------------+--------------------------------------------------
Reporter: martinl | Owner: martinl
Type: defect | Status: assigned
Priority: normal | Milestone: 7.0.0
Component: Display | Version: unspecified
Keywords: d.mon | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by glynn):
Replying to [comment:19 martinl]:
> * direct rendering is a nice feature,
It's a bit more than that, given that it's the only way to actually get
graphics out of GRASS.
> Can we have consensus on these points above?
r63747 requires that either MONITOR or GRASS_RENDER_IMMEDIATE be set.
Additionally, GRASS_RENDER_IMMEDIATE=default can be used to select the
default driver (cairo if available, otherwise PNG).
> If so let's focus on implementation of the second issue and after
releasing 7.0 we can discuss better implementation of monitors rather than
using hacks like $MONITOR. Make sense to you?
Personally, I'd rather see it done before 7.0 so that it doesn't become
something we're stuck with supporting for the next decade. Getting rid of
legacy cruft was supposed to be a key point of 7.0, and now we have new
cruft added before it's even released.
I would rather see something like:
If MONITOR is set, it names a program which will be executed with the
complete argument list of the original program (including `argv[0]`). So
e.g. if MONITOR is set to "wx-monitor", then running "d.rast
elevation.dem" would execute "wx-monitor d.rast elevation.dem" then
terminate (or would execute it using execve(), which has essentially the
same result).
IOW, MONITOR simply causes the display library to delegate everything to
some other program. This could write to a file or communicate with wxGUI
via a socket (or DDE etc) or whatever. This keeps the details (and any
dependencies, which might be platform-specific) out of the display
library.
Future changes or extensions wouldn't require any modifications the
display library, which hopefully guarantees that the important case (i.e.
immediate rendering, which is where everything ends up eventually) won't
get broken by such changes.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2509#comment:20>
GRASS GIS <http://grass.osgeo.org>