[GRASS-dev] Re: [GRASS-SVN] r33885 - grass/trunk/include

[Glynn Clements]

Martin Landa wrote:

> >> is it really necessary to recover this macro? It's only one used here.
> >> If so maybe we should define other standard gisprompts in the similar
> >> way (e.g. "old,vector,vector", "old_dbcolumn,dbcolumn,dbcolumn",
> >> etc.).
> >
> > After it was removed, much of display/d.* failed to compile (30 uses
> > in 17 modules). Before it can be removed, anything which uses it needs
> > to be converted to use either an equivalent G_define_standard_option(),
> > or the literal string.
> 
> sorry, I have overlooked that. Anyway, is it better to define
> 
> #define GISPROMPT_COLOR    "old,color,color"

It should probably be "color,color,color".

In 7.0, it doesn't matter. Apart from the GUI, the value of the
->gisprompt field is only significant in terms of whether the first
component is "new". If any option has "new", then the --o[verwrite]
flag is included in the help text, interface description, etc.

In 6.x, the ->gisprompt field affects the terminal-based interaction
which occurs if GRASS_UI_TERM is set and you don't provide any
arguments. If the age is "old", then it will use G_ask_old(); if the
age is unrecognised, it will just prompt for a string.

> and other standardized gisprompts in gis.h
> 
> or just remove GISPROMPT_COLOR and fix the all modules by using
> G_define_standard_option()?

Using G_define_standard_option() is preferable. Apart from anything
else, it will mean less work if we subsequently change the Option
structure.

-- 
Glynn Clements <glynn at gclements.plus.com>