On Mar 19, 2008, at 4:24 AM, grass-dev-request@lists.osgeo.org wrote:
Date: Wed, 19 Mar 2008 06:09:58 -0000
From: "GRASS GIS" <trac@osgeo.org>
Subject: [GRASS-dev] Re: [GRASS GIS] #102: new tabs in GUI have
required last
To: undisclosed-recipients:;
Message-ID: <051.3c96e54adb8c658dd6ced99152612671@osgeo.org>
Content-Type: text/plain; charset="utf-8"#102: new tabs in GUI have required last
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.3.0
Component: default | Version: unspecified
Resolution: | Keywords:
-----------------------+----------------------------------------------------
Comment (by hamish):FWIW I don't really see the point in putting options in a Required tab
using the guisection control. That info is already supplied by the
opt->required parser switch.I'm not completely sold on putting all parser required options in the
front tab. I would be happy if those options were just bolded.
(I can see the problem with something like d.vect where you would have to
hunt for them in lots of tabs, annoying)For r.colors, v.in.ascii the input can come from stdin which is why those
input filenames are not required by the parser, although piping to stdin
isn't really an option from a GUI window.I am not sure about the wxPython GUI but for the TclTk one IIRC tabs are
created in the order their options arrive, with flags having the first
pass, and all sorts of other funny rules. I think it is bad policy to do a
lot of option reordering to make the tabs look nice.
IMO they should be
grouped in logical order when viewed serially from the help page. Special
care must be taken with the first option as users may expect it to be the
optional "opt=" from the command line. see trac task #88.
The only reason to have the tabs at all is to present the options in the most easily and logically accessible way to users via the GUI. In fact this is the only reason for the parser options section. The order of the manual is a pretty good guide in general. Beyond that, the options that users always have to fill out (e.g., input map for r.colors) should be presented first and most easily to users. Ones that are least likely to be used should be last. FWIW, in some cases, there is nothing wrong with reordering the option descriptions in the manual to put them in more logical order (e.g., when new, but critical, options may have been tacked onto older descriptions) if appropriate.
Michael
2c,
Hamish