[GRASS5] some thoughts

[Bjorn Roald]

Eric G. Miller, wrote Friday, January 18, 2002 4:08 AM

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

Thanks for the insigt on monitor scenario and TclTk GUI! I guess I already
had figured most of this out.  But it is always good to have the history of
things in mind.

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

I agree,
The first question to ask is:

Is there really any point?

Maybe what some of us want GRASS to become is better served by other "free"
software, existing or emerging.

If the answer to that is NO, then everybody may be served by a GRASS
development focusing on increased functionality, rather than better
usability as stand along application or building blocks.  GRASS would then
continue to appeal to its limited user base, but never become/or be part of
any mainstream application.  It is just not simple enough to use.

If the  answer is YES:  Well then I think the important thing is to get the
architectural issues in place as well as the tools the individual programmer
needs.  As long as the existing functionality is not broken, the need for a
complete re-work of every module by any set deadline is not critical.  If
the tools are easy to use (and understand), and they add something to the
existing system, such as better robustness, then I think re-writing the
modules for the new design as they come by becomes natural.  Eventually at
some point, somebody will take the task of getting everything cleaned up.
So what are these tools, I think the code structure, make system and naming
conventions are central.  But also stuff like error/exception handling,
error reporting system, debug tracing....

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

I think functionality that need to interact with the user while it is
executing, such as v.digit, need to be split up at the library level.  The
hole idea is then that this will facilitate new UI support for the same
tasks.  The old UI may be completely scrapped in exchange with something new
and better.

As for GUI support, think it is vice to use a "strategy" pattern for support
of GUI interaction at the library level.  Without knowing the details, I
don't think the GRASS sources nesseserially are that far of the mark.  But I
have a feeling there are a "lack of feature" problem.  The idea is to
possibly be able to support multiple GUI and graphical libraries.  I am not
asking for everybody, or anybody, to jump into multi target development (in
the sense of GUI/and graphical libraries, not hardware/OS platform).  The
point is to insulate the libraries from changes in the application code
utilizing it.  If GRASS libraries are becoming mainstream building blocks,
then they will need to be adaptable into applications using various
graphical engines, existing and future such.  Using a "strategy" pattern
will hopefully protect the libraries against major re-write every time new
technology arises.

----
Bjorn Roald, mailto://bjroald@online.no