Okay, I promise this to be the last post from me today. I have already used more bandwidth than normal :) I split my reply to Richard's long email to cover different aspects more clearly.
For Rev compatibility it's useful to support the auto-open option, and with preOpenStack as a hook the world is the scripter's oyster. But beyond the most basic compatibility with the majority of Transcripters I'm much less excited about plugin features.
Actually, if we are talking about Rev compatibility, we should support all its open options, including quit, as well different open modes (modeless, invisible, etc). I think this can be added without much effort.
If you look at little deeper I don't think you want to employ full Rev compatibility: those extra messages bouncing around are anethema to the MC experience, and the inconsistency of their behavior annoys even die-hard Rev fans.
As for modeless, invisible, etc.: those were discussed here, and the general preferences was to just use the built-in properties for those things rather than Rev's custom properties which redundantly mirror the built-in ones.
Once upon a time this was all so simple: folks wanted a menu to provide convenient access to extra utilities, and decided it would be useful to also have the option of having some of those automatically opened if they choose. At that point, everything else possible with the engine is available or a plugin's behavior.
Why it needs to be any more complicated than that continues to elude my simple mind.
Admittedly though, all Rev plugins I have seen are "passive" or simple "auto-open" types. In case of MC, I can envision a number of plugins that expand or supplement its spartan interface.
Such distinctions are arbitrary. Plugins are just stack files, and using preOpenStack as a hook there is nothing the engine allows that can't be done by a plugin.
Rather than two or four "types" or "modes" or whatever we call them, I see an infinite variety of possibilities.
But I don't see it as the IDE's responsibility to provide point-and-click affordances for all of them. One hook opens the world for a plugin.
The number of lines written to justify automatic accomodation of the script font settings plugin easily exceeds the number of lines needed to simply make it do whatever it needs in a simpler Plugins Manager.
Personally I wouldn't write components for use by other developers that weren't compatible with the current shipping product, and the stuff I write for internal use hasn't been slowed down by anything absent from an IDE.
True for commercial or shareware plugins. Not so true for utilities. Even some of us MC diehards may need to dig into modifying home and mctools less and start using plugins instead.
Why, now that there's a plugins menu with auto-open capabilities?
And how is it that such a person would be inclined to dive into direct modification of the IDE but be unable/unwilling to write a two-line initialization plugin to coordinate any specialized needs they might have?
Many of the MC developers I know have been using one form of Plugins folder or another for years, far less feature-rich and with narry a complaint....
But until now there was no way to share any such extensions to IDE. Most are probably hard coded in Home stack. Plugins allow us to share. We will see what happens.
Indeed they do, which is why I first proposed this last summer. But with a menu for easy access and an auto-open option all possibilities are available without placing finite boundaries on different types of behaviors and teaching people what these "modes" mean.
Furthermore, I postulate that the order of events at startup should be to
1. build plugins menu 2. start using all library plugins 3. execute all active plugins 4. open plugins to be opened at startup
Holding shift key down, should disable 2, 3, and 4.
That the order of things in B4 (with the exception of #3, as "active plugins" hadn't been discussed here at the time).
Actually, that was not the order of things in b4. #2 and #4 were executed for each stack alphabetically. It means that if my aXXX auto-open stack needed yMMMM library to function, I had to rename it to ZaXXXX.
B2 works as you describe, but the code for B4 first builds the menu, then loads libraries, then opens those plugins specified for auto-open.
Also, in b4, shift key disables not only execution but also building the plugin menu. I think that plugins should be always openable in passive mode (that is from menu).
Yes, it completely bypassed the entire Plugins system. Simply choosing Plugins Manager without the Shift key reactivated it. There's an argument for something more flexible, which is why I agreed with your suggestion as long as you were willing to write it. But the first pass was written only to prevent injury, and among two dozen people I'm not sure how many will be taking advantage of anything more with any regularity. After all, they've built successful businesses without a plugins manager at all, and may well continue to use whatever system they've been using for the last decade.
Another important change that I made for b5 is that the plugin menu is build only at startup and when plugin manager opens (and when the folder is changed, of course). The execution is done only at startup. In beta b4, any action involving plugin manager, opening it or even changing the display mode of the list, resulted in menu being rebuilt and all stacks opening/executing again.
Yes, it was: unlike Rev, the MC Plugins menu is (was) built dynamically so you can add new files at any time and it's easily updated without having to restart the program.
Yes, another change I did is to place all the plugin code inside the plugin manager stack (in b4 most is in the backscript from mctools), so plugin technology is more self-contained rather than spread between mctools and plugin manager stacks.
I hope you left the mcPluginPath function where I put it in the backscript. It would seem useful to be accessible to others.
-- Richard Gaskin Fourth World Media Corporation ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
