Re: [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:  | Status:  closed
  enhancement|
  Priority:  normal  |  Milestone:  7.0.5
 Component:  wxGUI   |Version:  svn-trunk
Resolution:  worksforme  |   Keywords:  d.mon, display, d.* commands,
   CPU:  |  rendering
  Unspecified|   Platform:  Unspecified
-+-

Comment (by wenzeslaus):

 As comment:26 says, please follow the following tickets:

 * #1703 querying (already closed)
 * #2233 d.* commands (currently open)
 * #2234 speed (currently open)

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  | Status:  closed
  enhancement|
  Priority:  normal  |  Milestone:  7.0.5
 Component:  wxGUI   |Version:  svn-trunk
Resolution:  worksforme  |   Keywords:  d.mon, display, d.* commands,
   CPU:  |  rendering
  Unspecified|   Platform:  Unspecified
-+-
Changes (by martinl):

 * status:  reopened => closed
 * resolution:   => worksforme


Comment:

 Last comment is 2 years old, closing, feel free to reopen if needed.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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 glynn):

 Replying to [comment:30 wenzeslaus]:

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

 By changing the GRASS_RENDER_COMMAND variable, or by changing settings
 which are used by that program. If we want to provide the equivalent of
 "d.mon", any variables should probably be GRASS variables so that they can
 be changed by a module (environment variables can only be changed via the
 parent shell).

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

 I don't think so. Using files for inter-program communication is a bit of
 a hack (e.g. there's no way to tell if the "reader" has died).

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:27 hamish]:
 > Reopening, because it is an interesting unresolved discussion and should
 not be forgotten/flushed. see also comment:22.
 >
 Please, create a new tickets with specification what you want and
 comparison with what we have. I'm not so experienced in `d.*` commands and
 older X monitors to know what exactly does comments here mean. Moreover,
 if we want some other people get involved, we should make tickets clear
 and doable (speaking for example about recent
 [http://lists.osgeo.org/pipermail/grass-dev/2014-March/067795.html request
 for GUI development ideas]).

 > We don't want to type d.* commands into the wxGUI console and have them
 work in the GUI, (as works in the old gis.m tcl/tk GUI); that's nice, but
 I think it misses the point.

 Now I don't understand, I though you were proposing `d.*` commands for
 wxGUI in #893.

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

 I'm afraid that there will never be a right click in `ximgview`,
 `wximgview`, `wxpyimgview` because there will be no will to reimplement
 what is in wxGUI (although any patch would be accepted). For these
 modules, all `d.*` commands are working (if png or cairo divers are used),
 so there is nothing to implement. The non-working commands are the ones
 involving mouse, and this is the case of right click menu.

 Anyway, I like the idea of light weight GUI, it could be actually created
 now from existing wxGUI classes but it would duplicate a lot code from the
 main GUI map display, so it would be actually better to do some
 refactoring or customization for map display to achieve light weight GUI.
 On the other hand, the precise specification of the minimal functionality
 would really help in this case. With the precise information we can
 determine the minimal work which needs to be done to achieve the goal.
 >
 > See comment:4 and d.mon2.py in grass7 addons for a partial hack of
 making it a bit easier to achieve this.
 >
 So, the only missing piece is to create `x`/`simple` driver in `d.mon`
 which would do what `d.mon2` is doing?
 >
 > regards,
 > Hamish

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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 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 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.

 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).

 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.

 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.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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   
 
--+-
Changes (by hamish):

  * status:  closed => reopened
  * resolution:  duplicate =>


Comment:

 Reopening, because it is an interesting unresolved discussion and should
 not be forgotten/flushed. see also comment:22.

 We don't want to type d.* commands into the wxGUI console and have them
 work in the GUI, (as works in the old gis.m tcl/tk GUI); that's nice, but
 I think it misses the point.
 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.


 regards,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  closed
 
  Priority:  normal   |   Milestone:  7.0.0 
 
 Component:  wxGUI| Version:  svn-trunk 
 
Resolution:  duplicate|Keywords:  d.mon, display, d.* commands, 
rendering
  Platform:  Unspecified  | Cpu:  Unspecified   
 
--+-
Changes (by wenzeslaus):

  * keywords:  d.mon => d.mon, display, d.* commands, rendering
  * status:  reopened => closed
  * resolution:  => duplicate


