[GRASS5] Interfaces ... (long)

[Eric G. Miller]

On Wed, Jul 11, 2001 at 12:10:34PM +0200, Jan-Oliver Wagner wrote:
[snip]
> >    * Add a "keydesc" element as an optional child of "parameter".  This
> >      corresponds to the "key_desc" member of an Option struct.  It has
> >      children called "item", each with an attribute of "order" so that
> >      the proper ordering can be insured for the "tuple".
> 
> I am not sure whether this type of paramter is useful anyway.
> I realize that it makes command line shorter.
> However, the type (eg string,float) of the single elements could
> not be identified this way. To my  mind such comma-separated lists
> are better be treated as groups of parameters.
> I realize this would mean changes in parser.c and for many grass commands.

I agree it is not the best.  It doesn't seem to be used that often for
its intended purpose, but the general concept of a "tuple" type in
conjunction with the "multiple=YES" ability does make some sense.  But,
without the ability to specify type info for each part, it doesn't
really do what it could.  The parser just makes sure the number of items
in the comma separated list are an even multiple of the key_desc
argument, but the program still just pulls each item from the "answers"
member.  It does make sense though, when multiple=YES and grouping needs
to occur.  In other cases, the idea of the parameter group is probably a
better fit.

> No solution to handle this in the GUI has come to my mind that I liked.
> Any proposals?
> BTW, it seems that some commands define key_desc with a single
> entry - what is the idea behind this?

I think it's a misapplication of the intended purpose, and I would
ignore any single item key_desc.  But, with multiple, a set of input
text areas could be used, like a record entry in a database system...
The front-end, at this point, could at least make sure even multiples
for each element are completed and could use the item names for column
headings.  Make any sense?

   parameter                         # The parameter name
       -------------------------
       | item1 | item2 | item3 |     # The key_desc headings
       -------------------------
       | val1  | val2  | val3  |     # Tuple 1 of values
       -------------------------
       | val4  | val5  | val6  |     # Tuple 2 of values
       -------------------------
       ...                           # etc, ...
       ...                           
       ...
       
Which would translate to a command having:

     parameter=val1,val2,val3,val4,val5,val6,...

There are practical limitations involving the maximum length of a
command line.  Some programs provide for getting the list from a file
rather than on the command line.  This type of thing starts to overlap
with what would be better provided with generic database table handling
routines.

> >    * Add a "gisprompt" element as an optional child of "parameter".
> >      This is an empty element corresponding to "gisprompt" of the Option
> >      struct.  It has three required attributes:
> > 
> >        + "age" - The "age" part of the gisprompt argument ("old", "new",
> >        		"any", or "mapset")
> >        + "element" - The mapset "element" part of the gisprompt
> >                	argument ("cell", "dig", "site_lists", etc...)
> >        + "prompt" -  What should be displayed to the user for a prompt.
> 
> No good idea came to my mind how to handle this in the gui generator.
> Also, I am not sure whether I have understood the concept of
> gisprompts.

It's for prompting for database elements.  TclTkGRASS already has a
dialog mechanism for this.  Sort of like a generic file browse dialog,
but limited to selecting entries from mapset elements, such as "cell",
which could be listed from entries in "cell_hd" for each of the mapsets
in the current mapset search path.  This, I think, would be very useful
to implement.  In interactive mode, the parser calls various G_ask
routines to collect this information, each responding to a "list"
directive.  An analog would need to be written for any GUI, since the
G_ask_* routines are stdin/stdout based.  The "age" and "element" are
limited, whereas the "prompt" could be whatever:

  For "age":
     "old" -- The database item must already exist
     "new" -- The database item must not exist yet.
     "any" -- The database item may already exist (typically will get
              overwritten if it is selected)
     "mapset" -- The database item must exist in the current mapset
                  (typically for modules that modify a mapset element
		   in place)

  For "element":
     "cell" -- A raster
     "fcell" -- An FCELL raster
     "dig"  -- A vector
     "site_lists" -- A sites file
     ....
     (there are several possibilities)

There doesn't seem to be any way to prompt for any old file in the
filesystem.  From a console perspective, that seems fine, but from a
GUI, it'd probably be good to have a way to indicate regular file browse
is desired.

-- 
Eric G. Miller <egm2 at jps.net>