[GRASS5] Platform for next generation UI

[Michael Barton]

Glynn and Trevor,

I agree with your recent posts. I was trying to outline the pluses and
minuses of different platforms as 'objectively' as possible as far as I
could tell. In an ideal case, it seems like Qt might have a slight edge over
other platforms. But there is never an ideal case. The reality will be
shaped by available expertise. I don't know enough of the inner workings of
any of the platforms (except TclTk and even there, I feel what I know is
pretty superficial and ad hoc) to discuss some of the important issues
brought up below.

I agree with Trevor in that I would be happy to help in any platform that we
go with. At the moment, we do have someone who wants to give it a try in Qt
and no one who wants to spearhead something in GTK (Bob Covill mentioned
that he has been messing around with this, but I haven't heard anything from
him in quite awhile), wxWidgets, or even TclTk (one additional person
offered to help, but no one offered to develop a new TclTk interface).

It looks like, using Qt designer, a number of people can work on the overall
look and operation of the UI. But it needs a couple people who can work in
C++ to deal with the guts of the system--monitor widgets, etc.

My main goal has been to try to have some kind of organized, coordinated
effort in developing a new UI. GRASS seems a rather diffuse open source
project, which means that it is open to a wider variety of contributors and
more difficult to organize. It seems like we need to get a few energetic
people to give a UI a trial run and then try to build some support for it.
I'm trying to spark that.

If you think that there are real difficulties with Qt, then perhaps we need
to put the breaks on. But at the moment, this has more momentum than other
directions. Thanks again for your insights.

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

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



> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Sun, 1 Jan 2006 12:35:12 +0000
> To: Trevor Wiens <twiens at interbaun.com>
> Cc: Michael Barton <michael.barton at asu.edu>, grass5 <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Platform for next generation UI
> 
> 
> 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>