[GRASS-dev] [GRASS GIS] #1719: GRASS 7 Monitor command line support

[GRASS GIS]

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