[GRASS5] Interfaces ... (long)

Eric_G_Miller · June 28, 2001, 6:41am

As some of you may know, I've been monkeying around with the XML
interface thing that Jan put together (thanks Glynn for fixing that
printf bug). Anyway, I have some changes or proposals I'd like to
submit. I've categorised them in order of importance and ease of
implementation. I apologize if I've made some assumptions about
SGML/XML knowledge.

Simple and Necessary:

  * Currently the "gisprompt" and "key_desc" parts of the Option
     group are ignored. Both are very important for providing a user
     with the correct interface. I submit that these changes should be
     added as attributes of the "parameter" element right away.

  * There needs to be a way to handle interactive programs. I'll have
     more on this later, but perhaps there should be an attribute of
     "task" for flagging interactive *only* programs. Some programs
     may run as command line, but prompt for user input. This latter
     case is more difficult, but for the time being they could all be
     specified as "interactive" and a front-end that couldn't accomodate
     that could drop the "task" from its list. TclTkGrass has a
     mechanism to spawn an xterm for these, but that wouldn't be viable
     for a browser interface... For the simple yes/no interactive, this
     could be added to the GModule struct (name, description,
     interactive?).

Simple and better semantics:

  * Currently the "parameter" element is used both for Options and
     Flags. From a parsing stand point, it makes life slightly more
     difficult. Also, most of the attributes and child elements of the
     "parameter" element do not apply to Flags and would be erroneous if
     present (e.g. "required=", "multiple=", "<default>",
     "<values>,<value>"). A flag is always "off" by default, and is
     almost never required (more on this later), can't be specified
     multiple times, and has no set of possible values.

I propose separating the flag element from the parameter element.

<!ELEMENT flag description?>
<!ATTLIST flag name CDATA #REQUIRED>

<!ELEMENT parameter-group (description?, (parameter | flag)+)>

  * Currently the DTD does not enforce that if there is a "default"
      element and a set of "value" elements, that the default be a
      member of the set of "values". It may be better to have an
      attribute of "value" that has default property, or to let
      "default" occur once in the "values" set. The latter is probably
      easier and more logically correct. NOTE: DTD's can't really say
      much about the content of elements, only the structure (XML
      Schemas *can* speak to content, but it is only recently adopted).
      But the G_usage_xml() could clearly handle the latter case, and
      it'd help any front end. This change is less important, but a
      good idea IMHO.

More Work and More Complex:

  * In some modules there is a clear dependency/conflict relationship
      between various flags and options. In cases I've encountered, it
      often seems to be, you can run the command with a, b, c or with a
      and d (but not b and c). I think it would be valuable to be able
      to capture this inter option/flag dependency, as better interfaces
      could be generated. I don't have a fully formulated suggestion
      for this one, but it would require some significant changes.

      One way to look at them, is to create an option/flag grouping.
      This should be feasible within the current DTD framework as more
      than one "parameter-group" can exist for a given task. However,
      the "parameter-group" is probably too high up the chain, as we
      would probably not want to have to duplicate common options for
      each parameter-group.

      One way to change this in the DTD, would be to allow "parameter"
      and "flag" elements to exist as direct children of "task" and only
      use "parameter-group" when a set of options should be grouped
      together *and* conflict with any other parameter-group. The
      G_parser() system would have to have a way to specify this
      information. There could be the concept of a OptionGroup, and
      individual options could be added to OptionGroups.

      Another way to approach, might be to add a mechanism to specify
      more complex dependency/conflict relationships between options
      before calling G_parser(). That is there'd be a functions like:
      G_parser_depends (OptionOfInterest, OptionRequired),
      G_parser_conflicts (OptionOfInterest, OptionConflicts)
      There'd be some interaction with the "required" member for Options
      which would need to be considered. For instance, if a "global"
      option has "opt->required = YES", then another option can't
      conflict with it. Nor, could one option require an option that
      requires a third option that conflicts with the first. I'm not
      sure how you'd specify this in a DTD...

This kind of dependency/conflict stuff can't get a bit hairy, but
it would provide the ability to create better user interfaces.

