Oops, I accidently sent this to Julian (sorry julian). I just realized my
mistake, so I'm posting it to the list.
Now wait a sec, lets just keep our goal in sight, a generic xTalk interpreter
(and perhaps a compiler). Trying to store stacks as html would undoubtedly
waste space and require time by OpenTalk to parse the file. That's not to say
someone can't hack up a quick addition to OpenTalk that will generate these
html things, and a simple interpreter for it too, but for a preliminary effort
to create an open-sourced hypercard, lets not make things too confusing, which
brings me to my second topic...
WE'RE NOT THE ONLY ONES WITH DREAMS FOR xTALK!!! Everybody has their own
needs for xTalk, as julian just showed, everyone needs something slightly
different for their needs, so while we're open sourcing our "OpenCard", why
don't we keep the compiler and interpreter seperate from the stack writing
routines, display routines, etc, so that other people can just take the
interpreter and stick it into their own products. Imagine, clarisWorks with an
xTalk interpreter? We should make some form of appleevent thing to allow any
app using the xTalk routines to control each other, like Applescript. In fact,
when we're finished with the interpreter, someone can make some kinda OSA
extension. oh darn, nature calls, until next time.
<<The way i see it we should first design the language.
I think the whle thing should be programable. for instance.
Instead of haveing a button called "a" on a card you could have a make
file:
<cd>
name="card1"
<button>
name="a"
</button>
</card>>>
