Table of Contents
Display Architecture in GRASS 7
Comments from Glynn Clements (from here):
- Eliminating separate driver processes. Having to extend the protocol for each new operation has been a major drag on development.
- Use of floating-point for all graphics coordinates. For geographic data, the expected approach will be to set an appropriate transform then use cartographic coordinates.
- Common architecture for both video and hardcopy output. ps.map should be redundant.
In retrospect, 1. means that we don't really need support for the Windows/MacOSX GUI, just the ability to generate image files.
With X, we could take the shortcut of having d.* commands draw directly into an existing window, but I don't know whether that's possible on other platforms.
OTOH, it might be useful to be able to use the same functions for self-contained GUI programs (e.g. vector digitising) as for d.* commands.
Eliminate raster display functions
Directory lib/raster is now used for raster library.
Initial step was to eliminate R_() fns (some of them moved to lib/display).
- lib/raster has been removed in r37976 (lib/raster/raster.c -> lib/display/r_raster.c). The fn names unchanged.
- raster.h merged with display.h
- Some R_() fns can be made be static, see suggestion (r38001)
Drop support for interactive xmon modules
- d.font etc.
Huidae Cho merged d.text.freetype and d.text into d.text.new; drop them and rename d.text.new into d.text.Done
- merge d.font and d.font.freetype too - now done in 6.3?
- consolidate parameter names (attrcol, wcolumn, rgb_column) : -> attr_column, width_column, rgb_column?
- remove d.ask, d.menu, d.linegraph(?),
d.mapgraph, d.text.freetype, d.paint.labels (symlink), d.font.* - rewrite d.ask, d.menu as WxGUI popup-window modules independent of display? remove d.mDone
- d.legend, d.barscale, d.text, etc: make at=0,0 origin identical! - FWIW, I copied the d.legend at= syntax from d.frame --HB