[GRASS5] d.legend and d.out.png

[Michael Barton]

Hamish,

Thanks for the explanation. A couple things a I still have questions on.


On 8/20/04 8:12 PM, "Hamish" <hamish_nospam at yahoo.com> wrote:

>> A small interface note. The autogenerated tcltk dialog for d.legend
>> has a pulldown for the position coordinates. This pulldown (i.e.,
>> #%options-> value,value,...) only contains the entry 0-100. This is
>> also automatically entered in the field (i.e., #%answer->0-100). This
>> is an incorrect format that generates an error unless it is erased
>> each time d.legend is started.
> 
> I know. This is happens when there is "->options" specified but no
> default value ("->answer"). Many of the other parameters have options
> ranges (and therefore bounds checking) too, without harm. The at option
> actually has "NULL" as the default answer. (default: automatic sizing)

For position coordinates, this causes an error even if you use the 'set
position with a mouse' flag. You are right, however, in that it does not
cause an error for the other fields. A NULL with automatic sizing would
actually be OK in the position coordinates if this worked.

> 
> d.barscale gets it right, but note it doesn't use D_color_list() so no
> pull down menu for the colors. (cost of allowing R:G:B and "none")
> 
> opt->options is also unaware of opt->multiple=YES; I'd prefer to have
> it be   options: 0-100,0-100,0-100,0-100
> and bounds checking on all inputs & an arg==4 check from that, although
> sometimes it is useful to draw a bit beyond the edge of the screen.
> This is another matter.
> 

Since this doesn't work, what is the best solution at present? Disable the
pulldown range checking or put a reasonable set of defaults in the answer->
field (e.g., 10, 20,10,90)?

> 
>> All other pulldowns, except color, have equally meaningless values.
> 
> No, the values listed in the other boxes are the default values.
> See 'd.legend --help'. Having the default values filled in even if you
> don't use them is harmless.
> 
> 
> So the issue is that the value of "->options" shouldn't be placed in the
> tcl input boxes, only the "->answer" (default) values. On the other hand
> this works nicely when there is a default value (try the pull down menu
> for another option to see).
> 
> 
>> FWIW, it might work better if the range option worked more like
>> the'required' option. That is, if a value for the entry was outside
>> the range, it would produce an interpretable error like "values for
>> <entry> must be within the range<range>".
> 
> It already does that, that's the point of "->options".

OK. It wasn't clear to me that it did anything. Now I understand that it
actually works.

> 
> 
> 
>> A couple questions about the full d.zoom command.
>> 
>> 1) Is there any reason to put this in the menus? That is, does it do
>> anything that the 2 current menu entries (zoom in current window, and
>> zoom with pan in current window) don't accomplish?
> 
> -h handheld mode, probably mainly used via mouse/stylus input from the
> menus and not entered on the command line from a tiny keyboard if you
> can help it.  I've never used -j, maybe it is useful too?
> 
>  
>> 2) What does the zoom magnification do? It would be nice, I suppose,
>> to be able to zoom to a percentage rather than just using a mouse. But
>> I can't seem to get it to work.
> 
> How fast it unzooms.

This is unclear. The description suggests it will zoom and unzoom. I think
this would be more useful.

> 
>  
>> 3) We lost the pan function with the shift to GRASS 5.7. It would be
>> nice to get it back somehow.
> 
> 'd.zoom -f'  does it, having d.pan as well is just more code to
> maintain for no additional functionality. I guess we could have 'd.zoom
> -p' which goes into pan mode automatically and the menu could call that.
> 
> 
> Perhaps a Zoom submenu which gives the three options:
> 
> - Zoom/Unzoom active display
> - Pan and zoom active display
> - Zoom with bells and whistles

I can do this. It does make sense. To me, an even better set would be

-zoom/unzoom in active display
-pan in active display
-zoom with bells and whistles

> 
> which is a bit better placed than the current postition. As one of the
> most used commands it shouldn't be right at the bottom of a long list.

Your point is well taken. I guess I thought the most used commands should be
at either end of the menu, but not in the middle. I did want to put erase
somewhat away from the other commands so that a user is less apt to hit it
by accident when searching for another command. How about if the zoom
submenu is at the top, followed by nviz, etc, and d.erase is at the bottom.

> maybe relegate "Pan&Zoom" to the bells and whistles one and have two
> options in the submenu.

I think it is better to have an easily accessible pan option in the submenu
than to bury it more in the 'zoom with options'

> 
> 
> This might require adding --parser or --gui (like --html-description) to
> force a GUI box when needed. I think this is what Glynn was considering?
> --no-gui (or --cli) might be a useful control too.
> 
> I don't think d.zoom, d.redraw, d.erase should load GUIs by default, but
> as they can take options sometimes it might be nice to be able to when
> needed.
> 

I agree. 

Neither d.erase nor d.redraw are set up to run through g_parser(). AFAICT,
d.redraw doesn't have any options anyway.

D.erase could be redone to have a dialog to specify redraw color--either by
adding the appropriate option-> code or by scripting. This would be handy
occasionally.

Michael

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