Hi,
let's clarify some abbreviations first:
OODL - OpenCard, just the word
OCON - The OpenCard proof-of-concept that will be 100% HC compatible. This
supports stacks, buttons, menus etc.
OPLG - an OpenCard browser plug-in -- Alain often wished for this. This
will include no DUI, but the UI will look like any OODL stack and it will
support stacks.
OTINT - The OpenTalk engine with support for executing text files, but no
support for stacks, buttons etc.
OTPW - OTINT with supports for creating buttons, fields and other objects
that have their own scripts, but probably without support for persistent
objects.
UI - User Interface. These are the parts of OpenCard that will be inside
the stack window and that are positioned using editing tools.
DUI - The development UI, that is, windows like "Stack Info...", "Button
Tasks...", the tools palette, and how a part selected with the
button/field/pointer tool will look as well as what tools we have etc.
Now ...
What I was proposing was that we start working on the DUI, which can
easily be done using HyperCard by employing multiple stacks and just
creating a mock-up. This could be done in MetaCard, which would not only
make the mock-up look more realistic but which would also allow adding the
actual features behind it since the MetaCard engine has them.
The UI will be a combination of HyperCard's current UI (with support for
color, and maybe different shadow offsets or some similar imrpovement) and
some additions from the Macintosh Toolbox resp. Windows/Unix GUI, depending
on the platform it runs on. This will be the same in OTPW, OPLG and OCON,
and any other incarnation that may be desired. Of course, the UI is
reflected in the DUI's features, but they're still separate entities.
Now, for flexibility I think we should make OCON basically an OTPW with
added support for persistent objects (that is, automatically load/save
parts to/from stacks etc.). And then we'd go out and implement the DUI on
top of that, as a stack. This would get us a customizable editing
environment just like it's used in MetaCard and SuperCard. Of course,
commands like "set script" etc. will also be available in OPLG, we won't
make this just a dumb player. But the actual engine will have no DUI, just
the basic UI which depends on what the developer of the stack it is running
(its "home stack", or the stack that was turned into a standalone by
attaching the engine) created. There will be no "message box" unless the
user copied that into his stack, etc.
This will get us the flexibility many here are seeking. It will make sure
that we can create stacks that are just documents to be run by OCON and use
doMenu and other things to employ the editing environment, we'll be able to
run text files, we'll be able to run stacks over the web using OPLG (like
it would run in a player as we'll very likely leave out the DUI here), or
we can save them as standalones by making them the home stack of an OCON
program or even merging an OCON with the stack.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
