Grass GUI (was Re: [GRASS5] Problems with vector import, and
hmitaso at unity.ncsu.edu
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 d.dm to do that (thanks to Radim)
> > + save/load "view" created (list of layer, legend and extent)
> d.save does the "save" part now, the "load" would be done by running the
> script created by d.save.
> > + 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. ps.map offers some of these capabilities
> now. I very much appreciate having ps.map but ps.map 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
> > + 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
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
> 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
> 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 grass.itc.it
More information about the grass-dev