[GRASS5] Platform for next generation UI

GRASS GIS GRASS GIS developer
,
1

Among the discussions on the features desired and needed for a next generation UI for GRASS were a number of posts on interface development platforms. The overall message was that a sophisticated UI can be developed with a number of different tool sets. I’ve tried to look at these in a systematic manner and have done some research. However, I’m SURE that there are others who are more knowledgeable than I am on this and I hope that they can add their perspectives and correct any misconceptions that I might have. Andy Tai’s GUI toolkit comparison site is helpful http://www.geocities.com/SiliconValley/Vista/7184/guitool.html, though a little out of date (Feb 2005 seems the most recent update).

Here are a few of what I think are important criteria to consider to narrow the field a bit, in no particular order.

We clearly need to use a set of interface development tools rather than developing a UI ‘from scratch’ (i.e, in C)–for consistent and better look and feel, and more importantly so that it can be developed and maintained by a group of volunteers who can only work on this part time. The latter issue–maintainability by GRASS team members–is very important. A slick UI that cannot be maintained by the development community is problematic.

It is highly desirable to have an interface that will run natively on the major platforms that can run GRASS. Currently, this includes Linux, Mac OS X, Sun and other Unix?, and Cygwin. The recent success in compiling an experimental native Windows version means that we should look for something that also runs natively under Windows.

The tool set should be well-developed and documented, well maintained, and likely to be maintained into the future. We don’t want to be orphaned if we can avoid it.

The tool set must be open source and compatible with GRASS’s GPL license.

It either must already come bundled on the OS platforms with we expect to run GRASS, or we must be able to distribute it to the extent needed to run GRASS (i.e., we may not need to distribute the whole tool set for simply running the application, but we need to be able to distribute whatever is necessary).

The tool set must be compatible with the GRASS C code base.

If we are to move beyond the current limited xdriver display, the tool set needs to be sufficiently richly endowed with proper graphic tools for GIS display.

Related to this, if we are to maintain GRASS’s recent advanced development of 3D GIS, the tool set needs to be able to use OpenGL (given the feature discussion that OpenGL is needed for 3D).

It is highly desirable to have a tool set that also will interact well with SQL databases–particularly SQLite, PostgresSQL, MySQL–and possibly dbf.

OK, with that preamble, this is where I think we are at the present. There seem to be a limited number of interface development tool sets that meet these criteria. The ones I’ve found that seem the best AFAICT are: TclTk, GTK+, Qt, and WxWidgets (formerly WxWindows). Here are a few observations on each.

TclTk: Everyone knows that GRASS has a large existing investment in TclTk. However, it is used to a much more limited extent that it could be. The xdriver could be replaced by a TclTk canvas. TclTk supports OpenGL (it is used in NVIZ). The new versions (I think 8.4.12 is current, with 8.5 in beta) have tools to make a MUCH slicker interface than we now have (check out the screenshots at http://aspn.activestate.com/ASPN/Tcl/Tk_Contest/). There are specific TclTk tool kits for SQLite, and much more (e.g., expect and tile). To make best use of all of this, we would need to distribute current TclTk with GRASS (or at least a runtime version if we went with a compiled UI instead of the non-compiled scripts we use now). Ironically, the widespread popularity of TclTk has created some problems for GRASS currently. TclTk comes with most Linux distributions, Mac OS X, and Cygwin. But the versions and implementation differ by platform. This has led to incompatibilities and conflicts (e.g., with 8.4 in some Linux distros and with the Cygwin version), issues with OpenGL in NVIZ, and dueling versions in some cases (e.g., if you install Lorenzo’s binaries for Mac OS X, you end up with 3 different versions: the one that comes with OS X, the x11 one, and TclTk Aqua). If a new UI for GRASS is based on TclTk, it could not simply be a dependency IMHO; we would need to distribute it with GRASS in order to make sure that all GRASS users have proper functionality–and we would need to install it so as to avoid incompatibilities with versions that come with OS’s (e.g., as Lorenzo does by putting it into a grasslib directory). See http://www.activestate.com/Products/ActiveTcl/ and http://tcltkaqua.sourceforge.net/ for more information

GTK+: GTK+ is widely used in the Linux world, especially for GNOME and GNOME apps. The best known is GIMP, of course. GTK+ meets all the criteria, except possibly the cross-platform one. The current version of GTK+ for Linux is 2.9.1. The newest version for Windows is 2.6.9. The Mac version is under development. There is one project that is built on GTK 1.x; another just announced seems to be based on a reasonably current version 2.x. However both are still in development, meaning that any GTK app in the near future would have to run in x11 on a Mac. Using x11 is not the problem on a Mac that it is on Windows (i.e., Cygwin). But the need to install x11 and use non-native apps makes GRASS installation and use considerably less accessible for the normal Mac user. See http://www.gtk.org/ for more information.

Qt: As of last summer, there are GPL versions of Qt for all major platforms that run GRASS. It meets all interface criteria listed above. There is already a Qt GIS project with a GRASS plugin–QGIS–that could provide examples for developing a GRASS UI. Qt seems to be gaining considerable support for designing interfaces for scientific applications. See http://www.trolltech.com/download/qt/x11.html for more information on the GPL version of Qt. I’m not aware of any drawbacks.

WxWidgets: I’ve only recently come across this tool set. It was mentioned in posts by Rich Shepard and Joel Pitt. Like Qt, it is a completely cross-platform tool kit with good support for the kinds of graphic displays we now use and envision for the next generation GRASS. I’ve heard good things about it from other people too. See http://www.wxwidgets.org/ for more information and screenshots. I’m not aware of any drawback with this platform either.

In summary, current version of TclTk would work well for the next generation of GRASS, but there are issues to solve with regard to multiple versions and potential conflicts with versions that come installed with OS’s. GTK+ will accomplish all needed UI functions, but has more limited support for non-Linux platorms than the other 3 tool kits. This leaves Qt and WxWidgets as interface development platforms that seem best suited to for the next generation UI for GRASS. I’ve only worked with TclTk, so I don’t have any feel for the comparative ease or difficulty of working with any of these platforms for interface development.

That said, the reality is that the availability of people with appropriate expertise will have a big role in which platform is chosen. A couple of people have expressed interest in developing a Qt or GTK+ UI; I can continue to work with TclTk and am willing to help with another platform. But we will need a team of people both to develop and maintain the UI. If this is the kind of project that we envision, it will take more than simply the development of an interface that sits on top of GRASS as it is now. For example, if we replace the xdriver with a modern display integrated with the UI, it will require some degree of rewriting of d.rast, d.vect, and any other display modules are retained. If we combine 2D and 3D GIS, NVIZ will need to be rewritten to incorporate OpenGL into the main display. If we do not go with TclTk, the routines for autogenerating dialogs for modules at runtime will need to be ported to another platform—or perhaps they can be dropped if we can have better GUI/CLI integration. This all will involve other members of the GRASS team beyond simply UI development. So deciding on a platform for UI development is more than a simple vote of which one is preferred, but which is one that the GRASS team will actively support.

I hope this offer you all some food for thought.

Un saludo cordial to all the GRASS team
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

2

One note: I have tried a few WxWidgets apps, and I found them unstable on
Linux. Apparently the problem is general.
One question: who is active in developing the TclTk interface (except for
you)?
All the best.
pc

At 07:16, mercoledì 28 dicembre 2005, Michael Barton has probably written:
...

OK, with that preamble, this is where I think we are at the present. There
seem to be a limited number of interface development tool sets that meet
these criteria. The ones I've found that seem the best AFAICT are: TclTk,
GTK+, Qt, and WxWidgets (formerly WxWindows). Here are a few observations
on each.

...
--
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

3

Thanks for the mind sushi, Michael.

I'm not sure I'm hammering the right nail here, but I'd suggest that
whatever the toolkit chosen, we strive first to define a proper
interface/API between the GUI front-end and the traditional CLI
front-end. What I mean is that there is a balance between a) the GUI
driving commands and b) the GUI managing state for the rest of GRASS.

