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 _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
