[GRASS5] Platform for next generation UI

[Glynn Clements]

Trevor Wiens wrote:

> > It needs to be borne in mind that GRASS doesn't exactly have an glut
> > of developers, so we need to get the most out of those which we have.
> 
> I totally agree with this. If everyone wants to use GTK or wx, that
> is fine with me, I'll learn and contribute as I have time and ability. I
> raised the GTK on Mac issue because Michael had raised it and to my
> knowledge he has been doing a great deal of the work on the Tcltk GUI
> and has been spearheading the new GUI project so I don't want to loose
> his contributions. If I'm wrong in this point, I apologize to anyone
> involved, I've only been on the list a short time.
> 
> I think your line of thinking however is bang on. We need something that
> is technically adequate, but we also have limited developer resources,
> so we have to choose something that everyone can use, or learn easily.
> This is why I had proposed the possibility of using Qt and C++ for parts
> where speed is needed and PyQt for everything else. Python is easy
> to learn (if one doesn't know it) and runs everywhere. This however is
> just a suggestion.

The problem with using uncommon languages is that someone wishing to
make a limited contribution may not consider it worth their while to
learn the language, however easy it may be. In that regard, C is the
best choice, probably followed by C++. 

Personally, I find that C++ code is harder to understand if you aren't
familiar with the overall design of the system. E.g. to find out what
foo->bar() actually does, you need to search the class hierarchy until
you find the ancestor class which implements bar(). If bar() is
reimplemented in subclasses, you need to determine what bar() does in
each class for which foo might be an instance.

Although GTK (specifically, glib) has some object-oriented features,
the "methods" are all tagged with the class name, and can't be
re-implemented by subclasses. That makes it a lot easier for someone
who has never used GTK to understand code.

There's also the issue that C is still more portable, particularly on
non-mainstream platforms. Although most open-source Unices will have a
recent version of g++ installed, on commercial Unices the vendor's
official C++ compiler may be a decade out of date and/or cost a
significant amount of money, and g++ may not interoperate reliably
with system libraries.

It all comes down to the likely developer base and the range of
platforms. If the GUI is going to be developed by a small team of
dedicated developers, and minority platforms are going to be given low
priority, a C++ toolkit may be a better choice, while a broader
development effort and a wider range of supported platforms would tend
to favour a C toolkit.

-- 
Glynn Clements <glynn at gclements.plus.com>