Pipe Dream:

  * Returning to the problem of interactive programs...
      This gets alot deeper into system architecture concepts, but it is
      extremely important if we agree there should be a mechanism for
      separating the interface from the implementation.

      It's clear there needs to be a mechanism for a running module to
      prompt for user action, but be able to do so in a way not tied to
      any particular implementation (like Vask or the various G_ask_*
      listing routines both which assume a terminal, and the first
      assumes "curses"). We could return to XML to provide such
      mechanisms (or at least the specifications), but it will take some
      thought and alot of work to realize.

      There are different types of user interaction that are often
      required. The simplest to deal with would probably be the Vask
      case where the user is prompted to fill out "form" type data.
      But, the program would have to know it wants to dump out a form
      specification, rather than a curses interface *and* the program
      would have to have to ability to restart where it left off
      (consider the nature of http -- the module would have to exit,
      then be restarted when it was called again with the form data
      "posted").

      Even if we solved the above, what about display programs that take
      direction via "mouse clicks", or something of the nature of
      v.digit? Here the interaction is of a different sort, and it
      wouldn't do for the modules to stop and start.

I don't have much for suggestions on this last one, but it is
something to consider longer range.
--
Eric G. Miller <egm2@jps.net>

From neteler Thu Jun 28 11:06:50 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id LAA08485; Thu, 28 Jun 2001 11:06:50 +0100
Date: Thu, 28 Jun 2001 11:06:50 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5 developers list <grass5@geog.uni-hannover.de>
Subject: Script engine - was: Re: [GRASS5] Driver Update
Message-ID: <20010628110649.K1927@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5 developers list <grass5@geog.uni-hannover.de>
References: <15144.45297.673435.379639@cerise.nosuchdomain.co.uk> <20010614161829.B18856@hgeo02.geog.uni-hannover.de> <15145.8392.320239.598657@cerise.nosuchdomain.co.uk> <20010625171204.G18370@hgeo02.geog.uni-hannover.de> <15159.51431.130059.539081@cerise.nosuchdomain.co.uk> <15159.60464.129470.381175@cerise.nosuchdomain.co.uk> <20010626093823.I19099@hgeo02.geog.uni-hannover.de> <15160.51173.144087.254495@cerise.nosuchdomain.co.uk> <20010626231305.A27722@hgeo02.geog.uni-hannover.de> <15161.6350.757343.78528@cerise.nosuchdomain.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15161.6350.757343.78528@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Wed, Jun 27, 2001 at 12:20:46AM +0100
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 1641
Lines: 38

On Wed, Jun 27, 2001 at 12:20:46AM +0100, Glynn Clements wrote:
[...]

> Thanks for pointing this out. The general problem in GRASS is
> the odd mixture of old and new code... as we all know already.

Having said that, all scripts suffer from the drawback that they don't
generally behave like other GRASS programs. I've recently been
thinking about creating a utility specifically for running scripts.

One possibility would be a modified tclsh which includes key libgis
functions (e.g. G_parser) as tcl commands. However, I don't know
whether tcl is sufficiently widely available to be able to justify
using it in place of the Bourne shell.

Another possibility would be a simple utility which could be invoked
by shell scripts to handle the G_parser() stuff before re-invoking the
script with a full argument list (unless "help" or "--int*-desc*" were
used). However, this could still leave incompatibilities between C
programs and scripts in other areas.

Comments?
--
Glynn Clements <glynn.clements@virgin.net>

...for platform independency and due to the unknown future of tcl/tk I
vote for option (2): a simple utility which could be invoked by shell
scripts to handle the G_parser() stuff before re-invoking the script.

If an C-based (?) environment would be present to support own script
developments, less later work to reach consistency is to be expected.
Even other GIS have script-builders, so why not GRASS. Maybe some
compulsory definitions at top of the script could be interpreted to
define the settings for G_parser, description text etc. Then the
script stuff follows.

Markus

Glynn_Clements · June 28, 2001, 5:55pm

Eric G. Miller wrote:

  * In some modules there is a clear dependency/conflict relationship
      between various flags and options. In cases I've encountered, it
      often seems to be, you can run the command with a, b, c or with a
      and d (but not b and c). I think it would be valuable to be able
      to capture this inter option/flag dependency, as better interfaces
      could be generated. I don't have a fully formulated suggestion
      for this one, but it would require some significant changes.

I think that it would be worth doing, though. I've already encountered
a few cases where the assumption that the options' "required"
attributes are independent is a nuisance. Currently you have to
specify that none are required and then signal an error if a suitable
combination isn't used.

