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