[GRASS5] Platform for next generation UI
Glynn Clements
glynn at gclements.plus.com
Fri Jan 6 14:53:39 EST 2006
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>
More information about the grass-dev
mailing list