[GRASS-dev] v.digit: Qt or wxWidgets

GRASS GIS GRASS GIS developer
1

[snip]

AFAICT, the main obstacles are v.digit and NVIZ. v.digit
needs a decision on a suitable toolkit (probably either Qt or
wxWidgets) and a volunteer. NVIZ requires someone to update
Togl to 1.7 and to conditionalise the GLX-specific code in do_zoom.c.

Glynn:
(1) I'd like to see the code written in C, as opposed to C++.
    I think more developers and users are going to know C. This
    lets users be able to trouble shoot and find bugs.
    [full disclosure: I only know C.]

(2) I looked at wxWidgets after the last time you mentioned it.
    I assume you can use it with C?

(3) I didn't understand the relationship between wxWidgets and GTK.
    Can you explain some of this?

(4) GTK is not on your list. Can you explain your thinking about
    which you prefer or which kit you would use?

Perhaps by virtue of asking these questions it means I am not
qualified to work on v.digit but I get excited (and frustrated)
about the possibility of having a window based v.digit program.

If we could discuss it a little and then have Glynn just make a
decision [1], I would run off and start learning that toolkit. I
already learned some GTK.

Respectfully,
John

[1] technical lead/mentor type relationship. So that Glynn wouldn't
do the work but so we would head off in the right direction. I
see Glynn as informally doing something like that now. Just my
opinion, of course.

2

> AFAICT, the main obstacles are v.digit and NVIZ. v.digit
> needs a decision on a suitable toolkit (probably either Qt or
> wxWidgets)

As goes v.digit, so goes GRASS. So choose wisely.

Hamish

3

Hallo, I have a copy of Art of Unix programing here (Eric S. Raymond)
from 2003 and he writes, that wxWindows does not provide support for C,
where Qt does.

wxWindows should be very well look and feeling on all importand
platforms (Win, Mac, Unix).

I would say, after all I read, that wxWindows should be *the* toolkit,
however, GRASS should be developed in C - but as you know, I do not have
much experience in GUI programing.

Conclusion: what about using python for this task? Thuban is allready
using it and it works. Lot of people are learning python right now
(including me), so there could be, theoreticaly more people able to help
with the development, than people knowing C(++) very well (same for
pyQt)

Any way, good luck by your decision!

Jachym

On Sat, May 20, 2006 at 06:38:04AM +1200, Hamish wrote:

> > AFAICT, the main obstacles are v.digit and NVIZ. v.digit
> > needs a decision on a suitable toolkit (probably either Qt or
> > wxWidgets)

As goes v.digit, so goes GRASS. So choose wisely.

Hamish

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

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

4

I can offer a couple of answers, though Glynn and others can fill in richer
details.

(2) wxWidgets is an interface building platform, like TclTk, QT, and GTK. It
can be used with C.

(3) I think that this is answered in (2)

(4) wxWidgets, like QT and TclTk has versions that run natively across
platforms--inlcuding most *nix flavors, Mac OS X, and Windows. GTK runs
primarily in X11 (though there are experimental versions under development
for other platforms I understand).

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

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

From: John Gillette <JGillette@rfmd.com>
Date: Fri, 19 May 2006 12:03:15 -0400
To: Glynn Clements <glynn@gclements.plus.com>
Cc: <grass-dev@grass.itc.it>
Subject: [GRASS-dev] v.digit: Qt or wxWidgets

[snip]

AFAICT, the main obstacles are v.digit and NVIZ. v.digit
needs a decision on a suitable toolkit (probably either Qt or
wxWidgets) and a volunteer. NVIZ requires someone to update
Togl to 1.7 and to conditionalise the GLX-specific code in do_zoom.c.

Glynn:
(1) I'd like to see the code written in C, as opposed to C++.
    I think more developers and users are going to know C. This
    lets users be able to trouble shoot and find bugs.
    [full disclosure: I only know C.]

(2) I looked at wxWidgets after the last time you mentioned it.
    I assume you can use it with C?

