<HTML>
<HEAD>
<TITLE>Platform for next generation UI</TITLE>
</HEAD>
<BODY>
<FONT FACE="Helvetica, Verdana, Arial"><SPAN DEFANGED_STYLE='font-size:12.0px'>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 <a href="http://www.geocities.com/SiliconValley/Vista/7184/guitool.html"><http://www.geocities.com/SiliconValley/Vista/7184/guitool.html></a>, though a little out of date (Feb 2005 seems the most recent update).<BR>
<BR>
Here are a few of what I think are important criteria to consider to narrow the field a bit, in no particular order.<BR>
<BR>
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.<BR>
<BR>
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. <BR>
<BR>
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.<BR>
<BR>
The tool set must be open source and compatible with GRASS's GPL license. <BR>
<BR>
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). <BR>
<BR>
The tool set must be compatible with the GRASS C code base.<BR>
<BR>
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.<BR>
<BR>
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).<BR>
<BR>
It is highly desirable to have a tool set that also will interact well with SQL databases--particularly SQLite, PostgresSQL, MySQL--and possibly dbf.<BR>
<BR>
-------------------<BR>
<BR>
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.<BR>
<BR>
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<BR>
<BR>
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.<BR>
<BR>
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 <a href="http://www.trolltech.com/download/qt/x11.html"><http://www.trolltech.com/download/qt/x11.html></a> for more information on the GPL version of Qt. I’m not aware of any drawbacks.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
I hope this offer you all some food for thought.<BR>
<BR>
Un saludo cordial to all the GRASS team<BR>
Michael<BR>
</SPAN></FONT><SPAN DEFANGED_STYLE='font-size:12.0px'><FONT FACE="Verdana, Helvetica, Arial"><BR>
__________________________________________<BR>
Michael Barton, Professor of Anthropology<BR>
School of Human Evolution and Social Change<BR>
Arizona State University<BR>
Tempe, AZ 85287-2402<BR>
<BR>
phone: 480-965-6213<BR>
fax: 480-965-7671<BR>
www: <a href="http://www.public.asu.edu/~cmbarton">http://www.public.asu.edu/~cmbarton</a> <BR>
<BR>
</FONT></SPAN>
</BODY>
</HTML>