[GRASS-dev] Re: [GRASS GIS] #886: improve module wxGUI tab logic

[GRASS GIS]

#886: improve module wxGUI tab logic
-------------------------+--------------------------------------------------
 Reporter:  hamish       |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  wxGUI        |     Version:  svn-trunk                
 Keywords:  tabs         |    Platform:  All                      
      Cpu:  All          |  
-------------------------+--------------------------------------------------

Comment(by cmbarton):

 This ticket is seems to be about a couple of different things

 1. The tabs. What argument is on which tab is not needed for the GUI to
 parse a command. However, for proper error trapping and messaging, the GUI
 needs to know which fields are required and which are optional. Already,
 there is a specification for which fields are required and which are
 optional. Trying to use this specification for tabs has always been
 clunky. We should not inherently link (and confuse) *WHICH* tab (i.e.,
 notebook page) an argument or flag goes on in the GUI with whether or not
 the argument or flag is required or not. What would be more sensible would
 be to do the following:

 a) Each command would have a set of tab numbers and name specifications,
 and each named tab would get its own page in a GUI notebook. For example,
 in pseudo code, tab 1="Important things"; tab 2="Other things"; tab
 3="Trival things". This would produce a dialog with 5 tabs (notebook
 pages), one each for the specified tabs 1-3, plus a tab for the command
 output and one for the manual. There may or may not be any arguments or
 flags on tabs 1-3, but the tabs would be generated nonetheless. It is up
 to the programmer who manages a module to name and populate the tabs
 appropriately.

 b) Each argument or flag has a specification as to the *NUMBERED* tab on
 which it is placed. For example, "input" and "output" could go on tab 1,
 while all flags could go on tab 2. But placement is up to the module
 programmer/maintainer. Items that are actually *REQUIRED* should be
 colored, boldfaced, marked with an asterisk, or otherwise noted in some
 standardized way for all of GRASS. But they don't need to always go on the
 first tab (notebook page) or on a tab named "Required". It is a good idea
 to put all required items where they can be easily seen, of course. This
 is usually on tab 1, but there may be cases where it makes more sense to
 place some required items on tab 1 and others on tab 2. It certainly makes
 sense to put some required things and some non-required things under the
 same tab at times. But what is and what is not required should be clearly
 indicated in the GUI.

 2. Command operation. From my perspective, any command that operates by
 waiting for user input into a terminal is problematic not only for the GUI
 but for any kind of scripting. For all GRASS commands to work in a
 consistent fashion such that they can be used by a human from the CLI and
 in a program, they need to run such that input can be entered as a value
 for an argument prior to running the command; the command is then run,
 does its thing, and ends without any further user interaction. This value
 can be a path to a text file and things are still OK. While it is OK if
 commands can accept pipes or redirects, they should not *require* it as a
 way to get needed information into a command. By the same token, using
 'arg=-' as a way to allow interactive user input from the command line is
 OK, as long at it is not the default. IMHO, this is a cleaner and more
 consistent command line usage (i.e,. all commands work alike) than having
 some needing interactive command line input and others not.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/886#comment:7>
GRASS GIS <http://grass.osgeo.org>