[Pythoncard-users] state of the framework - general concepts and limitations

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

Environment
There is not an Integrated Development Environment (IDE) for PythonCard. The
stated intent all along was to build a framework and then later build an
environment on top of the framework that represents the best aspects of
other environments like HyperCard, Visual Basic, Delphi, etc.

I digress...
I will reiterate what Andy stated earlier that KISS should be of primary
importance. That goes beyond the current state of the framework topic of
this message, but the KISS motto got us to where we are now. Dan Winkler has
told me in the past that one of Bill Atkinson's (QuickDraw, MacPaint,
HyperCard, etc.) strengths was knowing when to NOT add a feature. If you
think keeping things simple is easy, look at the vast majority of complaints
normal users have about using Windows or Unix or even the Mac these days.
Look at the bloat that has ruined almost every application I can think of.

My own bias is that shorter programs are simpler to write and maintain, the
exception being code written in Perl which is unreadable at any length. I
much prefer multiple highly focused apps with short learning curves to one
big multi-purpose app.
...end of digression

I would also like to support building apps with the framework without using
the environment since that will appeal to a large number of Python users.
The complication of working outside an environment is that the
user/programmer is responsible for keeping resources, source code, and
application data synchronized and there is more room for user/programmer
mistakes with names/ids.

Ids
All objects in PythonCard have a name that is unique at a given level of the
component hierarchy. The name is used as the unique id by the framework
internally and almost all references are done via a dictionary lookup, so
they are both fast and simple to use. Numerical object ids are not exposed
to the user code.

The widgets themselves are kept in a dictionary called 'components' that has
some dot notation capabilities. See the earlier message about widgets or any
of the sample apps for examples of using the background components
dictionary.

Widget tab traversal and order
The widget tab traversal order is determined by the order the widget
components are defined in the resource file. The first widget defined in the
list is the first widget tabbed to and it will always be front of the
second, third, etc. widgets if the widgets overlap. Look at any resource
file and then observe the behavior when you run the app. The resourceEditor
is a good way to experiment with how overlapping widgets look and behave.

Printing
There is no support for printing in the prototype.

Windows
There is currently support for only one app window (other than modal dialogs
that sit on the app window). In addition, the app window has only one style
and does not support scrolling. Internally, the Background class is the main
app window. In wxPython terms it is a wxFrame that contains a wxPanel. The
wxPanel provides the automatic tab traversal for widgets inside the window.

PythonCard prototype apps are rough equivalents of single card, single
background, HyperCard stacks. There is no transparent persistent storage
mechanism in the framework. Some of the samples do provide their own storage
mechanisms and the intent of the samples is to explore a way to generalize
at least a class or set of classes with get/set record and get/set field
that can be used by any PythonCard app. By making the access fairly generic
we're hoping that a variety of backend solutions could be plugged in rather
than requiring one particular solution such as ZODB.

Given that we are at the prototype stage there are more limitations than
there are features. Andy has already pointed out the lack of multiple
windows. If you simply look over the "classes by category" in the
wxWindows/wxPython documentation, you'll see that there is a huge amount of
functionality we haven't even begun to leverage.

wxPython
In some cases, limitations in PythonCard are caused by limitations in
wxWindows/wxPython. It is also true that PythonCard issues are often really
wxWindows issues and it is necessary to stay abreast of wxWindows and
wxPython if you want to do more than the simplest PythonCard apps. I have
been frustrated lately enough to consider doing something that only worked
on Windows, so that I could make use of the MFC and COM directly. However,
after a breather I come back to the desire to have something that works
across platforms and so I'm willing to put up with the limitations and extra
work imposed by that requirement.

The prototype framework attempts to hide wxPython from user code. The only
time wxPython is exposed is where a feature is not currently available in
the PythonCard framework. If a sample has "from wxPython.wx import *" then
direct access was necessary. This is typically how new features are tested
prior to being added to the framework. One interesting aspect of how
PythonCard works now is that it in many cases it is easy to intermingle
wxPython and PythonCard code, so from that standpoint PythonCard can be seen
as a way of simplifying the use of wxPython.

tkinter
I'm not a tkinter expert, but I think we are already providing a large
portion of the functionality available with tkinter. Please feel free to
list the tkinter items we're missing that seem the most important to you.

ka