[GRASS5] Zoom

[Glynn Clements]

Eric G. Miller wrote:

> > > Personally, I think that the option parser should be significantly
> > > upgraded in 5.1/6.0. Enhancements would include:
> > >
> > > + Option groups (i.e. inter-dependent requirements, rather than each
> > > option independently being either required or not).
> > >
> > > + A more complete type system (rather than just int/float/string,
> > > having e.g. "dimension", "angle", "coordinate pair", "existing raster
> > > map name" etc as distinct types).
> > >
> > > + Improved handling of defaults, especially dynamic defaults.
> > >
> > > This is an area where the overall design would need to be thought
> > > through before it's worth thinking about implementation.
> > 
> > I have already written for g51 new
> > Option * G_define_standard_option (int opt)
> > where opt may be 
> > #define G_OPT_WHERE      0 /* SQL where conditions */
> > #define G_OPT_R_INPUT  100 /* old input raster */
> > #define G_OPT_R_OUTPUT 101 /* new output raster */
> > #define G_OPT_R_MAP    102 /* old input raster */
> > #define G_OPT_V_INPUT  200 /* old input vector */
> > #define G_OPT_V_OUTPUT 201 /* new output vector */
> > #define G_OPT_V_MAP    202 /* old input vector */
> > #define G_OPT_V_TYPE   203 /* primitive type */
> > #define G_OPT_V_FIELD  204 /* field number */
> > #define G_OPT_V_CAT    205 /* one category */
> > #define G_OPT_V_CATS   206 /* more categories */
> > ....

The last one isn't really a primitive type, but a list of the previous
type. For any existing type(s), it should be possible to have lists
and tuples.

> That looks like a good start, but what's the difference between the MAP
> and INPUT versions?  Does the MAP version mean read/write?  Also, the
> V_CATS one doesn't seem useful, since there already is a multiple flag.
> 
> One thing I'd like, is for the tuple types (key_desc), to have type
> flags for each part:
> 
>   opt->key_desc = "foo,bar,baz";
>   opt->key_type = G_option_key_types(3, TYPE1, TYPE2, TYPE3);
> 
> Also, could we consider moving to enum's rather than #defines whenever
> possible.  The two small benefits are possibly better type checking,
> and better debugging support.

Agreed.

> As for the two other main areas:
> 
>   Dynamic options could maybe be handled via callbacks?  How much
>   flexiblity do these really need?  Do they need state information
>   from the parser?  Maybe just a lister function that returns a
>   NULL terminated array of pointers to char?  Mostly I've seen this
>   for display functions wanting to list currently drawn items.

Another case is using the current region settings. E.g. a default
distance which is proportional to the resolution. In this case, this
default could be made a constant by allowing distances to be specified
in "cells".

>   Beyond just the parser, I've been thinking about how to make dialogs
>   currently done with Vask, interface independent.  Now, it doesn't seem
>   too far gone to map the dialogs to XML, but I was also thinking about
>   disconnected round trips for the data and how modules could be stopped
>   and restarted, or otherwise operate such that state could be temporily
>   saved.  
>   
>   I'm thinking about a web interface, for instance.  Currently it's
>   mostly possible to generate an invocation interface for commands, but
>   what if they require further input?  Also, even if we don't go so far
>   as saving/restoring state and handling dialogs, there's no way of
>   knowing if a command will request more input from the user.  That
>   aspect could at least be handled via and "interactive" flag, or some
>   such.

I don't think that it's practical to handle interactive modules in
this way. The only solution is to ensure that all functionality is
available non-interactively. Interactive programs would provide an
alternative interface to that functionality, in environments which
support interaction (i.e. not a web interface; if you wanted an
interactive interface there, you would need to implement it
specially).

-- 
Glynn Clements <glynn.clements at virgin.net>