Comment:

 Closing this ticket because it is too broad and we would not be able to
 close it nor keep a track of all the things mentioned here.

 The original description mentioned querying (the GUI part is in ticket
 #1703), `d.*` commands (new ticket #2233) and speed (new ticket #2234,
 discussed also on some other places). Feel free to enhance their
 descriptions.

 Alternatively, create other tickets (if you have specific requests) or
 Trac wiki pages (if you have some broader ideas or larger proposals).

 Synchronization of regions and customizable/smaller GUI (e.g. for `d.mon
 wx*`) does not have any tickets right now.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by wenzeslaus):

 Replying to [comment:23 hamish]:
 > Also, with 'd.mon wx0' running I notice the process count in gkrellm is
 fluctuating rather loudly.
 >
 > ?

 C module `d.mon` calls Python script `gui/wxpython/mapdisp/main.py` which
 calls `d.vect`, `d.rast` and others to do the actual rendering.

 This, as well as other things, is a consequence of design choices which
 were made in GRASS rendering, i.e. rendering functionality distributed
 over modules and not a part of the library, so it is hard to use this
 functionality in GUI application such as monitor.

 Since this is complicated topic, I don't see a reason for mixing this
 topic with the hiding/showing toolbar/statusbar in the monitor or
 synchronizing of computational and display region. All these things needs
 discussion and we should not mix them. Different situation would be if we
 have subtickets but we don't (Trac version is too low). However, we can
 create tickets and note them here. That is IMO the way how to deal with
 wide tickets. If you want to collect ideas, you can create a Trac wiki
 page, e.g. wiki:wxGUIDevelopment/Monitors.

 To conclude, suggested enhancements (synchronization of regions,
 customizable GUI) are doable for any wxGUI developer, only problem is
 their time, I guess. However, we've discussed the rendering several times
 and we still don't have any idea what is the ideal solution (note for
 example, that the approach `wximgview` is using has some limitations, e.g.
 when you want to use opacity). Please see the Trac wiki page for all
 collected ideas: wiki:wxGUIDevelopment/MapRendering.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by nikosa):

 Replying to [comment:22 hamish]:
 > wish: for 'd.mon wx0' be able to turn off the toolbar and replace it a
 right-click context menu.  a menu item there to also turn on/off the lower
 status bar.

 Yes, please :-).  I know, I cannot code this stuff... can I do, however,
 anything else to support this cause?

 > right now those are avoided with grass-
 addons/grass7/display/d.mon2/d.mon2.py, but it's not an ideal solution.

 Can't draw anything in d.mon2 currently (rev.=56960) :-?

 > Since this is near to the original wish & mentioned early in it,
 g.region is not respected upon d.redraw, and the redraw speed is still too
 slow, I'm reopening instead of creating a new ticket saying the same
 things.

 Same experiences here using G7 the last months.  When I learned about
 ximgview (via the ML) I was really happy just because of the speed
 difference! And, yes, launching "d.mon wx0" moves the CPUs a bit up.

 Otherwise, the wx monitor(s) are great -- all of the pan, d.zoom, g.region
 and d.histogram operations at your fingertips.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by hamish):

 Also, with 'd.mon wx0' running I notice the process count in gkrellm is
 fluctuating rather loudly.

 ?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by hamish):

  * status:  closed => reopened
  * resolution:  fixed =>


Comment:

 wish: for 'd.mon wx0' be able to turn off the toolbar and replace it a
 right-click context menu.  a menu item there to also turn on/off the lower
 status bar.

 right now those are avoided with grass-
 addons/grass7/display/d.mon2/d.mon2.py, but it's not an ideal solution.

 Since this is near to the original wish & mentioned early in it, g.region
 is not respected upon d.redraw, and the redraw speed is still too slow,
 I'm reopening instead of creating a new ticket saying the same things.


 thanks,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-trunk
