#1719: GRASS 7 Monitor command line support --------------------------+------------------------------------------------- Reporter: annalisapg | Owner: grass-dev@… Type: enhancement | Status: reopened Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Resolution: | Keywords: d.mon, display, d.* commands, rendering Platform: Unspecified | Cpu: Unspecified --------------------------+-------------------------------------------------
Comment(by wenzeslaus): Replying to [comment:28 glynn]: > Replying to [comment:27 hamish]: > > > We want to use the d.* commands on a real command line without the GUI, as is done with Xmons in earlier GRASSes. So in a separate, super light-weight window with no toolbar or other visual clutter. Just a command line and a viewport window. i.e. enhance something similar to ximgview or wximgview with a right click menu for minimal interactivity. > > > > See comment:4 and d.mon2.py in grass7 addons for a partial hack of making it a bit easier to achieve this. > > An alternative approach is to I'm afraid that we have more problems with the "servers" than with the connection. However, the wxGUI-based d.mon backend could use some alternative. Now `d.*` are writing to the file which the wxGUI application reads in regular time intervals. Approach you suggested might be more than a better replacement. > modify D_open_driver() to allow display commands to be "redirected". E.g. if the environment variable GRASS_RENDER_COMMAND is set, D_open_driver() would treat its value as the name of a program. It would execute the specified program with the original command line (program name and arguments) as arguments, then exit. > It would be great if you would elaborate more on this idea now or in the future. (I'm not sure if I can extend it and consider all the issues.) For example, how switching between different `wx*` monitors and other applications (ximgview, g.gui) would be solved? > Such a program would typically be a "remote control" program which sends the command line (via DDE, TCP, or whatever) to a display server (which could be wxGUI or something simpler). I think Soeren was actually suggesting this (Python multiprocessing communication for display commands and servers) somewhere but without this "library calls another program" part. This additional command might slow things down (?) but it seems necessary. > > The main reason for delegating to an external command is that it avoids enforcing a specific communication protocol, or embedding the details into lib/display, which would be an issue for high-level protocols such as Windows' DDE or Python's pickle format. But still, wouldn't be Windows' DDE or Python's pickle even more fragile (in any sense) than the current file-based approach? > > Display commands which are implemented as scripts using other d.* commands would need to implement this mechanism themselves, so that the display server "sees" the original script, not the individual d.* commands. Once there would be function in the library for it, this should not be a problem. -- Ticket URL: <https://trac.osgeo.org/grass/ticket/1719#comment:30> GRASS GIS <http://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev