Grass GUI (was Re: [GRASS5] Problems with vector import, and a suggestion)

[Glynn Clements]

Michel Wurtz wrote:

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

I'd suggest using external programs for drawing as well. Otherwise
you'll be re-implementing half of src/display.

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

Translucency is awkward. Many display systems don't support it
directly. PostScript *can't* support actual translucency, as the
framebuffer is write-only; although you can provide some form of
emulation with halftones, you need to be careful when dealing with
multiple layers.

As for new features generally, they would belong in the general
display architecture, where they are available to all programs. Adding
functionality which is only available through an interactive
application is bad idea.

My main concern is that, rather than extending GRASS, you may end up
simply forking off a lot of code into a self contained application.

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

Well, obviously the interpreter would be either Ghostscript (for
screen display, image creation, and printing to non-PostScript
printers), or the one which is built into a PostScript printer.

As for performance, the overhead of sending PostScript to an external
process is trivial compared to the actual processing and rendering
(which occurs regardless of whether the interpreter is external).
Rendering complex geometry is expensive however you do it.

-- 
Glynn Clements <glynn.clements at virgin.net>