[GRASS5] Platform for next generation UI

[Michael Barton]

Hi Wolf,

Thanks very much for the comments AND for the interest in working on the UI.
I agree about the priority of UI design. However, I wanted to put out some
information on toolkits because we've spent the past couple months talking a
lot about UI design--but people continue to bring up toolkits too. I
summarized a lot of the UI design information in my post of a couple days
ago and posted on my website
<http://www.public.asu.edu/~cmbarton/files/grass_ui>.

I also was surprised at the UI quality for current TclTk. If we do use it,
as you say, I don't know how much of the current code we would want to port
over because I think (hope) that we are looking at a pretty different design
concept. A couple of drawbacks to TclTk are the competing versions issue I
mentioned yesterday and the (AFAIK) comparative lack of interactive, GUI
design environments for the platform (visual TclTk is kind of old). Still,
the fact that GRASS already uses a lot of TclTk code means that it might be
possible to implement some parts of a new UI in stages rather than having to
do the whole thing at once. While I could probably do a lot more initially
in TclTk than in another platform, I simply don't have the ability (that is,
I don't have the time to learn the expertise) to start this from
scratch--even in TclTk--I feel I need to be kind of neutral about platforms
at the moment, and see what the overall response is.

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



> From: Wolf Bergenheim <wolf+grass at bergenheim.net>
> Date: Wed, 28 Dec 2005 20:53:47 +0200
> To: Michael Barton <michael.barton at asu.edu>
> Cc: grass5 <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Platform for next generation UI
> 
> Hi,
> 
> Thanks for the summary, Michael.
> 
> The first thing that we should do even before we decide on a toolkit is
> IMHO a UI design. At http://openusability.org/ we could register GRASS
> and look for usability experts. Then when we have a snazzy UI design we
> implement it with whatever toolkit we feel we can do the job.
> 
> Now a few words about the toolkit. I was really surprised with what one
> can do with TclTk, I'm impressed. I'm familiar with the other three
> candidates, and at first I thought that yuck, let's get away quickly
> from this TclTk, but now that I have seen that it really seems to be
> possible to make it look native and modern on all platforms I'm actually
> voting for it. We might not be able to reuse much code, but since we are
> familiar with TclTk, we can make better progress (both faster and better
> quality). I'm not at all familiar with TclTk, but I've wanted to learn
> it, and now I think that I have a nice excuse (;, but I'm still not a
> GUI developer, but would be interested in helping out. Especially the
> interface to the command line. All the d. commands should IMO be
> something that will pass commands to the GUI, this is something that I'd
> be interested in developing.
> 
> --Wolf
> 
> On 28/12/05 08:16, Michael Barton wrote:
>> 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
>> 
>> 
>>