An example would be for programs which operate on red, green and blue
maps (e.g. d.rgb, r.composite). It would be useful to allow either

d.rgb r=red g=green b=blue
or
d.rgb input=image

with the latter using e.g. "image.r", "image.g" and "image.b".

      One way to look at them, is to create an option/flag grouping.
      This should be feasible within the current DTD framework as more
      than one "parameter-group" can exist for a given task. However,
      the "parameter-group" is probably too high up the chain, as we
      would probably not want to have to duplicate common options for
      each parameter-group.

      One way to change this in the DTD, would be to allow "parameter"
      and "flag" elements to exist as direct children of "task" and only
      use "parameter-group" when a set of options should be grouped
      together *and* conflict with any other parameter-group. The
      G_parser() system would have to have a way to specify this
      information. There could be the concept of a OptionGroup, and
      individual options could be added to OptionGroups.

      Another way to approach, might be to add a mechanism to specify
      more complex dependency/conflict relationships between options
      before calling G_parser(). That is there'd be a functions like:
      G_parser_depends (OptionOfInterest, OptionRequired),
      G_parser_conflicts (OptionOfInterest, OptionConflicts)
      There'd be some interaction with the "required" member for Options
      which would need to be considered. For instance, if a "global"
      option has "opt->required = YES", then another option can't
      conflict with it. Nor, could one option require an option that
      requires a third option that conflicts with the first. I'm not
      sure how you'd specify this in a DTD...

      This kind of dependency/conflict stuff can't get a bit hairy, but
      it would provide the ability to create better user interfaces.

The most general case would be to allow the dependencies to be
specified as a boolean expression, e.g.

input OR (red_map AND green_map AND blue_map)

However, this isn't necessarily the best method for generating a UI.
For that, explicit groups might be better, e.g.

  input_opt->required = GROUP;
  input_opt->group = 1;
  input_opt->subgroup = 1;

  r_opt->required = GROUP;
  r_opt->group = 1;
  r_opt->subgroup = 2;

  g_opt->required = GROUP;
  g_opt->group = 1;
  g_opt->subgroup = 2;

  b_opt->required = GROUP;
  b_opt->group = 1;
  b_opt->subgroup = 2;

This would result in a GUI where the group has a set of radio buttons
to choose which subgroup was active, e.g.

<*> Input [ ]

  < > Red [ ]
      Green [ ]
      Blue [ ]

This is basically the boolean case restricted to a "sum of products"
form.

  * Returning to the problem of interactive programs...
      This gets alot deeper into system architecture concepts, but it is
      extremely important if we agree there should be a mechanism for
      separating the interface from the implementation.

      It's clear there needs to be a mechanism for a running module to
      prompt for user action, but be able to do so in a way not tied to
      any particular implementation (like Vask or the various G_ask_*
      listing routines both which assume a terminal, and the first
      assumes "curses"). We could return to XML to provide such
      mechanisms (or at least the specifications), but it will take some
      thought and alot of work to realize.

      There are different types of user interaction that are often
      required. The simplest to deal with would probably be the Vask
      case where the user is prompted to fill out "form" type data.
      But, the program would have to know it wants to dump out a form
      specification, rather than a curses interface

The existing Vask interface could remain largely unchanged. V_call()
would become a "switcher" which selects the correct input mechanism.
Similiarly for G_ask().

The main requirement is that programs only use the designated
functions to interact with the user, i.e. using G_ask() rather than
fprintf() and fgets() (or whatever).

A similar issue applies to information and warning messages (i.e. use
of G_warning() rather than writing to stderr).

      *and* the program
      would have to have to ability to restart where it left off
      (consider the nature of http -- the module would have to exit,
      then be restarted when it was called again with the form data
      "posted").

This is where interactive programs fall down. To my mind, the only
solution is to ensure that all useful processing functionality is
available in a non-interactive manner.

      Even if we solved the above, what about display programs that take
      direction via "mouse clicks", or something of the nature of
      v.digit? Here the interaction is of a different sort, and it
      wouldn't do for the modules to stop and start.

      I don't have much for suggestions on this last one, but it is
      something to consider longer range.

v.digit is a special case, as it is basically a data-entry mechanism.

The cases where it might be worth changing programs to fit a more
general framework are where interaction is combined with some form of
computation.

As an example, consider d.measure. It might be worthwhile having one
program which can take a list of x,y coordinates and computed
distances and areas, and a separate program which can generate those
coordinates from user input.

