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

[Eric G . Miller]

On Fri, Oct 20, 2000 at 02:32:32PM -0500, Frank Warmerdam wrote:
> 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.

I've seen it used in one or two places. Essentially defines a "tuple".
 
>  o The multiple field apparently indicates whether the user can
>    give multiple answers for an option. 

Several modules use this.

>  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. 

This is usually used for input/output file validation
(noclobber/existence checks). Also widely used, and should be used
whenever possible.

>  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. 

Haven't seen anything using this.  Most modules I've looked at do there
checking after the call to G_parser().  You can't check for interactions
between parameters (or things that won't be known until after a "file"
is opened). And, you still will have to convert the parameter later
(though the TYPE_<foo>) macros should catch wrong type arguments (??)).
 
> 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. 

My general thoughts are, modules could be turned into little mini
libraries (and dlopen'ed) if all main.c and main() did was pass
validated arguments to a function defined in another file.  Then the
files/functions the do the work could be separated into little shared
libraries like 's.to.rast.so.5.0.1'.  I'd think it'd make writing GUI's
easier and it'd minimize the use of things like system() which can't
return much useful information.  Just a thought.

AFAIK, glade uses an XML file for libglade (just an example).  There's
also this ENTITY thing, but it's still pretty early development.

-- 
/bin/sh ~/.signature:
Command not found

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