Plugins, fonts

[Robert Brenstein]

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.

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.

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

I have indeed been using MC for many years and built a business 
around it so do speak. However, even for my own usage, I see plugins 
as a big boost, actually extending into my products (and yes, 
"active" plugins play a critical role there :).

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

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


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

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

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

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

Well, I have already coded all this for others to try. I will post a 
new beta over the weekend. Then anyone can try it out and see whether 
it is an improvement or anything should be rolled back or improved 
further.

Robert