(3) I didn't understand the relationship between wxWidgets and GTK.
    Can you explain some of this?

(4) GTK is not on your list. Can you explain your thinking about
    which you prefer or which kit you would use?

Perhaps by virtue of asking these questions it means I am not
qualified to work on v.digit but I get excited (and frustrated)
about the possibility of having a window based v.digit program.

If we could discuss it a little and then have Glynn just make a
decision [1], I would run off and start learning that toolkit. I
already learned some GTK.

Respectfully,
John

[1] technical lead/mentor type relationship. So that Glynn wouldn't
do the work but so we would head off in the right direction. I
see Glynn as informally doing something like that now. Just my
opinion, of course.

5

Hello,

I have been working on a GTK based GUI for a little while now. Hopefully
I will get around to releasing it one of these days. I have tested the
program under Linux, CygWin, and Windows(XP). It easily cross-compiles
to run under Windows. Unfortunately, I do not have access to a Mac, so I
cannot test it there.

Also, I should mention that I have been building it against the GRASS
ogsf library allowing it to render in 3D (NVIZ). The idea is that the
user can easily switch between 2D & 3D views.

--
Bob

On Fri, 2006-05-19 at 12:42 -0700, Michael Barton wrote:

I can offer a couple of answers, though Glynn and others can fill in richer
details.

(2) wxWidgets is an interface building platform, like TclTk, QT, and GTK. It
can be used with C.

(3) I think that this is answered in (2)

(4) wxWidgets, like QT and TclTk has versions that run natively across
platforms--inlcuding most *nix flavors, Mac OS X, and Windows. GTK runs
primarily in X11 (though there are experimental versions under development
for other platforms I understand).

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

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

> From: John Gillette <JGillette@rfmd.com>
> Date: Fri, 19 May 2006 12:03:15 -0400
> To: Glynn Clements <glynn@gclements.plus.com>
> Cc: <grass-dev@grass.itc.it>
> Subject: [GRASS-dev] v.digit: Qt or wxWidgets
>
> [snip]
>
>> AFAICT, the main obstacles are v.digit and NVIZ. v.digit
>> needs a decision on a suitable toolkit (probably either Qt or
>> wxWidgets) and a volunteer. NVIZ requires someone to update
>> Togl to 1.7 and to conditionalise the GLX-specific code in do_zoom.c.
>
> Glynn:
> (1) I'd like to see the code written in C, as opposed to C++.
> I think more developers and users are going to know C. This
> lets users be able to trouble shoot and find bugs.
> [full disclosure: I only know C.]
>
> (2) I looked at wxWidgets after the last time you mentioned it.
> I assume you can use it with C?
>
> (3) I didn't understand the relationship between wxWidgets and GTK.
> Can you explain some of this?
>
> (4) GTK is not on your list. Can you explain your thinking about
> which you prefer or which kit you would use?
>
> Perhaps by virtue of asking these questions it means I am not
> qualified to work on v.digit but I get excited (and frustrated)
> about the possibility of having a window based v.digit program.
>
> If we could discuss it a little and then have Glynn just make a
> decision [1], I would run off and start learning that toolkit. I
> already learned some GTK.
>
> Respectfully,
> John
>
> [1] technical lead/mentor type relationship. So that Glynn wouldn't
> do the work but so we would head off in the right direction. I
> see Glynn as informally doing something like that now. Just my
> opinion, of course.
>
>
>
>
>
>
>

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

6

John Gillette wrote:

> AFAICT, the main obstacles are v.digit and NVIZ. v.digit
> needs a decision on a suitable toolkit (probably either Qt or
> wxWidgets) and a volunteer. NVIZ requires someone to update
> Togl to 1.7 and to conditionalise the GLX-specific code in do_zoom.c.

Glynn:
(1) I'd like to see the code written in C, as opposed to C++.
    I think more developers and users are going to know C. This
    lets users be able to trouble shoot and find bugs.
    [full disclosure: I only know C.]

