MC IDE - developer tool additions - sugggestion

[Robert Brenstein]

>Robert Brenstein wrote:
>
>>I looked at the two plugin tests and I feel more comfortable with 
>>Richard's. Being able to specify custom location of the plugins 
>>folder will be a handy addition. Actually, I would like for IDE to 
>>check both its local plugins folder (for plugins that are specific 
>>for this version) and my custom plugin folder (for plugins that are 
>>universal).
>>
>>However, it seems to me that the plugins menu is essentially just a 
>>convinience launchpad for various utility stacks. I'd like to see 
>>also an option for plugin library stacks. I mean stacks that IDE 
>>automatically starts using when it launches. This could be easily 
>>addressed by having a parallel "library" folder or by requiring 
>>libraryStack handler present in the card script.
>>
>>Libary stacks should be included in the plugin menu but probably 
>>after a separator line to distinguish them from others.
>>
>>This functionality would also allow us to have active plugins, 
>>plugins that modify the IDE in some active (but non-permanent) way: 
>>since the starts using sends a message, we can use it to activate 
>>the required features.
>
>Agreed on all front, and in progress:
>
>In addition to the ability to select an arbitrary folder, the 
>Plugins Manager window will allow you to auto-open any stack within 
>it.  If you want a "Class 3" plugin you can do in the card script:
>
>   on preopenStack
>      start using this stack
>      pass preOpenStack
>   end preOpenStack
>
>The simplicity of the engine is a beautiful thing.
>
>--
>  Richard Gaskin
>  Fourth World Media Corporation

Great to hear that, Richard, and looking forward to test :)

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.

Moreover, library stacks might have a gui to provide documentation, 
so it must be possible to open them also from the plugins menu. The 
preopenstack solution you suggest would result in a stack window 
showing up at launch and requiring a manual close. If stack is made 
invisible, there must be a way to make it visible when opening from 
menu. Unfortunately, I don't see an obvious way to know whether a 
stack is opened by plugin manager at launch or later from menu. 
Having a window open might be okay for a single library but not if 
one has a dozen. A remote 'start using' does not have this 
side-effect so the above suggestion would work for both modes AFAIS.

With regards to active plugins, I see a similar complication: these 
plugins must be able to distinguish whether they are opened by 
plugins manager at launch or opened by us from the menu (to configure 
the plugin, for example). Again, I can't think of an easy way to 
distinguish these two modes from within preOpenStack.

For example, if my example SetScriptEditorFont plugin is launched at 
startup, it should simply set the global property and exit. No reason 
to open an window and no reason to stay open. However, to choose a 
different font, I need to open it from the plugin menu and change the 
font selection.

One possible way would be to muddle the distiction between active 
plugins and library stacks. What I mean is that instead of having to 
tell plugin manager to auto-open a given stack, we would include a 
libraryStack handler that does whatever needs to be done invisibly 
and then takes itself out of stacksinuse. This would, of course, 
require implementing the transparent launching of library stacks as I 
suggested above to fool manager into thinking it is a library stack. 
Little dirty trick but it should work and is rather easy to explain. 
For my example plugin, the handler could be

on libraryStack
  set the scripttextfont to (the preferredEditorFont of this stack)
  stop using this stack
  close this stack
end libraryStack

whereas my preopenstack would have a different task:

on preopenstack
   get the fontnames
   put it into fld "fontlist"
   set the hilitedlines of fld "fontlist" \
   to lineOffset(the preferredEditorFont of this stack,it)
end preopenstack

Well, just more food for your thoughts.

Robert Brenstein