MC IDE - developer tool additions - sugggestion

[Richard Gaskin]

Robert Brenstein wrote:
> 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
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com