We also need to add option_rules or something to g.parser so that python scripts can have access to these functions. Something like:
#%option_rules #% exclusive: -a, -b #% requires_all: opt1, opt2, -a #%end On Fri, Jun 20, 2014 at 9:59 PM, Huidae Cho <gras...@gmail.com> wrote: > G_option_excludes() works for me. > > > On Fri, Jun 20, 2014 at 7:58 PM, Glynn Clements <gl...@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 <gl...@gclements.plus.com> >> > >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev