[GRASS5] Platform for next generation UI

[Daniel Calvelo]

Thanks for the mind sushi, Michael.

I'm not sure I'm hammering the right nail here, but I'd suggest that
whatever the toolkit chosen, we strive first to define a proper
interface/API between the GUI front-end and the traditional CLI
front-end. What I mean is that there is a balance between a) the GUI
driving commands and b) the GUI managing state for the rest of GRASS.

The way the GRASS plugin for QGIS and g.parsers --xml-description
provide a "glue" API between both worlds has its limitations,
especially wrt procedure-oriented vs. data-oriented manipulation.
Thinking out loud, I'd say that the hard job is defining how the
command's published intent is hooked to an interface description, a la
glade or XRC (that's wxWidgets interface description language).

Not sure I'm making much sense. It's late. Bed's calling. Be back later.

Daniel.

On 12/28/05, Michael Barton <michael.barton at asu.edu> 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
>
>


--
-- Daniel Calvelo Aros