[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:16 neteler]:

 > > > The current behaviour of d.* to silently write into a PNG file is
 unhelpful.
 > >
 > > Yet, that's how those commands behaved since the display system was
 re-written.
 >
 > Maybe that was the idea but for sure not clearly communicated or
 implemented in all d.* modules.

 I'm not sure how it could have been communicated more clearly. And the
 behaviour is consistent across all display[*] modules. It cannot be
 otherwise, as the behaviour comes from lib/display, not any particular
 module.

 [*] I'd like to say "all d.* modules", but there are a number of cases
 where people have used that prefix for modules which are unrelated to the
 display system, e.g. d.mon, d.out.file, etc.

 > > I don't recall any discussion about the behaviour; it got changed by
 accident and now that's how it's "supposed" to be? When did we agree to
 this change, and why?
 >
 > Now which change?

 r46984 and r46999.

 When the support for 6.x-style monitors was removed in r32584, immediate
 rendering became the only supported mode of operation (as was already the
 case on Windows). Thus, it was no longer necessary to set
 GRASS_RENDER_IMMEDIATE; executing any display command would simply
 generate an image file (default map.png, configurable via $GRASS_PNGFILE,
 later changed to $GRASS_RENDER_FILE).

 r46984 and r46999 re-introduce a form of the "monitor" concept (although
 I'm not clear on the details, it has something to do with $MONITOR).
 AFAICT, r46984 effectively disabled direct rendering. r46999 re-enabled
 it, but forced $GRASS_RENDER_IMMEDIATE to be explicitly set (if neither
 $MONITOR nor $GRASS_RENDER_IMMEDIATE are set, it generated a fatal error).

 In case it wasn't clear from [http://lists.osgeo.org/pipermail/grass-
 dev/2014-December/072274.html this thread], the requirement for
 GRASS_RENDER_IMMEDIATE to be set was news to me (I had explicitly set it
 while investigating differences between the cairo and PNG drivers, and
 forgotten to remove the setting).

 > I just asked that the d.* modules please say what they do since I don't
 check the file system for a new file every time I issue a command.

 You were unaware of immediate rendering? Or of it having been the default
 since the earliest days of GRASS 7?

 > If it matters, more people are interested in a working d.mon/command
 line approach:

 I don't doubt it. I've tried to have discussions on such things in the
 past. But some people prefer to just implement hacks like $MONITOR without
 any discussion. Ultimately, that's likely to be counter-productive in
 terms of any reasonable solution.

 FWIW, I don't actually object to requiring $GRASS_RENDER_IMMEDIATE to be
 set. I do object to it being done by /fait accompli/. I'm also less than
 keen on the way that wxGUI seems to be slowly getting shoehorned into
 somehow being "part of" the display system (e.g. using the d.* prefix for
 commands which have nothing to do with the display system per se).

 If the wxGUI developers need additional functionality from the display
 system, that should be resolved through discussion rather than "edit
 wars". Otherwise, it's likely to result in a display system which is of no
 use for anything but wxGUI.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2509#comment:18>
GRASS GIS <http://grass.osgeo.org>