[Pythoncard-users] the HyperCard model

I've been going over Thomas Heller's Doc/View code posted to the
wxpython-users list as well as looking at the Doc/View application framework
provided by wxWindows (but not included in wxPython) and thinking about the
HyperCard model. So, without further delay, I present another mind spew.

From a user/programmer standpoint HyperCard had a very interesting model.
The simplest way to see this model in an updated form is to download
Revolution
http://www.runrev.com/revolution/index.html
http://www.runrev.com/revolution/downloads/downloads.html
Script length is limited in this version, but it does run on a variety of
platforms, so everyone can look at it. The scripts are a HyperTalk
derivative, or more generally known as xTalk script languages.

One of the main points of PythonCard is to use Python as the scripting
language and leverage the existing Python libraries, so Revolution isn't a
viable substitute, but by taking a look at it, those of you not familiar
with HyperCard will see some of the original HyperCard model in action.

Almost every "object" in HyperCard could have an associated script. There
was a hierarchy to the objects so that if an event or message to an object
wasn't handled at one layer it would pass onto the next object in the
hierarchy. We've implemented a simple version of this in the current
framework, which you can see in the tictactoe sample; only one background
handler is required to deal with all the mouseClick messages for the
BitmapButtons. You can't actually get the same result just using wxPython
EVT_ bindings directly, since those have no concept of message passing.

There were really only two widget types, button and field. Rather than
distinct "classes" for radio buttons and check boxes, those were just
different "styles" of buttons along with opaque, rectangle, round rect,
shadow, standard, default, oval, and popup. Popup was a menu (our Choice
class). Depending on the style, a button could also have a standard Mac icon
(32x32 black and white with a mask). I have to agree with Rowland, that
trying to stuff everything into a button or field type seems outmoded today
and that it is better to have distinct classes instead.

Like buttons, fields also had a transparent style. Transparency is something
we can't do with wxPython, at least not consistently. Transparency combined
with overlapping buttons and fields, was a common aspect of many HyperCard
stacks. Most of the time, these combinations were elegant hacks done to get
around HyperCards' limited widget set.

You can think of the stack as both a document and an application. A document
such as a text file has no smarts, but a HyperCard stack which is the
document type of the HyperCard application does have smarts. Furthermore,
anyone with HyperCard can modify the document/application to better suit
their needs. Of course, you could also create a HyperCard stack that
manipulated other document types, further complicating the normal
application/document definitions. If you're not familiar with HyperCard,
you're probably starting to see why it is hard to describe exactly what
HyperCard was.

Stacks were made up of one or more backgrounds and each background contained
one or more cards. Cards are roughly analogous to a record in a database,
but each card can have unique objects on it in addition to the common
objects shared between cards on the same background. The current PythonCard
framework supports only a single background and no cards. You can also think
of the card and background as layers, with the card elements layered on top
of the background layer, so visually anything on the card layer would
overlap anything in the background layer. If you wanted to create something
directly analogous to a normal flat-file database in HyperCard then you put
all your buttons and fields in the background layer and if you wanted a
button or field to share the same state across cards then you set a "shared
hilite" flag to true.

HyperCard transparently saved both the meta-data and data for all the
objects except the script, which you had to save manually. Most of the time
this was welcome, sometimes this was extremely annoying, especially when you
Cut an object out of the stack and then ended up copying something else
before pasting it and ended up losing the object, script, etc. Depending on
the feature set of our environment, we'll probably have similar issues. At a
minimum, I would like the option to suspend whatever transparent save
mechanism we implement both to improve performance of certain operations and
allow for reverting to the last saved version of an applciation/document.

I haven't used HyperCard in a long time, so any errors above are due to a
bad memory. Please feel free to supplement or correct the descriptions above
or bring up important aspects of the HyperCard model that I skipped.

Writing up the description above has convinced me even more that we probably
don't want to adhere to the HyperCard model too closely, but just take the
best parts. As the tag line says, "PythonCard is a software construction kit
(in the spirit of Apple's HyperCard) written in Python." PythonCard is not
HyperCard.

ka