Hi,
Well, there are no equivalent functions in python yet. Other than that, I think this new API is functionally satisfying and r.clump is using it. The patch looks good to me. BTW, I prefer option= and -f.
Regards,
Huidae
···
On Tue, Jul 22, 2014 at 1:53 PM, Anna Petrášová <kratochanna@gmail.com> wrote:
On Wed, Jun 25, 2014 at 2:09 AM, Huidae Cho <grass4u@gmail.com> wrote:
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
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Fri, Jun 20, 2014 at 9:59 PM, Huidae Cho <grass4u@gmail.com> wrote:
G_option_excludes() works for me.
On Fri, Jun 20, 2014 at 7:58 PM, Glynn Clements <glynn@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@gclements.plus.com>
Hi,
is this new API now stable enough to be actually used in C modules? Should we start to replace the manual checks in modules with these functions? BTW, documentation is still missing.
I attached a patch which should fix this ticket [1]: when user doesn’t type any command arguments and the module has no explicitly required options (like g.region), it checks if there is any RULE_REQUIRED and if yes, it opens GUI dialog.
Also I would consider a little bit better error message, the name of the option is not very visible in the sentence. Perhaps using quotes or <> around the option would help. Also, “Option myoption1 requires at least one of myoption2” sounds weird, perhaps there should be special handling of cases when there is just one option required. These are just details.
Thanks,
Anna