Plugins, fonts

[Richard Gaskin]

Robert Brenstein wrote:

> Okay, I promise this to be the last post from me today. I have already 
> used more bandwidth than normal :) I split my reply to Richard's long 
> email to cover different aspects more clearly.
> 
>> 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.

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.

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.

Why it needs to be any more complicated than that continues to elude my 
simple mind.

> 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.

Rather than two or four "types" or "modes" or whatever we call them, I 
see an infinite variety of possibilities.

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.

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.

>> 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?

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?


>> 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.


>>> 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).
>
> Actually, that was not the order of things in b4. #2 and #4 were 
> executed for each stack alphabetically. It means that if my aXXX 
> auto-open stack needed yMMMM library to function, I had to rename it to 
> ZaXXXX.

B2 works as you describe, but the code for B4 first builds the menu, 
then loads libraries, then opens those plugins specified for auto-open.


> Also, in b4, shift key disables not only execution but also building the 
> plugin menu. I think that plugins should be always openable in passive 
> mode (that is from menu).

Yes, it completely bypassed the entire Plugins system.  Simply choosing 
Plugins Manager without the Shift key reactivated it.  There's an 
argument for something more flexible, which is why I agreed with your 
suggestion as long as you were willing to write it.  But the first pass 
was written only to prevent injury, and among two dozen people I'm not 
sure how many will be taking advantage of anything more with any 
regularity.  After all, they've built successful businesses without a 
plugins manager at all, and may well continue to use whatever system 
they've been using for the last decade.


> 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.

> 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.

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