RE: [Pythoncard-users] What Do We Call These Things?

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

> As much as I've been involved in PythonCard, I still don't know
> what exactly
> is meant by stack, background and card. Can someone provide definitions of
> these that make sense in wxPython terms, for those of us who never used
> HyperCard?

We have two of the most popular HyperCard authors on this list and one of
the original authors of HyperCard, so one of them should probably be
providing an answer, not me.

There is not a one to one relationship between HyperCard terms and wxPython
windows and controls. I found a quote in "REALbasic for HyperCard Users"
http://www.oreillynet.com/pub/a/mac/2001/09/20/realbasic.html
that is relevant.

"HyperCard's card/background metaphor supports a light database where
storage, display, and searching come more or less free"

The whole article is interesting in that it sort of mirrors where we're at
with PythonCard right now. There is no automatic persistent storage in
PythonCard yet, the user code has to manage that.

wxPython windows, frames, panels, and controls are just GUI widgets, there
is no document model tied to them.

In HyperCard, the stack is more or less an "application" as we typically
think of them, but in reality was a HyperCard document. The stack contains
one or more backgrounds and each background can contain one or more cards.
Graphics, buttons, and fields can be placed on cards or backgrounds. Cards
are roughly equivalent to database records but every object (button, field,
card, background, stack) can have an associated script and the state of
every object is automatically saved as the user moves from card to card or
quits the stack (application). If you copy a card in HyperCard and go to
another stack and do a paste, then the card, it's background, all of its
attributes including the script, buttons, fields, and graphics on the card,
etc. are pasted as well; all the data and metadata stay with the object. The
contents of variables in memory are not preserved when the user quits.
People coding in HyperCard ended up using the buttons and fields on the
cards and backgrounds as variables. This is one of those things that makes
"real programmers" cringe.

If you aren't completely confused yet, then remember that stacks are
documents. So, in HyperCard you could have a lot of different stacks open at
once passing messages and sharing data back and forth. You didn't need to
write monolithic programs, because you could share the work between stacks.
For example, a Notes stack could access the fields in the Addresses stack
and it was a lot simpler than COM or XML-RPC or most of the other methods we
use to share data between apps/documents, but it only worked for HyperCard
stacks.

Most of my later stacks avoided the persistent storage and worked more like
PythonCard does today, just a single background with an external data store.

Here's another brief overview:
http://www.cs.sfu.ca/CourseCentral/SW/HyperCard/TeachHC/hcintro.html

I hesitate to send this message since when I reread the text I don't think
it really answers your question. Maybe somebody else will step in and give a
clear answer.

ka