Plugins, fonts

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