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

Hamish hamish_nospam at yahoo.com
Fri Aug 20 23:12:27 EDT 2004

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

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.

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

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

> 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

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.

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

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


More information about the grass-dev mailing list