#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 martinl): Replying to [comment:18 glynn]: > > 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 Let's start with fundamental points: * some users like monitor concept (GUI monitors, and "file-based" monitors), we should keep it since there is relatively strong request to have them * direct rendering is a nice feature, but should be enabled only on demand (eg. when $GRASS_RENDER_IMMEDIATE is set), otherwise the most of users will be confused why display modules are producing `map.png` (or `map.ps`...) files in the current directory just without asking Can we have consensus on these points above? 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? -- Ticket URL: <http://trac.osgeo.org/grass/ticket/2509#comment:19> GRASS GIS <http://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev