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

[Glynn Clements]

Hamish wrote:

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

Maybe we should support opt->gisprompt="color". Then the Tcl/Tk
interface could have a button to display one of those fancy colour
selector dialogs (the sort that allocate the entire colour map in one
go).

For building a usable GUI, the more distinct data types, the better. 
However, there is an issue with modularity here. E.g. d.mon should
have opt->gisprompt="monitor" for the start/stop/select/unlock
options. However, that would require the ability to read the
monitorcap file, which is currently part of libraster.

I suppose that we could have some form of extension mechanism, whereby
individual modules can register handlers for additional types. E.g. 
d.mon would register a handler for the "monitor" type; the handler
would need libraster, but d.mon already needs libraster anyhow.

[On the subject of the monitorcap file, I have some menu.tcl changes
to build the start/stop/select monitors menus from the monitorcap
file, so any additional monitors will become available automatically.]

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

A couple of modules initialise opt->answer dynamically (e.g. based
upon the current region or information stored on the selected
monitor). In that situation, if commands are remembered (scripting,
command history), there's a difference between omitting an option and
explicitly supplying the default value.

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

Yes.

> --no-gui (or --cli) might be a useful control too.

Ideally that shouldn't be necessary; if a command doesn't require any
options (i.e. it doesn't have any options, or they are all optional),
then the GUI should only be displayed if explicitly requested by e.g. 
--gui.

However, the behaviour of d.what.rast, d.zoom etc (i.e. may or may not
require options, depending upon what's on the monitor) is potentially
problematic for scripts. If there doesn't happen to be anything on the
monitor (e.g. because a previous command failed), the script will just
sit there waiting for user input.

There should be an explicit flag meaning "act upon whatever is
displayed on the monitor, and fail if nothing is displayed". Arguably,
this flag should be necessary to obtain the current no-option
behaviour so that, when run without arguments, these programs always
display the GUI.

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

d.erase and d.redraw shouldn't display dialogs when run without
arguments, but should from tcltkgrass (maybe d.erase should have two
menu entries; one uses the default colour, the other displays a
dialog). For the reason mentioned above, I think that d.zoom should
require an explicit flag to get the existing no-option behaviour.

-- 
Glynn Clements <glynn.clements at virgin.net>