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.
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.
Most of the handful of people who still use the MC IDE have businesses
based around it. They're mostly building applications, not IDE components. The relative few who do make publicly-distributed plugins usually make them for Rev, or at least Rev-compatible.
I have indeed been using MC for many years and built a business around it so do speak. However, even for my own usage, I see plugins as a big boost, actually extending into my products (and yes, "active" plugins play a critical role there :).
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.
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.
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.
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).
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, 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.
The extra stuff sounds okay to me, as long as it doesn't break Rev compatibility and I don't have to write it. I'll be the first to admit that it's hard to get me motivated to spend much time on nuances that will be used by so few people.
Well, I have already coded all this for others to try. I will post a new beta over the weekend. Then anyone can try it out and see whether it is an improvement or anything should be rolled back or improved further.
Robert
_______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
