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.
I did not say anything about FULL compatibility but about OPEN options. This meant to exclude support for the custom messages.
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.
I agree that using built-in properties would really suffice. However, Rev plugins may rely on the setting in the plugin manager since RunRev decided otherwise. The issue is whether we care. Coding to support this and actual execution are insignificant. The only issue is degree of compatibility with Rev. It is also possible to recognize these options as set by Rev but not support for MC stacks.
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.
Well, you know the saying about the finger and the hand.
If Plugins menu is used only as a simple launchpad to open stacks, the plugin concept stops short to fullfill its promise IMHO. If we make the next step, we need to recognize that some stacks may have dual functionality when used as plugins.
Why it needs to be any more complicated than that continues to elude my simple mind.
Well, all this "complicated" stuff comes into play ONLY when you explicitely ask for it. If you don't, you have your simple world.
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.
Of course, such distinctions are arbitrary. They just help to keep things apart. Why do we talk about toplevel, modal, modeless etc stacks? They are all still stacks.
Rather than two or four "types" or "modes" or whatever we call them, I see an infinite variety of possibilities.
Apple and oranges. Those four modes define simply their handling by plugin manager. What the plugins do is up to programmers.
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.
I don't understand what you mean.
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.
Please explain. If I have 5 plugins that are "active" I need to repeat the same kludge code in each of them. In the plugin manager, it is a few extra lines which work same for any number of such plugins. If there are no such plugins, plugin manager just ignores this code. BTW, it took me longer to debug this kludge code than write and debug those few lines in Plugin 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?
That is what I said, didn't I?
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?
That is what I said, too, didn't I?
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.
Hmm? I really don't follow your line of logic. Where are the boundaries? Adding new plugin type opens new possibilities without changing anything else.
I don't think there is really anything to teach. As a matter of fact, it may take longer to explain to someone why a certain stack is marked as a library in the Plugin Manager, although it is not really a library.
Opening a stack sends a whole series of messages (at least preOpenStack, preOpenCard, suspendStack, focusIn, openStack, openCard, mouseEnter, suspendStack, focusOut, resumeStack, focusIn, but even more are possible) plus an extra code is needed to distinguish between normal open and open at startup. And all this to issue possibly a single command at startup. The new plugin type allows to avoid all of this, so in the time it takes to open one stack, probably ten active plugins may run.
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.
It still is rebuilding the menu dynamically, allowing to add plugins at any time without restart. However, the automatic (startup) execution occurs only (true to its name) at startup.
I see no reason to start using all libraries again, set the script editor font again, or open 3 auto-open stacks again, only because I want to see stack titles not filenames in the plugin list. And all again when I switch back to see filenames. If you really want this behavior, you should not have labelled it "at startup".
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.
You mean mcPluginFolder, don't you? I moved it to the Plugin Manager stack, although, of course, it can be moved back to backscript. But why would any stack need it? Any plugin knows its own path. Nothing in IDE should do anything with plugins directly. And the primary function of mcPluginFolder is to ensure that an existing folder is set (creating it if needed), but this should be needed only at startup.
If some other stack really needs the path, it is more efficient to fetch it directly from the custom property set by mcPluginFolder. A better way would be to make it a public (documented) property or function. But it should only return the current setting without actually creating any folders.
Robert _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
