Re: [GRASS-dev] Added suppress_required field to flags
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Added suppress_required field to flags
Hi, 2010/11/25 Glynn Clements : > 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. Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Added suppress_required field to flags
Glynn wrote:
> "struct Flag" now has a boolean ->suppress_required
> field. If this field is set on a flag, and that flag is given
> on the command line, the parser won't check whether ->required
> options were provided.
see also
https://trac.osgeo.org/grass/ticket/886
that would help avoid some currently "required" options from
actually being set as required. presently some are set as
such just to get the option onto first tab of the GUI. (grumble)
quote:
"""
I propose guisection->_("main") (important|core|primary|...?) as the first
module wxGUI tab, which
* Required=YES options are automatically assigned to,
* and other options can be assigned to it as needed...
the Required tab while usually doing the right thing, is too blunt an
instrument for all cases.
[...]
also this allows to have input= or output= on the front tab even if it can be
optional due to a flag that prints some info to the terminal and exits. Forcing
users to specify output=dummy to overcome Req=YES + --list style flags isn't a
very nice solution, when Req=YES is just there to force the important option on
to the front tab for visibility.
[...]
any more thoughts on this? ie some way to get around some of the wx module gui
usability problems when none of the module's options are (nor should be)
required, or some important non-required ones are hidden away in less obvious
tabs.
I fear for things like m.proj that default to input=stdin that the best
solution from the gui will ultimately be a wrapper script that forces it to
require a real file.
"""
with enough control, we don't have to compromise between focusing
module interfaces to favour GUI or CLI users, as we do now.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Added suppress_required field to flags
"struct Flag" now has a boolean ->suppress_required field. If this field is set on a flag, and that flag is given on the command line, the parser won't check whether ->required options were provided. This will allow options which are normally required to be marked as required even if there are special cases which override this requirement, e.g. a -l (list) flag or other "alternate mode" flags. 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. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
