Re. PythonCard - was Re: Event-driven GUIs ...

[Chris Barker]

Kevin Altis wrote:
> what is missing is the tight coupling of a GUI environment.

I'm not sure if I mean the same thing as Kevin, but this is a big
problem. ALL the GUI options for Python (tkinter, wxPython, PyQT, PyGTK,
etc.) are wrappers around a GUI toolkit made for some other laguage, for
some other purpose. This is a major limitation. What Python needs is a
Native GUI toolkit. Guido talked about it in the past, saying that the
interface would likely be something like tkinter, but nothing is
happening on that front.

What I imagine is this:

A GUI library that is built for Python, that interacts well with the
Python library and all the native type. This library would, for
instance, expect to get a Python list whne is needed a list of items. It
would be written in C++ (or maybe C). It would be platform independent.
The strength in this approach is that the core library could just as
easily be extended in either Python or C/C++. This way, the community
could develop nice higher-level widgets and really expand the toolbox.
It could be used from either C/C++ or Python. This way, one could
develop a C/C++ app with an embedded python interpreter, and GUI code
could be run from either language, the transition would be easy.

Many of these features now exist in wxPython. That is why I am using it.
However, wxPython is a thin wrapper around a C++ class library. This is
a good thing because it allows common documentation and the wrappers can
be produced with SWIG. It is a bad thing because you end up writing
Python code that is not natural (pythonic), and a whole lot more verbose
and complex than it needs to be. It also suffers some from performance
issues do to translating from Python lists to wxLists, generating
wrappers around C++ objects, etc. I don't understand the details, but
the issues are there. wxWindows and Python also share a lot of duplicate
functionality: sockets, database access, process control, file system
manipulations, etc. etc. 

This doesn't mean that we would have to start from scratch, I'm sure a
lot of the underlying code from wxWindows, or Fox, or FLTK, or GTK, or
whatever could be used, but it would be a substantial effort.

If such a toolkit existed, PythonCard would be a whole lot easier to
write, as would many other tools.

Unfortunatly, Python is suffering, in this respect, from an Free
Software problem: people build what they need, and putting a wrapper
around an existing toolkit gets them something that works, with a whole
lot less effort than writing something new. So we now have ten wrappers,
and no native toolkit. :-(

Well, I've proposed, and I've whined, and I have neither the time nor
the skills to do it, so I'm done for the moment.

-Chris



-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------