[GRASS-dev] [GRASS GIS] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#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>