[GRASS-dev] Re: Re: [GRASS GIS] #156: new attribute in Option struct to allow conditional options requirement

I'll respond here with an idea because I'm not sure if it quite fits in the
this track ticket yet, but am happy to add it in for future reference if all
think I should.

Why not have one field that defines the order of the tabs and one that
defines the tab label? I haven't dug into the TclTk code that parses these,
but it can't be that hard to change it to account for this. The same goes
for the wxPython parser code. It would probably simplify a LOT of things in
the parser.

Michael

On 5/5/08 7:37 AM, "grass-dev-request@lists.osgeo.org"
<grass-dev-request@lists.osgeo.org> wrote:

Message: 8
Date: Mon, 05 May 2008 07:23:47 -0000
From: "GRASS GIS" <trac@osgeo.org>
Subject: [GRASS-dev] Re: [GRASS GIS] #156: new attribute in Option
struct to allow conditional options requirement
To: undisclosed-recipients:;
Message-ID: <050.e05a2c6a873960813873d075d37a086f@osgeo.org>
Content-Type: text/plain; charset="utf-8"

#156: new attribute in Option struct to allow conditional options requirement
----------------------+-----------------------------------------------------
  Reporter: martinl | Owner: grass-dev@lists.osgeo.org
      Type: task | Status: new
  Priority: major | Milestone: 7.0.0
Component: default | Version: svn-trunk
Resolution: | Keywords: parser, required, conditional
----------------------+-----------------------------------------------------
Comment (by hamish):

Martin:

This can be solved with a new attribute in Option struct
which tells the parser not to worry about testing all required
options=

..

f_flag->suppress_required=YES;

i.e. a new attribute in the '''Flag''' struct.

other (shorter) ideas what to call it.....
{{{
flag->runandexit
flag->reqnotreq
flag->skip_req
flag->ignore_req
...
}}}

Hamish

--
Ticket URL: <#156 (new attribute in Option struct to allow conditional options requirement) – GRASS GIS;
GRASS GIS <http://grass.osgeo.org>

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael,

2008/5/5 Michael Barton <michael.barton@asu.edu>:

Why not have one field that defines the order of the tabs and one that
defines the tab label? I haven't dug into the TclTk code that parses these,
but it can't be that hard to change it to account for this. The same goes
for the wxPython parser code. It would probably simplify a LOT of things in
the parser.

I am not quite sure here, I think it is not necessary to define order
of tabs in that way. In the best case flags/parameter should be
grouped based on guisection (or logical connection) when defining
Flag/Option instances. See d.vect where flags/parameters are grouped
by guisection. It means to keep some kind of consistency between CLI
module usage description and GUI dialogs (tab order).

BTW, in wxPython code, tabs are reordered ('required' tab is always
the first one [1]).

Martin

[1] http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/gui_modules/menuform.py#L853

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *