[GRASS5] D.zoom behavior

[Michael Barton]

Glynn,

I  agree with you overall. But in regards to #2 below, I would go even
further. D.zoom is described as an interactive way to change the region
extents. IMHO, this is what it should be. It should not be necessary to have
anything displayed in order to change the region extents in this way (It is
not necessary to have anything displayed in order to run g.region). IOW, you
should be able to open a monitor, display nothing, create a zoom box using
d.zoom, and change the region extents accordingly. Any *subsequently*
displayed map would use those extents. If anything *is* displayed, the
region change would be followed by a screen redraw of course.

There should be no error generated. d.zoom should always change the region
extents, but should only do a redraw if there is something to redraw.
(Although perhaps it does no harm to do a redraw even if there is nothing to
redraw?). How difficult would it be to have d.zoom work in this way?

Michael


On 9/12/04 6:19 AM, "Glynn Clements" <glynn.clements at virgin.net> wrote:

> 
> Michael Barton wrote:
> 
>> D.zoom operates in an xterm, going directly to using the left,center,right
>> mouse buttons to control a zoom in the current monitor, if you start it with
>> d.zoom [mapname] or run d.zoom without an argument if a map has been
>> displayed in the current monitor.
>> 
>> D.zoom goes to the tcltk gui if you run it without arguments and there is no
>> map displayed.
>> 
>> So far so good. 
>> 
>> However, if you display a map with d.his or d.rgb, d.zoom with no argument
>> behaves as if there was no map displayed. That is, it goes to the tcltk gui.
>> I can't find any other display commands that behave this way.
>> 
>> All the rest (d.rast and d.vect, or based on these 2 commands) seem to
>> behave like the first way I described.
>> 
>> This is minor, but a bit odd. As you were talking about the behavior of
>> d.zoom a couple weeks back, I thought it might be worth reporting this.
> 
> This is essentially the problem which I was describing.
> 
> At startup, before it calls G_parser(), it connects to the monitor and
> reads the lists of raster and vector maps which are current displayed
> on the monitor. It then sets the "answers" fields of the rast= and
> vector= options to these lists. Also, if no maps are displayed on the
> monitor, it sets the "required" field of the rast= option, and
> automatically activates the the -j flag).
> 
> It doesn't work in conjunction with d.rgb or d.his because these don't
> register the maps with D_add_to_cell_list(). [This is arguably
> correct; these programs don't directly display the rasters which they
> read; they display data which is generated from them. Zooming the
> individual rasters wouldn't produce the correct result.]
> 
> There are a number of problems here:
> 
> 1. The argument-handling logic used by d.zoom is convoluted. And
> wrong. E.g. if no maps are displayed, you have to specify rast=
> (vector= doesn't suffice). If any vector maps are displayed, the
> vector= option is initialised to this list, and "d.zoom rast=..." will
> display the vector maps as well.
> 
> 2. It doesn't recognise anything which isn't either a raster or vector
> map, according to D_add_to_{cell,dig}_list(), e.g. displays generated
> by d.rgb, d.his. However, if the -j flag is used, it will redraw these
> maps by re-executing the commands which were set using
> D_add_to_list().
> 
> Personally, I think that all of the argument-manipulation logic should
> go. The rast= and vector= options should be initialised to NULL, and
> the -j switch should be off. After G_parser has been called, it should
> check that at least one of rast=, vector= or -j was given, and
> generate an error if none are given. If -j was given, it should redraw
> the display using the command list; otherwise it should draw the
> specified raster and/or vector maps.
> 
> IOW, to obtain the existing behaviour when no arguments are given but
> maps are displayed, you should have to use "d.zoom -j".
> 
> BTW, G_parser() also needs a --no-ui switch. The idea is that
> tcltkgrass would always use this switch when running a command from a
> dialog generated by --tcltk. If options are required, but the user
> failed to specify any using the dialog, the program should generate an
> error rather than displaying another dialog.

____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ  85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>