[GRASS-dev] [GRASS-SVN] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raster/r.neighbors raster/r.out.bin raster/r.quant raster/r.resamp.filter raster/r.series raster/r.series.accumulate raster/r.series.interp raster/r.stats.quantile vector/v.colors vector/v.external.out

[Glynn Clements]

Huidae Cho wrote:

> I assume G__check_option_rules() is supposed to be called by G_parser().
> Then, instead of calling G_fatal_error, it should append errors to
> st->errors.

Okay; I presume that the intent is so that it will report all errors,
not just the first.

> If so... for g.mlist we can define two different versions of
> rules:
> 
> This version prints more correct errors because only present options/flags
> will be displayed in errors, but too much typing.
>     G_option_exclusive(flag.regex, flag.extended, NULL);
>     G_option_exclusive(flag.pretty, flag.full, NULL);
>     G_option_exclusive(flag.pretty, opt.output, NULL);
>     G_option_exclusive(flag.pretty, flag.mapset, NULL);
>     G_option_exclusive(flag.pretty, flag.type, NULL);
>     G_option_exclusive(flag.full, opt.output, NULL);
>     G_option_exclusive(flag.full, flag.mapset, NULL);
>     G_option_exclusive(flag.full, flag.type, NULL);
> 
> This version is shorter, but -p -f will print three errors including
> options/flags not present.
>     G_option_exclusive(flag.regex, flag.extended, NULL);
>     G_option_exclusive(flag.pretty, flag.full, opt.output, NULL);
>     G_option_exclusive(flag.pretty, flag.full, flag.mapset, NULL);
>     G_option_exclusive(flag.pretty, flag.full, flag.type, NULL);
> 
> Can we implement something like
> G_option_exclusive(pretty, full, G_option_or(output, mapset, type))
> ?

I'd rather stick to "flat" rules rather than heading in the direction
of generalised boolean expressions.

Not because it's hard to implement, but because it makes it harder to
utilise the information.

The next logical step is to include the rules in the
--interface-description output so that the GUI can convey the
relationships to the user. E.g. mutually-exclusive options might use
radio buttons, or greying-out excluded options. Options which are
required by another option could be marked as "required" when a value
is given for the first option. And so on.

Realistically, that requires that the rules belong to a finite set of
patterns.

> pretty, full, and any of output, mapset, and type are mutually exclusive,
> but output, mapset, and type are not exclusive.

How about another rule type:

>     G_option_excludes(flag.pretty, opt.output, flag.mapset, flag.type, NULL);
>     G_option_excludes(flag.full,   opt.output, flag.mapset, flag.type, NULL);

where the first option excludes all remaining options.

This is essentially the negation of G_option_requires().

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