[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]

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 <grass4u at gmail.com> wrote:

> 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/20140625/2d674c0c/attachment.html>