[GRASS5] Platform for next generation UI

Wed Dec 28 01:16:49 EST 2005

Among the discussions on the features desired and needed for a next
generation UI for GRASS were a number of posts on interface development
platforms. The overall message was that a sophisticated UI can be developed
with a number of different tool sets. I've tried to look at these in a
systematic manner and have done some research. However, I'm SURE that there
are others who are more knowledgeable than I am on this and I hope that they
can add their perspectives and correct any misconceptions that I might have.
Andy Tai¹s GUI toolkit comparison site is helpful
<http://www.geocities.com/SiliconValley/Vista/7184/guitool.html>, though a
little out of date (Feb 2005 seems the most recent update).

Here are a few of what I think are important criteria to consider to narrow
the field a bit, in no particular order.

We clearly need to use a set of interface development tools rather than
developing a UI 'from scratch' (i.e, in C)--for consistent and better look
and feel, and more importantly so that it can be developed and maintained by
a group of volunteers who can only work on this part time. The latter
issue--maintainability by GRASS team members--is very important. A slick UI
that cannot be maintained by the development community is problematic.

It is highly desirable to have an interface that will run natively on the
major platforms that can run GRASS. Currently, this includes Linux, Mac OS
X, Sun and other Unix?, and Cygwin. The recent success in compiling an
experimental native Windows version means that we should look for something
that also runs natively under Windows.

The tool set should be well-developed and documented, well maintained, and
likely to be maintained into the future. We don't want to be orphaned if we
can avoid it.

The tool set must be open source and compatible with GRASS's GPL license.

It either must already come bundled on the OS platforms with we expect to
run GRASS, or we must be able to distribute it to the extent needed to run
GRASS (i.e., we may not need to distribute the whole tool set for simply
running the application, but we need to be able to distribute whatever is
necessary). 

The tool set must be compatible with the GRASS C code base.

If we are to move beyond the current limited xdriver display, the tool set
needs to be sufficiently richly endowed with proper graphic tools for GIS
display.

Related to this, if we are to maintain GRASS's recent advanced development
of 3D GIS, the tool set needs to be able to use OpenGL (given the feature
discussion that OpenGL is needed for 3D).

It is highly desirable to have a tool set that also will interact well with
SQL databases--particularly SQLite, PostgresSQL, MySQL--and possibly dbf.

-------------------

OK, with that preamble, this is where I think we are at the present. There
seem to be a limited number of interface development tool sets that meet
these criteria. The ones I've found that seem the best AFAICT are: TclTk,
GTK+, Qt, and WxWidgets (formerly WxWindows). Here are a few observations on
each.

TclTk: Everyone knows that GRASS has a large existing investment in TclTk.
However, it is used to a much more limited extent that it could be. The
xdriver could be replaced by a TclTk canvas. TclTk supports OpenGL (it is
used in NVIZ). The new versions (I think 8.4.12 is current, with 8.5 in
beta) have tools to make a MUCH slicker interface than we now have (check
out the screenshots at <http://aspn.activestate.com/ASPN/Tcl/Tk_Contest/>).
There are specific TclTk tool kits for SQLite, and much more (e.g., expect
and tile). To make best use of all of this, we would need to distribute
current TclTk with GRASS (or at least a runtime version if we went with a
compiled UI instead of the non-compiled scripts we use now). Ironically, the
widespread popularity of TclTk has created some problems for GRASS
currently. TclTk comes with most Linux distributions,  Mac OS X, and Cygwin.
But the versions and implementation differ by platform. This has led to
incompatibilities and conflicts (e.g., with 8.4 in some Linux distros and
with the Cygwin version), issues with OpenGL in NVIZ, and dueling versions
in some cases (e.g., if you install Lorenzo's binaries for Mac OS X, you end
up with 3 different versions: the one that comes with OS X, the x11 one, and
TclTk Aqua). If a new UI for GRASS is based on TclTk, it could not simply be
a dependency IMHO; we would need to distribute it with GRASS in order to
make sure that all GRASS users have proper functionality--and we would need
to install it so as to avoid incompatibilities with versions that come with
OS's (e.g., as Lorenzo does by putting it into a grasslib directory). See
<http://www.activestate.com/Products/ActiveTcl/> and
<http://tcltkaqua.sourceforge.net/> for more information

GTK+: GTK+ is widely used in the Linux world, especially for GNOME and GNOME
apps. The best known is GIMP, of course. GTK+ meets all the criteria, except
possibly the cross-platform one. The current version of GTK+ for Linux is
2.9.1. The newest version for Windows is 2.6.9. The Mac version is under
development. There is one project that is built on GTK 1.x; another just
announced seems to be based on a reasonably current version 2.x. However
both are still in development, meaning that any GTK app in the near future
would have to run in x11 on a Mac. Using x11 is not the problem on a Mac
that it is on Windows (i.e., Cygwin). But the need to install x11 and use
non-native apps makes GRASS installation and use considerably less
accessible for the normal Mac user. See <http://www.gtk.org/> for more
information.

Qt: As of last summer, there are GPL versions of Qt for all major platforms
that run GRASS. It meets all interface criteria listed above. There is
already a Qt GIS project with a GRASS plugin--QGIS--that could provide
examples for developing a GRASS UI. Qt seems to be gaining considerable
support for designing interfaces for scientific applications. See
<http://www.trolltech.com/download/qt/x11.html> for more information on the
GPL version of Qt. I¹m not aware of any drawbacks.

WxWidgets: I've only recently come across this tool set. It was mentioned in
posts by Rich Shepard and Joel Pitt. Like Qt, it is a completely
cross-platform tool kit with good support for the kinds of graphic displays
we now use and envision for the next generation GRASS. I've heard good
things about it from other people too. See <http://www.wxwidgets.org/> for
more information and screenshots. I¹m not aware of any drawback with this
platform either.

In summary, current version of TclTk would work well for the next generation
of GRASS, but there are issues to solve with regard to multiple versions and
potential conflicts with versions that come installed with OS's. GTK+ will
accomplish all needed UI functions, but has more limited support for
non-Linux platorms than the other 3 tool kits. This leaves Qt and WxWidgets
as interface development platforms that seem best suited to for the next
generation UI for GRASS. I¹ve only worked with TclTk, so I don¹t have any
feel for the comparative ease or difficulty of working with any of these
platforms for interface development.

That said, the reality is that the availability of people with appropriate
expertise will have a big role in which platform is chosen. A couple of
people have expressed interest in developing a Qt or GTK+ UI; I can continue
to work with TclTk and am willing to help with another platform. But we will
need a team of people both to develop and maintain the UI. If this is the
kind of project that we envision, it will take more than simply the
development of an interface that sits on top of  GRASS as it is now. For
example, if we replace the xdriver with a modern display integrated with the
UI, it will require some degree of rewriting of d.rast, d.vect, and any
other display modules are retained. If we combine 2D and 3D GIS, NVIZ will
need to be rewritten to incorporate OpenGL into the main display. If we do
not go with TclTk, the routines for autogenerating dialogs for modules at
runtime will need to be ported to another platform‹or perhaps they can be
dropped if we can have better GUI/CLI integration. This all will involve
other members of the GRASS team beyond simply UI development. So deciding on
a platform for UI development is more than a simple vote of which one is
preferred, but which is one that the GRASS team will actively support.

I hope this offer you all some food for thought.

Un saludo cordial to all the GRASS team
Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20051227/443eed1d/attachment.html