Resolution:  fixed|Keywords:  d.mon
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by wenzeslaus):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Current ticket summary:

  * zoom - works using mouse wheel
  * query - works with ''Query tool'' in toolbar
  * speed of display - subject to separate ticket but since it is wide
 topic a Trac wiki page was created (wiki:wxGUIDevelopment/MapRendering)
 which also contains summary of discussion above

 It is partially fixed, so I'm closing the ticket (as fixed since the is no
 more suitable option). Please create new tickets if needed (for example,
 for insufficient zoom possibilities).

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [comment:17 wenzeslaus]:

 > Can be wxBitmap used for what you are talking about? It is the same as X
 Pixmap on linux?

 Not entirely. The data for an X Pixmap resides within the X server. On the
 client side, a Pixmap is just an XID (a 32-bit integer identifying a
 server-side resource).

 For X11-based versions of wxWidgets, a wxBitmap probably has an associated
 Pixmap, but I can't see any way to get at it, or to create a wxBitmap for
 an existing Pixmap.

 > But how would be this bitmap/pixmap transfered from d.* module to wxGUI
 application?

 If GRASS_PNGFILE ends in ".xid", the cairo driver will use the XRender
 back-end, and will write the XID of the underlying Pixmap to the file
 specified by $GRASS_PNGFILE. It will also call XSetCloseDownMode(dpy,
 RetainTemporary), which results in server-side resource being retained
 when the X connection is closed.

 Another program can read the XID from this file, and use it with any Xlib
 function expecting a Pixmap or Drawable argument. E.g. g.cairocomp uses
 cairo_xlib_surface_create_with_xrender_format(), which takes the XID of an
 existing Drawable as an argument [http://www.cairographics.org/manual
 /cairo-XLib-XRender-Backend.html#cairo-xlib-surface-create-with-xrender-
 format Link].

 Thus, the d.* module creates the Pixmap on the X server and leaves it
 there for other programs to use.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by cmbarton):

 Replying to [comment:17 wenzeslaus]:
 > Replying to [comment:16 glynn]:
 > >
 > > In theory, the fastest solution should be to use the cairo driver with
 output to X Pixmaps. The d.* modules generate output in video memory, and
 may be hardware accelerated. Compositing occurs entirely in video memory,
 and may be hardware accelerated. The main unknowns are how hard wxWidgets
 makes this, and whether something similar can be achieved on other
 platforms.
 >
 > In wxWidgets there is wxBitmap ([http://wxpython.org/docs/api/wx.Bitmap-
 class.html wxPython], [http://docs.wxwidgets.org/2.8/wx_wxbitmap.html
 wxWidgets]).
 > {{{
 > This class encapsulates the concept of a platform-dependent bitmap,
 either monochrome or colour or colour with alpha channel support.
 > }}}
 >
 > This wxBitmap can be directly drawn on some wx widget/window. This
 operation is fast.
 >
 > Can be wxBitmap used for what you are talking about? It is the same as X
 Pixmap on linux?
 >
 > But how would be this bitmap/pixmap transfered from d.* module to wxGUI
 application?


 We already use wx.Bitmap

 The PNM file generated by g.pnmcomp is read by wx.Image. A wx.Bitmap is
 created from the wx.Image object and is rendered to the DC canvas. This
 part is fast.

 AFAICT, the slowest part of the process is the d.* rendering.

 For any changes to the rendering, keep in mind that other modules use this
 rendering engine to. So any fix needs to work in all modules that go from
 d.* modules to screen.

 Michael

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by cmbarton):

 Replying to [comment:16 glynn]:
 > Replying to [comment:15 cmbarton]:
 >
 > > The PNM image is translated to a PNG.
 >
 > By what? g.pnmcomp outputs a PPM file.

 By wx.Image. It is translated to a wx.Bitmap

 >
 > > This could skip running g.pnmcomp and g.pnmtopng.
 >
 > g.pnmtopng?

 Wrong. I mentioned g.ppmtopng by mistake.

 >
 > > 2. A 'wxPython driver' could be developed that would dispense with
 rendering to files that need to be read.
 >
 > How would this work?

 No idea. Just that wxPython can read a bitstream.

 >
 > > 4. The d.* modules simply take some time to render. I'm pretty sure
 that this is what takes up the most time in displays, even with displaying
 to screen resolution instead of region resolution. Perhaps these could be
 sped up. Or perhaps the rendering and compositing could be done in GRASS
 in a single step.
 >
 > In theory, the fastest solution should be to use the cairo driver with
 output to X Pixmaps. The d.* modules generate output in video memory, and
 may be hardware accelerated. Compositing occurs entirely in video memory,
 and may be hardware accelerated. The main unknowns are how hard wxWidgets
 makes this, and whether something similar can be achieved on other
 platforms.


 X is only reliably available on Linux. Not really an option for Windows or
 Mac.

 Michael

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by wenzeslaus):

 Replying to [comment:16 glynn]:
 >
 > In theory, the fastest solution should be to use the cairo driver with
 output to X Pixmaps. The d.* modules generate output in video memory, and
 may be hardware accelerated. Compositing occurs entirely in video memory,
 and may be hardware accelerated. The main unknowns are how hard wxWidgets
 makes this, and whether something similar can be achieved on other
 platforms.

 In wxWidgets there is wxBitmap ([http://wxpython.org/docs/api/wx.Bitmap-
 class.html wxPython], [http://docs.wxwidgets.org/2.8/wx_wxbitmap.html
 wxWidgets]).
 {{{
 This class encapsulates the concept of a platform-dependent bitmap, either
 monochrome or colour or colour with alpha channel support.
 }}}

 This wxBitmap can be directly drawn on some wx widget/window. This
 operation is fast.

 Can be wxBitmap used for what you are talking about? It is the same as X
 Pixmap on linux?

 But how would be this bitmap/pixmap transfered from d.* module to wxGUI
 application?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [comment:15 cmbarton]:

 > The PNM image is translated to a PNG.

 By what? g.pnmcomp outputs a PPM file.

 > This could skip running g.pnmcomp and g.pnmtopng.

 g.pnmtopng?

 > 2. A 'wxPython driver' could be developed that would dispense with
 rendering to files that need to be read.

 How would this work?

 > 4. The d.* modules simply take some time to render. I'm pretty sure that
 this is what takes up the most time in displays, even with displaying to
 screen resolution instead of region resolution. Perhaps these could be
 sped up. Or perhaps the rendering and compositing could be done in GRASS
 in a single step.

 In theory, the fastest solution should be to use the cairo driver with
 output to X Pixmaps. The d.* modules generate output in video memory, and
 may be hardware accelerated. Compositing occurs entirely in video memory,
 and may be hardware accelerated. The main unknowns are how hard wxWidgets
 makes this, and whether something similar can be achieved on other
 platforms.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by cmbarton):

 Perhaps it would help to give a simple description of the display
 workflow.

 1. All rendering begins with GRASS display modules, d.*. The PNG driver is
 set so that rendering is to temporary PNM files. It could also be to PNG
 or Cairo with current GRASS 7 architecture. IMHO, this is the place of the
 greatest slow down. The default setting of the PNG driver is to render
 files produced by the display modules to the current screen resolution and
 H/W ratio, using a combination of temporary display region and PNG driver
 settings for H and W. This avoids a problem with the old xmon driver that
 rendered to the current region only--fast for regions with few cells but
 really slow for regions with lots of cells.

 2. All rendered PPM files are sent to g.pnmcomp along with opacity values
 for each layer. These are rendered into a composite PNM image with the H/W
 values from the PNG driver settings. The PNM image is translated to a PNG.

 3. The PNG is read by wxPython and rendered to a display context (DC)
 canvas. It can be shifted and rescaled on the fly (though with impacts to
 resolution) so that panning and zooming actions can happen visually while
 any needed rerendering is done in the background

 Overlays like scales and legends are done somewhat differently. They also
 depend on relevant GRASS modules like d.barscale and d.legend, but they
 render to PNG files and are not composited with g.pnmcomp. They are read
 into a DC canvas individually so that each can be arranged on top of the
 base composite map.

 There are several possible places for speed up in this workflow

 1. All GRASS layers could simply be rendered to PNG files and use wxPython
 for compositing in the DC canvas. Glynn has suggested this and it has long
 been considered a medium term goal. But it takes fairly substantial
 rewriting of part of the display code. Not huge, but considerable work all
 the same. This could skip running g.pnmcomp and g.pnmtopng. There are a
 number of wxPython compositing tools that allow you to shift images on
 screen, zoom, and add transparency.

 2. A 'wxPython driver' could be developed that would dispense with
 rendering to files that need to be read. We discussed this sometime back.
 Glynn's opinion at the time was that this would not be significantly
 faster than rendering to files. Moreover the files provide a way to
 recover the display in case of a crash. Of course the temp files also can
 get orphaned and left on disk if there is a crash.

 3. Intermediate would be to have something like g.pnmcomp that works
 directly with PNG files or at least outputs to a PNG file to save the PNM
 to PNG translation. I'm not sure if using a compressed file format would
 save anything because something somewhere has to compress and decompress
 it, taking CPU time. Also there is the chance of loss of information,
 though that is probably of little to no concern for a display that is
 regularly refreshed.

 4. The d.* modules simply take some time to render. I'm pretty sure that
 this is what takes up the most time in displays, even with displaying to
 screen resolution instead of region resolution. Perhaps these could be
 sped up. Or perhaps the rendering and compositing could be done in GRASS
 in a single step.

 Hope this is helpful to thinking about this.
 Michael

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [comment:13 wenzeslaus]:

 > Files are much smaller

 The downside of this is that the d.* command will take longer as it has to
 compress the output file.

 > and there is one file less

 If desired, we could have a single file without the compression overhead
 by using the PNG writer from lib/pngdriver, which allows the compression
 level to be set via the GRASS_PNG_COMPRESSION environment variable.

 > (thanks to composing in Python) but during zooming/panning the most of
 the time is spent with disk IO. (Tested on Ubuntu 10.04.)

 Zooming and panning require re-executing the d.* commands to generate new
 images.

 > But we can output binary data to stdout and read them in Python
 directly. This would avoid disk IO. What do you think about using stdout
 instead of a file in case of d.* modules?

 That requires either storing all layers in memory, regardless of whether
 or not they are displayed, or re-generating layers if they are disabled
 then re-enabled. It also eliminates the possibility of implementing a
 decent caching mechanism (i.e. being able to undo zoom/pan operations by
 re-using the previous images rather than having to re-generate them).

 And using pipes may be slower than disk (if the Python side is using
 select(), there will be a context switch for each pipe-buffer-size of
 data).

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by wenzeslaus):

 In attachment png_rendering_pil_composition.diff you can see some changes
 which are necessary for rendering PNG (instead of PPM) and composing of
 images in Python using PIL (instead of g.pnmcomp).

 It is not completely working code. It is only experiment to see if this
 can be faster.

 The answer is no. I don't have any numbers but user experience is
 completely the same.

 Files are much smaller and there is one file less (thanks to composing in
 Python) but during zooming/panning the most of the time is spent with disk
 IO. (Tested on Ubuntu 10.04.)

 But we can output binary data to stdout and read them in Python directly.
 This would avoid disk IO. What do you think about using stdout instead of
 a file in case of d.* modules?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [comment:11 wenzeslaus]:
 > So let's start brainstorming about rendering.
 >
 > Currently used options:
 >  * wxGUI renders to uncompressed PPM and uses g.pnmcomp
 >   * Glynn suggested that composition should be done by wxGUI
 ([http://lists.osgeo.org/pipermail/grass-dev/2012-August/059188.html
 link])
 >   * can PIL be used? (currently only Cartographic Composer preview
 depends on it)

 Note that the cairo driver can render to an X Pixmap. These can then be
 composited via g.cairocomp. Rendering and compositing may be hardware-
 accelerated, and the resulting raster data will never leave video memory.

 However:
  1. Requires X. I don't think that there's any equivalent on Windows. It
 relies upon the fact that an X client can create resources (e.g. Pixmaps)
 on the server which are retained after the program terminates.
  2. Requires that cairo was built with XRender support (although that's
 almost certain on X; cairo was created largely to facilitate the use of
 XRender).
  3. Can wxWidgets use an X Pixmap directly (i.e. without copying the
 contents to client memory and back again)?
  4. Leaving "stale" images in the X server's memory is even worse than
 leaving stale PPM files in the temp directory. Even keeping all of the
 "live" images in the X server's memory may be an issue on some systems.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by wenzeslaus):

 So let's start brainstorming about rendering.

 Currently used options:
  * wxGUI renders to uncompressed PPM and uses g.pnmcomp
   * Glynn suggested that composition should be done by wxGUI
 ([http://lists.osgeo.org/pipermail/grass-dev/2012-August/059188.html
 link])
   * can PIL be used? (currently only Cartographic Composer preview depends
 on it)
  * wxWidgets xganim reads a raster file directly and stores data in
 wxImage
   * it is fast in C++ but to do the same in Python you have to use some
 numpy magic to make it at least comparably fast (Anna can tell more)
   * G_fatal_error() and exit() are still here
   * in order to provide full drawing capabilities code from d.* modules
 have to be moved to library

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 The request is really about optimization, especially to get rid of the
 file based
 rendering approach and to write directly to the graphic card's memory (as
 wxNVIZ
 does IMHO).

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by hamish):

 There is no need for a second GUI. Just a minor tweak of what we already
 have for a slightly more useful minimalistic display port.
 And of course, to be done as a side project by those who feel the
 particular need for it themselves, not asking anything of anybody else.


 best,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by wenzeslaus):

 Even if we have people, time or money to develop another (simpler, faster)
 version of GUI, I think that this would be wasting resources.

 But I understand the pressure for second GUI. To my knowledge there are
 several problems with the wxGUI which are difficult to over come:
  * it is in Python and simple loop is always slower in Python then in
 C/C++
  * loading of dynamic (wxWidgets, wxPython) libs and modules always takes
 some time, when you open display/GUI for the first time (when I'm opening
 the second display it is much faster)
  * rendering to files and then displaying this files on screen is slower
 than direct drawing of data to screen

 About the last point, we are using rendering to files because
 displaying/drawing of maps is done by modules, not library functions, and
 moreover, it is not safe to call functions from GUI since they call
 G_fatal() which calls exit(), right?

 However, the situation is not so bad. Considering current state, the
 rendering can be improved at least in two ways:
  * change the PPM files to something compressed (see
 [http://lists.osgeo.org/pipermail/grass-dev/2012-August/059099.html ML])
  * use different rendering engine for (big) GUI and for (wx) monitors.
 This engine could use library functions and can call exit() because it
 would end only one monitor, not the whole GUI. But there are two problems.
 The first is mirroring of display architecture provided by modules and the
 second is maintenance of additional code (but this can be only minor issue
 if it is well designed)

 Then I got impression that there is some issue with PNG driver (if we want
 to use it instead of PPM) and also that cairo driver could help but it is
 not ready.

 I haven't studied this monitor/display topic and I can be wrong, please
 correct me if so.

 However, I'm pretty sure that for some things mentioned above and for
 enabling wxGUI functionality to wx monitors heavy GUI code refactoring is
 necessary. The place to start is mapdisp package as martinl mentioned. I'm
 very interested in this refactoring but currently I have no time for it.
 But at least we can start to discuss it.

 Considering GUI development, I think that GUI code refectoring is what we
 should spend time with, not the second GUI. After refactoring we can get
 some new features much more easily and also the maintenance can be easier.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by cmbarton):

 I'm sure you feel you have a need for this. Though it would help to know
 why you need a different GUI than the existing one. But the issue that
 concerns me is that currently, there are only a very few people who are
 working on interfaces. Maintaining the 99,000 + lines of code in the GUI
 is a full time job for the few people who are doing this, all on a
 volunteer basis.

 Working on a 2nd, different interface takes away from time available to
 improve and maintain the main interface because there is only so much time
 in the day in addition to the jobs we are paid to do, no matter how much
 we love the volunteer work on this project.

 So it would be great if annalisapg and other people who have a need for it
 could take on the task of developing and maintaining a 2nd interface for
 GRASS.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:4 hamish]:
 > I'm with annalisapg on this one. There are some refinements to wx0 which
 would help (top toolbar replaced by a right-click menu, status bar at the
 bottom optional, make query tool functional, but most importantly make
 display region invisible to the user and have it be responsive to
 g.region/WIND).

 ... devs feel free to contribute on developing better stand-alone wx
 monitors (needs some refactoring of existing wxGUI code (package
 `mapdisp`)) ...

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by cmbarton):

 What it sounds like you are asking for is the development and maintenance
 of a second, interactive display architecture that is quite different from
 the existing one--in the window controls, the way you interact with it,
 and the way in which images are rendered. This architecture needs to mimic
 the behavior of a GRASS 5 display and run from a bash script rather than
 from Python.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
