Grass GUI (was Re: [GRASS5] Problems with vector import, and a
mw at teledetection.fr
Thu, 07 Feb 2002 18:35:06 +0000
Glynn Clements wrote:
> 1. Have you considered using WxWindows? This provides a layer on top
> of the platform's native toolkit(s). This may provide better
> integration than a toolkit which is built from scratch on top of the
> platform's lowest-level components.
Well, I've heard of, but have not studied it in details...
> 2. Qt requires C++, which is a disadvantage from a portability
> standpoint. Also, I still don't quite understand TrollTech's licensing
It's quite complicated, and to be honest, I don't understand all :)
> 3. The most recent version of XDRIVER can use a window supplied by the
> application, rather than creating its own (via the XDRIVER_WINDOW
> environment variable). This won't work for the libW11 port, but
> Windows should really have a native driver anyway.
> 4. By GUI, I hope you're talking about a front-end (in the sense of
> tcltkgrass), and not a monolithic program. I've previously outlined
> the serious problems with the latter, but can clarify/elaborate if
> 5. Right now, the most useful GUI tool would, IMHO, be something to
> manage display "layers".
> Each layer would effectively be a d.* command. Layers could be added,
> removed, re-ordered, temporarily disabled and re-enabled, and changed.
> The program would automatically refresh the display when the state
> changes. Other features could include:
> + Save/load the current state
> + Render to an image, via the PNG driver
> + Print, via ps.map (although that has some limitations)
> + Zoom/pan, i.e. change the current region
> This could be either be a standalone program, or added to tcltkgrass.
In fact, I started by looking at something less frustrating than ps.map.
I consider actualy that two modules are necesary : the first is a kind
of enhanced tcltkgrass (use external functions, except for drawing) ;
the second is a map manager (maps, legend, title, text, images, order of
drawing (so it's easy to make overlays), and probably some recusrive
feature (map in a map). You should naturally be able to load/save
a map (layout, content, and definition), and output the final result as
a ps file, an image (albeit this may be managed externally by ghostscript),
or an xfig file.
A short list of what I'm dreaming of as a display tool :
+ manage layers (add, remove, re-order)
+ save/load "view" created (list of layer, legend and extent)
+ enhanced drawing capabilities:
- color transparency for raster,
- style for lines (including parallel lines for roads)
- fill area with color or patterns, and transparency
- style for sites (pixmap or vectorized symbols, the later being orientable)
+ view created usable in the map manager for output
+ query on the map (raster and vector) and (eventually with an
external function) manage the attribute of selected object(s)
+ mesure on the image
+ draw line on it and pass it to external application (profil in a DEM,...)
+ at a second time, add point/line area digitizing
+ map manager must work with mouse, but let you fix all positions or
dimensions with figure (this ensures a perfect map)
everything else should be done by external modules (import/export,
analysis, raster, area/line/point style edition, etc...)
> 6. I'm looking into replacing the display architecture eventually;
> PostScript is the main contender, with SVG and OpenGL as alternative
> options. This won't happen soon, but I'd welcome comments regarding
> the design of any future display architecture.
Well, I like the idea of postscript. The only drawback I see is that
poor performance in redrawing are to be expected if you have a lot of
lines to draw, and that you must include a postscript interpreter (or
call an external one, which is also not very good for performances)
In the meantime, I don't have any time (all this was dreamed when I
woke up during the night and hesitate to get off the bed ;-)
Michel WURTZ - DIG - Maison de la télédétection
500, rue J.F. Breton
34093 MONTPELLIER Cedex 5