Tcl/Tk and GRASS

GRASS GRASS user
1

Hello all,

Anyone had any further thoughts about this GUI?

I have received lots of info from people about this subject recently.

We need to gather together those interested in developing it.

We also need to ascertain what has already been done.

e.g., Gille Clement & Janne Soimasuo, Finland.

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.

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

3. We put out a list of the GRASS commands that have TCL scripts so far,
and what is needed.

4. Users familiar with TCL write their scripts, and contribute.

This way, we can ensure that we don't reinvent any wheels. It is at least the
best way I can think of to get this task completed, and to facilitate
global cooperation on it.

Jeremy Stocks,

University of Wales,
Bangor.

2

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@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@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@henson.cc.wwu.edu
Bellingham, WA 98227-0296
--------------------------------------------------------------------

3

In <Pine.3.07.9403081239.B14222-d100000@henson.cc.wwu.edu> markline@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 :wink:
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@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

4

On Mon, 14 Mar 1994, Tom Moore wrote:

In <Pine.3.07.9403081239.B14222-d100000@henson.cc.wwu.edu>
markline@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@henson.cc.wwu.edu
Bellingham, WA 98227-0296
--------------------------------------------------------------------