This page is just a placeholder. Feel free to start editing and adding information about PythonCard from the perspective of a HyperCard user. - KEA 2002-05-11
Users Who Edit Here
- [KEA] - Kevin Altis
- [DGS] - Dan Shafer
Introduction
Apple's HyperCard was one of the main inspirations for PythonCard. It is simple, yet powerful.
PythonCard is not HyperCard.
PythonCard is cross-platform (Mac OS X, Windows, Linux), where HyperCard is Macintosh only
The scripting language is Python, not HyperTalk
The Environment
We already have runtime tools (Message Watcher, Property Editor, Shell) and a layout editor (resourceEditor sample), but we don't have an environment yet. You can use the resourceEditor sample to build layouts for your applications and the codeEditor sample to edit your source code.
Samples
See the addresses sample for an example of converting a HyperCard stack to PythonCard. The script.txt file shows how I exported both the layout and data of the HyperCard Addresses stack to a format usable by PythonCard.
Interesting Differences
HyperCard automagically saves information the user enters. No explicit Save operation is required or included in the application. While one can easily duplicate such behavior in PythonCard, PythonCard does not force that data model. This is a blessing for all but those who are accustomed to HyperCard's style, in which case forgetting to update data on the disk can be a really painful experience. (Interestingly enough, HyperCard's heir apparent, Revolution, does away with auto-saving as well, for different but related reasons. Once you get used to this, it's not that big a deal.) [DGS] - 7/20/02
In many ways, PythonCard presently resembles HyperCard much less than it does REALBasic and even MS Visual Basic. Ultimately, it may well be the case that there will be a sort of underlying framework that remains a close cousin of these Basic implementations with their visual IDEs, and a more HyperCard-like application will be created using that framework. Time will tell. [DGS] - 7/20/02
If enough old HyperTalkers show up and want it, I could create a document describing sort of how to migrate a HyperCard stack to a PythonCard app. It's not really possible -- at least yet -- to import HyperCard stacks. My guess is it never will be.
Some Subjective Thoughts About PythonCard and Runtime Revolution
by Dan Shafer
I've spent much of the last few weeks (this is mid-September 2002) working with Runtime Revolution, which is a HyperCard clone on steroids for building cross-platform standalone applications using HC-style technology. I've built some fairly cool stuff quite quickly and my mind set has gotten back into the xTalk universe quite smoothly and nicely. I have had a lot of fun working with the tool even though ithas sometimes been frustrating.
In the course of doing this, I've been keeping my PythonCard hat on, observing what works well in RR, what doesn't, why I like it, what about the gestalt brings a smile to my lips, all that sort of stuff. And I've come up with a couple of key conclusions.
First, and I think foremost, the seamlessness of the RR environment is crucial to the feel-good response I get from using that tool. Everything is in one place, one tool. It isn't one window but all of the pieces integrate. Scripts are edited in the same window/context as other properties.
Second, and almost as important, the notion of programming specific controls and components in complete textual isolation from other parts of the application is really important. It makes the programming tasks feel managgeable. There isn't the notion of a single source code file somewhere that you could mess up and break the whole application, for example.
Finally, the absolute transparency of data storage means that I don't have to focus on data structures, storage/retrieval commands, and all that arcania. I just put information into components in a card/stack and write one-line scripts to save everything at whatever points it seems appropriate. It's only one step harder than HyperCard and probably better from a design perspective than transparent auto-save.
Clearly there are down sides as well, but I'm focusing here on the things I think we in the PythonCard community can learn from what RR does right. These are big items for people I call "Inventive Users" and that's the audience I think PythonCard has the best chance of reaching.