I gather your classification is then
1. passive plugin 2. active plugin 3. library plugin
If I follow correctly what you said above about library plugins, I'd have to
a) add the above script and b) visit plugins manager to activate auto-open
in order to have that stack automagically put in use upon launch.
I wonder whether we could make it totally transparent and eliminate both of these steps: since each well-behaved library stack should have a librarystack handler, (even if empty -- so it traps the message intended for it rather then letting it pass to whatever other library is already open), the plugin manager could easily check for its presense and act accordingly. I believe it is possible to fetch stack script without actually opening stack and two offset calls and a couple of if's per plugin are an acceptance price.
True, but if the stack is password-protected it'll generate an error. As Rev grows we can anticipate a third-party marketplace of components, and some of those may be locked for public distribution, such as Ken's XML library or my hopefully-released-soon Devolution toolkit.
Another approach would be to include a property that lists available handlers, but if we're going to go so far as to add properties I would sooner just adopt Rev's property-based scheme for compatibility reasons.
But whether a stack is libraried by its own script or through the addition of a property, neither is completely "transparent" in the sense that some additional action is required by the developer to invoke the desired behavior.
For simplicity's sake, my personal preference is to use native commands and properties whenever possible, augmenting the engine only where absolutely necessary. In this case that would mean adding a line of script as opposed to adding a property and requiring a new mechanism in the IDE to read and use that property.
Another example is with window styles: Transcript has a built-in stack property called "style" which allows a stack to be opened in the mode specified in that property when using "open" or "go". While we could add the additional mirror property that Rev uses I feel okay about departing from that in favor of the built-in solution as it already exists and works great.
Moreover, library stacks might have a gui to provide documentation, so it must be possible to open them also from the plugins menu.
For this reason I'm proposing we break from Rev's convention on another front: when a stack is marked for auto-opening it will still appear in the Plugins menu.
> The preopenstack solution you suggest would result in a stack > window showing up at launch and requiring a manual close.
Not if you use a "pre" message, like "preOpenStack" or even "preOpenCard", as those are sent before the stack is drawn.
Hmmmm....
after thinking about I think I'm getting it. The problem is one of ambiguity: when is stack opened to be libraried and when to be looked at? (later in your email you address this clearly; that'll teach me to rush through catching up on my email <g>)
Okay, I'll modify the Plugins Manager window like this:
A stack can be set to auto-open OR to be auto-libraried. That way we still only have one custom property being set and a library stack can still be opened for viewing/editing through the Plugins menu.
Would that do it?
> If stack is made invisible, there must be a way to make it > visible when opening from menu.
No need for a stack to be made invisible: a stack brought into use is not opened.
And even in my initial proposal (hence revised per your suggestion above) the stack can be opened and closed without affecting its libraried status.
In the current version of the engine this is only true if the stack's destroyStack property is off, but that's a bug scheduled to be fixed so it will soon be universally true.
But by supporting your excellent suggestion the issue goes completely away anyway.
-- Richard Gaskin Fourth World Media Corporation ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
