Updated: March 31, 2006 for release 0.8.2
I'll cover the main points of the PythonCard framework from a user point of view.
Environment
PythonCard does not have an Integrated Development Environment (IDE) yet. 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.
PythonCard does have a layout editor (resourceEditor) and source code editor (codeEditor) to help users build applications.
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 that want to use their favorite editors and tools instead of what ships with PythonCard. 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 and ids.
I digress...
I will reiterate what Andy Todd stated in an early mailing list post that KISS (Keep It Simple Stupid) 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. I much prefer multiple highly focused apps with short learning curves to one big multi-purpose app.
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 framework does not currently enforce unique names, but we will likely add a runtime exception to warn the programmer when they occur.
Components
The components themselves are kept in a dictionary called 'components' that has some dot notation capabilities. See the Components overview of the sample apps for examples of using the background components dictionary.
Component tab traversal and order
The component tab traversal order is determined by the order the components are defined in the resource file. The first component defined in the list is the first component tabbed to and it will always be in front of the second, third, etc. components even if the components 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 components look and behave.
Printing
PythonCard supports printing via the wxHtmlEasyPrinting class in wxPython. An unwrapped example of using wxHtmlEasyPrinting is shown in the textEditor sample. If the HtmlWindow component can display the formatted HTML you would like to print, then that is a very easy way to get cross-platform printing in PythonCard.
Windows (Backgrounds)
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 components inside the window. The resourceEditor sample shows how you can use multiple windows in your app.
We may add support for scrolling windows and other window styles before release 1.0 of PythonCard.
PythonCard is not HyperCard
PythonCard apps are rough equivalents of single card, single background, HyperCard stacks. There is no transparent persistent storage mechanism in the framework yet. 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. See the addresses, companies, flatfileDatabase, and textIndexer samples for examples of some HyperCard-like data apps.
In many ways, PythonCard applications are currently more akin to Visual Basic. Paul Paterson is even working on a project called vb2py that converts Visual Basic projects to Python and one of the targets is PythonCard.
wxPython
In some cases, limitations in PythonCard are caused by limitations in wxWidgets/wxPython. It is also true that PythonCard issues are often really wxWidgets issues and it is necessary to stay abreast of wxWidgets and wxPython if you want to work on the framework itself or use features of wxPython not provided by PythonCard.
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 import wx" 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.
| General Concepts and Limitations | Components | Dialogs | Events and Handlers | Menus | Resource Files | Runtime Tools
$Revision: 1.6 $ : $Author: alextweedly $ : Last updated $Date: 2006/04/06 11:00:26 $