Tcl/Tk and GRASS

[Mark P. Line]

On Mon, 14 Mar 1994, Tom Moore wrote:

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

Perhaps you've misunderstood what I meant. I was talking about _reverse
engineering_ of our current GRASS 4.1 user interface in order to get a
better handle on how best to design a GUI around it. Here, you mention the
re-engineering of core GRASS in terms of OOD: that's something completely
different. All I'm asking for is an approach to a rapidly-developed GRASS
GUI which does not optimize ease of programming at the expense of all else
as such tools as xclip do: it's really easy to cast a GRASS command in
terms of an xclip script, but the result is not necessarily a very good
GUI, all things considered.

The approach I favor would break down GRASS functionality currently
accessible through the standard interactive and non-interactive commands
into more primitive and orthogonal elements, and then organize all those
elements in object-oriented (rather than function-oriented) fashion under
a coherent GUI. This does not imply any kind of re-engineering of the
underlying GRASS 4.1 product, only a more coherent understanding of how
its current user interface works.

Maybe an example would be in order. The commands d.rast, d.vect, d.sites
(among others) cause a map layer to be displayed in the active frame. In a
function-oriented approach, you would select something representing
'd.rast' first, for instance, and then you would select a raster map to be
displayed. In an object-oriented approach, you would first select whatever
map you want to see, than click on "Display", unless you wanted to
override defaults. Once you've selected the map, there's not really any
need for you to say explicitly that you want to display a raster map with
d.rast, a vector map with d.vect and a sites list with d.sites (or
whatever). It would not be difficult to get the GUI to know what database
element a selected map is in, and to run the appropriate command without
further necessary intervention.

The only way such redundancies can be found systematically in the current
GRAS 4.1 user interface is to go and look for them, and write them down:
reverse engineering. 

> While I don't know if such a major change to GRASS
> will ever occur,

Here you're referring to the object-oriented re-engineering of GRASS. As
it happens, Kurt Buehler gave a paper at the last conference in Reston
entitled "Geographic Modeling Framework" on this. It is my understanding
that some future version of GRASS (5.0?) will be based on such an
object-oriented framework. 

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

I agree with this completely. I would design a GUI around the current user
interface without assuming that that interface can be adapted very much to
the needs of the GUI. Given that, though, there is still lots of room for
good GUI design informed by what we know about good human-computer
interaction.

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

If we can get the widget(s) developed and debugged quickly enough, that
is. That's something that should definitely proceed in parallel with the
rest of the GUI development, but I certainly wouldn't want to wait for
that before _any_ display-relevant functionality is made accessible
through the GUI. As far as I'm concerned: we've been working around
XDRIVER for years now, we might as well work around it for another six
months or so until some really bullet-proof Tk widgets are forthcoming
which allow us to circumvent the display driver mechanism altogether.
Until then, I'm quite content to have an application window controlling
one or more XDRIVER windows.

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

Isn't that the same kind of re-engineering you frowned upon above? I would
suggest, as a first cut, providing a widget that can operate as an
XDRIVER. Let the rest of the application talk to that (or to those). Given
such a widget, there's no part of GRASS that can't be recast into the new
GUI in a coherent and seamless fashion, IMO.

> 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 think the day of Swiss army knives with 1,376 utensils has come and
gone. Fortunately. Make orthogonal sets of small, reusable
components -- not monolithic structures that are supposed to be able to do
anything, given enough parameters.

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

My point exactly. That's why I advised against rushing whole-hog into
pressing GRASS non-interactive commands into yet another
hunt-and-hunt-and-hunt-and-hunt-and-point-and-click GUI. I think Tk will
let us explore many more favorable designs.

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

Absolutely correct. Tcl/Tk _is_ a cleverly designed shell.

-- Mark

--------------------------------------------------------------------
Mark P. Line                       Phone: +1-206-733-6040
Open Pathways                        Fax: +1-206-733-6040
P.O. Box F                         Email: markline at henson.cc.wwu.edu
Bellingham, WA 98227-0296
--------------------------------------------------------------------