>So can we agree on:
> 3 properties of NuCard* for storing stack, application, and document
> search paths
>
> NuCard:FindStack, NuCard:FindApp, NuCard:FindDoc which are functions
> taking the name of the stack, app, or doc, and returning a path to
> it.
>
> NuCard will have defaults for the three functions above. The default
> behavior will be a simple search through all of those directories
> to find the stack, and return the first one found.
>
> NuCard will be responsible for restoring and saving the three paths
> properties in a manner sane for the implementation it's running on,
> such as a prefs file on a Mac/Windows box, or config. files on Unix
> boxen.
>
>
>*since we can't call it OpenCard anymore
Anthony,
We'll have to change the names. I want a standard that can be used by
other engines, too. That is, maybe we should introduce a new type of
handler, like an internal handler and the only three defined so far are:
internal findStack stackName
statements
end findStack
internal findDocument stackName
statements
end findDocument
internal findApplication stackName
statements
end findApplication
You should propose them on the xTalk list and see whether anyone there has
any objections. One more thing: Don't call them "findDoc" or "findApp".
Long names are much more self-explanatory, and users won't need them so
frequently that they'd really benefit from having to type less. In a normal
case, every home stack or standalone will have these three, and that's it.
How many home stacks do you create in a year?
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
