<div dir="ltr"><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 25, 2014 at 2:09 AM, Huidae Cho <span dir="ltr"><<a href="mailto:grass4u@gmail.com" target="_blank">grass4u@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">We also need to add option_rules or something to g.parser so that python scripts can have access to these functions. Something like:<div>
<br></div><div><div><div>#%option_rules</div><div>#% exclusive: -a, -b</div>
<div>#% requires_all: opt1, opt2, -a</div><div>#%end</div></div><div><br></div><div><br></div></div></div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 9:59 PM, Huidae Cho <span dir="ltr"><<a href="mailto:grass4u@gmail.com" target="_blank">grass4u@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">G_option_excludes() works for me. </div><div>
<div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Fri, Jun 20, 2014 at 7:58 PM, Glynn Clements <span dir="ltr"><<a href="mailto:glynn@gclements.plus.com" target="_blank">glynn@gclements.plus.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
Huidae Cho wrote:<br>
<br>
> I assume G__check_option_rules() is supposed to be called by G_parser().<br>
> Then, instead of calling G_fatal_error, it should append errors to<br>
> st->errors.<br>
<br>
</div>Okay; I presume that the intent is so that it will report all errors,<br>
not just the first.<br>
<div><br>
> If so... for g.mlist we can define two different versions of<br>
> rules:<br>
><br>
> This version prints more correct errors because only present options/flags<br>
> will be displayed in errors, but too much typing.<br>
> G_option_exclusive(flag.regex, flag.extended, NULL);<br>
> G_option_exclusive(flag.pretty, flag.full, NULL);<br>
> G_option_exclusive(flag.pretty, opt.output, NULL);<br>
> G_option_exclusive(flag.pretty, flag.mapset, NULL);<br>
> G_option_exclusive(flag.pretty, flag.type, NULL);<br>
> G_option_exclusive(flag.full, opt.output, NULL);<br>
> G_option_exclusive(flag.full, flag.mapset, NULL);<br>
> G_option_exclusive(flag.full, flag.type, NULL);<br>
><br>
> This version is shorter, but -p -f will print three errors including<br>
> options/flags not present.<br>
> G_option_exclusive(flag.regex, flag.extended, NULL);<br>
> G_option_exclusive(flag.pretty, flag.full, opt.output, NULL);<br>
> G_option_exclusive(flag.pretty, flag.full, flag.mapset, NULL);<br>
> G_option_exclusive(flag.pretty, flag.full, flag.type, NULL);<br>
><br>
> Can we implement something like<br>
> G_option_exclusive(pretty, full, G_option_or(output, mapset, type))<br>
> ?<br>
<br>
</div>I'd rather stick to "flat" rules rather than heading in the direction<br>
of generalised boolean expressions.<br>
<br>
Not because it's hard to implement, but because it makes it harder to<br>
utilise the information.<br>
<br>
The next logical step is to include the rules in the<br>
--interface-description output so that the GUI can convey the<br>
relationships to the user. E.g. mutually-exclusive options might use<br>
radio buttons, or greying-out excluded options. Options which are<br>
required by another option could be marked as "required" when a value<br>
is given for the first option. And so on.<br>
<br>
Realistically, that requires that the rules belong to a finite set of<br>
patterns.<br>
<div><br>
> pretty, full, and any of output, mapset, and type are mutually exclusive,<br>
> but output, mapset, and type are not exclusive.<br>
<br>
</div>How about another rule type:<br>
<br>
> G_option_excludes(flag.pretty, opt.output, flag.mapset, flag.type, NULL);<br>
> G_option_excludes(flag.full, opt.output, flag.mapset, flag.type, NULL);<br>
<br>
where the first option excludes all remaining options.<br>
<br>
This is essentially the negation of G_option_requires().<br>
<span><font color="#888888"><br>
--<br>
Glynn Clements <<a href="mailto:glynn@gclements.plus.com" target="_blank">glynn@gclements.plus.com</a>><br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br></blockquote></div><br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">
Hi,<div><br></div><div>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.</div><div><br>
</div>
<div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks,</div><div>Anna</div><div><br></div><div><br></div><div>[1]<a href="http://trac.osgeo.org/grass/ticket/1778">http://trac.osgeo.org/grass/ticket/1778</a><br></div><div><br></div></div></div>