[GRASS-dev] Re: [GRASS GIS] #102: new tabs in GUI have required last

[Michael Barton]

On Mar 19, 2008, at 4:24 AM, grass-dev-request at lists.osgeo.org wrote:

> Date: Wed, 19 Mar 2008 06:09:58 -0000
> From: "GRASS GIS" <trac at osgeo.org>
> Subject: [GRASS-dev] Re: [GRASS GIS] #102: new tabs in GUI have
> 	required last
> To: undisclosed-recipients:;
> Message-ID: <051.3c96e54adb8c658dd6ced99152612671 at osgeo.org>
> Content-Type: text/plain; charset="utf-8"
>
> #102: new tabs in GUI have required last
> ----------------------- 
> +----------------------------------------------------
>   Reporter:  cmbarton  |       Owner:  grass-dev at 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