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
