Re: [Pythoncard-users] Python/PythonCard: live like HyperCard?

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

On Apr 28, 2004, at 7:05 AM, Geoff Canyon wrote:

> Forgive the newby question, but I didn't see the answer to this on the 
> web site(s):
>
> HyperCard runs live -- you never have to run because it is always 
> running, even as you change properties and set scripts. Is this 
> possible in Python/PythonCard?
>
No and sort of. That applies to version 1.0 which will be done sometime 
in early summer; the next release, 0.8, will be out sometime in May. 
Version 2.0 of PythonCard will have an expanded feature set.

PythonCard is not HyperCard, and it doesn't currently work the same. In 
HyperCard there was an application, either HyperCard or a HyperCard 
runtime application and the stacks that it ran were "documents". You 
could build single stack standalones, but for the most part you were 
always running HyperCard and just switched stacks (documents). Of 
course, the stacks were more than just data, so they acted like 
applications and you could send messages between stacks.

We can't do that in PythonCard today, in part because we don't entirely 
know how to pull it off and more so because there aren't enough 
developer resources to make it happen yet. A long time ago I thought we 
might do it by using a central PythonCard app that was optionally 
started when you start up your application. The application would 
register itself with the server app and then any other registered 
PythonCard app, even on different machines could message with your app. 
The directory service becomes one of the central problems. The original 
idea was going to use XML-RPC for communication. These days I lean 
towards basing it all on Twisted if the Twisted LGPL license won't 
cause a problem.

So PythonCard apps are like apps that you would create with most other 
GUI toolkits. There is no automatic persistent data storage nor can 
applications message to one another, they are just like any other 
application. There is a flatfileDatabase module and samples that 
explore the idea of automatic persistent storage similar to what you 
would get with a single background HyperCard stack, but using it is 
optional.

The "sort of" is that PythonCard has optional runtime tools that any 
PythonCard app has access to including a Shell, Namespace Viewer, 
Property Editor and Message Watcher. The Shell is a complete Python 
interpreter environment and more, in comparison the HyperCard Message 
Box was a complete wimp. <wink> You can create and manipulate 
components and have full access to the runtime object model of your 
application. This is unbelievably powerful, but I'm guessing that it is 
generally underutilized, except by me, since I run most of the samples 
and tools with the shell on a regular basis. The codeEditor is a pretty 
good example of some immediate ways that you can leverage this power in 
the form of "scriptlets". The Property Editor allows you to change some 
component attributes at runtime, but the changes are not saved to the 
resource file.

The Message Watcher is very similar to the one HyperCard had. One big 
difference is that in the underlying wxPython event model there is 
really no such thing as "idle", that is, an event that fires when the 
system isn't doing anything. Instead "idle" in wxPython means there are 
no more events in the event queue so if the user isn't doing anything 
and no timers are running then you'll get one idle and that's it.

See the PythonCard documentation page for more info on the runtime 
tools.

Once PythonCard 1.0 is done I would like to start investigating an "app 
runner" that works more like HyperCard did. All PythonCard "background" 
classes are defined in modules with a separate if __name__ == 
'__main__' block at the bottom of the file specifically because it 
makes it very easy to support loading the background from the module as 
a child window of another app if the module isn't run standalone. So, 
without breaking the user code API we should be able to add a 
PythonCard app environment say in version 1.1. The environment would 
run and via the File menu you would load PythonCard modules. That 
environment in theory could switch between "design" and "run" and would 
allow messaging between applications. This may just be theory, there 
might be something that prevents it from working and so the idea would 
have to get bumped to what I currently think of as PythonCard 2.0.

What I do know is possible and will probably do first is make a 
flatfileDatabase environment app which has some of the features of a 
full PythonCard environment. This is probably analogous to FileMaker or 
MS Access. The database app is started and then you can open, use, 
design, etc. various database templates which will all get some 
capabilities from the database app environment. The same thing would be 
possible for SQL databases, but I'll do it for flatfileDatabase first. 
If anyone else is interested, let me know and maybe work will get done 
on it before 1.0 is finished.

Also see: http://wiki.wxpython.org/index.cgi/PythonCardForHyperCardUsers

ka