[Pythoncard-users] why is the framework changing?

0.5.3 is the last prototype release that will make any pretense of hiding
wxPython. The changes that Rowland and I started checking into cvs today are
going to expose wxPython directly. The main focus of these changes is to
leverage the power of wxPython and provide helper classes and wrappers where
needed to simplify some of the more difficult aspects of wxPython. I'll go
into the details of these changes in another message. First I want to
clarify the "why". This is a big deal for the future of PythonCard.

First of all, I see only two usable solutions for a cross-platform GUI
toolkit for Python. Tkinter is the obvious choice because it ships with
Python and works on just about every platform that Python runs on. For
various reasons outlined in past messages to the list I don't like or want
to use tkinter. The other solution is wxPython and that is where I'm putting
my effort.

Last month I spent time trying to create interest in a wxPython-specific
application framework. While the idea didn't get much attention on the
wxPython-users list, at least from people willing to do development work, it
did help my thinking about PythonCard. I still wanted PythonCard features
such as resource files, default attribute initialization, automatic event
binding, and dot notation attributes. I also wanted to use more of the
wxPython classes without having to wrap them with PythonCard-specific
classes and method names. If possible, I also wanted to be able to rely on
the wxPython documentation for most of the classes rather than having to
create a completely separate documentation set. The 'state of the framework
messages' and 'future direction of PythonCard' threads on the list also
helped focus my thinking. You might want to go and read through some of the
archives.

In the end, it didn't seem like there was anything particularly bad or
difficult about the wxPython events or classes. The problem is the code
overhead and learning curve you have to climb in order to use them even for
a simple app. Another big issue, is that the documentation is presented from
the standpoint of C++ instead of Python. Robin has said that the
documentation issue will be addressed sometime after 2.3.2 is released. That
probably fits into the same Real Soon Now universe that the Mac wxPython
port exists in, but I'm confident it will get done; wxPython Mac is
compiling now, it just isn't running correctly.

So, while exposing wxPython is a major change in the framework and requires
some reworking of the existing samples, I don't think it strays from the
real purpose of PythonCard (to me at least), which is to create a powerful,
but simple to use, cross-platform GUI software construction kit for Python.

This is an open source project, if you feel this move is bad and disagree
with the direction we're taking, then you need to speak up. You can always
use release 0.5.3 or any earlier releases for projects that you want to hide
wxPython or to use as the basis for a framework that might work on top of
another GUI toolkit such as tkinter. I won't be spending any effort in that
direction. The PythonCardPrototype 0.5.3 zip is in the files section and all
of the files are tagged as proto-0_5_3 in cvs, so anyone can go back to
0.5.3 if they need to.

ka