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

[David Finlayson]

I'm not crazy about Tcl as a language---I would have preferred GRASS
standardize on Python---but, I think Michael makes several good
points:

1. It is working
2. It is easy to learn
3. It is pretty powerful

Tk can look butt-ugly on Debian/Ubuntu, but maybe that will be fixed
sooner rather than later...

At any rate, even if Tcl isn't the language for us, surely Python
could be. It has mature bindings to all of the major GUI toolkits. I
can't imagine why we would program a GUI in C or C++ unless it was
absolutely necessary. GRASS is a research tool, rapid development is
part of its appeal.

David






On 5/20/06, Trevor Wiens <twiens at interbaun.com> wrote:
> 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)
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
David Finlayson