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

[Michael Barton]

Glynn, et al.

I've replied on where we are from a GUI standpoint below.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

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



> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Mon, 20 Feb 2006 11:25:32 +0000
> To: Michael Barton <michael.barton at asu.edu>
> Cc: David Finlayson <david.p.finlayson at gmail.com>, Grass Developers List
> <grass5 at grass.itc.it>, Multiple recipients of list <GRASSLIST at baylor.edu>
> Subject: Re: [GRASSLIST:10424] Re: [GRASS5] gis manager 2 rc3 - bug fixes and
> updates
> 
> 
> Michael Barton wrote:
> 
>>> 1) The mouse polling thing with interactive commands nearly killed my
>>> last windows laptop. It would lock up the mouse for 30 or more seconds
>>> between mouse clicks. I always remember to "end" an interactive
>>> command, even on Linux since it pegs the CPU, but on Cygwin's x win
>>> implementation, it was nearly fatal to the system.
>> 
>> I hope that this is no longer a problem with zoom, pan, measure, and query.
>> 
>> Because digitizing and GCP creation/management is still tied to x-windows,
>> you'll still have a problem with these.
> 
> 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

> d.measure 
Replaced with GUI procedures

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

> d.where
Dynamic GUI procedure to show cursor location at all times

> d.zoom
Replaced with GUI procedure

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

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

The following use interactive x-terminals for control and display. They need
to be rewritten
> d.path
> d.profile
> i.class

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

I think these should be combined and rewritten as i.gcp as I suggested last
week.
> i.points
> i.vpoints

As you indicate, the digitizing needs to be redone. IMHO r.digit should be
combined with v.digit functionally or dropped entirely (replaced with
v.digit and r.to.vect)
> r.digit
> v.digit

I haven't worked with these and so don't have a feel for what is needed.
> r.le.setup
> i.ask
> etc/photo.2image
> etc/photo.2target
> 
> Most of these wouldn't take too much work to either replace entirely
> or to replace the specific mouse-using features with command-line
> options.
> 
> v.digit will need a complete replacement, which will be non-trivial.
> Actually, v.digit is probably the key factor in determining the need
> for mouse input; v.digit is probably the only non-trivial mouse-using
> program which is important enough to justify the existence of mouse
> input.
> 
> The imagery stuff needs a top-to-bottom re-write; aside from the mouse
> issues, there's also extensive use of the vask library, and the fact
> that much of the functionality simply isn't available in any
> non-interactive form.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>