MC IDE - developer tool additions - sugggestion

[Robert Brenstein]

>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