[GRASS-dev] WxPython front-end to ps.map

[Glynn Clements]

J-Báchym Čepický wrote:-A

> * the gui will be never as fast as compiled one

Unless the GUI is going to do its own rendering, that isn't really an
issue.

> I would say, if we would need to rewrite Map Displays so they access
> raster and vector files directly, we would need to code this parts in
> C. It would take us too much time IMHO.

I would caution against that.

The GRASS API was designed for traditional one-shot utilities; it is
entirely unsuited to persistent applications such as a GUI. E.g.:

1. If anything unexpected occurs, the usual response is to call
G_fatal_error(), which terminates the process.

2. The core libraries have many global variables, which are
initialised either by the loader at program startup, by G_gisinit(),
or on first access. In many (most?) cases, there is no way to reset
the library state back to its initial state.

> My imagination is, to use Map Display with pop-up tool bar(s) for
> specific tools -- if there is someone, who disagrees with this point,
> please raise your hand. ps.map is very good tool for creation of
> hard-copy maps. It should not be too big task to add tool, which would
> generate configuration file for ps.map based on map display content.
> 
> For the future, it would be good to improve d.vect to be able to
> display e.g. dashed lines

That's an architectural change. I really don't want to see the
existing graphics system (libraster etc) improved. It's long overdue
to be replaced with something better. Unfortunately, the problem with
a better API is that it's the interface which needs to change, rather
than just the implementation. And that involves re-writing a lot of
d.* modules.

> and so on and to improve ps.map so it is possible to work with
> multiple raster tiles and so on.

Are you talking about overlaying raster maps? One thing to bear in
mind here is that you need level 3 PostScript for masked images
(images with transparent pixels), and there are plenty of printers out
there which don't support level 3.

-- 
Glynn Clements <glynn at gclements.plus.com>