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

[Glynn Clements]

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

d.barscale
d.geodesic
d.legend
d.measure
d.nviz
d.path
d.profile
d.rast.edit
d.rhumbline
d.what.rast
d.what.vect
d.where
d.zoom
d.text.freetype
i.class
i.points
i.vpoints
r.digit
r.le.setup
r.profile
v.digit
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>