[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

[Huidae Cho]

G_option_excludes() works for me.


On Fri, Jun 20, 2014 at 7:58 PM, Glynn Clements <glynn at gclements.plus.com>
wrote:

>
> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140620/e6a1307a/attachment.html>