#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> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev