[GRASS5] proposal for a grass command interface description forautomatic GUI building

[Frank Warmerdam]

Jan-Oliver Wagner wrote:
> With the Option and Key structures we have a base to produce the forms.
> I have modified parser.c to accept a special parameter for generating
> xml specification:
> 
> GRASS:~ > r.basins.fill --task-description
> <task name="r.basins.fill">
>         <parameter-group>
>                 <parameter name="number" type="integer" required="yes">
>                         <description>
>                                 Number of passes through the dataset
>                         </description>
>                 </parameter>
>                 <parameter name="c_map" type="string" required="yes">
>                         <description>
>                                 Coded stream network file name
>                         </description>
>                 </parameter>
>                 <parameter name="t_map" type="string" required="yes">
>                         <description>
>                                 Thinned ridge network file name
>                         </description>
>                 </parameter>
>                 <parameter name="result" type="string" required="yes">
>                         <description>
>                                 Name for the resultant watershed partition file
>                         </description>
>                 </parameter>
>         </parameter-group>
> </task>

Jan-Oliver, 

I really like the fact that these descriptions can be established from the
existing information provided by the programmer to the parser.  

I read over the section of the programmers manual on the parser, and I see 
there is alot more capability there than I had known.  I would encourage 
folks interested in this issue to carefully review all of section 15.16 in 
the manual. 

Some items apparently supported by the parser, but not mentioned by you
are:

 o The key_desc field of the Option structure apparently allows the
   program to descibe an arguments format to some degree.  For
   instance a location might have a key_desc of "x,y", and apparently
   the parser uses this to put two separate items into "answers"
   after parsing, and presumably to prompt the user accordingly. 

   Is this used?  Perhaps we should capture this information to
   support a more rigerously checked forms interface.

 o The multiple field apparently indicates whether the user can
   give multiple answers for an option. 

 o The Gisprompt field can be used to control prompting for particular
   items like an existing raster layer, or a new vector name.  I think
   capturing this is critical so that the generated form can provide 
   comparible prompting in the form of pick lists and so forth. 

 o There is a Checker field where programs can register validation
   functions for parameters.  This doesn't appear to be described any
   further.  I presume it isn't used much?  For programs that do alot
   of programatic validation of parameters after G_parser(), it may be
   helpful to move some of that into the Option and then a forms based
   application could launch the program in a special non-interactive mode
   that just validates the parameters.  This is likely not worth pursuing
   on the first pass. 

It seems likely that once we start generating forms automatically we will
discover that many programs have not fully utilized the above options to
inform the parser of the program arguments definitions, and that we will
have to patch them up a bunch.  This should be helpful even for traditional
use of the programs. 

We should (I think) also keep our minds open to the possiblity of extending
the Option structure if necessary to return additional useful information. 

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerda at home.com
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'