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

GRASS GIS GRASS GIS developer
1

David,

See below

Michael
__________________________________________
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

Thanks for working with the new gis.m. I should mention that the issues you
raise about screen resizing, and several similar things, are fixed in the
version I released on Friday.

The CVS mirror(?) I am using must be a day behind then, I updated and
recompiled Saturday night (PST). I'll try again soon.

There were "issues" with the cvs. These are fixed now. So you should be able
to update and actually get a current version.

Actually, I'm mainly on Linux, but I used to keep a windows laptop
with cygwin/grass installed. I will be doing that again soon. On that
note, I am really hoping the new gui will solve some long standing
Cygwin/GRASS issues:

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.

I'd appreciate it if you could let me know about this.

2) Please don't depend (I didn't say don't use ever) on a 3-button
mouse! Most laptop keypads only have 2 buttons! I can't use it without
bringing along a real 3-button mouse. That's hard to use on an
airplane or bus.

AGREED! The last (I think) feature change before freezing features to finish
testing is to make the display controls like radio buttons. This means that
you only need a 1-button mouse to do zoom, pan, measure, and query with no
loss of functionality or convenience.

I would love to hear about your use of GRASS in classrooms in another thread.

Happy to oblige. I'm doing a remote sensing class this semester and will use
GRASS among other things.

Cheers,
Michael

2

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@gclements.plus.com>

3

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@gclements.plus.com>
Date: Mon, 20 Feb 2006 11:25:32 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: David Finlayson <david.p.finlayson@gmail.com>, Grass Developers List
<grass5@grass.itc.it>, Multiple recipients of list <GRASSLIST@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@gclements.plus.com>

4

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@gclements.plus.com>