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

Helena hmitaso at
Thu Feb 7 15:12:03 EST 2002

Roger Miller wrote:

> On Thu, 7 Feb 2002, Michel Wurtz wrote:
> > A short list of what I'm dreaming of as a display tool :
> > + manage layers (add, remove, re-order)
> This doesn't seem like it would be that difficult.

there is also to do that (thanks to Radim)

> > + save/load "view" created (list of layer, legend and extent)
> does the "save" part now, the "load" would be done by running the
> script created by
> > + 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)

Some nice capabilities for displaying sites, including diagrams for multiple
attributes are in SG3d - maybe some of that code could be re used:
see examples in this document:

> I'd love to see this happen. offers some of these capabilities
> now.  I very much appreciate having but is difficult to
> learn and use.
> > + 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)
> Of course we can query now (d.what.sites, d.what.rast, d.what.vect), but
> it would be nice to be able to select objects and manage their attributes
> interactively.
> > + mesure on the image
> d.area, d.measure.
> > + draw line on it and pass it to external application (profil in a DEM,...)
> That seems like it could be difficult to do.
> > + at a second time, add point/line area digitizing
> This sounds like v.digit, integrated more completely into the environment.

some of these capabilities were also in xgrass, xdigit, but I guess that is dead
now -
I am not sure whether any of the code could be used to save some effort.


> I guess I have a shorter list of things I'd like to see done in the near
> future.
> From the command line--at least as of pre2--when the user creates a
> monitor window, the focus is passed to the monitor (or is this just a
> characteristic of the window manager?). The monitor window is never
> initialized in a state where it's ready to accept input.  That behavior is
> annoying because it's always necessary to get the focus back to an
> interactive shell before you can go on with whatever you are doing.
> Is there some way to keep a newly-created monitor from grabbing the focus?
> Even better, could we give the monitor windows a default action in
> response to mouse clicks, double clicks, drags and so on?  I'd like it if
> the monitor came up with the functionality of d.where, d.zoom, d.erase or
> d.what.* already running and available with just a mouse action on the
> monitor.
> I'd also like it if the active monitor were alway "on top" of the display
> and if it were possible to select a monitor (as with d.mon select=x*) with
> the mouse just by clicking it to give it the input focus.  That is, the
> "top" monitor is always selected, and the selected monitor is always "on
> top".  Again, this may be behavior specific to the window manager.  If so,
> then too bad.
> Roger Miller
> _______________________________________________
> grass5 mailing list
> grass5 at

More information about the grass-dev mailing list