Changes (by hamish):

 * cc: hamish (added)


Comment:

 Hi,

 I'm with annalisapg on this one. There are some refinements to wx0 which
 would help (top toolbar replaced by a right-click menu, status bar at the
 bottom optional, make query tool functional, but most importantly make
 display region invisible to the user and have it be responsive to
 g.region/WIND).


 fwiw, I keep a little script called 'x0' in my addons dir which does:

 {{{
 #!/bin/sh

 if [ -z "$GISBASE" ] ; then
echo "You need to be in GRASS to use this"
exit 1
 fi

 export GRASS_WIDTH=720
 export GRASS_HEIGHT=585

 GR_MAJ_VER=`g.version | cut -f2 -d' ' | cut -f1 -d'.'`

 if [ "$GR_MAJ_VER" = "7" ] ; then
echo "# Run this:"
echo "export GRASS_WIDTH=720 GRASS_HEIGHT=585"
d.mon2 -b width=$GRASS_WIDTH height=$GRASS_HEIGHT
 else
d.mon start=x0
d.mon sel=x0
 fi
 }}}


 d.mon2(.py) is available in grass7 addons.


 when you run it from trunk you get text printed to the terminal like:

 {{{
 # Run this:
 export GRASS_WIDTH=720 GRASS_HEIGHT=585
 GRASS_PNGFILE="/home/hamish/grassdata/nc_spm_08/grass7/.tmp/ocean6/5684.0.bmp"
 GRASS_RENDER_IMMEDIATE=PNG
 GRASS_PNG_MAPPED=TRUE
 GRASS_PNG_READ=TRUE
 export GRASS_PNGFILE GRASS_WIDTH GRASS_HEIGHT GRASS_RENDER_IMMEDIATE
 GRASS_PNG_MAPPED GRASS_PNG_READ;
 d.erase bgcolor=white;
 wximgview
 image="/home/hamish/grassdata/nc_spm_08/grass7/.tmp/ocean6/5684.0.bmp"
 percent=10 &
 }}}

 which sets up wximgview with a cut and paste*. No access d.zoom, d.where,
 or d.what, but it is responsive to g.region, d.rast, d.vect, and d.erase,
 and fulfills my minimalistic wishes.

 [*] or ximgview, wxpyimgview, qiv as per handler option of d.mon2.py


 regards,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