That would be nice. Unfortunately, both Qt and wxWidgets use a C++
API. GTK uses C, but the native MacOSX version is currently "alpha"
quality.

Actually, the MacOSX port seems a bit further along than I had
realised. In that case, GTK might be a viable option. If the native
MacOSX version isn't stable enough for normal use, the X11 version of
GTK can be used until the native version has matured.

The status page is here:

http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do

(2) I looked at wxWidgets after the last time you mentioned it.
    I assume you can use it with C?

No. The API is C++ (i.e. each widget is a C++ object).

(3) I didn't understand the relationship between wxWidgets and GTK.
    Can you explain some of this?

wxWidgets provides a common interface to a variety of different GUI
toolkits: GTK, Motif, raw Xlib, Win32, and Mac (Carbon and
"non-Carbon").

The basic WX widgets are usually wrappers around the widgets provided
by the underlying toolkit. More complex widgets have to be implemented
by wxWidgets itself (as do all of the widgets for the raw Xlib
version).

The net result is a wxWidgets application should have a native look
and feel. Other GUI toolkits tend to implement all of the widgets
themselves, which mean that an application tends to look and behave
the same on all platforms.

(4) GTK is not on your list. Can you explain your thinking about
    which you prefer or which kit you would use?

I had excluded GTK because there didn't appear to be a usable native
version for MacOSX. If the native MacOSX version is likely to be
usable in the near future, then GTK would be a viable option (and the
fact that it's API is in C gives it an advantage over Qt and
wxWidgets).

Perhaps by virtue of asking these questions it means I am not
qualified to work on v.digit but I get excited (and frustrated)
about the possibility of having a window based v.digit program.

If we could discuss it a little and then have Glynn just make a
decision [1], I would run off and start learning that toolkit. I
already learned some GTK.

It would be useful if someone with a Mac could provide feedback on the
current state of GTK on MacOSX.

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

7

I am very much in favor of continuing to develop and improve the GRASS GUI.
Since we've come back to the question of GUI platforms, I have a question
that might help to clarify things somewhat.

Why do we need/want switch from TclTk? After working with it for the past
several months and seeing the kind of work that Cedric Shock has done, I'm
very impressed.

TclTk is completely open source--no licensing issues (unlike QT).
It is very cross-platform, with mature versions--largely in sync--available
on all platforms that run GRASS (unlike GTK+).
The versions have a native look on different platforms. With Tile being
included in version 8.5 (currently in active beta and far along), this will
get even better with multiple themed looks for all platforms.
It is being actively developed. I think it's gone from 8.4.5 to 8.4.13 in
the last year, and 8.5 appears nearing final release.
It is relatively easy to program in (even I can do it). This makes it easier
to find developers among the volunteers that maintain GRASS
It has API's and libraries for C (unlike wxWidgets)--and for other languages
including Java.
There are sophisticated extensions that we could use if we wanted (for
tables, SQLite, XML, SWIG, SOAP, etc.).
The Togl widget allows it to use OpenGL and do so very efficiently. NVIZ
rendering always blows people away who are used to ArcGIS.

I'm sure there are limitations, but I don't know what they are or whether
they are or are not relevant for a GRASS GUI. Any slowness in the displays
with the new TclTk canvases is primarily due to GRASS display drivers, not
TclTk. If the icons look amaturish, it is because they are made by an
amature (me). I've seen screenshots of other TclTk application that are very
slick.

Because I want GRASS to have a very good UI, I am not opposed to moving to a
new GUI development platform. But it would be helpful to understand the
reasons for doing so.

Thanks
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

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

From: Glynn Clements <glynn@gclements.plus.com>
Date: Sat, 20 May 2006 12:50:54 +0100
To: John Gillette <JGillette@rfmd.com>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] v.digit: Qt or wxWidgets

John Gillette wrote:

AFAICT, the main obstacles are v.digit and NVIZ. v.digit
needs a decision on a suitable toolkit (probably either Qt or
wxWidgets) and a volunteer. NVIZ requires someone to update
Togl to 1.7 and to conditionalise the GLX-specific code in do_zoom.c.

