[GRASSLIST:10424] Re: [GRASS5] gis manager 2 rc3 - bug fixes and updates

[Glynn Clements]

Michael Barton wrote:

> > Can you provide an update on progress regarding replacing mouse-using
> > programs?
> > 
> > AFAICT, the following programs all use R_get_location_with_* directly
> > (there will also be a few which use it indirectly through libdisplay).
> 
> The following are in the GUI using manually entered xy coordinates for
> placement only (i.e., no mouse  placement). It shouldn't be too difficult to
> create a GUI procedure to capture xy coordinates from the display, using a
> mouse, and insert them into the coordinate fields. I'm not sure if there is
> any point in doing this for d.geodesic or d.rhumbline (i.e., using a mouse
> to draw these lines). Perhaps a tool to create simple graphics on the screen
> would be more useful in the long run (though you can do this after the fact
> in more sophisticated ways by dropping saved displays into a graphics
> program)
> 
> > d.barscale
> > d.geodesic
> > d.legend
> > d.rhumbline

There should ideally be general-purpose tools to mark points, lines
and rectangles on the monitor for use by subsequent commands.

E.g. for d.legend, rather than running the command then it expecting
you to mark a rectangle, you would first mark a rectangle with the
rectangle tool, and the rectangle would be passed to d.legend via the
at= option.

IOW, similar to the way that, in a paint program, you mark a
rectangle, then choose crop, cut, etc to perform the operation on the
selected rectangle.

> > d.what.rast
> > d.what.vect
> 
> Replaced with GUI procedures and v.what/r.what. Cannot edit vector attribute
> table (thought this would be nice). Having implemented these, it would be
> nice if v.what and r.what optionally accepted 2 coordinate pairs that would
> define a rectangle and query all features within the rectangle.

Probably more useful would be a region-copy operation, i.e. mark a
rectangle (or maybe other region), then create a copy of the map which
is cropped to the selected region. You can then perform any whole-map
queries on the cropped copy.

> > d.text.freetype
> Replaced with GUI text layer (high resolution, postscript output)

It would be useful to be able to include rasterised text as well (e.g.
if you save the display contents as a PNG etc).

> > d.nviz
> > r.profile
> 
> Could be dealt with in the same way as d.barscale. I haven't done this
> because they are not map layers and don't have options panels. This means
> that we'd need to work with the autogenerated GUI for modules.

Right.

An area for future developement is the display of non-geographic
graphical information (e.g. r.profile, d.histogram etc). This should
be kept separate from map display.

There needs to be a general purpose system for running miscellaneous
d.* commands and showing the resulting PPM file in a window.

Once the d.* programs are decoupled from the existing driver
architecture, there's no reason why they can't use other mechanisms
for generating their output (e.g. generating PostScript then using
Ghostscript to convert that a PPM file).

> This should be fixible fairly easily. All you need to do is have it accept
> xy coodinate input and a value to ID the cell and replace the current cell
> value. Something similar could be done for vectors, but would need to be
> more sophisticated.
> 
> > d.rast.edit

You would still need to build a UI on top of the cannibalised utility. 
Initially, that should probably be a stand-alone Tcl/Tk program;
there's no need to integrate everything into gis.m at first.

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