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