[Pythoncard-users] wxPython issues

[Kevin A. <al...@se...>]

Unless someone posts a compelling reason to use a different toolkit
underneath PythonCard, wxPython is what we'll commit to for the future of
PythonCard.

The question then becomes how thin of a layer should we have over wxPython?
What is the framework doing that wxPython doesn't do? What are the pros and
cons of exposing more of wxPython? Since I'm naturally a critical guy, most
of the stuff below is probably going to emphasize the negative aspects of
wxPython, but I like wxPython, I'm just not very good in the praise
department :)

Critical mass
One obvious problem that the PythonCard project has is critical mass. In
order to be successful it really needs more developers and more users to
make it into the best framework/environment for building cross-platform GUI
apps in Python.

mailing list         people on list
------------------------------------
pythoncard-users     ~45
wxpython-users       ~600
wx-users             ~670

As one would expect, the newer project (PythonCard) has a fraction of the
users of wxPython on the mailing list. This doesn't reflect the total number
of users, but it does give an idea of the number of active participants
interested in a project that can provide answers and opinions. The number of
downloads of the latest release of PythonCard 0.4.5 is ~340 while there have
been over 20,000 downloads of wxPython 2.3.1 in various forms.

This is probably the single most important reason I see for minimizing the
differences between PythonCard and wxPython and making most if not all of
wxPython available in PythonCard apps. PythonCard will end up being the
simple to use application framework that wxPython doesn't have and hopefully
the environment will be equally simple to use, yet still powerful enough to
get most jobs done. If PythonCard doesn't stray too far from wxPython it
will also be appropriate to bundle it as part of wxPython in the future.

The best chance we have of increasing the number of users and developers is
to make PythonCard very close to wxPython and leverage the installed base of
users, developer expertise, etc. A helper class for PythonCard can be
beneficial to other wxPython projects.

PythonCard problems are often wxPython problems which are often wxWindows
problems
Since PythonCard sits on top of wxPython, it is not surprising that in many
ways it is limited by the capabilities of wxPython. If you've spent much
time on the wxPython-users list you will also know that wxPython problems
and issues are often wxWindows issues and some investigation on the wx-users
list or worst-case going into the wxWindows C++ sources is required to find
a problem. The good news is that it is open source so you can look at the
sources.

Documentation
The good is that there is some. The bad is that the wxPython docs are really
wxWindows (C++) docs with wxPython notes stuck in here and there. The docs
can also be misleading because wxPython only implements a portion of the
wxWindows framework. The docs are almost always out of sync with the
sources. I have found out the hard way that when you have a question, one of
the first things you should do is grep the sources and demo for the class or
function you are interested in. The next thing you should do is search the
ASPN wxPython-users archives
http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/wxPython-users

Robin knows documentation is one of the warts of wxPython and has stated
that he will be providing better documentation. Unlike, tkinter, there is
very little book material on wxPython.

wxPython does have a small online wiki (currently down)
http://wxpython.org/cgi-bin/wiki
for FAQs and cookbook entries and the wxPython Pit
http://wxpython-pit.sourceforge.net/
which is the best place to find other projects using wxPython that may also
have solutions to the problem you're trying to solve.

wxPython has a lot of functionality, the trick is learning how to harness
that power. I feel that of all the GUI toolkits for Python, you have to
compromise the least with wxPython. You also get native widgets on each OS
platform and that is important to me.

Boa and wxDesigner
There are two IDEs that are wxPython-aware that you can use to build
wxPython apps. I haven't used either that much, so those of you that have
should chime in here with the pluses and minuses of each.

A good question with regards to the environment that PythonCard needs is why
not just use Boa? What aspects/features of Boa, if any, makes it unsuitable?
Could we just add-on or modify Boa to make it acceptable? I'm not a fan of
code generators myself and the resource files are a fundamental requirement
for PythonCard for me, so I need to be able to build/code with resources and
that will require some Boa modifications, AFAIK. Note that if you haven't
already looked at Boa, you need to get the version out of cvs, do not use
the 0.0.5 release in the files area. Boa is at:
http://sourceforge.net/projects/boa-constructor

Class complexity
If you look at any window or control in wxPython like wxTextCtrl, you will
see that it uses multiple-inheritance and derives from a lot of classes.
Here's wxTextCtrl:
  streambuf
  wxControl
  wxWindow
  wxEvtHandler
  wxObject

The number of methods available in the wxWindow class alone is huge. You
need to use a number of classes for even the most basic app. GUI programming
is event driven and with wxPython you have to bind all the event handlers
yourself. Furthermore, most of the options available with wxPython classes
are set via CONSTANTS and there are a lot of constants. That means that new
users to wxPython can find it a quite daunting task to figure out how to get
even the simplest app done. I pretty much have to keep the wxWindows help
document open just to look up the various constants when I'm programming
wxPython. Some of the ugliness in the current PythonCard framework is from
just renaming wxPython constants or methods, but still following the same
procedural paradigm.

More procedural than object-oriented
This boils down to wxPython only being sort of object-oriented. Robin has
done a good job of making portions of wxWindows more pythonic, but there is
more work to be done. OOP folks will have to provide further comment, I'm no
OOP design expert.

wxPython does not provide an application framework, that is partly the point
of PythonCard.

That's probably enough for now. I'll post some ideas later about providing a
thin layer over wxPython that gives us some of the benefits the current
PythonCard model... while exposing most if not all of wxPython.

ka