[GRASS5] Zoom

[Eric G. Miller]

On Thu, May 02, 2002 at 09:23:29AM +0200, Radim Blazek wrote:
> On Tuesday 30 April 2002 07:28 pm, Glynn Clements 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 */
> ....

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.

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.

  The option group support will take some more thinking.  There are
  a couple things going on there:  Group A is exclusive of Group B,
  and options A1 and A2 of Group A are required, if Group A is used,
  otherwise if Group B is used, only option B1 is required... Then,
  there's the possibility of groups that aren't exclusive, or some
  mixture.  And maybe groups are optional, but if included, at least
  some parts become required...  While working this out is somewhat
  complicated, there are several modules that could benefit.  This
  kind of thing maps well onto XML via a DTD.  I could imagine the
  parser inlining a DTD with the --xml-description.  I'd like to 
  see a way to pass back an XML "document" containing the selected
  options (maybe a dispatching command that could verify the
  input before executing the real command).

  Maybe it'd be useful to approach the input options as if they were
  always XML based, and then craft a solution that maps those to the
  parser interface.  I've been ruminating over this for a little bit,
  and was considering that rather than replace G_parser()  with a 
  slighty modified variant, that maybe an alternative interface could
  be implemented, and when working, migrate modules over.  
  
  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.

Anyway, that's enough rambling for now...

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