[GRASS5] some thoughts

[Eric G. Miller]

On Fri, 18 Jan 2002 02:42:55 +0100, Bjorn Roald <bjroald at online.no> wrote:

[snip]
> My experience with GRASS as a user tool concur with Roger's.  The command
> line tools are a blessing as far as giving flexibility, but a curse as far
> as user friendliness for the less experienced user (like myself).  Roger
> wants some tools automating some of the small quirks the experienced user
> does without even thinking of it...  well I have also struggled with the
> monitors in GRASS. Coming from the outside, with no GRASS experienced friend
> to teach me, I find the hole concept rather odd. The fact that they don't
> work right away - does not help.. I am afraid this discourages a lot of
> potential GRASS users, even the ones that rather starts with the command
> line interface than attempting the tcl/tk stuff.

For a little perspective of the monitor scenario, think about the fragmented
nature of proprietary *nix in the 1980's before the standardization on
the X Window System.  It's my understanding, the display system was
developed to be a small simple set of commands for which drivers could
be written specific to the hardware (probably mostly 8-bit color without
any concept of "windows", hence d.frame).

TclTk GRASS is simply a menu systems written around previous/current
GRASS commands.  It's meant to make things a little easier for user's,
but isn't really standalone GUI.

> Glynn is bringing up something that need to be addressed if GRASS is ever
> are going to get a modern UI.  The cost of a modern UI is almost guarantied
> to be less flexibility than the UNIX like command line tools used today.  I
> don't think the community should even think of breaking what you have, to
> get what you want.  And that is why a more layered architecture of the
> libraries and/or tools should be considered.  I think the main thing a
> modern UI can do for GRASS is to increase the user base, and therefore also
> the incentive and award for being a GRASS developer.

I don't think there's a question about wanting to ditch the current display
architechture (and modifying the session management functionality).  It's
a big task to [re]write all the necessary parts to make the core of GRASS
really usable as a flexible backend for GUI's or WWW or whatever.

> 
> Some thought from me:
> 
> layer 1:
> basic current and future GRASS and other libraries

In order for GRASS "libraries" to be even usable as shared object libraries
will probably take considerable rewriting.  They rely heavily on a lot of
global data.  Not to mention, their contents probably need a reorganization.

> layer 2:
> user level libraries e.g. equalent to functionality of command line tools,
> e.g. v.in.mif would use a layer 2 routine called v_in_mif(...) which works
> on generic streams set up by the caller to files, pipes, sockets, or memory.
> Basically, the idea is to move most of the work-horse code into these
> library routines and publish them as a library with a documented and
> supported interface.  UI developers may use layer 2 routines directly.
> Additional layer 2 routines should also support multiple concurrent
> environments.

I essentially agree with this scenario.  My thought are, this part would
basically be broken into two or three related sets of things.

  1.  You have a function entry point that does the task.
  2.  You have a set of "generic" input validation routines.
  3.  You have an interface specification, such that command line, GUI,
      whatever, can be generated.

Such a scenario wouldn't necessarily work with all types of commands, but
I think it'd work for most.  It gets more complex with functionality that
needs to interact with the user more (and modifies its behavior based
on inputs).  Such functionality would probably have to be written specific
for the interface type (at least partially).

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