Plugins, fonts

[Robert Brenstein]

Sorry for breaking my promise to keep quiet, but either I presented 
my case badly or you are misreading my words, Richard.

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

I did not say anything about FULL compatibility but about OPEN 
options. This meant to exclude support for the custom messages.

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

I agree that using built-in properties would really suffice. However, 
Rev plugins may rely on the setting in the plugin manager since 
RunRev decided otherwise. The issue is whether we care. Coding to 
support this and actual execution are insignificant. The only issue 
is degree of compatibility with Rev. It is also possible to recognize 
these options as set by Rev but not support for MC stacks.

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

Well, you know the saying about the finger and the hand.

If Plugins menu is used only as a simple launchpad to open stacks, 
the plugin concept stops short to fullfill its promise IMHO. If we 
make the next step, we need to recognize that some stacks may have 
dual functionality when used as plugins.

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

Well, all this "complicated" stuff comes into play ONLY when you 
explicitely ask for it. If you don't, you have your simple world.

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

Of course, such distinctions are arbitrary. They just help to keep 
things apart. Why do we talk about toplevel, modal, modeless etc 
stacks? They are all still stacks.

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

Apple and oranges. Those four modes define simply their handling by 
plugin manager. What the plugins do is up to programmers.

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

I don't understand what you mean.

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

Please explain. If I have 5 plugins that are "active" I need to 
repeat the same kludge code in each of them. In the plugin manager, 
it is a few extra lines which work same for any number of such 
plugins. If there are no such plugins, plugin manager just ignores 
this code. BTW, it took me longer to debug this kludge code than 
write and debug those few lines in Plugin 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?

That is what I said, didn't I?

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

That is what I said, too, didn't I?

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

Hmm? I really don't follow your line of logic. Where are the 
boundaries? Adding new plugin type opens new possibilities without 
changing anything else.

I don't think there is really anything to teach. As a matter of fact, 
it may take longer to explain to someone why a certain stack is 
marked as a library in the Plugin Manager, although it is not really 
a library.

Opening a stack sends a whole series of messages (at least 
preOpenStack, preOpenCard, suspendStack, focusIn, openStack, 
openCard, mouseEnter, suspendStack, focusOut, resumeStack, focusIn, 
but even more are possible) plus an extra code is needed to 
distinguish between normal open and open at startup. And all this to 
issue possibly a single command at startup. The new plugin type 
allows to avoid all of this, so in the time it takes to open one 
stack, probably ten active plugins may run.

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

It still is rebuilding the menu dynamically, allowing to add plugins 
at any time without restart. However, the automatic (startup) 
execution occurs only (true to its name) at startup.

I see no reason to start using all libraries again, set the script 
editor font again, or open 3 auto-open stacks again, only because I 
want to see stack titles not filenames in the plugin list. And all 
again when I switch back to see filenames. If you really want this 
behavior, you should not have labelled it "at startup".

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

You mean mcPluginFolder, don't you? I moved it to the Plugin Manager 
stack, although, of course, it can be moved back to backscript. But 
why would any stack need it? Any plugin knows its own path. Nothing 
in IDE should do anything with plugins directly. And the primary 
function of mcPluginFolder is to ensure that an existing folder is 
set (creating it if needed), but this should be needed only at 
startup.

If some other stack really needs the path, it is more efficient to 
fetch it directly from the custom property set by mcPluginFolder. A 
better way would be to make it a public (documented) property or 
function. But it should only return the current setting without 
actually creating any folders.

Robert