[GRASS5] Ideas

[Tim Cera]

I have been a list lurker for some time, but now, maybe to the chagrin
of some, I have decided to participate.

I have a couple of ideas that I would like to propose.  If you wish,
these are my grass cuttings.   =:-)

1) Separation of the code from the interface.
Each program has the interface built into it.  What I propose is
something like sci (SCreen Input at http://linuxparts.com/software.html
) where the interface is held separate from the code.  Even though sci
might work unchanged with GRASS, I propose HTML (or XML?) as the
interface language instead of YAF (yet another format).  It would work
something like this:

call html_interface passing name of html file to use
html_interface would do the following:
  parse the html
  create interface based on FORM tags
  fill some of the interface with information (like a pop-up list of
existing raster files)
  return information from filled out form, variable names would be based
on the NAME=var in the HTML, or just var1, var2, ...etc.

I was hoping to create an example, but my C coding skills are too
primitive.

ADVANTAGES:
Trivial internationalization, just replace the HTML with German, or
French, or ?.  Of course the html_interface would have to understand how
to parse and properly display the HTML.

Programming would be easier, you just make one call, instead of the
series of calls made now.

A bunch of people can write HTML.

An interface could be built, based on the HTML files, in any programming
language.

Potential integration with the help in HTML.

Users could customize the interface, add notes, comments, or gotchas by
editing the HTML files.

Could be extended to include error messages (see number 2), mini helps
or howtos,...etc.

DISADVANTAGES:
Bunch o'work.

2) Error messages with help
It would be fantastic to have guidance about what to do after the error
message.  For example, 'rast_reclass' is a r.reclass version of 'rast'. 
If a user attempts an operation on 'rast_reclass' that requires _real_
raster data, the error message should say something like:

  In order to use ? command with rast_rescale, create new raster data
with
  > r.mapcalc new_raster=rast_rescale

followed by an option to take you to help.

This would fit in nicely with number 1 because a error message could be
shared among programs.

3) Move GRASS development to Sourceforge - http://sourceforge.net/
Marcus Neteler has mentioned at least twice about the amount of time
that he spends tracking bugs.  Sourceforge offers CVS repository, bug
tracking, mailing lists, web space,...etc. all for free.

4) All monitors should be stopped automatically if you quit GRASS, or at
least ask if you want to stop all monitors.  I am always starting GRASS
up again to stop monitors.

5) Expose the data structures to a scripting language. Something similar
has been done with MapServer ( http://mapserver.gis.umn.edu/index.html )
called MapScript.

Well, how was that for a first post?  Don't reconfigure your trash
filters yet, I can only get better, maybe.  =:-)

take care
tim cera

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