Martin Landa wrote: > > However, this feature cannot be used until the GUI's own requirement > > checking has been adapted to understand it. Currently, if an option > > marked as ->required is omitted but a flag marked as > > ->suppress_required is given, the command itself won't complain about > > the missing option but the GUI will. > > > > The field is included in the --interface-description output; the GUI > > just needs to be updated to make use of it. > ` > done in r44422.
Okay. If people know of more cases where options are being listed as ->required=NO for the sake of special cases, or where certain flags require option=dummy to satisfy the requirements, please mention them (or fix them). There isn't any way to identify such cases mechanically. The situation with g.mapsets will require a more complex solution, i.e. some way to inform the parser that at least one option from a set is required. One possibility is to allow the module to supply a boolean expression involving option/flag names which must evaluate to true. This would allow all of: + At least one of ... must be given + At most one of ... must be given + If ... is given, ... must also be given + If ... is given, ... must not be given However, a more restrictive form might be more useful to the GUI. Specifically, one or more lists of alternatives, where each alternative identifies a primary flag/option, along with any constraints on other options. This would allow a group of radio buttons to be attached to the primary options. E.g. for g.mapsets, the mapset=, addmapset= and removemapset= options would form a group (along with the -s flag and possibly the -l flag). So the user would be able to select exactly one of them, and the others would be greyed out. -- Glynn Clements <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev