kelly at nttmcl.com
Thu Apr 27 04:08:38 CEST 2006
On Tue, 25 Apr 2006, Shannon -jj Behrens wrote:
> On 4/25/06, Redefined Horizons <redefined.horizons at gmail.com> wrote:
>> It seems like wxPython is the most popular widget platform for Python. I
>> think most of the Python IDEs I've checked out offer wxPython GUI Builders.
>> Is anyone on this list using PyGTK instead? I use GTK in some of my other
>> programming, and would like to stick with it when using Python. I'm also
>> curious as to why it doesn't see as widespread use in Python as wxWidgets.
> wxPython probably does a better job at being cross platform than
> PyGTK. I have used PyGTK in the past, mainly because I wanted a
> native-looking GNOME application. I gave a talk on it in December.
> See <http://gcipher.sourceforge.net/>. If you want a trivial example
> project to get you started, just ask, and I'll send you one that I
> wrote. By the way, if you're going to use wxPython, I've heard that
> PythonCard takes a lot of the pain out of using wxPython.
> Best Regards,
Hi, JJ :)
Let me preface this with a disclaimer that I only played with PythonCard
for a short time while evaluating libraries for use developing a
shrink-wrapped python-based application for Windows. I'm sure a long-term
PythonCard user (are there any?) can point out how PythonCard can take "a
lot" of pain out of wxPython, but I just couldn't find it.
I found PythonCard to be little more than a framework re-inventing
wxWidgets' XRC resource files, an editor for their re-invented XRC file
format, a couple of extra widgets, plus some debugging aids like pyCrust
thrown in. From the PythonCard docs themselves:
The primary ways that PythonCard simplifies the GUI development
process are that it standardises event and attribute names,
automatically binds event handlers (where present) to your
components and separates program logic from application
presentation. Each of these may seem like a restriction but
allows the developer to focus on the important parts of their
applications - the layout of the graphical interface and the
application logic - without having to master a complex windowing
toolkit. The separation of the presentation (in a resource file)
and the application logic (in a Python module) in particular
provide a much simpler application structure for the developer.
And simplicity is what PythonCard is all about.
Having the presentation aspects of the application in their own
file enables the use of tools like the resourceEditor. The new
user of PythonCard doesn't need to know anything about the format
of the resource file, they can use a graphical tool to layout
their application and it will generate the resource file for them.
Of course this doesn't mean that you have to use the
resourceEditor, the resource file is a text file containing a
Python dictionary and can just as well be written in the text
editor of your choice.
Yeah, that's what wxWidget's XRC files already get you (although XRC
is XML rather than PythonCard's text representations of python
dictionaries). PythonCard includes a graphical resource file editor, but
it wasn't appreciably better than any of the multitude of XRC editors out
there. I wouldn't say any of the XRC editors are at the ease-of-use level
most beginners would expect, but I've been pretty happy with an
inexpensive commercial product called DialogBlocks.
So, for a beginner, the difference between wxPython (using XRC resource
files) and PythonCard isn't particularly notable. I only wanted to point
that out because I keep seeing the claim the PythonCard is "a lot" easier
than wxPython. And when you compare apples to oranges, i.e.
resource-based GUI layouts to hard-coded wxPython API calls, it is easier.
But if you compare apples to apples, PythonCard and wxPython's XRC
support, the differences are minor.
Anyway, that was experience; take it at a value no more than what you
paid to hear it. :)
More information about the Baypiggies