In order to make mouse-driven programs fit any kind of framework, I
think that we would need to perform an audit of such programs to
determine the kind of data which they are trying to obtain, and the
type of feedback that is required in obtaining that data.

If common patterns were to emerge, it might be possible to separate
the interactive portion into routines which could obtain certain types
of data (e.g. paths, boxes, site lists). These could then form part of
any GUI front-end.

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

Glynn_Clements · June 28, 2001, 7:15pm

Another issue related to G_parser() is those programs which initialise
options dynamically (either their default values, allowable values or
descriptions).

These seem to fall into a number of specific cases:

1. D_get_cell_name (d.colors), D_get_{cell,dig,site}_list (several
programs) and other functions (d.save) to obtain state from the
monitor.

2. G_gisbase, G_mapset, G_projection, G_zone, G_get_window and
G_get_set_window to obtain information about the current location.

3. spheroid_list and datum_list. In the case of spheroid_list, many
programs implement this function independently.

4. G_{lat,lon}_format_string, D_color_list. These functions actually
just return string literals.

5. read_list (used by g.{copy,list,remove,rename} to parse
etc/element_list).

Case 1 is problematic as they will fail (even for "help" and
int.desc.) if the there is no monitor running, although Eric (I think)
appears to fixing that.

Both cases 1 and 2 are problematic in that they generate help messages
or interface descriptions which depend upon the context in which they
are run. For example, v.surf.rst does this:

  if (G_get_set_window (&cellhd) == -1)
    exit (0);
  ew_res = cellhd.ew_res;
  ns_res = cellhd.ns_res;
  ...
  if (ew_res < ns_res)
    dmin = ew_res / 2;
  else
    dmin = ns_res / 2;
  ...
  sprintf (dmaxchar, "%f", dmin * 5);
  sprintf (dminchar, "%f", dmin);
  ...
  parm.dmax->answer = dmaxchar;
  ...
  parm.dmin->answer = dminchar;

The result is that "v.surf.rst help" says (amongst other things):

  Parameters:
       input Name of the vector file with input data
        dmax Maximum distance between points
               default: 250.000000
        dmin Minimum distance between points
               default: 50.000000

It should, IMHO, at least provide some indication that these defaults
are for the current location e.g.:

        dmin Minimum distance between points
               default: 50.000000 (Dynamic)
or even
        dmin Minimum distance between points
               default: min(ew_res,ns_res)/2

Cases 3, 4 and 5 don't appear to cause these problems, as the values
used seem to be constant. However, they do seem to point to an area
where it might be worth extending G_parser.

Some of these suggest that it might be worth the parser supporting
certain specific types, e.g. from case 2, "projection" and "zone",
from case 3, "spheroid" and "datum", and from case 4 "color" [sic ;)].
It also suggests that spheroid_list should be included into libgis.

The programs which use G_{lat,lon}_format_string tend to insert the
format string into an argument's "description" field with sprintf().
This leads me to wonder whether it might be worth G_parser()
supporting "macros" in the description field for this sort of thing.

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

Helena_Mitasova · June 29, 2001, 12:32am

Glynn Clements wrote:

Another issue related to G_parser() is those programs which initialise
options dynamically (either their default values, allowable values or
descriptions).

These seem to fall into a number of specific cases:

1. D_get_cell_name (d.colors), D_get_{cell,dig,site}_list (several
programs) and other functions (d.save) to obtain state from the
monitor.

2. G_gisbase, G_mapset, G_projection, G_zone, G_get_window and
G_get_set_window to obtain information about the current location.

3. spheroid_list and datum_list. In the case of spheroid_list, many
programs implement this function independently.

4. G_{lat,lon}_format_string, D_color_list. These functions actually
just return string literals.

5. read_list (used by g.{copy,list,remove,rename} to parse
etc/element_list).

Case 1 is problematic as they will fail (even for "help" and
int.desc.) if the there is no monitor running, although Eric (I think)
appears to fixing that.

Both cases 1 and 2 are problematic in that they generate help messages
or interface descriptions which depend upon the context in which they
are run. For example, v.surf.rst does this:

  if (G_get_set_window (&cellhd) == -1)
    exit (0);
  ew_res = cellhd.ew_res;
  ns_res = cellhd.ns_res;
        ...
  if (ew_res < ns_res)
    dmin = ew_res / 2;
  else
    dmin = ns_res / 2;
        ...
  sprintf (dmaxchar, "%f", dmin * 5);
  sprintf (dminchar, "%f", dmin);
        ...
  parm.dmax->answer = dmaxchar;
        ...
  parm.dmin->answer = dminchar;