Glynn:
(1) I'd like to see the code written in C, as opposed to C++.
    I think more developers and users are going to know C. This
    lets users be able to trouble shoot and find bugs.
    [full disclosure: I only know C.]

That would be nice. Unfortunately, both Qt and wxWidgets use a C++
API. GTK uses C, but the native MacOSX version is currently "alpha"
quality.

Actually, the MacOSX port seems a bit further along than I had
realised. In that case, GTK might be a viable option. If the native
MacOSX version isn't stable enough for normal use, the X11 version of
GTK can be used until the native version has matured.

The status page is here:

http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do

(2) I looked at wxWidgets after the last time you mentioned it.
    I assume you can use it with C?

No. The API is C++ (i.e. each widget is a C++ object).

(3) I didn't understand the relationship between wxWidgets and GTK.
    Can you explain some of this?

wxWidgets provides a common interface to a variety of different GUI
toolkits: GTK, Motif, raw Xlib, Win32, and Mac (Carbon and
"non-Carbon").

The basic WX widgets are usually wrappers around the widgets provided
by the underlying toolkit. More complex widgets have to be implemented
by wxWidgets itself (as do all of the widgets for the raw Xlib
version).

The net result is a wxWidgets application should have a native look
and feel. Other GUI toolkits tend to implement all of the widgets
themselves, which mean that an application tends to look and behave
the same on all platforms.

(4) GTK is not on your list. Can you explain your thinking about
    which you prefer or which kit you would use?

I had excluded GTK because there didn't appear to be a usable native
version for MacOSX. If the native MacOSX version is likely to be
usable in the near future, then GTK would be a viable option (and the
fact that it's API is in C gives it an advantage over Qt and
wxWidgets).

Perhaps by virtue of asking these questions it means I am not
qualified to work on v.digit but I get excited (and frustrated)
about the possibility of having a window based v.digit program.

If we could discuss it a little and then have Glynn just make a
decision [1], I would run off and start learning that toolkit. I
already learned some GTK.

It would be useful if someone with a Mac could provide feedback on the
current state of GTK on MacOSX.

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

8

On Sat, 20 May 2006 13:14:32 -0700
Michael Barton <michael.barton@asu.edu> wrote:

I am very much in favor of continuing to develop and improve the GRASS GUI.
Since we've come back to the question of GUI platforms, I have a question
that might help to clarify things somewhat.

Why do we need/want switch from TclTk? After working with it for the past
several months and seeing the kind of work that Cedric Shock has done, I'm
very impressed.

TclTk is completely open source--no licensing issues (unlike QT).
It is very cross-platform, with mature versions--largely in sync--available
on all platforms that run GRASS (unlike GTK+).
The versions have a native look on different platforms. With Tile being
included in version 8.5 (currently in active beta and far along), this will
get even better with multiple themed looks for all platforms.
It is being actively developed. I think it's gone from 8.4.5 to 8.4.13 in
the last year, and 8.5 appears nearing final release.
It is relatively easy to program in (even I can do it). This makes it easier
to find developers among the volunteers that maintain GRASS
It has API's and libraries for C (unlike wxWidgets)--and for other languages
including Java.
There are sophisticated extensions that we could use if we wanted (for
tables, SQLite, XML, SWIG, SOAP, etc.).
The Togl widget allows it to use OpenGL and do so very efficiently. NVIZ
rendering always blows people away who are used to ArcGIS.

I'm sure there are limitations, but I don't know what they are or whether
they are or are not relevant for a GRASS GUI. Any slowness in the displays
with the new TclTk canvases is primarily due to GRASS display drivers, not
TclTk. If the icons look amaturish, it is because they are made by an
amature (me). I've seen screenshots of other TclTk application that are very
slick.

Because I want GRASS to have a very good UI, I am not opposed to moving to a
new GUI development platform. But it would be helpful to understand the
reasons for doing so.

I would second Michael on this. At first I thought the thing to do was
to dump tcl/tk as the old d.m looked, well, pretty crappy, but things
have come a long way in a short time. If we don't have to start from
scratch, lets not, but if we can really improve functionality by going
with GTK (which seems the obvious choice for GRASS given the C bias) or
some other more modern tool kit, then it is worth it. If we need more
interactive functionality in our module dialogues, I would want to
explore further developing g.parser to support that before having to
dump it and start everything from scatch.

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)

9

Dear developers,

On Saturday 20 May 2006 22:14, Michael Barton wrote:

I am very much in favor of continuing to develop and improve the GRASS GUI.
Since we've come back to the question of GUI platforms, I have a question
that might help to clarify things somewhat.

Why do we need/want switch from TclTk? After working with it for the past
several months and seeing the kind of work that Cedric Shock has done, I'm
very impressed.

That question bothers me too!

Is there no way to implement v.digit and nviz in Tcl/Tk? Do we really need to
use GTK+, wxWidgets or Qt? If so, we have additional dependencies in grass and the look and
feel of the grass gui will differ between the "normal" GUI and v.digit + nviz.
A lot of new problems will appear, depedency problems, version problems, stability problems (especially with GTK+)... .

I think with Qt, wxWindows or GTK+ we may develop a very sophisticated GUI, but which one
of us has experience with those toolkits? I only know a bit of Qt and fltk (Im a big fan of C++) and
learning them needs a lot of time.
Programming a good! new GUI is a large and very complex piece of work.
And a lot of work has been done by Michael and Cedric to improve the existing GUI and they are doing very well,
and i like it very much. :slight_smile:
And AFAIK many developers have experience with TclTk. So i think we need a good reason to move from Tcl/Tk to
another toolkit.

And if somebody really want to extend an existing nice gui with an object orientated approach, qgis or jgrass
will appreciate any help. :wink: ... just kidding ...

Just my two cent
Best regards
Soeren

Because I want GRASS to have a very good UI, I am not opposed to moving to a
new GUI development platform. But it would be helpful to understand the
reasons for doing so.

Thanks
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

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

> From: Glynn Clements <glynn@gclements.plus.com>
> Date: Sat, 20 May 2006 12:50:54 +0100
> To: John Gillette <JGillette@rfmd.com>
> Cc: <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] v.digit: Qt or wxWidgets
>
>
> John Gillette wrote:
>
>>> AFAICT, the main obstacles are v.digit and NVIZ. v.digit
>>> needs a decision on a suitable toolkit (probably either Qt or
>>> wxWidgets) and a volunteer. NVIZ requires someone to update
>>> Togl to 1.7 and to conditionalise the GLX-specific code in do_zoom.c.
>>
>> Glynn:
>> (1) I'd like to see the code written in C, as opposed to C++.
>> I think more developers and users are going to know C. This
>> lets users be able to trouble shoot and find bugs.
>> [full disclosure: I only know C.]
>
> That would be nice. Unfortunately, both Qt and wxWidgets use a C++
> API. GTK uses C, but the native MacOSX version is currently "alpha"
> quality.
>
> Actually, the MacOSX port seems a bit further along than I had
> realised. In that case, GTK might be a viable option. If the native
> MacOSX version isn't stable enough for normal use, the X11 version of
> GTK can be used until the native version has matured.
>
> The status page is here:
>
> http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do
>
>> (2) I looked at wxWidgets after the last time you mentioned it.
>> I assume you can use it with C?
>
> No. The API is C++ (i.e. each widget is a C++ object).
>
>> (3) I didn't understand the relationship between wxWidgets and GTK.
>> Can you explain some of this?
>
> wxWidgets provides a common interface to a variety of different GUI
> toolkits: GTK, Motif, raw Xlib, Win32, and Mac (Carbon and
> "non-Carbon").
>
> The basic WX widgets are usually wrappers around the widgets provided
> by the underlying toolkit. More complex widgets have to be implemented
> by wxWidgets itself (as do all of the widgets for the raw Xlib
> version).
>
> The net result is a wxWidgets application should have a native look
> and feel. Other GUI toolkits tend to implement all of the widgets
> themselves, which mean that an application tends to look and behave
> the same on all platforms.
>
>> (4) GTK is not on your list. Can you explain your thinking about
>> which you prefer or which kit you would use?
>
> I had excluded GTK because there didn't appear to be a usable native
> version for MacOSX. If the native MacOSX version is likely to be
> usable in the near future, then GTK would be a viable option (and the
> fact that it's API is in C gives it an advantage over Qt and
> wxWidgets).
>
>> Perhaps by virtue of asking these questions it means I am not
>> qualified to work on v.digit but I get excited (and frustrated)
>> about the possibility of having a window based v.digit program.
>>
>> If we could discuss it a little and then have Glynn just make a
>> decision [1], I would run off and start learning that toolkit. I
>> already learned some GTK.
>
> It would be useful if someone with a Mac could provide feedback on the
> current state of GTK on MacOSX.
>
> --
> Glynn Clements <glynn@gclements.plus.com>
>
>

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

10

I'm not crazy about Tcl as a language---I would have preferred GRASS
standardize on Python---but, I think Michael makes several good
points:

1. It is working
2. It is easy to learn
3. It is pretty powerful

Tk can look butt-ugly on Debian/Ubuntu, but maybe that will be fixed
sooner rather than later...

At any rate, even if Tcl isn't the language for us, surely Python
could be. It has mature bindings to all of the major GUI toolkits. I
can't imagine why we would program a GUI in C or C++ unless it was
absolutely necessary. GRASS is a research tool, rapid development is
part of its appeal.

David

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

On Sat, 20 May 2006 13:14:32 -0700
Michael Barton <michael.barton@asu.edu> wrote:

> I am very much in favor of continuing to develop and improve the GRASS GUI.
> Since we've come back to the question of GUI platforms, I have a question
> that might help to clarify things somewhat.
>
> Why do we need/want switch from TclTk? After working with it for the past
> several months and seeing the kind of work that Cedric Shock has done, I'm
> very impressed.
>
> TclTk is completely open source--no licensing issues (unlike QT).
> It is very cross-platform, with mature versions--largely in sync--available
> on all platforms that run GRASS (unlike GTK+).
> The versions have a native look on different platforms. With Tile being
> included in version 8.5 (currently in active beta and far along), this will
> get even better with multiple themed looks for all platforms.
> It is being actively developed. I think it's gone from 8.4.5 to 8.4.13 in
> the last year, and 8.5 appears nearing final release.
> It is relatively easy to program in (even I can do it). This makes it easier
> to find developers among the volunteers that maintain GRASS
> It has API's and libraries for C (unlike wxWidgets)--and for other languages
> including Java.
> There are sophisticated extensions that we could use if we wanted (for
> tables, SQLite, XML, SWIG, SOAP, etc.).
> The Togl widget allows it to use OpenGL and do so very efficiently. NVIZ
> rendering always blows people away who are used to ArcGIS.
>
> I'm sure there are limitations, but I don't know what they are or whether
> they are or are not relevant for a GRASS GUI. Any slowness in the displays
> with the new TclTk canvases is primarily due to GRASS display drivers, not
> TclTk. If the icons look amaturish, it is because they are made by an
> amature (me). I've seen screenshots of other TclTk application that are very
> slick.
>
> Because I want GRASS to have a very good UI, I am not opposed to moving to a
> new GUI development platform. But it would be helpful to understand the
> reasons for doing so.
>

I would second Michael on this. At first I thought the thing to do was
to dump tcl/tk as the old d.m looked, well, pretty crappy, but things
have come a long way in a short time. If we don't have to start from
scratch, lets not, but if we can really improve functionality by going
with GTK (which seems the obvious choice for GRASS given the C bias) or
some other more modern tool kit, then it is worth it. If we need more
interactive functionality in our module dialogues, I would want to
explore further developing g.parser to support that before having to
dump it and start everything from scatch.

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)

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

--
David Finlayson

11

Subject: Re: [GRASS-dev] v.digit: Qt or wxWidgets

Tk can look butt-ugly on Debian/Ubuntu, but maybe that will be fixed
sooner rather than later...

Here is the Tile page with examples of different themes for various OS's.
Tile can be used now as a TclTk add on and Tile widgets are being included
in TclTk 8.5

<http://tktable.sourceforge.net/tile/&gt;
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

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

12

On Sat, 2006-05-20 at 15:45 -0700, David Finlayson wrote:

I'm not crazy about Tcl as a language---I would have preferred GRASS
standardize on Python---but, I think Michael makes several good
points:

1. It is working
2. It is easy to learn
3. It is pretty powerful

Tk can look butt-ugly on Debian/Ubuntu, but maybe that will be fixed
sooner rather than later...

At any rate, even if Tcl isn't the language for us, surely Python
could be.

I would second that, FWIW.

M

13

Michael Barton wrote:

I am very much in favor of continuing to develop and improve the GRASS GUI.
Since we've come back to the question of GUI platforms, I have a question
that might help to clarify things somewhat.

Why do we need/want switch from TclTk?

1. Both the Tcl language and the Tk toolkit are too primitive.
2. Linking to external libraries is too complex.

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

14

My idea was, if we have a better idea of what is missing in TclTk it would
help pick a GUI toolkit to replace it. We'll also need people with some
expertise in that toolkit to port the GUI.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

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

From: Glynn Clements <glynn@gclements.plus.com>
Date: Sun, 21 May 2006 07:53:27 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: John Gillette <JGillette@rfmd.com>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] v.digit: Qt or wxWidgets

Why do we need/want switch from TclTk?

1. Both the Tcl language and the Tk toolkit are too primitive.
2. Linking to external libraries is too complex.

15

On Sun, 21 May 2006 07:53:27 +0100
Glynn Clements <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

> I am very much in favor of continuing to develop and improve the GRASS GUI.
> Since we've come back to the question of GUI platforms, I have a question
> that might help to clarify things somewhat.
>
> Why do we need/want switch from TclTk?

1. Both the Tcl language and the Tk toolkit are too primitive.
2. Linking to external libraries is too complex.

Recalling discussions some time back, the move to gis.m involved in
part separating GRASS from x-display. That has been done and in fact
gis.m is evolved considerably (great work Michael and Cedric!). However
if we know we will drop Tcl/Tk, then perhaps it would be reasonable to
think about how far gis.m needs to be taken before beginning
development on the replacement.

Another question to be considered is one of both language and toolkit.
For people who have a strong familiarity with C they naturally choose
developing in C, but as has been pointed out in earlier posts, GRASS
is a oriented around research so rapid development is desirable. My
understanding is that with SWIG, calls to various GRASS libraries can
be made from Perl or Python (amongst other languages). It would seem
natural then to consider a language for the gui development that could
also be used to create new modules without having to use C. On a
personal note this would be a great boon and one of the reasons I use
PostGIS for most of my vector work because I dislike using C unless I
really have to.

From where I stand the considerations that flow into this are what is

accessible to new users and developers and also how can we ensure that
new code is readable. It is very true that obfuscated code can be
written in any language, but from my experience most people will agree
that Python is generally better for readability than Perl. Further with
ESRI adopting Python it means more and more potential converts to GRASS
will be familiar with it. Python is a natural choice. We can save C for
where it is really needed.

This still raises the question of toolkits and this is, even more than
language, is a question of preference. wxPython is built on GTK, which
begs the question why not just use PyGTK. PyQt is also very nice and
has nice tools. Having experimented with the gui builders for GTK and
Qt I would say that the QT tools are much more sophisticated and
there are no licensing issues anymore with Qt, so it would probably
be the best choice, even if it may mean some learning.

This debate has been put to the side for some time, but if we want to
take Glynn's comments seriously about the limitations of TclTk (which I
do) then we need to decide how much further to take gis.m and what to
use for its replacement.

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)

16

Michael:

We'll also need people with some expertise in that toolkit to port the
GUI.

I think if we all learn one system we can help each other and it won't
be "too much". Sure, we'll need expert help along the way.

Trevor:

However if we know we will drop Tcl/Tk, then perhaps it would be
reasonable to think about how far gis.m needs to be taken before
beginning development on the replacement.

The hard part is the design*, not the implementation**.

[*] menu clustering, good icons, correct use of WIND vs WIND_OVERRIDE, etc.
[**] what language it is finally written in.

As long as we are not spending all our time working around TclTk
limitations, I don't see new work on gis.m as being wasted. Quite the
contrary.

[Python]

Python lowers the barriers to entry & removes whole classes of bugs,
which is nice when our numbers of expert C programmers is low. We'd have
a lot more devels for the project too. This is why TclTk has been nice.
But I know zero Python, GTK, Qt, Wx, etc. :slight_smile:
We can improve GRASS's SWIG code as needed.

To air personal preferences: (purely cosmetic, so "+0")
I find Qt too bubble-gum, Tcl/Tk (even themes*) too ugly.
[*] the Mac/Win native ones are ok.

Glynn:

I'm more concerned about the Mac. In particular, the fact that you can
use the Unix/X11 version of GTK with an X server allows developers to
"cop out" and risks reducing the motivation to develop the native
version.

Are you saying it's a "cop out" for us or for the MacGTK porters?

It is a crutch; we can develop with X11 GTK on Mac and release with
native GTK when it is ready. We are not going backwards by doing that.
My guess is that GTK is big enough and Mac devels are pro-native enough
that the existing situation will not last very long.

Hamish

17

Hamish wrote:

> I'm more concerned about the Mac. In particular, the fact that you can
> use the Unix/X11 version of GTK with an X server allows developers to
> "cop out" and risks reducing the motivation to develop the native
> version.

Are you saying it's a "cop out" for us or for the MacGTK porters?

Well, both.

We could choose any Unix/X11 toolkit and sidestep portability issues
with "the Mac has X11, and Windows has Cygwin and Cygwin's X server".

So far as "native" Windows/Mac versions are concerned, I consider
"native" to mean "doesn't require an X server, Cygwin etc", so
Windows/Mac versions of GTK or Qt are acceptable. As opposed to "must
use the OS' native widgets", which would limit us to wxWidgets.

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

18

On 5/20/06, Michael Barton <michael.barton@asu.edu> wrote:

TclTk is completely open source--no licensing issues (unlike QT).

???!!!

Radim

19

Michael Barton wrote:

>> Why do we need/want switch from TclTk?
>
> 1. Both the Tcl language and the Tk toolkit are too primitive.
> 2. Linking to external libraries is too complex.

My idea was, if we have a better idea of what is missing in TclTk it would
help pick a GUI toolkit to replace it. We'll also need people with some
expertise in that toolkit to port the GUI.

The main thing that's missing is an immediate-mode canvas and the
drawing functions needed to make use of it. I.e. equivalents of
GtkDrawingArea/GDK, XmDrawingArea/Xlib etc.

You also need adequate performance; if executing the language wrapper
around XDrawLine() takes 10 times as long as actually executing
XDrawLine(), redraw is going to be slow.

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

20

Trevor Wiens wrote:

This still raises the question of toolkits and this is, even more than
language, is a question of preference. wxPython is built on GTK, which
begs the question why not just use PyGTK.

wxPython is based upon wxWidgets, which provides a common interface to
several GUI toolkits (as well as providing a complete toolkit using
just Xlib). The most popular version of wxWidgets on Unix/X11 systems
is wxGTK, although you can also use the Motif or Xlib versions (or, if
you really wanted to, you could probably use wxMSW atop WINElib).

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