On 3/18/07 3:49 PM, "Brad Douglas" <
[hidden email]> wrote:
>
> Okay. I wanted to make sure there was a consensus on this before
> proceeding. I know this issue has been discussed extensively in the
> past, but I don't recall the outcome.
>
> Markus, should this be formalized by the PSC? I loosely get that
> impression from RFC1...something quick and painless to just reflect
> current knowledge/thinking. The procedure may be helpful if there is
> desire to have a roadmap that extends to the future (rather than the
> current collection of ideas on wiki).
>
>
Brad,
About a year and a half ago, I launched a discussion about the next
generation GUI for GRASS. I asked for input and opinions and we went through
a considerable discussion.
I distilled a lot of this at
<
http://www.public.asu.edu/~cmbarton/files/grass_ui/>
There is also more on the GRASS GUI and developers list archive from early
2006. I've got a lot of this discussion saved in my email folders if you are
interested.
The brief gist was that
1. TclTk has a number of problematic limitations for continued long-term use
as a GUI platform, although we were not using its potential by any means at
that time, especially with respect to display architecture. This was the
impetus of my redesign of the TclTk GUI, with a lot of advice from Glynn
Clements and some contributions from Cedric Shock. This led to the current
GRASS 6.3 GUI--including the potential for a native Windows GRASS for the
first time.
2. The other sufficiently rich GUI platforms considered most seriously were:
QT, GTK+, and wxWidgets. All have a richer tool set than TclTk, especially
with regards to the needs of a GRASS GUI. However, there are also some
drawback to all (TclTk is actually quite easy to work with and potentially
very cross-platform). QT is primarily implemented in a C++ environment. This
makes it a little more difficult to wrap around GRASS (implemented in C) and
requires an understanding of C++ to use. Few people working with GRASS seem
to know much about C++ (nor do they appear to have much desire to do so).
GTK+ is a solid and very useable platform, but the Mac version remains in
Beta form and was (still is?) lagging considerably in development. This
means we would be stuck with an x11 version for Mac rather than a native
one. wxWidgets, like QT, is built on C++, with all the same issues.
3. However, there is a Python implementation of wxWidgets (wxPython) that is
much easier to work with and will interface with GRASS better. It is
actively maintained across all major platforms, and has a toolset as rich as
(or perhaps even richer than) the original wxWidgets. An added bonus is that
there are already a fair number of Python programmers in the GRASS community
and Python is relatively easy to learn. This boded well both for development
and longer-term maintenance of a wxPython GUI.
The majority opinion was that we should see if it is possible to create a
viable GUI in wxPython first. So I spent last summer learning Python and
wxPython. Several other people have volunteered to contribute to GUI
development--including Jáchym Cepicky, Martin Landa, Daniel Calvelo, Trevor
Wiens. This gives us a real team of GUI developers for the first time.
I certainly don't mind reopening this discussion in the PSC if you think we
need something more formal now that we have a PSC. I should note that after
about 9 months of effort invested in wxPython, there is a considerable 'sunk
cost' in wxPython that will need to be taken into account in addition to the
considerations above.
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_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