The result is that "v.surf.rst help" says (amongst other things):

        Parameters:
             input Name of the vector file with input data
              dmax Maximum distance between points
                     default: 250.000000
              dmin Minimum distance between points
                     default: 50.000000

It should, IMHO, at least provide some indication that these defaults
are for the current location e.g.:

              dmin Minimum distance between points
                     default: 50.000000 (Dynamic)
or even
              dmin Minimum distance between points
                     default: min(ew_res,ns_res)/2

or even better
default: 50.000000, min(ew_res,ns_res)/2
or 50.000000, half the cell size
(for those who may not know what ew_res means)

because often when I run help I would like to know what the default
would be for my particular region/resolution. but there are also
situations
when the user wants to know what the command does in general - and
then it would be good to know that it depends on resolution.
When this was set up we idealistically assumed that everybody who wants
to use this program will read the manual where the default is described.
I guess that this should be considered for 5.1???

Helena

Cases 3, 4 and 5 don't appear to cause these problems, as the values
used seem to be constant. However, they do seem to point to an area
where it might be worth extending G_parser.

Some of these suggest that it might be worth the parser supporting
certain specific types, e.g. from case 2, "projection" and "zone",
from case 3, "spheroid" and "datum", and from case 4 "color" [sic ;)].
It also suggests that spheroid_list should be included into libgis.

The programs which use G_{lat,lon}_format_string tend to insert the
format string into an argument's "description" field with sprintf().
This leads me to wonder whether it might be worth G_parser()
supporting "macros" in the description field for this sort of thing.

--
Glynn Clements <glynn.clements@virgin.net>
_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5

Bernhard_Reiter · June 29, 2001, 9:09am

Eric:

it is good that you are on the subject, unfortunatly
jan and myself might not have enough time right now to participate
in the discussion.

