#1778: Typing in g.region without parameters does not open a g.region window ----------------------------------------+----------------------------------- Reporter: pvanbosgeo | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: g.region, r.colors, r.mask | Platform: Linux Cpu: x86-64 | ----------------------------------------+-----------------------------------
Comment(by glynn): Replying to [comment:14 annakrat]: > So we need options to have another field (something like 'group_required') which tells the parser that the certain options belong to a group of options where one of them has to be specified by the user. Would it be complicated to implement? The main complication is that someone will need to modify a very large number of modules to have them declare their requirements. If we're going to all that trouble, it would be better to finish the job. As well as the case where at least one of a group of options must be supplied, it's also common for certain options to be mutually exclusive, or for certain options to require other options. In all cases, there may be multiple such relationships. If the information on the relationships between options was supplied to the parser, not only could the parser perform such checks automatically, but it would be able to supply the information to the GUI. So the GUI could display this information to the user, e.g. by adding radio buttons to options which belong to an "exactly one of" group, and/or greying out options which have been excluded by the use of other options. To have the parser perform checking, it would be enough to specify the requirements as a boolean expression which must evaluate to true. But that's hard for the GUI to translate into visual cues, and it's also hard to produce useful error messages if the requirements aren't met. So we really need a more restrictive form, but still something which is flexible enough to handle the majority of the inter-dependencies between options. As to exactly what that form should be, we really need some input from the GUI developers. -- Ticket URL: <http://trac.osgeo.org/grass/ticket/1778#comment:17> GRASS GIS <http://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev