It looks like v.pyedit is written in pyGTK rather than wxPython. Will
v.pygtk run natively on Windows or Apple? Will it look like a native
application?
From my brief look at the toolkits, it seemed that wxPython was a
little more cross platform friendly because it used native widgets.
--
David Finlayson
Hi,
On Wed, Jun 07, 2006 at 09:53:48AM -0700, David Finlayson wrote:
It looks like v.pyedit is written in pyGTK rather than wxPython. Will
v.pygtk run natively on Windows or Apple?
Should run
Will it look like a native application?
AFAIK now, does it harm? My experience with Gaim on windows area, that
it looks almost like the native gui apps. My mother is using gaim and
she has no problem with that, how it looks like.
From my brief look at the toolkits, it seemed that wxPython was a
little more cross platform friendly because it used native widgets.
I was asking other users, if they could live with Gtk gui. Nobody
answared. I do not understand, why any GUI should look "native". It
should just be intuitive.
I'm developing v.pydigit mostly for studing purposes. At the end should
we be on the beginning of the new GRASS GUI (if any). v.pydigit should
show, how to write things and show the posibilities and advantages of 3
tools:
* python
* glade
* gtk+
I thing, I can say now, that these tools
* are making gui development fast and easy even for non-programers
* the gui can be "fast enough" for common usage
* it is possible to run it even on not-so-well equiped computers
--
* I like the way, Gtk+ apps are looking/can look.
--
(Ones I tryed to work with python+Qt - it was sooo sloow)
IIRC, there is no tool for wxWindows, which would act similar to Glade.
Glade is producing XML files. What I read, the best tool like glade for
gtk, would be wxglade for wxwindows. It produces pure xml file, which
disables to bind results from glade in another language, but this is
only how I understand it, so if anybody else would have experience with
tools like this, I would welcome comments from your site.
Anyway, if you or anybody else will start to develop any other GUI using
wxWindows, you can count with me.
BTW: New version of v.pydigit is able to digitize lines, boundaries,
points and centroids. You can edit your attribute table and add
attributes to new digitized features. I wrote some summary to another
e-mail, but it did not come to this list so far.
I newver said, v.pydigit will/should be *the* grass GUI or *the* grass
digitalisation tool. The more it can, the more I thing, I would start
from scratch and build most of the app again more as real GUI framework
and not only one-tool program. But it could be here, until we will not
have something more common, and people could use it for their common
work. I hope to make it work better (user friendlier), than v.digit ever was
(I'll see, how much time I'll have, this is not my only project and not
the most importand one)
Jachym
--
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
David Finlayson wrote:
It looks like v.pyedit is written in pyGTK rather than wxPython. Will
v.pygtk run natively on Windows or Apple?
Only if you have GTK.
Will it look like a native application?
Only to the extent that GTK does, which depends upon the theme being used.
>From my brief look at the toolkits, it seemed that wxPython was a
little more cross platform friendly because it used native widgets.
While a native look-and-feel is nice to have, using native widgets can
create portability issues due to differences in the way that
equivalent widgets behave.
Also, obtaining a native look-and-feel involves more than just using
the platform's native widgets. There are also conventions which rely
upon the application to follow them, which means writing separate
cases for each platform.
Using a toolkit which behaves identically on all platforms is simpler
for the developers (and we aren't exactly overstaffed). It also means
that the application behaves in a consistent manner on all platforms,
which is useful if you use multiple platforms, or if you are writing
documentation.
--
Glynn Clements <glynn@gclements.plus.com>
I am sure your work is great and greatly appreciated! For what it is
worth, I use Gnome on Linux, so I agree with you about GTK looking
good---it does to me anyway.
I was mainly concerned about Apple users. The last I heard, GTK was
not easy to install on Apple OSX and many apple users have a natural
revulsion to non-native apps (I don't own an apple so I don't
understand myself). Windows has never had a standard GUI so it is less
of an issue with Windows users.
I was toying with the idea of creating a Matlab or R-style GUI for
grass. The idea would be to have a command line interface with helper
applications such as graphics monitors, text editor, file browser,
help-system, etc. All accessible from tool bars. People seem to really
like Matlab once they learn it and I thought that if a grass version
were done right, even guys like me might use it (which means that I
better write code that I want to use!).
If the "shell" were Python, I could build most of this out of the
default tools in wxPython. In fact, I got a basic editor up and
running in about 100 lines of code!
All the pieces are there for display, editing, python interpreter,
color pickers etc.
I was looking at the XML specification for GUIs which could build a
GUI for command line tools on the fly the way gis.m does now. And the
framework seems flexible enough to make it really easy to add new
tools by non-programmers who know a few things about Python.
All that being said. It would be a real pain to maintain programs in 3
different GUI frameworks. If pyGTK works, maybe I ought to look at
that for my GUI.
David
On 6/7/06, Jachym Cepicky <jachym.cepicky@centrum.cz> wrote:
Hi,
On Wed, Jun 07, 2006 at 09:53:48AM -0700, David Finlayson wrote:
> It looks like v.pyedit is written in pyGTK rather than wxPython. Will
> v.pygtk run natively on Windows or Apple?Should run
> Will it look like a native application?
AFAIK now, does it harm? My experience with Gaim on windows area, that
it looks almost like the native gui apps. My mother is using gaim and
she has no problem with that, how it looks like.>
> From my brief look at the toolkits, it seemed that wxPython was a
> little more cross platform friendly because it used native widgets.
>I was asking other users, if they could live with Gtk gui. Nobody
answared. I do not understand, why any GUI should look "native". It
should just be intuitive.I'm developing v.pydigit mostly for studing purposes. At the end should
we be on the beginning of the new GRASS GUI (if any). v.pydigit should
show, how to write things and show the posibilities and advantages of 3
tools:* python
* glade
* gtk+I thing, I can say now, that these tools
* are making gui development fast and easy even for non-programers
* the gui can be "fast enough" for common usage
* it is possible to run it even on not-so-well equiped computers
--
* I like the way, Gtk+ apps are looking/can look.
--
(Ones I tryed to work with python+Qt - it was sooo sloow)IIRC, there is no tool for wxWindows, which would act similar to Glade.
Glade is producing XML files. What I read, the best tool like glade for
gtk, would be wxglade for wxwindows. It produces pure xml file, which
disables to bind results from glade in another language, but this is
only how I understand it, so if anybody else would have experience with
tools like this, I would welcome comments from your site.Anyway, if you or anybody else will start to develop any other GUI using
wxWindows, you can count with me.BTW: New version of v.pydigit is able to digitize lines, boundaries,
points and centroids. You can edit your attribute table and add
attributes to new digitized features. I wrote some summary to another
e-mail, but it did not come to this list so far.I newver said, v.pydigit will/should be *the* grass GUI or *the* grass
digitalisation tool. The more it can, the more I thing, I would start
from scratch and build most of the app again more as real GUI framework
and not only one-tool program. But it could be here, until we will not
have something more common, and people could use it for their common
work. I hope to make it work better (user friendlier), than v.digit ever was
(I'll see, how much time I'll have, this is not my only project and not
the most importand one)Jachym
--
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-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)iD8DBQFEhzR7yKt0uAjU4I8RAilqAKCzAFMAv2nrTGdsLOVhWbI7kINRxQCdHEoc
GMMh3ioWxjdvR+i9TNB64qs=
=XPrR
-----END PGP SIGNATURE-----
--
David Finlayson
Perhaps a more important question. The GTK apps I know of (GIMP for example)
need x11 to run on my Mac. Can GTK apps run without x11? In Aqua on Macs? In
(whatever it is) on Windows?
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: Glynn Clements <glynn@gclements.plus.com>
Date: Wed, 7 Jun 2006 21:48:13 +0100
To: David Finlayson <david.p.finlayson@gmail.com>
Cc: GRASS developers list <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Python GUI toolkitsDavid Finlayson wrote:
It looks like v.pyedit is written in pyGTK rather than wxPython. Will
v.pygtk run natively on Windows or Apple?Only if you have GTK.
Will it look like a native application?
Only to the extent that GTK does, which depends upon the theme being used.
From my brief look at the toolkits, it seemed that wxPython was a
little more cross platform friendly because it used native widgets.
While a native look-and-feel is nice to have, using native widgets can
create portability issues due to differences in the way that
equivalent widgets behave.Also, obtaining a native look-and-feel involves more than just using
the platform's native widgets. There are also conventions which rely
upon the application to follow them, which means writing separate
cases for each platform.Using a toolkit which behaves identically on all platforms is simpler
for the developers (and we aren't exactly overstaffed). It also means
that the application behaves in a consistent manner on all platforms,
which is useful if you use multiple platforms, or if you are writing
documentation.--
Glynn Clements <glynn@gclements.plus.com>
David Finlayson wrote:
I am sure your work is great and greatly appreciated! For what it is
worth, I use Gnome on Linux, so I agree with you about GTK looking
good---it does to me anyway.I was mainly concerned about Apple users. The last I heard, GTK was
not easy to install on Apple OSX and many apple users have a natural
revulsion to non-native apps (I don't own an apple so I don't
understand myself). Windows has never had a standard GUI so it is less
of an issue with Windows users.
Windows has had lots of "standard" GUIs in its time, although
adherence to UI guidelines tends to be rather more lax than on the Mac
(in particular, Microsoft doesn't seem particularly interested in
following the guidelines which they suggest for other developers).
I would expect the non-native appearance to be more of an issue on the
Mac, partly because UI guidelines tend to be more strongly adhered to
there, but mainly because Unix GUI toolkits tend to be more heavily
influenced by the Windows GUI than by the Mac GUI, so the difference
is less noticable on Windows.
--
Glynn Clements <glynn@gclements.plus.com>
Michael Barton wrote:
Perhaps a more important question. The GTK apps I know of (GIMP for example)
need x11 to run on my Mac. Can GTK apps run without x11? In Aqua on Macs? In
(whatever it is) on Windows?
There is a native MacOSX port of GTK under development:
http://developer.imendio.com/wiki/Gtk_Mac_OS_X
However, it doesn't appear to be as mature at the Windows port yet:
http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do
Of the items on that list, most seem to be related to applications
which do their own low-level event handling and drawing, rather than
more typical UIs built from standard widgets. Some of them could be
relevant to the display canvas, though.
The most serious issues seem to be:
Menus/pop up windows
* These are currently buggy and need fixing. (medium)
Miscellaneous
* Currently GTK+ runs only on Tiger. This should perhaps be fixed. (medium) #322372
* Bugs, bugs, bugs 
Just pick one and fix it!
So far as Windows is concerned, I use GIMP, Pan and X-Chat on Windows
using the native GTK port. They have a few rough edges, but those are
all quite minor. The UI appearance is no less "native" than e.g.
Delphi applications.
Given the number of Windows users who seem willing to tolerate stuff
like WinAmp, I don't see any reason to worry about the differences
between GTK and the standard Windows/MFC controls.
Admittedly WinAmp-style UIs don't seem to have caught on for "serious"
applications, although I've seen plenty of "Easy Photo Album" programs
(usually bundled with scanners, digital cameras etc) which seem to go
out of their way to avoid looking like normal Windows applications
(e.g. most of the icons look like they belong on a toy aimed at the
pre-school age group).
--
Glynn Clements <glynn@gclements.plus.com>
In contrast to GTK, wxPython appears to be mature for all
platforms---at least there are no major warnings on the download page
(other than a note about Universal binaries)
The screenshots page shows examples from all of the major platforms:
http://www.wxpython.org/screenshots.php
I think that the demo that comes with wxPython would be an excellent
test of the look and feel across platforms. Can someone try it out on
OSX? I know that the demo program works well on Linux (Ubuntu/Gnome =
GTK) and Windows. I haven't tried it on a QT system. It is impressive
how little code is required to build the demo programs.
Personally, I like the idea that it will blend in with the rest of my
desktop. I think you get all the integration for free. The toolkit
abstracts out the differences between platforms. There would be no KDE
vs Gnome choice that needs to be made since wxWidgets handles will
work with QT or GTK depending on the installed packages.
I don't really know. I've only programmed toy applications with it.
On 6/7/06, Glynn Clements <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
> Perhaps a more important question. The GTK apps I know of (GIMP for example)
> need x11 to run on my Mac. Can GTK apps run without x11? In Aqua on Macs? In
> (whatever it is) on Windows?There is a native MacOSX port of GTK under development:
http://developer.imendio.com/wiki/Gtk_Mac_OS_X
However, it doesn't appear to be as mature at the Windows port yet:
http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do
Of the items on that list, most seem to be related to applications
which do their own low-level event handling and drawing, rather than
more typical UIs built from standard widgets. Some of them could be
relevant to the display canvas, though.The most serious issues seem to be:
Menus/pop up windows
* These are currently buggy and need fixing. (medium)
Miscellaneous
* Currently GTK+ runs only on Tiger. This should perhaps be fixed. (medium) #322372
* Bugs, bugs, bugs
So far as Windows is concerned, I use GIMP, Pan and X-Chat on Windows
using the native GTK port. They have a few rough edges, but those are
all quite minor. The UI appearance is no less "native" than e.g.
Delphi applications.Given the number of Windows users who seem willing to tolerate stuff
like WinAmp, I don't see any reason to worry about the differences
between GTK and the standard Windows/MFC controls.Admittedly WinAmp-style UIs don't seem to have caught on for "serious"
applications, although I've seen plenty of "Easy Photo Album" programs
(usually bundled with scanners, digital cameras etc) which seem to go
out of their way to avoid looking like normal Windows applications
(e.g. most of the icons look like they belong on a toy aimed at the
pre-school age group).--
Glynn Clements <glynn@gclements.plus.com>
--
David Finlayson
Ideally, we should be able to write one piece of GUI code that will run on
all platforms, without x11 on Windows and preferably running under aqua on a
Mac.
Does anyone looking into either wxPython or pyGTK know if this can be done
with either of these platforms?
The whole idea of not requiring x11 for GRASS is kind of lost if it is
required for the GUI. By the same token, it would be difficult to maintain 3
different versions of the GUI (unless the differences were very minimal).
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: Thu, 8 Jun 2006 00:39:34 +0100
To: David Finlayson <david.p.finlayson@gmail.com>
Cc: Jachym Cepicky <jachym.cepicky@centrum.cz>, GRASS developers list
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Python GUI toolkitsDavid Finlayson wrote:
I am sure your work is great and greatly appreciated! For what it is
worth, I use Gnome on Linux, so I agree with you about GTK looking
good---it does to me anyway.I was mainly concerned about Apple users. The last I heard, GTK was
not easy to install on Apple OSX and many apple users have a natural
revulsion to non-native apps (I don't own an apple so I don't
understand myself). Windows has never had a standard GUI so it is less
of an issue with Windows users.Windows has had lots of "standard" GUIs in its time, although
adherence to UI guidelines tends to be rather more lax than on the Mac
(in particular, Microsoft doesn't seem particularly interested in
following the guidelines which they suggest for other developers).I would expect the non-native appearance to be more of an issue on the
Mac, partly because UI guidelines tend to be more strongly adhered to
there, but mainly because Unix GUI toolkits tend to be more heavily
influenced by the Windows GUI than by the Mac GUI, so the difference
is less noticable on Windows.--
Glynn Clements <glynn@gclements.plus.com>
I just downloaded and installed wxPython, Activestate's Python for Mac,and
the wxPython sample/demo/docs package.
I ran the demo and it looks great. I think that people would be thrilled to
have this look for GRASS on a Mac.
The demo code *looks* very short and easy--but I don't know what is involved
to put it all together.
A very important aspect that I don't know is if creating GUI code on my Mac
in wxPython would run the same on Linux and Windows.
Also, how easy would it be to port a piece of pyGTK code to wxPython? I
realize that they are running different underlying platforms (though I
noticed that the wxPython docs say you need GTK for the Linux version). But
since they are both Python, doesn't that make the syntax somewhat similar???
Can anyone advise?
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: David Finlayson <david.p.finlayson@gmail.com>
Date: Wed, 7 Jun 2006 21:36:04 -0700
To: Glynn Clements <glynn@gclements.plus.com>
Cc: Michael Barton <michael.barton@asu.edu>, GRASS developers list
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Python GUI toolkitsIn contrast to GTK, wxPython appears to be mature for all
platforms---at least there are no major warnings on the download page
(other than a note about Universal binaries)The screenshots page shows examples from all of the major platforms:
http://www.wxpython.org/screenshots.php
I think that the demo that comes with wxPython would be an excellent
test of the look and feel across platforms. Can someone try it out on
OSX? I know that the demo program works well on Linux (Ubuntu/Gnome =
GTK) and Windows. I haven't tried it on a QT system. It is impressive
how little code is required to build the demo programs.Personally, I like the idea that it will blend in with the rest of my
desktop. I think you get all the integration for free. The toolkit
abstracts out the differences between platforms. There would be no KDE
vs Gnome choice that needs to be made since wxWidgets handles will
work with QT or GTK depending on the installed packages.I don't really know. I've only programmed toy applications with it.
On 6/7/06, Glynn Clements <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
Perhaps a more important question. The GTK apps I know of (GIMP for example)
need x11 to run on my Mac. Can GTK apps run without x11? In Aqua on Macs? In
(whatever it is) on Windows?There is a native MacOSX port of GTK under development:
http://developer.imendio.com/wiki/Gtk_Mac_OS_X
However, it doesn't appear to be as mature at the Windows port yet:
http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do
Of the items on that list, most seem to be related to applications
which do their own low-level event handling and drawing, rather than
more typical UIs built from standard widgets. Some of them could be
relevant to the display canvas, though.The most serious issues seem to be:
Menus/pop up windows
* These are currently buggy and need fixing. (medium)
Miscellaneous
* Currently GTK+ runs only on Tiger. This should perhaps be fixed.
(medium) #322372* Bugs, bugs, bugs
Just pick one and fix it!
So far as Windows is concerned, I use GIMP, Pan and X-Chat on Windows
using the native GTK port. They have a few rough edges, but those are
all quite minor. The UI appearance is no less "native" than e.g.
Delphi applications.Given the number of Windows users who seem willing to tolerate stuff
like WinAmp, I don't see any reason to worry about the differences
between GTK and the standard Windows/MFC controls.Admittedly WinAmp-style UIs don't seem to have caught on for "serious"
applications, although I've seen plenty of "Easy Photo Album" programs
(usually bundled with scanners, digital cameras etc) which seem to go
out of their way to avoid looking like normal Windows applications
(e.g. most of the icons look like they belong on a toy aimed at the
pre-school age group).--
Glynn Clements <glynn@gclements.plus.com>--
David Finlayson
According to the pyGTK FAQ there is no native MacOS X support, it
requires an X server of some kind (X11 or Apple's version):
http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq01.019.htp
This toolkit seems like a dead end if the goal is to liberate GRASS
from an X server (though it does look nice)
On 6/8/06, Michael Barton <michael.barton@asu.edu> wrote:
I just downloaded and installed wxPython, Activestate's Python for Mac,and
the wxPython sample/demo/docs package.I ran the demo and it looks great. I think that people would be thrilled to
have this look for GRASS on a Mac.The demo code *looks* very short and easy--but I don't know what is involved
to put it all together.A very important aspect that I don't know is if creating GUI code on my Mac
in wxPython would run the same on Linux and Windows.Also, how easy would it be to port a piece of pyGTK code to wxPython? I
realize that they are running different underlying platforms (though I
noticed that the wxPython docs say you need GTK for the Linux version). But
since they are both Python, doesn't that make the syntax somewhat similar???Can anyone advise?
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State Universityphone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton> From: David Finlayson <david.p.finlayson@gmail.com>
> Date: Wed, 7 Jun 2006 21:36:04 -0700
> To: Glynn Clements <glynn@gclements.plus.com>
> Cc: Michael Barton <michael.barton@asu.edu>, GRASS developers list
> <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] Python GUI toolkits
>
> In contrast to GTK, wxPython appears to be mature for all
> platforms---at least there are no major warnings on the download page
> (other than a note about Universal binaries)
>
> The screenshots page shows examples from all of the major platforms:
>
> http://www.wxpython.org/screenshots.php
>
> I think that the demo that comes with wxPython would be an excellent
> test of the look and feel across platforms. Can someone try it out on
> OSX? I know that the demo program works well on Linux (Ubuntu/Gnome =
> GTK) and Windows. I haven't tried it on a QT system. It is impressive
> how little code is required to build the demo programs.
>
> Personally, I like the idea that it will blend in with the rest of my
> desktop. I think you get all the integration for free. The toolkit
> abstracts out the differences between platforms. There would be no KDE
> vs Gnome choice that needs to be made since wxWidgets handles will
> work with QT or GTK depending on the installed packages.
>
> I don't really know. I've only programmed toy applications with it.
>
> On 6/7/06, Glynn Clements <glynn@gclements.plus.com> wrote:
>>
>> Michael Barton wrote:
>>
>>> Perhaps a more important question. The GTK apps I know of (GIMP for example)
>>> need x11 to run on my Mac. Can GTK apps run without x11? In Aqua on Macs? In
>>> (whatever it is) on Windows?
>>
>> There is a native MacOSX port of GTK under development:
>>
>> http://developer.imendio.com/wiki/Gtk_Mac_OS_X
>>
>> However, it doesn't appear to be as mature at the Windows port yet:
>>
>> http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do
>>
>> Of the items on that list, most seem to be related to applications
>> which do their own low-level event handling and drawing, rather than
>> more typical UIs built from standard widgets. Some of them could be
>> relevant to the display canvas, though.
>>
>> The most serious issues seem to be:
>>
>> Menus/pop up windows
>>
>> * These are currently buggy and need fixing. (medium)
>>
>> Miscellaneous
>>
>> * Currently GTK+ runs only on Tiger. This should perhaps be fixed.
>> (medium) #322372
>>
>> * Bugs, bugs, bugs
>>
>> So far as Windows is concerned, I use GIMP, Pan and X-Chat on Windows
>> using the native GTK port. They have a few rough edges, but those are
>> all quite minor. The UI appearance is no less "native" than e.g.
>> Delphi applications.
>>
>> Given the number of Windows users who seem willing to tolerate stuff
>> like WinAmp, I don't see any reason to worry about the differences
>> between GTK and the standard Windows/MFC controls.
>>
>> Admittedly WinAmp-style UIs don't seem to have caught on for "serious"
>> applications, although I've seen plenty of "Easy Photo Album" programs
>> (usually bundled with scanners, digital cameras etc) which seem to go
>> out of their way to avoid looking like normal Windows applications
>> (e.g. most of the icons look like they belong on a toy aimed at the
>> pre-school age group).
>>
>> --
>> Glynn Clements <glynn@gclements.plus.com>
>>
>
> --
> David Finlayson
--
David Finlayson
On Thu, 8 Jun 2006, Michael Barton wrote:
Also, how easy would it be to port a piece of pyGTK code to wxPython? I
realize that they are running different underlying platforms (though I
noticed that the wxPython docs say you need GTK for the Linux version). But
since they are both Python, doesn't that make the syntax somewhat similar???Can anyone advise?
If we choose pyGTK it means we can develop the UI with PyGlade, and it generates pyGTK code + xml files for libglade to parse. And that is AFAIK the thing that makes developing with pyGTK so quick. And that is IMO why this combination is the strongest candidate.
As for porting pyGTK to wxPython, well don't even think about it (; It is IMO better to code for wxPython directly.
Read here more about this:
http://www.linuxjournal.com/article/7421 + resources: http://www.linuxjournal.com/article/7558
http://www.linuxjournal.com/article/6586
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
On Thu, 8 Jun 2006, David Finlayson wrote:
According to the pyGTK FAQ there is no native MacOS X support, it
requires an X server of some kind (X11 or Apple's version):http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq01.019.htp
This toolkit seems like a dead end if the goal is to liberate GRASS
from an X server (though it does look nice)
Indeed, but as people here have said they are working on a native GTK, and
as soon as there is a native GTK I suspect that there will be a pyGTK that
can use the native GTK.
--W
--
<:3 )---- Wolf Bergenheim ----( 8:>
On Thu, 8 Jun 2006, Wolf Bergenheim wrote:
On Thu, 8 Jun 2006, Michael Barton wrote:
Also, how easy would it be to port a piece of pyGTK code to wxPython? I
realize that they are running different underlying platforms (though I
noticed that the wxPython docs say you need GTK for the Linux version).
But
since they are both Python, doesn't that make the syntax somewhat
similar???Can anyone advise?
If we choose pyGTK it means we can develop the UI with PyGlade, and it generates pyGTK code + xml files for libglade to parse. And that is AFAIK the thing that makes developing with pyGTK so quick. And that is IMO why this combination is the strongest candidate.
As for porting pyGTK to wxPython, well don't even think about it (; It is IMO better to code for wxPython directly.
Read here more about this:
http://www.linuxjournal.com/article/7421 + resources: http://www.linuxjournal.com/article/7558
http://www.linuxjournal.com/article/6586
Looking for a RAD for wxWidgets + Python I found wxGlade:
http://wxglade.sourceforge.net/
That makes me lean toward wxWidgets again, but on the other hand I like the idea of using GTK (or QT) since then we could have a constant GRASS look, instead of having a native look. But making it easier to install GRASS is more important IMHO.
--W
--
<:3 )---- Wolf Bergenheim ----( 8:>
On Thu, Jun 08, 2006 at 12:19:44AM -0700, Michael Barton wrote:
Also, how easy would it be to port a piece of pyGTK code to wxPython? I
realize that they are running different underlying platforms (though I
noticed that the wxPython docs say you need GTK for the Linux version). But
since they are both Python, doesn't that make the syntax somewhat similar???Can anyone advise?
Michael
Syntax maybe. I was looking after some gui builder tool. The nicest
could be wxGlade, however I was not able to re-build something similar
to current version of v.pydigit. I'm affraid, the gui code will have to
be maintained by hand 
At least code of the monitors, since wxglade
seems not to be able to add drawing area object to the gui.
Jachym
--
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
IMO we should pick a GUI language based on its long term merits, not
because we have a nice editor for one. Fast development is nice, but
lack of bug reports is much nicer. (especially if they are upstream
bugs)
Having the resulting GUI look somewhat native is indeed very important
on the Mac. Looking native but acting like GRASS on all platforms isn't
too bad I think. Rewritting to conditionally "become" a Mac app on Mac
and no where else is surely a bad idea. Linux people will be used to a
world of heterogenous interfaces and Windows people will be used to a
world of pain ... but on Mac ... if I understand correctly
Python seems to be a common theme, that's nice to see.
Can anyone test v.pydigit on Mac + native GTK? Win+WinGTK?
Would pyGTK it need to have libglade on all platforms?
Or just for development?
David:
I was toying with the idea of creating a Matlab or R-style GUI for
grass. The idea would be to have a command line interface with helper
applications such as graphics monitors, text editor, file browser,
help-system, etc. All accessible from tool bars. People seem to really
like Matlab once they learn it and I thought that if a grass version
were done right, even guys like me might use it (which means that I
better write code that I want to use!).
FWIW, I really like the Matlab language & engine but I hate the 6+ GUI
command interface. I run it -nojvm from my normal rxvt terminal window
with nedit in Matlab mode for the editor. For me, I need to focus when
working with it and a cluttered command window really hurts that.
It doesn't help that the Java interface is slow, buggy, and the fonts
horrible. I don't know R so well, so there the GUI version is a nice
crutch -- I can see the advantage to the concept.
Hamish
On 6/8/06, Hamish <hamish_nospam@yahoo.com> wrote:
IMO we should pick a GUI language based on its long term merits, not
because we have a nice editor for one. Fast development is nice, but
lack of bug reports is much nicer. (especially if they are upstream
bugs)
Indeed. WIth the exception of Visual Basic, I've always built GUI code
by hand. In the end it makes for cleaner code. Here (wxpython or
pygtk) widgets and event handlers are rarely more than a few lines of
code each anyway.
Mark Lutz's book on Programming Python (a classic now) has some nice
examples of programming GUI code in Tcl/tk. He shows how to use mixen
classes to wrap up the tedious parts of the GUI construction. There
are two advantages:
1. Common objects are easy to instantiate with sensible defaults
2. More importantly, you isolate the program from the underlying GUI
implementation so that the GUI toolkit can be changed in the future by
modifying the mixen class methods in one place (for example, when GTK
becomes native on OS X) without modifying the main program calls.
Python is about 80% lisp now. Which means you can write meta programs
that write programs. Its a powerful concept once you start working
with it.
Hammish:
FWIW, I really like the Matlab language & engine but I hate the 6+ GUI
command interface. I run it -nojvm from my normal rxvt terminal window
with nedit in Matlab mode for the editor. For me, I need to focus when
working with it and a cluttered command window really hurts that.
It doesn't help that the Java interface is slow, buggy, and the fonts
horrible. I don't know R so well, so there the GUI version is a nice
crutch -- I can see the advantage to the concept.
In my opinion, one of the problems with a GUI is that you have to
learn GRASS twice to use it in scripts. Once, you learn the buttons
for getting things done. Twice, you learn the commands to do the same
thing. That makes scripting a high barrier to cross and a lot of
people never learn how to automate there work. In CLI, you only learn
the program once, you use the same command for interactive and
scripting use. Just like the big math programming languages. This must
work because all of the big math programs use this approach (Matlab,
Maple, Mathematica, R, S-plus, etc.) and many of these are popular
with their users.
BUT, the main problem with the CLI is discoverability. You can't use
it if you don't know the commands and weak CLI do not assist in the
tedious usage parts. And there are some things that are just easier
when interactive, like laying out a figure. So, a nice IDE can really
make using the program easier by providing helper tools that make the
CLI friendlier and more discoverable.
My idea is to combine the best of both worlds. Focus on the CLI so
that the user only learns the tool one way. But make it discoverable.
For example, the GUI-IDE thing could have a tree view of all the
available programs organized by task. An executable index to all grass
programs. A browser for locations/mapsets, etc. Use the same tool to
drag-and-drop a simple script in the built-in editor.
This is a different paradigm than a full-on GUI like is found on Qgis.
We can implement different GUIs for GRASS 7 and see which one becomes
popular enough to support in the main distribution.
Michael Barton wrote:
Ideally, we should be able to write one piece of GUI code that will run on
all platforms, without x11 on Windows and preferably running under aqua on a
Mac.Does anyone looking into either wxPython or pyGTK know if this can be done
with either of these platforms?The whole idea of not requiring x11 for GRASS is kind of lost if it is
required for the GUI. By the same token, it would be difficult to maintain 3
different versions of the GUI (unless the differences were very minimal).
wxPython uses wxWidgets, which uses the platform's native widgets.
This provides a more native look-and-feel, but is harder to code for,
as there tend to be subtle differences between the behaviour of
similar widgets on different platforms.
wxGTK uses GTK; whether or not that requires an X server depends upon
whether you use the platform's native GTK port or the X11 version.
On Unix systems (other than MacOSX), the X11 version /is/ the native
version.
On Windows, there is a mature native version, while Cygwin offers an
X11-based GTK package. You would only use the Cygwin version if you
require an especially high degree of compatibility, e.g. because the
application directly uses X11 functions in addition to GTK functions.
On MacOSX, the native port appears to be at an alpha stage (based upon
the "todo" list on the web site). Also, running Unix/X11 applications
isn't as problematic on OSX as it is on Windows, as you don't need a
Cygwin-style compatibility layer.
--
Glynn Clements <glynn@gclements.plus.com>
David Finlayson wrote:
In my opinion, one of the problems with a GUI is that you have to
learn GRASS twice to use it in scripts. Once, you learn the buttons
for getting things done. Twice, you learn the commands to do the same
thing. That makes scripting a high barrier to cross and a lot of
people never learn how to automate there work. In CLI, you only learn
the program once, you use the same command for interactive and
scripting use. Just like the big math programming languages. This must
work because all of the big math programs use this approach (Matlab,
Maple, Mathematica, R, S-plus, etc.) and many of these are popular
with their users.BUT, the main problem with the CLI is discoverability. You can't use
it if you don't know the commands and weak CLI do not assist in the
tedious usage parts. And there are some things that are just easier
when interactive, like laying out a figure. So, a nice IDE can really
make using the program easier by providing helper tools that make the
CLI friendlier and more discoverable.
For GRASS, the main problem with a command line is that specifying
points by typing in coordinates is a lot less convenient than using a
mouse.
Modules such as v.digit and i.points /need/ a GUI.
Beyond that, the visualisation aspects of gis.m should ultimately be
able to be controlled from the command line. I.e. being able to type a
command to add, move, modify, hide (etc) layers, rather than having to
use buttons or menus.
Even from a command-line perspective, the existing display
architecture is deficient in that you can't modify the layer stack
other than adding a new layer on the top or clearing the stack
altogether.
--
Glynn Clements <glynn@gclements.plus.com>
I'm willing to test, but what does it take to test this? I'm running GIMP
under x11, so I must have some version of GTK+ installed. Can I just get it
and run it or do I have to do anything?
.....
With respect to GUI design and platforms, I suggest we take things one step
at a time since we don't have a large development/design team, but do have
quite a bit of interest.
Out of the next generation GUI discussion of last Fall and early this year,
the basic plan was to...
1) Come up with a set of interface design specs.
2) Implement the new design specs as well as possible in the current TclTk
platform.
3) Identify and migrate to a new GUI platform if needed.
4) This step was not discussed, but reasonably, it would be to review and
revise if necessary the overall GUI design specs in the context of the new
GUI platform.
We're almost through step 2.
I recommend that we try to implement the design specs we are just now
completing in TclTk in a new platform, rather than trying to migrate to a
new platform AND comprehensively change the interface design again (after
just barely getting it out the door over the last 4-5 months). The latter
seems overly ambitious and likely to devolve into UI chaos, with multiple
competing designs.
Currently, we have a team of people all working together on the same design
plan and same GUI platform. The result is how much it has progressed in such
a short time. I'd hate to lose that kind of synergy.
Granted, a reason for switching from TclTk to another GUI platform is that
it gives us richer options for a GUI (we already have very rich CLI
options). But it seems better to begin to explore those by improving on the
design specs we now have, rather than starting from scratch. And to be
honest, if the idea of learning Python (I've already started, given that it
is summer and I can work it in around writing and analysis) seems a little
daunting, the idea of learning Python, building a GUI, AND redesigning the
GUI from the ground up seems exhausting.
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: Hamish <hamish_nospam@yahoo.com>
Date: Fri, 9 Jun 2006 00:47:45 +1200
To: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Python GUI toolkitsIMO we should pick a GUI language based on its long term merits, not
because we have a nice editor for one. Fast development is nice, but
lack of bug reports is much nicer. (especially if they are upstream
bugs)Having the resulting GUI look somewhat native is indeed very important
on the Mac. Looking native but acting like GRASS on all platforms isn't
too bad I think. Rewritting to conditionally "become" a Mac app on Mac
and no where else is surely a bad idea. Linux people will be used to a
world of heterogenous interfaces and Windows people will be used to a
world of pain ... but on Mac ... if I understand correctlyPython seems to be a common theme, that's nice to see.
Can anyone test v.pydigit on Mac + native GTK? Win+WinGTK?
Would pyGTK it need to have libglade on all platforms?
Or just for development?David:
I was toying with the idea of creating a Matlab or R-style GUI for
grass. The idea would be to have a command line interface with helper
applications such as graphics monitors, text editor, file browser,
help-system, etc. All accessible from tool bars. People seem to really
like Matlab once they learn it and I thought that if a grass version
were done right, even guys like me might use it (which means that I
better write code that I want to use!).FWIW, I really like the Matlab language & engine but I hate the 6+ GUI
command interface. I run it -nojvm from my normal rxvt terminal window
with nedit in Matlab mode for the editor. For me, I need to focus when
working with it and a cluttered command window really hurts that.
It doesn't help that the Java interface is slow, buggy, and the fonts
horrible. I don't know R so well, so there the GUI version is a nice
crutch -- I can see the advantage to the concept.Hamish