Changes (by cmbarton):

  * type:  defect => enhancement


Comment:

 The old monitor system was fine for Linux in some respects but a problem
 for other platforms. Making GRASS much better cross-platform software
 meant that the very old monitor display architecture had to be replaced.
 However, there are equivalent--and more scriptable--tools for the same and
 other functions in GRASS 7. In fact, GRASS 7 is much more scriptable than
 the old xmonitor architecture. For scripts, a difference between setting a
 region in one way and another is negligible. For interactive use,
 separating the display zoom from the computational zoom has a number of
 advantages, including making the display faster with large maps. But it
 doesn't work like GRASS 5 or even 6.1 anymore. Personally, I'm happy about
 that because there is a lot more interactive functionality than there used
 to be (in early GRASS 5, there was no way to even export the display to a
 graphics file) and scripting is more flexible and reliable. This is not a
 defect. I'm not sure if it is an enhancement request, but improved speed
 is an enhancement that is always appreciated

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by annalisapg):

 Yes, I tried but I found that, if I zoom on a specific zone, the
 computational region remains the same - I should use "set computational
 region from display", but it seems a little more complicated and less
 intuitive than the old Monitor

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Annalisa Minelli]

Yes I tried it, but I found that, for example, the zoom doesn't zoom region
but display map..



