Plugins, fonts

[Richard Gaskin]

Robert Brenstein wrote:
>>> Why did you add the "library" as plugin type?
>>
>> Because two people presented an argument that there may be times
 >> when a stack should only be libraried at startup but not when
 >> opening the stack.  Moreoever, most good libraries are designed
 >> to be initialized with "start using" called from an app, and
 >> have no auto-initialization of their own.
> 
> But this is exactly the same argument for the "active" plugin type.

It's not my argument, so that's as far as I can go in explaining it. As 
I said, beyond the same auto-launch feature that the other 99% of 
Transcripters use I have no further needs.

 > Is the fact that I am the only one advocating it the issue? Or is
 > it that I am the only one who sees the utility of it?

My own conservative reaction is based on the number of requests for this 
new "mode"/"type" (currently one).  But now that it no longer requires 
me to displace billable time, if it does no harm it's much easier for me 
to just let it be than to prolong the discussion of its necessity.

If it's useful people will use it; if they don't like it they'll speak 
up.  I'd rather let the community speak for themselves.

I would, however, encourage other plugin developers to consider using 
only those IDE features that are also available in the Rev IDE, if for 
no other reason than to help the larger whole of people who enjoy this 
language.  Since this includes the entire Transcript vocabulary and 
object model, it leaves things pretty wide open.

My interest in maintaining the fewest necessary options in the Plugin 
Manager was to further this encouragement toward universal deployment of 
plugins.  The more options available in MC that are not in Rev, the more 
people have to remember if they want to share their work with several 
thousand people instead of just a few dozen.

But the community calls the shots here, and as code monkey I just 
implement 'em.

Perhaps a healthy compromise would be to group Rev-breaking options 
visually in the PM with a note about their effects, so folks can make 
informed decisions when using them.


>> But what I do is completely irrelevant here.  This project is a 
>> community effort, so when a feature is proposed and the majority vote 
>> in favor of it, someone must write even if some will never use it.
> 
> I don't see other open source projects run really so democratically but 
> I have actively participated only in a couple :) There was a brief but 
> interesting thread on these issues on HyperCard list just recently.

Background on this is in another thread from today titled "A History and 
Roadmap of the MC IDE Project".


> Anyway, I think by now I have outlined and argued all changes I 
> envisioned for the next beta. A few people suggested to continue with 
> the workabout solutions using either auto-open or library routes instead 
> of supporting "active" plugins explicitely. Only Richard discussed the 
> operation of Plugin Manager self. The majority has been quite silent.
> 
> So, should I bother to post what I suggested as b5? Or should we 
> continue with b4? If everyone is happy with the way b4 works, I will 
> shut up and just make my own version as Richard suggested :)

Or I can make my own.  I got through the last seven years by maintaining
a script called "FixMC" which wormed through the IDE making minor
behavioral and aesthetic tweaks.  A number of clients and friends have
found it useful, and all that was needed to support such personal
preferences were a few seconds to run the script each time an IDE was
released.

If things ever change in a direction I can't work with, I can find a way 
take care of any of my own needs and those of my clients under nearly 
any circumstances.

--
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com