[GRASS5] Platform for next generation UI

[Michael Barton]

I agree with all of this. We can make considerable headway in improving the
GRASS UI with a good plan and the tools we now have. But we probably also
will hit some limits, for example in integrating 3D GIS with 2D GIS in a way
that is apparently seamless to users.

So I'm moving ahead with some nice interim updates to the UI while others
are working on prototypes for more advanced interfaces. With respect to
interpreted vs. compiled, the latter may not be so much of a problem for
people to help with if we keep it in the cvs with source code that can be
worked on with standard, widely available tools (e.g., *.ui files for Qt
designer or gtk files for glade).

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Fri, 06 Jan 2006 19:53:39 +0000
> To: Moritz Lennert <mlennert at club.worldonline.be>
> Cc: Trevor Wiens <twiens at interbaun.com>, Michael Barton
> <michael.barton at asu.edu>, grass5 <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Platform for next generation UI
> 
> 
> Moritz Lennert wrote:
> 
>>>> I think that there is a tendency among programmers in general to apply
>>>> the tools they are most comfortable with beyond their optimal use.
>>>> Interpreted languages like Python are often quite suitable for GUI
>>>> development. So, I wonder if we should consider, using a hybrid
>>>> strategy especially if it will enable us to make the transition from
>>>> GRASS in its current state to a more GUI friendly GRASS. Further, it
>>>> that were to work, why rework the transitional GUI in C?
>>> 
>>> 
>>> Using a minority language is likely to limit the number of people who
>>> will work on the code. This is more of an issue for maintenance than
>>> for the original development.
>> 
>> I completely agree with Glynn concerning the lack of developers (altough
>> I think that using an "easy" language such as Python might actually
>> allow more people to participate in developing...),
> 
> That's true. A lot depends upon the degree of motivation. Someone who
> has a strong desire to participate in GUI development may be willing
> to learn a new language to do so. In which case, the easier the
> language, the better.
> 
> OTOH, someone who stumbles across a bug or wants a minor feature added
> is more likely to do the work themself if they don't need to learn
> another language in order to do so.
> 
>> but I do really like
>> the idea of a scripted language for the GUI as it allows very easy and
>> rapid changes to the GUI without any need for compilation. Just look at
>> the way that Michael has been able to send us tcl/tk files for testing
>> which we could just use as drop-in replacement for the existing
>> installed GUI. I find this a fairly nice feature which allows
>> non-programmers to participate more actively.
> 
> Using an interpreted language is certainly a significant benefit when
> the GUI is in a state of flux. Ultimately, I think that we will start
> to run into limitations though. More so for Tcl/Tk than for a binding
> to a "real" toolkit (e.g. wxPython).
> 
> The main issue there is likely to be the limitations of the "canvas"
> used to display maps etc. While the Tcl/Tk canvas widget is quite
> powerful, you can't get around its limitations (e.g. adding new object
> types). For that, you need access to the base rendering primitives so
> that you can redraw the canvas yourself.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>