But as far as I am concerned it is a kludge and a kludge that anyone writing such plugins must always remember to follow. If I open Plugin Manager and see something marked as a library, it should be a library. May be I am a purist, but since plugins are new to MC, it would be a shame to start with a kludge that is not necessary.
Using Transcript is a kludge?
I would imagine the audience for such a specific feature would be rather small, possibly more than one but unlikely to be many more given how few people use MC.
Why not just encourage ever more effective use of the language, so that the developer can have any behavior she wants wants, get a much larger audience for her effort, and the other 99% of Transcripters have the opportunity to benefit from it?
These are MetaCard folks here. Mostly professional developers, they seem accustomed to scripting a line or two as needed. :)
So, in my view, the following categories of plugins should be recognized:
Passive plugins -- plugins that are opened only manually by the user. Any MetaCard or Revolution stack can be used as a passive plugin. The "Plugins" menu is basically a launchpad to open them convieniently.
Auto-open plugins -- plugins that are opened automatically at startup. Any MetaCard or Revolution stack can be set to be an auto-open plugin. The standard sequence of preOpen and open messages is sent when the stack opens.
Library plugins -- plugins that are installed as libraries (through start using) automatically at startup: they are not opened but a 'libraryStack' message is sent to them. They open as a normal stack when selected from the "Plugins" menu or opened in the Plugin Manager.
(new) Active plugins -- plugins that are executed automatically at startup: they are not opened but a 'pluginStack' message is sent to them. Such plugins are meant to perform one-time actions just after the MetaCard IDE loads. They open as normal stacks when selected from the "Plugins" menu or opened in the Plugin Manager.
A given plugin can actually belong to multiple categories. They are not exclusive (except passive of course).
Half of these won't work for most Transcripters, but all of them could if they just used preOpenStack as their hook instead of dependency on a new feature in an obscure IDE.
I guess it's one of those subjective things. In my own head I just see one type a plugin: a stack file. Driven by an incredibly flexible engine, there's almost no end to the combinations of modes and behaviors one can come up with.
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.
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.
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.
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).
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.
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....
I was hoping to post the B5 build you sent, but it crashes my Stuffit Expander:
------
Date/Time: 2004-05-06 18:34:21 -0700
OS Version: 10.3.3 (Build 7F44)
Report Version: 2
Command: StuffIt Expander Path: /Applications/Utilities/Stuffit Stuff/StuffIt Expander.app/Contents/MacOS/StuffIt Expander Version: 7.0.3 (7.0.3) PID: 3528 Thread: 2
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000004 --------
I double-checked my Stuffit installation by downloading a fresh copy of B4, which decompressed without error. While I haven't had issues with other attachments I can't rule out a Mozilla email issue (I'm testing last night's build of Mozilla 1.7b).
I was going to ask you to resend but it seemed simpler to just add you to the moderator list so I did. You can post b5 directly. You may want to double-check the Stuffit file before posting to make sure the issue I encountered was just a Mozilla issue. Also, a housekeeping favor if you don't mind: when I post a new build into the "Latest Test Version" folder I move the last one into "Archives/Non-Release Builds/". There's a handy Cut and Paste feature for moving files easily.
While I see no harm in the new IDE message you've added, in the future please post feature requests to the list for discussion before posting a build that contains them. Staying away from IDE messages flying around is one of the reasons we use the MC IDE, and while I'm confident your dilligent style will avoid the pitfalls of other designs, some folks here have strong opinions about such matters and I feel their arguments have merit.
Above all else this is a community project. The crew here chose the X11 license specifically because it has the fewest hindrances of any GPL-compatible license. Among other things this means there's nothing stopping anyone interested in more adventurous exploration from making their own forked project from any version of the MC IDE from v2.5.1 forward. As Scott Raney says, "Let a thousand flowers bloom." But this specific implementation has a narrow mandate from the community: make the fewest changes necessary.
Please review the credit for your contributions that I added in B4 and let me know if you feel it's appropriate (Help->Licensing, Version History tab). Also, please consider updating the Read Me to include a descriptions of this new "active plugin" feature.
And as discussed here a couple weeks ago in response to the leftover script editor windows, please send the message "mcStripAndShip" to the mctools mainstack before posting; that strips any leftover script editors and saves the IDE.
Thanks in advance for posting b5, and for your contributions to the code base.
-- Richard Gaskin Fourth World Media Corporation ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
