Tcl/Tk and GRASS

[Tom Moore]

In <Pine.3.07.9403081239.B14222-d100000 at henson.cc.wwu.edu> markline at henson.cc.wwu.edu (Mark P. Line) writes:

>Insofar as Gille's stuff is based on xclip, and xclip is based on the
>existing function-oriented paradigm of the command-line interface of
>GRASS, I would be inclined to believe that such an approach might be
>quick to implement, but not necessarily what I would favor as a GUI.

Gilles Clement has made two seperate and distinct contributions
using GRASS and Tcl/Tk.  The first is a  Tk GRASS display widget.
This is not a complete replacement for the GRASS display driver,
but it provides a lot of useful functionality for people who are
considering using the Tcl/Tk toolkit to develop graphical users
interfaces to grass applications.  Gilles' widget is called 'View'.
As far as I know it is display only, it cannot be used to run commands
such as r.what.  It only possesses the ability to show a 2D display,
so it does not replace the functionality of d.3d.  It does provide a 
functionality similar to a standard grass display and d.raster and
a few of the other display commands (lines, sites).  What is unique 
about this widget is that it is aware of its own state.  If you modify 
the widget (for example, by resizing it) it is smart enough to know 
what images need to be redisplayed, and in what order.  You can tell 
the widget to zoom, or to pan.  You can ask the widget what images 
it is currently displaying, and it will reply by passing information
back into the Tcl shell environment.

The other contribution is a translator that converts xclip specifications
into tcl/tk scripts.  I would say that this is a very convenient
translator that will help people who are interested in getting quickly 
up to speed in using Tcl/Tk with GRASS.  ALthough I am sure that the 
Tcl/Tk scripts that will be generated will be faithful to the original
XGRASS style, this might not represent the best approach to the design
of graphical user interface to GRASS using Tcl/Tk.  However it is there,
it is quick, and it is done.

There are several 'levels' at which we can discuss object-oriented vs.
feature-oriented design.  Allow me to make two distinctions:  a 'systems
programming' level and an 'applications programming' level (this may be
vintage jargon but bear with me, I am getting old and creaky ;-)
I would say that the widget that Gilles has produced is objected-oriented
at a systems programming level.  The View command creates instances of
the view widget, and each widget maintains its own state and responds
to appropriate messages.  View widgets also properly handle the class
messages for all tk widgets, and thus are well behaved tk citizens.

The View widget could be used to assemble applications that are objected-
oriented at the applications level.  We are beginning to proto-type
a few decision support tools that integrate our custom made simulation
models with a few grass commands and with the view widget.  We are
adopting a 'object-message' approach (as opposed to a verb-object approach)
where it seems appropriate.  This is possible in part because the
underlying toolkit and set of widgets was designed (from a systems
point of view) to make this easy.

>Other areas of look-and-feel would be more important to standardize: the
>object-oriented vs. function-oriented approach as mentioned above, for
>instance; an inventory of reusable components, such as a mapset/file
>browser; a standard way of using the 'expect' package to interface with
>interactive commands like v.digit; across-the-board functionality such as
>a history mechanism (hopefully also object-oriented) or an undo operation.

>Note that parcelling out existing GRASS commands for contributed coding of
>the GUI sort of prejudices the GUI towards a function-oriented approach. I
>think a certain amount of reverse engineering might be in order before
>deciding how to break down all of GRASS into little easily-codable chunks.

Good points, I agree 100%.  However, it would require a lot of time and $$$
to take the bull by the horns and re-engineer some of the core GRASS
mechanisms towards an OO design.  This is obviously not something that 
the grass community can expect to happen just for the sake of a user 
interface toolkit.  While I don't know if such a major change to GRASS
will ever occur, significant value using Tcl/Tk can be gained with 
marginal effort.  I think it is a question of how much gets 'loaded'
into something like the View widget, vs. how much is left in the
original grass environment.  For example, any command which is 
non-interactive and does not use a GRASS display is probably fine
just as it is.  Any command that interacts with the GRASS display is
a candidate to be integrated into a widget.  Following this logic
would mean that a complete Grass Tk widget would have to know not 
only how to display 2D datasets, but how to translate from screen
to geographic coordiantes, how to drape datasets across DEM's, and 
would have to know about illumination angles, etc.  You would end up 
having a very large, complex widget (the kitchen sink syndrome).  
I don't know if this is a good or bad idea, I can think of arguments 
for both sides.

I expect that the likely course of development will be the emergence
of a variety of tk grass widgets, all exhibiting different strengths
and weaknesses.  Perhaps we need a bit more time to see what problems
we are up against and what creative solutions are available.

As far as having an object-oriented approach to using GRASS the GIS, 
maybe this is something that can be done through a cleverly designed 
shell.

Tom
--
Tom Moore                                       tmoore at pnfi.forestry.ca
Petawawa National Forestry Institute            
Canadian Forest Service, Box 2000, Chalk River  +1 (613) 589-3048
ONT K0J 1J0  CANADA                             +1 (613) 589-2275 telefax