[GRASS-dev] v.digit: Qt or wxWidgets

[Trevor Wiens]

On Sat, 20 May 2006 13:14:32 -0700
Michael Barton <michael.barton at asu.edu> wrote:

> I am very much in favor of continuing to develop and improve the GRASS GUI.
> Since we've come back to the question of GUI platforms, I have a question
> that might help to clarify things somewhat.
> 
> Why do we need/want switch from TclTk? After working with it for the past
> several months and seeing the kind of work that Cedric Shock has done, I'm
> very impressed. 
> 
> TclTk is completely open source--no licensing issues (unlike QT).
> It is very cross-platform, with mature versions--largely in sync--available
> on all platforms that run GRASS (unlike GTK+).
> The versions have a native look on different platforms. With Tile being
> included in version 8.5 (currently in active beta and far along), this will
> get even better with multiple themed looks for all platforms.
> It is being actively developed. I think it's gone from 8.4.5 to 8.4.13 in
> the last year, and 8.5 appears nearing final release.
> It is relatively easy to program in (even I can do it). This makes it easier
> to find developers among the volunteers that maintain GRASS
> It has API's and libraries for C (unlike wxWidgets)--and for other languages
> including Java.
> There are sophisticated extensions that we could use if we wanted (for
> tables, SQLite, XML, SWIG, SOAP, etc.).
> The Togl widget allows it to use OpenGL and do so very efficiently. NVIZ
> rendering always blows people away who are used to ArcGIS.
> 
> I'm sure there are limitations, but I don't know what they are or whether
> they are or are not relevant for a GRASS GUI. Any slowness in the displays
> with the new TclTk canvases is primarily due to GRASS display drivers, not
> TclTk. If the icons look amaturish, it is because they are made by an
> amature (me). I've seen screenshots of other TclTk application that are very
> slick.
> 
> Because I want GRASS to have a very good UI, I am not opposed to moving to a
> new GUI development platform. But it would be helpful to understand the
> reasons for doing so.
> 

I would second Michael on this. At first I thought the thing to do was
to dump tcl/tk as the old d.m looked, well, pretty crappy, but things
have come a long way in a short time. If we don't have to start from
scratch, lets not, but if we can really improve functionality by going
with GTK (which seems the obvious choice for GRASS given the C bias) or
some other more modern tool kit, then it is worth it. If we need more
interactive functionality in our module dialogues, I would want to
explore further developing g.parser to support that before having to
dump it and start everything from scatch.

T
-- 
Trevor Wiens twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)