(But as it is all archived, we'll get back to it.)
Bernhard

On Wed, Jun 27, 2001 at 11:41:26PM -0700, Eric G. Miller wrote:

I've been monkeying around with the XML
interface thing that Jan put together (thanks Glynn for fixing that
printf bug). Anyway, I have some changes or proposals I'd like to
submit.

Eric_G_Miller · July 7, 2001, 11:27pm

I've made a few of the minor alterations to XML interface that I
previously mentioned. If everyone is cool with these changes, then I'll
commit them (it will break the proof-of-concept dialog generator that
Jan built).

Changes:

   * There is now a distinct element called "flag" separate from
     "parameter". It takes an attribute "name", and has an optional
     child element for the "description".

   * Make both "flag" and "parameter" be children of "task" directly.
     This is now the default output, however the DTD still has the
     "parameter-group" with children "description", "parameter", and
     "flag". It is retained for the future possibility of having
     groups of mutually exclusive options. I started to implement such
     a thing, but it would require almost a complete rewrite of
     parser.c.

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

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

Example (s.to.vect --interface-description):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE task SYSTEM "grass-interface.dtd">
<task name="s.to.vect">
  <description>
    Converts a GRASS site_lists file into a vector file.
  </description>
  <parameter name="input" type="string" required="yes" multiple="no">
    <description>
      Name of site input file
    </description>
    <gisprompt age="old" element="site_lists" prompt="site list" />
  </parameter>
  <parameter name="output" type="string" required="yes" multiple="no">
    <description>
      Name of vector output file
    </description>
    <gisprompt age="new" element="dig" prompt="vector" />
  </parameter>
  <parameter name="cat" type="string" required="no" multiple="no">
    <description>
      Field type ("string", "dim", or "decimal") and index to use for category value (uses "cat" by default)
    </description>
    <keydesc>
      <item order="1">type</item>
      <item order="2">index</item>
    </keydesc>
  </parameter>
  <flag name="p">
    <description>
      Don't prompt for Map header information
    </description>
  </flag>
</task>

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

Jan-Oliver_Wagner1 · July 9, 2001, 10:23am

On Sat, Jul 07, 2001 at 04:27:43PM -0700, Eric G. Miller wrote:

I've made a few of the minor alterations to XML interface that I
previously mentioned. If everyone is cool with these changes, then I'll
commit them (it will break the proof-of-concept dialog generator that
Jan built).

will update the dialog generator.
Will other scripts be broken?

Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

Eric_G_Miller · July 9, 2001, 2:55pm

On Mon, Jul 09, 2001 at 12:23:13PM +0200, Jan-Oliver Wagner wrote:

On Sat, Jul 07, 2001 at 04:27:43PM -0700, Eric G. Miller wrote:
> I've made a few of the minor alterations to XML interface that I
> previously mentioned. If everyone is cool with these changes, then I'll
> commit them (it will break the proof-of-concept dialog generator that
> Jan built).

will update the dialog generator.
Will other scripts be broken?

Great. I'm not aware of anything else in the GRASS sources using this
XML interface yet. I've hacked on a few things personally, but I can
update those. I'm hoping to put together a GTK+ "command launcher" type
thing. So far, I have a part that builds a tree list of GRASS commands
with "tooltips". I want to plug in a terminal emulator, html man page
reader, dialog generator, and a few other things, but I'm just learning
this GTK stuff...

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

From neteler Mon Jul 9 19:46:50 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id TAA21247; Mon, 9 Jul 2001 19:46:50 +0100
Date: Mon, 9 Jul 2001 19:46:50 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5 developers list <grass5@geog.uni-hannover.de>
Message-ID: <20010709194650.A21114@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5 developers list <grass5@geog.uni-hannover.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [GRASS5] Anti-spam question
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 276
Lines: 11

Hi all,

at time it is very silent here - is there a technical problem?

BTW: I have switched on local anti-spam filter software for
my personal account, in case of problems please let me know
(perhaps notify a German colleague who may call me on phone).

Thanks

Markus

Jan-Oliver_Wagner1 · July 10, 2001, 7:02am

On Mon, Jul 09, 2001 at 07:55:54AM -0700, Eric G. Miller wrote:

On Mon, Jul 09, 2001 at 12:23:13PM +0200, Jan-Oliver Wagner wrote:
> On Sat, Jul 07, 2001 at 04:27:43PM -0700, Eric G. Miller wrote:
> > I've made a few of the minor alterations to XML interface that I
> > previously mentioned. If everyone is cool with these changes, then I'll
> > commit them (it will break the proof-of-concept dialog generator that
> > Jan built).
>
> will update the dialog generator.
> Will other scripts be broken?

Great. I'm not aware of anything else in the GRASS sources using this
XML interface yet.

please inform me as soon as you have done your changes so I can
follow with the wxPython dialog generator.

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

Jan-Oliver_Wagner1 · July 11, 2001, 10:10am

On Sat, Jul 07, 2001 at 04:27:43PM -0700, Eric G. Miller wrote:

I've made a few of the minor alterations to XML interface that I
previously mentioned. If everyone is cool with these changes, then I'll
commit them (it will break the proof-of-concept dialog generator that
Jan built).

Changes:

   * There is now a distinct element called "flag" separate from
     "parameter". It takes an attribute "name", and has an optional
     child element for the "description".

   * Make both "flag" and "parameter" be children of "task" directly.
     This is now the default output, however the DTD still has the
     "parameter-group" with children "description", "parameter", and
     "flag". It is retained for the future possibility of having
     groups of mutually exclusive options. I started to implement such
     a thing, but it would require almost a complete rewrite of
     parser.c.

the dialog generator is updated to handle the new way of flags.

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

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?

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

Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

Eric_G_Miller · July 11, 2001, 12:12pm

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@jps.net>

From neteler Wed Jul 11 15:32:01 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id PAA03817; Wed, 11 Jul 2001 15:32:01 +0100
Date: Wed, 11 Jul 2001 15:32:01 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5 developers list <grass5@geog.uni-hannover.de>
Message-ID: <20010711153201.E1885@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5 developers list <grass5@geog.uni-hannover.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [GRASS5] Releasing GRASS 5.0.0final?
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 358
Lines: 12

Hi all,

suprisingly it is very silent here since a few days... summertime?
Although there are a few (known) bugs, I feel it is time to
release GRASS 5.0.0final and to start with 5.1.0 then.

Too much important changes are waiting and I don't expect that
we get 5.0.0 fully bug free.

If there are no objections, I will tag 5.0.0final the next days.

Markus