[GRASS5] Interfaces ... (long)

[Glynn Clements]

Another issue related to G_parser() is those programs which initialise
options dynamically (either their default values, allowable values or
descriptions).

These seem to fall into a number of specific cases:

1. D_get_cell_name (d.colors), D_get_{cell,dig,site}_list (several
programs) and other functions (d.save) to obtain state from the
monitor.

2. G_gisbase, G_mapset, G_projection, G_zone, G_get_window and
G_get_set_window to obtain information about the current location.

3. spheroid_list and datum_list. In the case of spheroid_list, many
programs implement this function independently.

4. G_{lat,lon}_format_string, D_color_list. These functions actually
just return string literals.

5. read_list (used by g.{copy,list,remove,rename} to parse
etc/element_list).

Case 1 is problematic as they will fail (even for "help" and
int.desc.) if the there is no monitor running, although Eric (I think)
appears to fixing that.

Both cases 1 and 2 are problematic in that they generate help messages
or interface descriptions which depend upon the context in which they
are run. For example, v.surf.rst does this:

  if (G_get_set_window (&cellhd) == -1)
    exit (0);
  ew_res = cellhd.ew_res;
  ns_res = cellhd.ns_res;
	...
  if (ew_res < ns_res)
    dmin = ew_res / 2;
  else
    dmin = ns_res / 2;
	...
  sprintf (dmaxchar, "%f", dmin * 5);
  sprintf (dminchar, "%f", dmin);
	...
  parm.dmax->answer = dmaxchar;
	...
  parm.dmin->answer = dminchar;

The result is that "v.surf.rst help" says (amongst other things):

	Parameters:
	     input   Name of the vector file with input data
	      dmax   Maximum distance between points 
	             default: 250.000000
	      dmin   Minimum distance between points 
	             default: 50.000000

It should, IMHO, at least provide some indication that these defaults
are for the current location e.g.:

	      dmin   Minimum distance between points 
	             default: 50.000000 (Dynamic)
or even
	      dmin   Minimum distance between points 
	             default: min(ew_res,ns_res)/2

Cases 3, 4 and 5 don't appear to cause these problems, as the values
used seem to be constant. However, they do seem to point to an area
where it might be worth extending G_parser.

Some of these suggest that it might be worth the parser supporting
certain specific types, e.g. from case 2, "projection" and "zone",
from case 3, "spheroid" and "datum", and from case 4 "color" [sic ;)]. 
It also suggests that spheroid_list should be included into libgis.

The programs which use G_{lat,lon}_format_string tend to insert the
format string into an argument's "description" field with sprintf(). 
This leads me to wonder whether it might be worth G_parser()
supporting "macros" in the description field for this sort of thing.

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