The way the GRASS plugin for QGIS and g.parsers --xml-description
provide a "glue" API between both worlds has its limitations,
especially wrt procedure-oriented vs. data-oriented manipulation.
Thinking out loud, I'd say that the hard job is defining how the
command's published intent is hooked to an interface description, a la
glade or XRC (that's wxWidgets interface description language).

Not sure I'm making much sense. It's late. Bed's calling. Be back later.

Daniel.

On 12/28/05, Michael Barton <michael.barton@asu.edu> wrote:

Among the discussions on the features desired and needed for a next
generation UI for GRASS were a number of posts on interface development
platforms. The overall message was that a sophisticated UI can be developed
with a number of different tool sets. I've tried to look at these in a
systematic manner and have done some research. However, I'm SURE that there
are others who are more knowledgeable than I am on this and I hope that they
can add their perspectives and correct any misconceptions that I might have.
Andy Tai's GUI toolkit comparison site is helpful
<http://www.geocities.com/SiliconValley/Vista/7184/guitool.html&gt;,
though a little out of date (Feb 2005 seems the most recent update).

Here are a few of what I think are important criteria to consider to narrow
the field a bit, in no particular order.

We clearly need to use a set of interface development tools rather than
developing a UI 'from scratch' (i.e, in C)--for consistent and better look
and feel, and more importantly so that it can be developed and maintained by
a group of volunteers who can only work on this part time. The latter
issue--maintainability by GRASS team members--is very important. A slick UI
that cannot be maintained by the development community is problematic.

It is highly desirable to have an interface that will run natively on the
major platforms that can run GRASS. Currently, this includes Linux, Mac OS
X, Sun and other Unix?, and Cygwin. The recent success in compiling an
experimental native Windows version means that we should look for something
that also runs natively under Windows.

The tool set should be well-developed and documented, well maintained, and
likely to be maintained into the future. We don't want to be orphaned if we
can avoid it.

The tool set must be open source and compatible with GRASS's GPL license.

It either must already come bundled on the OS platforms with we expect to
run GRASS, or we must be able to distribute it to the extent needed to run
GRASS (i.e., we may not need to distribute the whole tool set for simply
running the application, but we need to be able to distribute whatever is
necessary).

The tool set must be compatible with the GRASS C code base.

If we are to move beyond the current limited xdriver display, the tool set
needs to be sufficiently richly endowed with proper graphic tools for GIS
display.

Related to this, if we are to maintain GRASS's recent advanced development
of 3D GIS, the tool set needs to be able to use OpenGL (given the feature
discussion that OpenGL is needed for 3D).

It is highly desirable to have a tool set that also will interact well with
SQL databases--particularly SQLite, PostgresSQL, MySQL--and possibly dbf.

-------------------

OK, with that preamble, this is where I think we are at the present. There
seem to be a limited number of interface development tool sets that meet
these criteria. The ones I've found that seem the best AFAICT are: TclTk,
GTK+, Qt, and WxWidgets (formerly WxWindows). Here are a few observations on
each.

TclTk: Everyone knows that GRASS has a large existing investment in TclTk.
However, it is used to a much more limited extent that it could be. The
xdriver could be replaced by a TclTk canvas. TclTk supports OpenGL (it is
used in NVIZ). The new versions (I think 8.4.12 is current, with 8.5 in
beta) have tools to make a MUCH slicker interface than we now have (check
out the screenshots at
<http://aspn.activestate.com/ASPN/Tcl/Tk_Contest/&gt;\). There
are specific TclTk tool kits for SQLite, and much more (e.g., expect and
tile). To make best use of all of this, we would need to distribute current
TclTk with GRASS (or at least a runtime version if we went with a compiled
UI instead of the non-compiled scripts we use now). Ironically, the
widespread popularity of TclTk has created some problems for GRASS
currently. TclTk comes with most Linux distributions, Mac OS X, and Cygwin.
But the versions and implementation differ by platform. This has led to
incompatibilities and conflicts (e.g., with 8.4 in some Linux distros and
with the Cygwin version), issues with OpenGL in NVIZ, and dueling versions
in some cases (e.g., if you install Lorenzo's binaries for Mac OS X, you end
up with 3 different versions: the one that comes with OS X, the x11 one, and
TclTk Aqua). If a new UI for GRASS is based on TclTk, it could not simply be
a dependency IMHO; we would need to distribute it with GRASS in order to
make sure that all GRASS users have proper functionality--and we would need
to install it so as to avoid incompatibilities with versions that come with
OS's (e.g., as Lorenzo does by putting it into a grasslib directory). See
<http://www.activestate.com/Products/ActiveTcl/&gt; and
<http://tcltkaqua.sourceforge.net/&gt; for more information

GTK+: GTK+ is widely used in the Linux world, especially for GNOME and
GNOME apps. The best known is GIMP, of course. GTK+ meets all the criteria,
except possibly the cross-platform one. The current version of GTK+ for
Linux is 2.9.1. The newest version for Windows is 2.6.9. The Mac version is
under development. There is one project that is built on GTK 1.x; another
just announced seems to be based on a reasonably current version 2.x.
However both are still in development, meaning that any GTK app in the near
future would have to run in x11 on a Mac. Using x11 is not the problem on a
Mac that it is on Windows (i.e., Cygwin). But the need to install x11 and
use non-native apps makes GRASS installation and use considerably less
accessible for the normal Mac user. See <http://www.gtk.org/&gt; for more
information.

Qt: As of last summer, there are GPL versions of Qt for all major platforms
that run GRASS. It meets all interface criteria listed above. There is
already a Qt GIS project with a GRASS plugin--QGIS--that could provide
examples for developing a GRASS UI. Qt seems to be gaining considerable
support for designing interfaces for scientific applications. See
<http://www.trolltech.com/download/qt/x11.html&gt; for more
information on the GPL version of Qt. I'm not aware of any drawbacks.

WxWidgets: I've only recently come across this tool set. It was mentioned
in posts by Rich Shepard and Joel Pitt. Like Qt, it is a completely
cross-platform tool kit with good support for the kinds of graphic displays
we now use and envision for the next generation GRASS. I've heard good
things about it from other people too. See <http://www.wxwidgets.org/&gt; for
more information and screenshots. I'm not aware of any drawback with this
platform either.

In summary, current version of TclTk would work well for the next
generation of GRASS, but there are issues to solve with regard to multiple
versions and potential conflicts with versions that come installed with
OS's. GTK+ will accomplish all needed UI functions, but has more limited
support for non-Linux platorms than the other 3 tool kits. This leaves Qt
and WxWidgets as interface development platforms that seem best suited to
for the next generation UI for GRASS. I've only worked with TclTk, so I
don't have any feel for the comparative ease or difficulty of working with
any of these platforms for interface development.

That said, the reality is that the availability of people with appropriate
expertise will have a big role in which platform is chosen. A couple of
people have expressed interest in developing a Qt or GTK+ UI; I can continue
to work with TclTk and am willing to help with another platform. But we will
need a team of people both to develop and maintain the UI. If this is the
kind of project that we envision, it will take more than simply the
development of an interface that sits on top of GRASS as it is now. For
example, if we replace the xdriver with a modern display integrated with the
UI, it will require some degree of rewriting of d.rast, d.vect, and any
other display modules are retained. If we combine 2D and 3D GIS, NVIZ will
need to be rewritten to incorporate OpenGL into the main display. If we do
not go with TclTk, the routines for autogenerating dialogs for modules at
runtime will need to be ported to another platform—or perhaps they can be
dropped if we can have better GUI/CLI integration. This all will involve
other members of the GRASS team beyond simply UI development. So deciding on
a platform for UI development is more than a simple vote of which one is
preferred, but which is one that the GRASS team will actively support.

I hope this offer you all some food for thought.

Un saludo cordial to all the GRASS team
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

--
-- Daniel Calvelo Aros

4

Paolo,

I checked in the CVS. Over the past year, contributors to the TclTk
interface have included Hamish, Markus, Cho, and Florian as well as me.
Glynn Clements has given a lot of help and advice on and off list. These
folks also actively contribute to other areas of the GRASS code. Several
other people have been a big help as early testers. I've done most of the
coding for the past couple years.

I don't know how many people actively contribute to GRASS. Given the size
and complexity of the project, we could always use more. It would be ideal
if there were 3-4 people who could focus on the UI, especially while it's in
development.

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: Paolo Cavallini <cavallini@faunalia.it>
Organization: Faunalia
Reply-To: <cavallini@faunalia.it>
Date: Wed, 28 Dec 2005 08:26:13 +0100
To: <grass5@grass.itc.it>
Subject: Re: [GRASS5] Platform for next generation UI

One note: I have tried a few WxWidgets apps, and I found them unstable on
Linux. Apparently the problem is general.
One question: who is active in developing the TclTk interface (except for
you)?
All the best.
pc

At 07:16, mercoledì 28 dicembre 2005, Michael Barton has probably written:
...

OK, with that preamble, this is where I think we are at the present. There
seem to be a limited number of interface development tool sets that meet
these criteria. The ones I've found that seem the best AFAICT are: TclTk,
GTK+, Qt, and WxWidgets (formerly WxWindows). Here are a few observations
on each.

...
--
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

5

Hi,

Thanks for the summary, Michael.

The first thing that we should do even before we decide on a toolkit is
IMHO a UI design. At http://openusability.org/ we could register GRASS
and look for usability experts. Then when we have a snazzy UI design we
implement it with whatever toolkit we feel we can do the job.

Now a few words about the toolkit. I was really surprised with what one
can do with TclTk, I'm impressed. I'm familiar with the other three
candidates, and at first I thought that yuck, let's get away quickly
from this TclTk, but now that I have seen that it really seems to be
possible to make it look native and modern on all platforms I'm actually
voting for it. We might not be able to reuse much code, but since we are
familiar with TclTk, we can make better progress (both faster and better
quality). I'm not at all familiar with TclTk, but I've wanted to learn
it, and now I think that I have a nice excuse (;, but I'm still not a
GUI developer, but would be interested in helping out. Especially the
interface to the command line. All the d. commands should IMO be
something that will pass commands to the GUI, this is something that I'd
be interested in developing.

--Wolf

On 28/12/05 08:16, Michael Barton wrote:

Among the discussions on the features desired and needed for a next
generation UI for GRASS were a number of posts on interface development
platforms. The overall message was that a sophisticated UI can be developed
with a number of different tool sets. I've tried to look at these in a
systematic manner and have done some research. However, I'm SURE that there
are others who are more knowledgeable than I am on this and I hope that they
can add their perspectives and correct any misconceptions that I might have.
Andy Tai¹s GUI toolkit comparison site is helpful
<http://www.geocities.com/SiliconValley/Vista/7184/guitool.html&gt;, though a
little out of date (Feb 2005 seems the most recent update).

Here are a few of what I think are important criteria to consider to narrow
the field a bit, in no particular order.

We clearly need to use a set of interface development tools rather than
developing a UI 'from scratch' (i.e, in C)--for consistent and better look
and feel, and more importantly so that it can be developed and maintained by
a group of volunteers who can only work on this part time. The latter
issue--maintainability by GRASS team members--is very important. A slick UI
that cannot be maintained by the development community is problematic.

It is highly desirable to have an interface that will run natively on the
major platforms that can run GRASS. Currently, this includes Linux, Mac OS
X, Sun and other Unix?, and Cygwin. The recent success in compiling an
experimental native Windows version means that we should look for something
that also runs natively under Windows.

The tool set should be well-developed and documented, well maintained, and
likely to be maintained into the future. We don't want to be orphaned if we
can avoid it.

The tool set must be open source and compatible with GRASS's GPL license.

It either must already come bundled on the OS platforms with we expect to
run GRASS, or we must be able to distribute it to the extent needed to run
GRASS (i.e., we may not need to distribute the whole tool set for simply
running the application, but we need to be able to distribute whatever is
necessary).

The tool set must be compatible with the GRASS C code base.

If we are to move beyond the current limited xdriver display, the tool set
needs to be sufficiently richly endowed with proper graphic tools for GIS
display.

Related to this, if we are to maintain GRASS's recent advanced development
of 3D GIS, the tool set needs to be able to use OpenGL (given the feature
discussion that OpenGL is needed for 3D).

It is highly desirable to have a tool set that also will interact well with
SQL databases--particularly SQLite, PostgresSQL, MySQL--and possibly dbf.

-------------------

OK, with that preamble, this is where I think we are at the present. There
seem to be a limited number of interface development tool sets that meet
these criteria. The ones I've found that seem the best AFAICT are: TclTk,
GTK+, Qt, and WxWidgets (formerly WxWindows). Here are a few observations on
each.

TclTk: Everyone knows that GRASS has a large existing investment in TclTk.
However, it is used to a much more limited extent that it could be. The
xdriver could be replaced by a TclTk canvas. TclTk supports OpenGL (it is
used in NVIZ). The new versions (I think 8.4.12 is current, with 8.5 in
beta) have tools to make a MUCH slicker interface than we now have (check
out the screenshots at <http://aspn.activestate.com/ASPN/Tcl/Tk_Contest/&gt;\).
There are specific TclTk tool kits for SQLite, and much more (e.g., expect
and tile). To make best use of all of this, we would need to distribute
current TclTk with GRASS (or at least a runtime version if we went with a
compiled UI instead of the non-compiled scripts we use now). Ironically, the
widespread popularity of TclTk has created some problems for GRASS
currently. TclTk comes with most Linux distributions, Mac OS X, and Cygwin.
But the versions and implementation differ by platform. This has led to
incompatibilities and conflicts (e.g., with 8.4 in some Linux distros and
with the Cygwin version), issues with OpenGL in NVIZ, and dueling versions
in some cases (e.g., if you install Lorenzo's binaries for Mac OS X, you end
up with 3 different versions: the one that comes with OS X, the x11 one, and
TclTk Aqua). If a new UI for GRASS is based on TclTk, it could not simply be
a dependency IMHO; we would need to distribute it with GRASS in order to
make sure that all GRASS users have proper functionality--and we would need
to install it so as to avoid incompatibilities with versions that come with
OS's (e.g., as Lorenzo does by putting it into a grasslib directory). See
<http://www.activestate.com/Products/ActiveTcl/&gt; and
<http://tcltkaqua.sourceforge.net/&gt; for more information

GTK+: GTK+ is widely used in the Linux world, especially for GNOME and GNOME
apps. The best known is GIMP, of course. GTK+ meets all the criteria, except
possibly the cross-platform one. The current version of GTK+ for Linux is
2.9.1. The newest version for Windows is 2.6.9. The Mac version is under
development. There is one project that is built on GTK 1.x; another just
announced seems to be based on a reasonably current version 2.x. However
both are still in development, meaning that any GTK app in the near future
would have to run in x11 on a Mac. Using x11 is not the problem on a Mac
that it is on Windows (i.e., Cygwin). But the need to install x11 and use
non-native apps makes GRASS installation and use considerably less
accessible for the normal Mac user. See <http://www.gtk.org/&gt; for more
information.

Qt: As of last summer, there are GPL versions of Qt for all major platforms
that run GRASS. It meets all interface criteria listed above. There is
already a Qt GIS project with a GRASS plugin--QGIS--that could provide
examples for developing a GRASS UI. Qt seems to be gaining considerable
support for designing interfaces for scientific applications. See
<http://www.trolltech.com/download/qt/x11.html&gt; for more information on the
GPL version of Qt. I¹m not aware of any drawbacks.

WxWidgets: I've only recently come across this tool set. It was mentioned in
posts by Rich Shepard and Joel Pitt. Like Qt, it is a completely
cross-platform tool kit with good support for the kinds of graphic displays
we now use and envision for the next generation GRASS. I've heard good
things about it from other people too. See <http://www.wxwidgets.org/&gt; for
more information and screenshots. I¹m not aware of any drawback with this
platform either.

In summary, current version of TclTk would work well for the next generation
of GRASS, but there are issues to solve with regard to multiple versions and
potential conflicts with versions that come installed with OS's. GTK+ will
accomplish all needed UI functions, but has more limited support for
non-Linux platorms than the other 3 tool kits. This leaves Qt and WxWidgets
as interface development platforms that seem best suited to for the next
generation UI for GRASS. I¹ve only worked with TclTk, so I don¹t have any
feel for the comparative ease or difficulty of working with any of these
platforms for interface development.

That said, the reality is that the availability of people with appropriate
expertise will have a big role in which platform is chosen. A couple of
people have expressed interest in developing a Qt or GTK+ UI; I can continue
to work with TclTk and am willing to help with another platform. But we will
need a team of people both to develop and maintain the UI. If this is the
kind of project that we envision, it will take more than simply the
development of an interface that sits on top of GRASS as it is now. For
example, if we replace the xdriver with a modern display integrated with the
UI, it will require some degree of rewriting of d.rast, d.vect, and any
other display modules are retained. If we combine 2D and 3D GIS, NVIZ will
need to be rewritten to incorporate OpenGL into the main display. If we do
not go with TclTk, the routines for autogenerating dialogs for modules at
runtime will need to be ported to another platform‹or perhaps they can be
dropped if we can have better GUI/CLI integration. This all will involve
other members of the GRASS team beyond simply UI development. So deciding on
a platform for UI development is more than a simple vote of which one is
preferred, but which is one that the GRASS team will actively support.

I hope this offer you all some food for thought.

Un saludo cordial to all the GRASS team
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

6

Hi Wolf,

Thanks very much for the comments AND for the interest in working on the UI.
I agree about the priority of UI design. However, I wanted to put out some
information on toolkits because we've spent the past couple months talking a
lot about UI design--but people continue to bring up toolkits too. I
summarized a lot of the UI design information in my post of a couple days
ago and posted on my website
<http://www.public.asu.edu/~cmbarton/files/grass_ui&gt;\.

I also was surprised at the UI quality for current TclTk. If we do use it,
as you say, I don't know how much of the current code we would want to port
over because I think (hope) that we are looking at a pretty different design
concept. A couple of drawbacks to TclTk are the competing versions issue I
mentioned yesterday and the (AFAIK) comparative lack of interactive, GUI
design environments for the platform (visual TclTk is kind of old). Still,
the fact that GRASS already uses a lot of TclTk code means that it might be
possible to implement some parts of a new UI in stages rather than having to
do the whole thing at once. While I could probably do a lot more initially
in TclTk than in another platform, I simply don't have the ability (that is,
I don't have the time to learn the expertise) to start this from
scratch--even in TclTk--I feel I need to be kind of neutral about platforms
at the moment, and see what the overall response is.

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: Wolf Bergenheim <wolf+grass@bergenheim.net>
Date: Wed, 28 Dec 2005 20:53:47 +0200
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5 <grass5@grass.itc.it>
Subject: Re: [GRASS5] Platform for next generation UI

Hi,

Thanks for the summary, Michael.

The first thing that we should do even before we decide on a toolkit is
IMHO a UI design. At http://openusability.org/ we could register GRASS
and look for usability experts. Then when we have a snazzy UI design we
implement it with whatever toolkit we feel we can do the job.

Now a few words about the toolkit. I was really surprised with what one
can do with TclTk, I'm impressed. I'm familiar with the other three
candidates, and at first I thought that yuck, let's get away quickly
from this TclTk, but now that I have seen that it really seems to be
possible to make it look native and modern on all platforms I'm actually
voting for it. We might not be able to reuse much code, but since we are
familiar with TclTk, we can make better progress (both faster and better
quality). I'm not at all familiar with TclTk, but I've wanted to learn
it, and now I think that I have a nice excuse (;, but I'm still not a
GUI developer, but would be interested in helping out. Especially the
interface to the command line. All the d. commands should IMO be
something that will pass commands to the GUI, this is something that I'd
be interested in developing.

--Wolf

On 28/12/05 08:16, Michael Barton wrote:

Among the discussions on the features desired and needed for a next
generation UI for GRASS were a number of posts on interface development
platforms. The overall message was that a sophisticated UI can be developed
with a number of different tool sets. I've tried to look at these in a
systematic manner and have done some research. However, I'm SURE that there
are others who are more knowledgeable than I am on this and I hope that they
can add their perspectives and correct any misconceptions that I might have.
Andy Tai¹s GUI toolkit comparison site is helpful
<Yahoo | Mail, Weather, Search, Politics, News, Finance, Sports & Videos, though a
little out of date (Feb 2005 seems the most recent update).

Here are a few of what I think are important criteria to consider to narrow
the field a bit, in no particular order.

We clearly need to use a set of interface development tools rather than
developing a UI 'from scratch' (i.e, in C)--for consistent and better look
and feel, and more importantly so that it can be developed and maintained by
a group of volunteers who can only work on this part time. The latter
issue--maintainability by GRASS team members--is very important. A slick UI
that cannot be maintained by the development community is problematic.

It is highly desirable to have an interface that will run natively on the
major platforms that can run GRASS. Currently, this includes Linux, Mac OS
X, Sun and other Unix?, and Cygwin. The recent success in compiling an
experimental native Windows version means that we should look for something
that also runs natively under Windows.

The tool set should be well-developed and documented, well maintained, and
likely to be maintained into the future. We don't want to be orphaned if we
can avoid it.

The tool set must be open source and compatible with GRASS's GPL license.

It either must already come bundled on the OS platforms with we expect to
run GRASS, or we must be able to distribute it to the extent needed to run
GRASS (i.e., we may not need to distribute the whole tool set for simply
running the application, but we need to be able to distribute whatever is
necessary).

The tool set must be compatible with the GRASS C code base.

If we are to move beyond the current limited xdriver display, the tool set
needs to be sufficiently richly endowed with proper graphic tools for GIS
display.

Related to this, if we are to maintain GRASS's recent advanced development
of 3D GIS, the tool set needs to be able to use OpenGL (given the feature
discussion that OpenGL is needed for 3D).

It is highly desirable to have a tool set that also will interact well with
SQL databases--particularly SQLite, PostgresSQL, MySQL--and possibly dbf.

-------------------

OK, with that preamble, this is where I think we are at the present. There
seem to be a limited number of interface development tool sets that meet
these criteria. The ones I've found that seem the best AFAICT are: TclTk,
GTK+, Qt, and WxWidgets (formerly WxWindows). Here are a few observations on
each.

TclTk: Everyone knows that GRASS has a large existing investment in TclTk.
However, it is used to a much more limited extent that it could be. The
xdriver could be replaced by a TclTk canvas. TclTk supports OpenGL (it is
used in NVIZ). The new versions (I think 8.4.12 is current, with 8.5 in
beta) have tools to make a MUCH slicker interface than we now have (check
out the screenshots at <ActiveState Community - Boosting coder and team productivity with ready-to-use open source languages and tools.).
There are specific TclTk tool kits for SQLite, and much more (e.g., expect
and tile). To make best use of all of this, we would need to distribute
current TclTk with GRASS (or at least a runtime version if we went with a
compiled UI instead of the non-compiled scripts we use now). Ironically, the
widespread popularity of TclTk has created some problems for GRASS
currently. TclTk comes with most Linux distributions, Mac OS X, and Cygwin.
But the versions and implementation differ by platform. This has led to
incompatibilities and conflicts (e.g., with 8.4 in some Linux distros and
with the Cygwin version), issues with OpenGL in NVIZ, and dueling versions
in some cases (e.g., if you install Lorenzo's binaries for Mac OS X, you end
up with 3 different versions: the one that comes with OS X, the x11 one, and
TclTk Aqua). If a new UI for GRASS is based on TclTk, it could not simply be
a dependency IMHO; we would need to distribute it with GRASS in order to
make sure that all GRASS users have proper functionality--and we would need
to install it so as to avoid incompatibilities with versions that come with
OS's (e.g., as Lorenzo does by putting it into a grasslib directory). See
<http://www.activestate.com/Products/ActiveTcl/&gt; and
<http://tcltkaqua.sourceforge.net/&gt; for more information

GTK+: GTK+ is widely used in the Linux world, especially for GNOME and GNOME
apps. The best known is GIMP, of course. GTK+ meets all the criteria, except
possibly the cross-platform one. The current version of GTK+ for Linux is
2.9.1. The newest version for Windows is 2.6.9. The Mac version is under
development. There is one project that is built on GTK 1.x; another just
announced seems to be based on a reasonably current version 2.x. However
both are still in development, meaning that any GTK app in the near future
would have to run in x11 on a Mac. Using x11 is not the problem on a Mac
that it is on Windows (i.e., Cygwin). But the need to install x11 and use
non-native apps makes GRASS installation and use considerably less
accessible for the normal Mac user. See <http://www.gtk.org/&gt; for more
information.

Qt: As of last summer, there are GPL versions of Qt for all major platforms
that run GRASS. It meets all interface criteria listed above. There is
already a Qt GIS project with a GRASS plugin--QGIS--that could provide
examples for developing a GRASS UI. Qt seems to be gaining considerable
support for designing interfaces for scientific applications. See
<http://www.trolltech.com/download/qt/x11.html&gt; for more information on the
GPL version of Qt. I¹m not aware of any drawbacks.

WxWidgets: I've only recently come across this tool set. It was mentioned in
posts by Rich Shepard and Joel Pitt. Like Qt, it is a completely
cross-platform tool kit with good support for the kinds of graphic displays
we now use and envision for the next generation GRASS. I've heard good
things about it from other people too. See <http://www.wxwidgets.org/&gt; for
more information and screenshots. I¹m not aware of any drawback with this
platform either.

In summary, current version of TclTk would work well for the next generation
of GRASS, but there are issues to solve with regard to multiple versions and
potential conflicts with versions that come installed with OS's. GTK+ will
accomplish all needed UI functions, but has more limited support for
non-Linux platorms than the other 3 tool kits. This leaves Qt and WxWidgets
as interface development platforms that seem best suited to for the next
generation UI for GRASS. I¹ve only worked with TclTk, so I don¹t have any
feel for the comparative ease or difficulty of working with any of these
platforms for interface development.

That said, the reality is that the availability of people with appropriate
expertise will have a big role in which platform is chosen. A couple of
people have expressed interest in developing a Qt or GTK+ UI; I can continue
to work with TclTk and am willing to help with another platform. But we will
need a team of people both to develop and maintain the UI. If this is the
kind of project that we envision, it will take more than simply the
development of an interface that sits on top of GRASS as it is now. For
example, if we replace the xdriver with a modern display integrated with the
UI, it will require some degree of rewriting of d.rast, d.vect, and any
other display modules are retained. If we combine 2D and 3D GIS, NVIZ will
need to be rewritten to incorporate OpenGL into the main display. If we do
not go with TclTk, the routines for autogenerating dialogs for modules at
runtime will need to be ported to another platform‹or perhaps they can be
dropped if we can have better GUI/CLI integration. This all will involve
other members of the GRASS team beyond simply UI development. So deciding on
a platform for UI development is more than a simple vote of which one is
preferred, but which is one that the GRASS team will actively support.

I hope this offer you all some food for thought.

Un saludo cordial to all the GRASS team
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

7

Hi all.
So basically the GUI devel team is split in two:
- TclTk (mostly Michael)
- Qt/QGIS (mostly Radim)
Please don't take it personally, but I'm still convinced of the superiority of
the new approach, especially because we can tap from another valid pool of
developers (the qgissers), which is something we need.
Using grass as an engine behind qgis has a number of important advantages
(behind the more pleasant experience for the "normal" GIS user), attracting
new users, easing up the migration from proprietary software (see
eghttp://www.faunalia.it/en/freegis_comments/qgis_mapinfo.php), and in
general, avoiding to expose new users to unnecessary complexity. In our case,
we saved 10+ Gb of disk space for our reference (background) maps by keeping
them in their original format (geotiff and jpeg) instead of converting them
into GRASS format. Displaying other formats of data (shapefile, postgis, wms,
etc.) is also much more straightforward with qgis.
So my vote (for what is worth) is for the second solution.
pc

At 18:10, mercoledì 28 dicembre 2005 you presumably wrote:

Paolo,

I checked in the CVS. Over the past year, contributors to the TclTk
interface have included Hamish, Markus, Cho, and Florian as well as me.
Glynn Clements has given a lot of help and advice on and off list. These
folks also actively contribute to other areas of the GRASS code. Several
other people have been a big help as early testers. I've done most of the
coding for the past couple years.

I don't know how many people actively contribute to GRASS. Given the size
and complexity of the project, we could always use more. It would be ideal
if there were 3-4 people who could focus on the UI, especially while it's
in development.

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

--
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

8

Daniel Calvelo wrote:

I'm not sure I'm hammering the right nail here, but I'd suggest that
whatever the toolkit chosen, we strive first to define a proper
interface/API between the GUI front-end and the traditional CLI
front-end. What I mean is that there is a balance between a) the GUI
driving commands and b) the GUI managing state for the rest of GRASS.

As you've mentioned state management, this would be a good place to
point out that it would be useful to be able to override a lot of the
built-in statefulness (e.g. WIND, $GISRC settings, data stored on
monitor "pads", etc).

Those features make sense for command-line usage, where you don't want
to have to manually specify dozens of parameters for every command.
But they can get in the way of other uses. In particular, it makes it
hard to safely run multiple programs concurrently.

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

9

Wolf Bergenheim wrote:

The first thing that we should do even before we decide on a toolkit is
IMHO a UI design. At http://openusability.org/ we could register GRASS
and look for usability experts. Then when we have a snazzy UI design we
implement it with whatever toolkit we feel we can do the job.

The main problem I see there is that feedback from people who don't
have a background in geosciences may be of limited value. I'd attach
far more significance to comments from regular GRASS users than to
those from someone with a background in (generic) usability issues.

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

10

On czw, 2005-12-29 at 10:26 +0100, Paolo Cavallini wrote:

Hi all.
So basically the GUI devel team is split in two:
- TclTk (mostly Michael)
- Qt/QGIS (mostly Radim)

The popularity of TCL/TK compared to QT is decreasing. Thus QT
develepers are more likely to join GRASS team than those who know
TCL/TK. QT is then a safer, more durable approach.

If QT, why not help developing QGIS GRASS Tools instead of developing a
native GRASS GUI from scratch? IMHO it would be safer - QGIS GRASS Tools
plugin is being actively developed already, while the modern, native
GRASS GUI is still a matter of concept only. (Slight OT: If only QGIS
could offer multiple displays with a highly managable (copy,cut,paste of
groups and layers alone) seperate layer tree for each display, it would
be perfect. Personally I would prefer separate windows within one
workspace rather than tabs - to be able to display and compare between
multiple windows at one time.)

I think it would be better to help Radim and QGIS team in their effort
rather than starting somthing new which will never be really functional
I'm affraid. New native Grass GUI would be best, but it's not realistic
IMHO. And QGIS with Grass Tools and Grass Digit can be good. Better than
current Grass GUI for sure.

Pros for QT/QGIS approach that matter for me:
- active QGIS devel team
- most basic work already done, only need to jump in (in my
non-developer thinking, correct me if wrong)
- the ability to mix different datasources within QGIS, which Paolo
mentioned, is a cool feature. Eg. I'm digitising GRASS vector layers
with GRASS Digit tool in QGIS using geotiffs as background - no need to
double the data and fiddle with importing it to Grass first
- QGIS already displays GRASS rasters quicker than GRASS
- most FOSS GIS users (who I know) use QGIS already anyway. Thus QT libs
are already present in their systems, even if they don't use KDE. Let's
not force them to install another, TCL/TK, for Grass only - most users
won't need TCL/TK for anyting else
- TCL/TK, which Michael mentioned, is not as cross-paltform as QT is
- "the look and feel" for what it matters. I have took a look at
Michael's links with screenshots of TCL/TK apps, and although they look
better than our GRASS GIS manager indeed, I don't like those TCL/TK
sliders and window size control. They look always different (and worse
as to me) than those in KDE or GTK apps.

Please don't take it personally, but I'm still convinced of the superiority of
the new approach, especially because we can tap from another valid pool of
developers (the qgissers), which is something we need.
Using grass as an engine behind qgis has a number of important advantages
(behind the more pleasant experience for the "normal" GIS user), attracting
new users, easing up the migration from proprietary software (see
eghttp://www.faunalia.it/en/freegis_comments/qgis_mapinfo.php), and in
general, avoiding to expose new users to unnecessary complexity. In our case,
we saved 10+ Gb of disk space for our reference (background) maps by keeping
them in their original format (geotiff and jpeg) instead of converting them
into GRASS format. Displaying other formats of data (shapefile, postgis, wms,
etc.) is also much more straightforward with qgis.
So my vote (for what is worth) is for the second solution.
pc

--------------------
W polskim Internecie s± setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

11

At 13:30, giovedì 29 dicembre 2005, Glynn Clements has probably written:

The main problem I see there is that feedback from people who don't
have a background in geosciences may be of limited value. I'd attach
far more significance to comments from regular GRASS users than to
those from someone with a background in (generic) usability issues.

Agreed. And I would consider important also the feedback from GIS (non-GRASS)
experts. We have to promote interoperability (and attract more users) here,
not to satisfy grass experts only.
pc
--
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

12

Hi,

to add fuel to flame:
  - will "NeXTGRASS" target also embedded devices/systems? Its a Q
about OpenGL/resource expensive GUI toolkit.
- what do You think about SAGA?
http://www.saga-gis.uni-goettingen.de/html/index.php Look at they GUI.
- Out there are lots of new OS/Free GIS apps (JUMP, gvSIG, etc) How
GRASS would be better? Currently it is its CLIness. Do we need to
fight with other apps in they (GUI) area?
  - TclTk has historic sources, but a new GUI toolkit can be a good
start point to overlook whole program and drop/change other things
too.
  - I like Qt (my vote) (especially in KDE and not pure one ;), but
isn't Qt too C++ oriented (I'm just lame and not programmer)? Will
NeXTGRASS be mixture of C an C++?

Lets make revolution!

just my 0,02 Ls :wink:
Happy new year from snowy Latvia,
Maris.

2005/12/29, Paolo Cavallini <cavallini@faunalia.it>:

At 13:30, giovedì 29 dicembre 2005, Glynn Clements has probably written:
> The main problem I see there is that feedback from people who don't
> have a background in geosciences may be of limited value. I'd attach
> far more significance to comments from regular GRASS users than to
> those from someone with a background in (generic) usability issues.

Agreed. And I would consider important also the feedback from GIS (non-GRASS)
experts. We have to promote interoperability (and attract more users) here,
not to satisfy grass experts only.
pc
--
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

13

Michael and others,

There are have a number of calls to talk about general design first.
This is reasonable, because until we have a concrete image of what we
want, we can't make other decisions. In general I think there are 3
critical decisions to be undertaken.

1. QGIS or not. Are we willing to work within an existing framework and
live with the limitations that this brings. If so, then we need to
decide what existing aspects of this project need enhancement to meet
our goals and what parts need to be started to that our GUI needs are
met. Going with QGIS is the most conservative choice. We might not get
our ideal, but we will have something usable.

2. Tcltk or not. Although deciding on a toolkit early is not ideal,
there has been expressed and exists a very real and practical concern
about being able to succeed. By building on an existing foundations
there is a definite advantage, even if much of the existing code were
to be orphaned, at least the question of CLI/GUI interaction is mostly
resolved by taking this step. Choosing Tcltk enhancement and redesign
is slightly more daring than choosing to build with QGIS, but it is
still quite likely to succeed.

3. Other toolkits. This is the most daring choice and the one most
likely to fail to deliver anything, but offers the chance of getting
the ideal. In this camp, probably vanilla Qt is the best choice (IMHO)
as it is going to be around for a long time and is mature. GTK and wx
seem like fine tools, but the cross platform issues with GTK rule it
out and as far as I know Qt is more complete than either. Use of KDE is
unwise as it ignores the diversity of our target users.

Personally, although I'm not all that keen on Tcltk, the flexibility of
going with an interpreted front end appeals to me. On this front I see
PyQt as another option. Whatever choice is made I think the that a
discussion and decision about joining the QGIS GUI needs to be made. On
this front I think perhaps listing things we don't like or would want to
change about QGIS might be helpful. For me these would be.

1. Everything is a single window. Yuck.
2. For label placement a separate map layout page sucks.
The original design of Atlas GIS was much better. The page was
fundamental so there were no surprises about what your labels looked
like at print time. For more details on this refer to my comments in
Michael's summaries.
3. For symbols I would like to be able to vary a single symbol based on
two variables. For example change the size based on population and the
colour based on air quality. In this way a single symbol provides
information on two pieces of information. AFAIK, this is another old
Atlas feature not available anywhere that was very useful and would be
very useful to others. This can't be done in QGIS right now.

Otherwise, I quite like QGIS and see great potential in developing a
GRASS GUI in this manner. Depending on how flexible the QGIS team is,
they may be willing to enable a user choice of interface style from a
single window or multiple windows. This would take some work, but
considerably less than starting from scratch. Similarly the cartography
part of QGIS could be rewritten to do it right IMVAO (In my very
arrogant opinion). Enhancing the symbols would be minor.

Those problems fixed, one would have an excellent tool for serious use
both for analysis (building on the existing GRASS plugin) and
cartography.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

14

On Tue, Dec 27, 2005 at 11:16:49PM -0700, Michael Barton wrote:

This has led to incompatibilities and conflicts (e.g., with 8.4 in some Linux distros and
with the Cygwin version), issues with OpenGL in NVIZ, and dueling versions
in some cases (e.g., if you install Lorenzo's binaries for Mac OS X, you end
up with 3 different versions: the one that comes with OS X, the x11 one, and
TclTk Aqua). If a new UI for GRASS is based on TclTk, it could not simply be
a dependency IMHO; we would need to distribute it with GRASS in order to
make sure that all GRASS users have proper functionality--and we would need
to install it so as to avoid incompatibilities with versions that come with
OS's (e.g., as Lorenzo does by putting it into a grasslib directory). See
<http://www.activestate.com/Products/ActiveTcl/&gt; and
<http://tcltkaqua.sourceforge.net/&gt; for more information

Embedding external software within other programs is generally discouraged in
any sane GNU/Linux distribution. It requiresi maintainers also supporting for
security the embedded sofware and could create conflicts with mainstream
tools if the whole thing is not properly managed. In Debian we are
currently supporting more flavors of Tcl/Tk just to avoid breakages
in application softwares due to version incompatibilties. I see no reasons to
change this. The only software I know of that embedded in the past Tcl
is AOLserver, but the team had a very good reason for that: the need
of multithreading support which was absent/broken in old versions. It
was indeed a fork, plain and clear.

I would try to fix NVIZ threading issues instead, which still require
us to use the non-thread enabled Tcl 8.3

--
Francesco P. Lovergine

15

Trevor Wiens wrote:

3. Other toolkits. This is the most daring choice and the one most
likely to fail to deliver anything, but offers the chance of getting
the ideal. In this camp, probably vanilla Qt is the best choice (IMHO)
as it is going to be around for a long time and is mature. GTK and wx
seem like fine tools, but the cross platform issues with GTK rule it
out

What cross-platform issues? I have never had any problems with the
Windows port of Gtk.

Personally, I find that C++ libraries take more effort to learn, and
result in code which is harder to understand if you aren't "fluent"
with the library in question.

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

16

On Fri, 30 Dec 2005 12:54:07 +0000
Glynn Clements <glynn@gclements.plus.com> wrote:

Trevor Wiens wrote:

> 3. Other toolkits. This is the most daring choice and the one most
> likely to fail to deliver anything, but offers the chance of getting
> the ideal. In this camp, probably vanilla Qt is the best choice (IMHO)
> as it is going to be around for a long time and is mature. GTK and wx
> seem like fine tools, but the cross platform issues with GTK rule it
> out

What cross-platform issues? I have never had any problems with the
Windows port of Gtk.

Personally, I find that C++ libraries take more effort to learn, and
result in code which is harder to understand if you aren't "fluent"
with the library in question.

Glynn,

I agree with you about sometimes C++ libraries being difficult. In
fact, I don't like C++ and have more experience with C, Object Pascal
(Delphi) and Python. The tools for GUI construction with Qt were much
nicer than what was available for either wx or GTK when I looked
into it about a year ago.

My concern with cross-platform issues related to GTK was about Mac OS X
as explained by Michael earlier.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

17

Trevor Wiens wrote:

> > 3. Other toolkits. This is the most daring choice and the one most
> > likely to fail to deliver anything, but offers the chance of getting
> > the ideal. In this camp, probably vanilla Qt is the best choice (IMHO)
> > as it is going to be around for a long time and is mature. GTK and wx
> > seem like fine tools, but the cross platform issues with GTK rule it
> > out
>
> What cross-platform issues? I have never had any problems with the
> Windows port of Gtk.
>
> Personally, I find that C++ libraries take more effort to learn, and
> result in code which is harder to understand if you aren't "fluent"
> with the library in question.

I agree with you about sometimes C++ libraries being difficult. In
fact, I don't like C++ and have more experience with C, Object Pascal
(Delphi) and Python. The tools for GUI construction with Qt were much
nicer than what was available for either wx or GTK when I looked
into it about a year ago.

My concern with cross-platform issues related to GTK was about Mac OS X
as explained by Michael earlier.

Ok, so you're referring to the need to use X11 for GTK apps rather
than having a "native" implementation?

Personally, I would consider requiring X11 on OSX to be a reasonable
trade-off, given that there is a standard, stable implementation
available. I don't consider the extra work required to provide a
native version to be justified, given that the Unix/X11 version ought
to run just fine on OSX.

I wouldn't be particularly bothered about requiring X11 on Windows if
it was going to save on development effort, but the Windows port of
GTK would make that unnecessary. Most of the work involved in a native
(non-Cygwin) Windows version would relate to the use of core Unix
functionality (i.e. the I/O API).

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.

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

18

On Sat, 31 Dec 2005 16:05:17 +0000
Glynn Clements <glynn@gclements.plus.com> 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.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

19

Hello all,

Choice of toolkit for GRASS GUI is not just a technical issue.
There will a lot of developers wishing to develop custom applications
on top of GRASS. I prefer GTK, but someone else may prefer Qt.

I agree that it is practically dificult to develop GUI on both of this
platforms. So one toolkit need to be selected.

But while desiging the GUI, it should be considered that
at a later point of time, support can be added to the other toolkit too.

On 1/1/06, Trevor Wiens <twiens@interbaun.com> wrote:

On Sat, 31 Dec 2005 16:05:17 +0000
Glynn Clements <glynn@gclements.plus.com> 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.

--
Change the rules, or the rules will change you
     ---------Kumaranasan

--
Change the rules, or the rules will change you
     ---------Kumaranasan

20

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@gclements.plus.com>