[GRASS5] Platform for next generation UI

[Wolf Bergenheim]

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