On Mar 19, 2008, at 4:24 AM, [EMAIL PROTECTED] wrote:
Date: Wed, 19 Mar 2008 06:09:58 -0000
From: "GRASS GIS" <[EMAIL PROTECTED]>
Subject: [GRASS-dev] Re: [GRASS GIS] #102: new tabs in GUI have
required last
To: undisclosed-recipients:;
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="utf-8"
#102: new tabs in GUI have required last
-----------------------
+----------------------------------------------------
Reporter: cmbarton | Owner: [email protected]
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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
