[Baypiggies] PyGTK

[Kelly Yancey]

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,
> -jj

   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. :)

   Kelly