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.
Ah yes, I did not consider this option and it is indeed important. Using a custom property is thus indeed a better solution.
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.
I don't think we would need a list of all handlers. A custom property that tells whether it is a library stack or not would suffice IMHO. I think a single property can be used to specify auto-opening (set by plugin manager) and auto-start-using (set by lib developer).
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.
Well, we can't have it all without some work, can we? The libraryStack needs to be added anyway, so it is not really an additional action. Adding custom property is but... it can be thought of as blessing a stack to become a library plugin. Not much to ask. And an omitment will be easy to spot and correct by anyone. As a matter of fact, this approach will also allow us to un-bless such a stack should there be a need.
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.
I agree. This is why I did not even mention an option to add a custom message.
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.
Yes, it definitely should. I see no problem being different. MC IDE is different anyway. Who knows, may be Rev will follow this variation if proven useful :)
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>)
Yes, it is indeed about ambiguity. Sorry, I did not explain it clearly for library stacks. I guess the issue has focused more clearly in my mind with active plugins where the distinction is more apparent.
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?
It sound that it should :)
One more consideration, possibly for future, coming from your mention of broader marketplace for plugins: the number of plugins in the menu may quickly become large and it may be worth to consider creating a separate menu for each class of plugins if the number of plugins exceeds a certain number.
In that case, the custom property should allow to distinguish between auto-start-using for true libraries and auto-start-using for active plugins as they should not end up on the same menu.
Actually, on 2nd thought, distinquishing them even with a single menu (having 2 dividers) is probably a good idea.
Yet another consideration is an option to tell plugin manager to disable a given plugin (akin to extension manager in Mac OS), so it is skipped starting with the next launch. May be you've already planned this feature and just did not mention. This can also be accomplished by modifying the same property, me thinks.
No need for a stack to be made invisible: a stack brought into use is not opened.
This item applied only to an alternative scheme which is disregarded.
Robert Brenstein _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
