[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
needed.
Hamish
More information about the grass-dev
mailing list