>Alain: It is my understanding that all our windows,
>dialogs, alerts, and so on, will indeed be editable
>STACKS instead of un-editable external resources.
Hi,
yup, this is the technique we were aiming for, as else we'd have to do
double work, once to get cross-platform stacks working and for
cross-platform P,D and A.
>Alain: For the record, I would like to have as much of
>FreeCard in stack-form as possible. Stack-based
>tool(s) to create Xternals and/or a stack-based
>FreeCard syntax editor (e.g. augment FC's parser with
>new vocabulary or grammar). The non-stack-based
>FC-core should/will be very small which of course is
>marvelous in many ways. Small is beautiful, to coin an
>ol' seventies idiom.
I have to say I doubt it'll really be feasible to make the interpreter
extensible using FreeScript. There are too many issues involved, many of
which were already an issue when Adrian was asking for a "call <something>
<constant name>". We will keep it extensible and we'll very likely try to
make it modular so people can remove the parts they don't need, but if we
implemented FreeScript by means of FreeScript instead of by means of
compiled code, we'd arrive where Java is now speed-wise :-(
However, the future is still open. Maybe Anthony one day gets a fantastic
idea while in the shower (typical location for programmers to get great
ideas, I heard) and finds a way to give you more extensible syntax.
>Alain: Nothing decided yet but several options have
>been discussed on this list on occasion. Extend the
>maximum number of allowed stacksInUse to more than 16.
>This might not be as necessary as it has been in the
>past because we no longer have any practical limit on
>script-size. Forget about the 30K barrier. It's gone.
>StacksInUse is still a good mechanism though, e.g. for
>modularity purposes.
stacksInUse won't go away, and the frontScript and backScript like
MetaCard and SuperCard have them also could be implemented by similar
means, so we'll likely have that, and as always we'll not introduce any
limits here. We have to be careful about such things though, as inserting
scripts into the hierarchy ad libitum might lead to something not unlike
spaghetti code.
>Then there are Xternals. MetaCard
>supports them on all platforms, so perhaps FC will
>too.
I think it's planned.
>> it would be good to have the possibility to force
>> the path hierarchy through a list of stack, which
>> would be defined in the stack dialog window.
>
>Alain: The hierarchy could be a property of the stack.
>You could script something like this:
>--> set the hierarchy of this stack to myListVar
See my above concerns as to why I think this shouldn't be possible. Maybe
we could allow changing the hierarchy in a restricted way, e.g. we could
add "set the stacksInUse to ..." and let scripters re-arrange start-used
stacks, but it would be very dangerous to insert a stack in front of the
current stack or even a button since then we might get unexpected results
by the wrong handler being triggered.
> 3) Please introduce a stack container similar to the
> one for buttons and bg (shared bg field). The only
> stack container is the script. But script is
> not to stack data, but primarely scripts.
This sounds like you're looking for a way to attach data to a stack,
right? MetaCard and SuperCard have user properties for this, which I
consider the right route to head there. This basically means you can just
define your own properties for any object (stack, card, button etc.) and
store anything in it you can store in a variable, and it will be saved into
your stack. I think we will need this for the editing environment (FreeUI,
which Eric is working on) anyway.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
