[GRASS-dev] [GRASS GIS] #2509: d.mon output overwrite

[GRASS GIS]

#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>