Plugins, fonts
Richard Gaskin
ambassador at fourthworld.com
Fri May 7 00:05:06 EDT 2004
Robert Brenstein wrote:
> 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
___________________________________________________________
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the metacard
mailing list