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

[Michael Barton]

Something I proposed is that we really limit the number of d.* modules used
in the new GUI. All the decorations (e.g., scale, north arrows, text,
histogram, maybe grids or others) would be better done within wx.Python
rather than rendered into raster maps by a d.* module as they are now. They
would look much better and offer greater flexibility in placement options
and appearance. I'm not proposing that we get rid of such modules, just not
use them in the new GUI. That would reduce the amount of d.* module
rewriting needed perhaps.

Michael


On 2/8/07 1:28 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

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

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton