Tcl/Tk and GRASS

[Mark P. Line]

DISCLAIMER (one lesson learned): I sometimes criticize existing software:
hopefully always constructively, but that's not strictly possible if I
believe that the "philosophy" underlying a piece of software is not the
way I think it should be, since it's generally impossible to "adjust" the
software to a different philosophy. No such criticism has any bearing
whatsoever on the merits or demerits of any designer, programmer or agency
involved in producing the software.

On Tue, 8 Mar 1994, Mr J D Stocks wrote:

> Anyone had any further thoughts about this GUI?

I've started staring deeply into Tk. Nice. 15 widget classes, about the
ones every application needs as a core set. Formulating an large GUI in
its entirety directly in Tk will become somewhat tedious, but not anywhere
nearly as tedious as programming directly against X widgets in C.

Since it is the primary bone of contention as regards GUI development for
GRASS, I have also started staring deeply into XGRASS. The more a stare,
the less I like it. The reason is relatively simple to state, but
difficult to explain without demonstration. The reason is that XGRASS is
function-oriented, not object-oriented, in its underlying user interface
paradigm. By this I do *not* mean that it doesn't use point-and-click
"objects" just like other GUI's: it does. What I mean by function vs.
object orientation has to do with the way the user approaches (is forced
by the GUI to approach) a given problem. 

In a function-oriented approach, you decide on what it is you want to
*do*, then refine that down until you have a command you can execute (cf.
the default xgrass menu):

    I want to do something having to do with a monitor.
    I want to display something.
    I want to display something deriving from a raster map.
    I want to display a raster map.
    I want to display PERMANENT at elevation.dted.

Contrast this with an object-oriented approach in which the number of
things you might possibly want to do is greatly constrained once you've
chosen the object (map layer, for instance) you're interested in:

    I want to do something with PERMANENT at elevation.dted.
    I want to display it.

Fortunately, there is a trend for GUI's to become more object-oriented in
this sense. The HCI work I'm familiar with certainly makes a strong case
for the object-oriented paradigm, and this is the way I think a GRASS GUI
should be designed.

> Steps:
> 
> 1. Email to grassu-list your current progress on this. (Gille Clement
> I understand is demosntrating his stuff at the GRASS User conference) Sounds
> good.

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.

> 2. Establish our standards - Fonts, colors, etc. Also, what is our front
end going to look like? 

In keeping with the conventions of the rest of the X world, I think that
fonts and colors should be handled through defaults and user
cusomizations. Since they can be customized so easily, I wouldn't try to
put too much energy into deciding on "standards". It would be much better,
I think, to simply standardize the way in which the defaults would be
implemented in Tk, and pretty much leave it at that for the time being.

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.

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