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

[Michael Barton]

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.

Thanks
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Sat, 20 May 2006 12:50:54 +0100
> To: John Gillette <JGillette at rfmd.com>
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] v.digit: Qt or wxWidgets
> 
> 
> John Gillette wrote:
> 
>>> AFAICT, the main obstacles are v.digit and NVIZ. v.digit
>>> needs a decision on a suitable toolkit (probably either Qt or
>>> wxWidgets) and a volunteer. NVIZ requires someone to update
>>> Togl to 1.7 and to conditionalise the GLX-specific code in do_zoom.c.
>> 
>> Glynn:
>> (1) I'd like to see the code written in C, as opposed to C++.
>>     I think more developers and users are going to know C. This
>>     lets users be able to trouble shoot and find bugs.
>>     [full disclosure: I only know C.]
> 
> That would be nice. Unfortunately, both Qt and wxWidgets use a C++
> API. GTK uses C, but the native MacOSX version is currently "alpha"
> quality.
> 
> Actually, the MacOSX port seems a bit further along than I had
> realised. In that case, GTK might be a viable option. If the native
> MacOSX version isn't stable enough for normal use, the X11 version of
> GTK can be used until the native version has matured.
> 
> The status page is here:
> 
> http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do
> 
>> (2) I looked at wxWidgets after the last time you mentioned it.
>>     I assume you can use it with C?
> 
> No. The API is C++ (i.e. each widget is a C++ object).
> 
>> (3) I didn't understand the relationship between wxWidgets and GTK.
>>     Can you explain some of this?
> 
> wxWidgets provides a common interface to a variety of different GUI
> toolkits: GTK, Motif, raw Xlib, Win32, and Mac (Carbon and
> "non-Carbon").
> 
> The basic WX widgets are usually wrappers around the widgets provided
> by the underlying toolkit. More complex widgets have to be implemented
> by wxWidgets itself (as do all of the widgets for the raw Xlib
> version).
> 
> The net result is a wxWidgets application should have a native look
> and feel. Other GUI toolkits tend to implement all of the widgets
> themselves, which mean that an application tends to look and behave
> the same on all platforms.
> 
>> (4) GTK is not on your list. Can you explain your thinking about
>>     which you prefer or which kit you would use?
> 
> I had excluded GTK because there didn't appear to be a usable native
> version for MacOSX. If the native MacOSX version is likely to be
> usable in the near future, then GTK would be a viable option (and the
> fact that it's API is in C gives it an advantage over Qt and
> wxWidgets).
> 
>> Perhaps by virtue of asking these questions it means I am not
>> qualified to work on v.digit but I get excited (and frustrated)
>> about the possibility of having a window based v.digit program.
>> 
>> If we could discuss it a little and then have Glynn just make a
>> decision [1], I would run off and start learning that toolkit. I
>> already learned some GTK.
> 
> It would be useful if someone with a Mac could provide feedback on the
> current state of GTK on MacOSX.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>
> 
>