2012/9/3 GRASS GIS 

> #1719: GRASS 7 Monitor command line support
>
> -+--
>  Reporter:  annalisapg   |   Owner:  grass-dev@…
>  Type:  defect   |  Status:  new
>  Priority:  normal   |   Milestone:  7.0.0
> Component:  wxGUI| Version:  svn-trunk
>  Keywords:  d.mon|Platform:  Unspecified
>   Cpu:  Unspecified  |
>
> -+--
> Changes (by martinl):
>
>   * keywords:  wxgui => d.mon
>   * component:  Display => wxGUI
>
>
> Comment:
>
>  Have you tried?
>
>  {{{
>  d.mon wx0
>  }}}
>
>  There are still some unresolved issues (including rendering speed). Anyway
>  possible to use or at least to test.
>
> --
> Ticket URL: 
> GRASS GIS 
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
Changes (by martinl):

  * keywords:  wxgui => d.mon
  * component:  Display => wxGUI


Comment:

 Have you tried?

 {{{
 d.mon wx0
 }}}

 There are still some unresolved issues (including rendering speed). Anyway
 possible to use or at least to test.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[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:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Display  | Version:  svn-trunk
 Keywords:  wxgui|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 in order to definitely migrate to GRASS 7, for our work it would be
 fundamental to have the same Monitor functionalities than GRASS 6.
 Mainly:

  * zoom
  * query
  * speed of display (!)

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev