Plug ins in MC 2.6b1

[Robert Brenstein]

>>The warning about mismatch of engine and mctools should show up 
>>before plugins are handled and possibly offer an option to quit 
>>right away.
>
>The version-check is handled in the Home stack, using a property in 
>mctools.mc.  That property has been correctly updated to read "2.6".
>
>What issues are you seeing (other than the new plugins additions, of course)?
>
>To the best of my knowledge there is no specialized syntax in the 
>IDE requiring languages features specific to any version after v2.5, 
>so should we modify the Home stack?

I haven't seen any problem explicitely related to this. However, I 
think the environment check should be done before starting to run 
anything, particularly when that something comes from users. Now we 
get errors from plugin execution before getting a dialog about 
engine/ide mismatch. The order of events is the only matter. 
Theoretically, such a mismatch may affect some execution issues.

You simply need to call mcplugininit after version check was done. I 
am not sure why you would insist on doing otherwise.

>
>>When I get an error opening plugins, the execution stops and I see 
>>the menu of Richard's plugins, none being operational of course.
>
>What does the error say?

One was a script error inside one of my plugins (wrong object 
reference) and another 'stack not found' error caused by the missing 
slash (the 'ps2' email in this thread) which was occuring for all 
plugins.

The problem was not the error per se but the fact that it interupted 
proper initialization of IDE.

>Richard, you need to empty the menu for distribution.
>
>The menu is built when the IDE initializes.  If we fix the error 
>this issue goes away.

Hmm, only if you can ensure that there are no errors that interupt 
the plugins init script. If there is an interuption (as I have seen), 
the last saved menus show up. It may be cute to see what plugins you 
had before your produced the distribution but I don't think it is too 
much to ask to empty the menu for distribution.

>Given the number of people using this without issue I am anxious to 
>learn what differs between your system and theirs.

OS 9.2.2. Downloaded your 2.6b1 distribution, unstuffed it, fetched 
Rev 2.2 from RunRev, placed the engine in your distrbution folder and 
renamed. Then copied the plugins folder from MC 2.5.1 folder. They 
worked there with your preliminary version of plugins system without 
problem.

>This may involve the potentially sticky world of issues surround 
>custom Rev properties and messages which are not part of the engine. 
>Let's hope not, but I've already found some Rev-borne plugins that 
>don't work well outside of Rev and we may hear more of that if the 
>MC IDE gets used by more people.

If a plugin uses anything that requires Rev's IDE, that would be 
normal. It is up to user to know that. Theoretically, plugin 
developers should be checking whether they run under Rev or MC but 
this will be hard to enforce.

>  > Further, the script handling plugins should first build the menu
>>  before trying to open or start using any plugins.
>
>What is the benefit of changing that order of operations?
>
>I'd had it that way once but the extra repeat loop seemed 
>superfluous to me at the time. Not hard to go back to it if we can 
>determine a benefit, but I suspect once we pin down the issue you're 
>having this will take care of itself.

The benefit is that a valid plugins menu is created before any of the 
plugins has a chance to terminate the init process. This allows to 
open those offending plugins from the menu and deal with them.

>  > And the opening/activating should trap errors allowing it to skip
>>  the buggy ones and finish the cycle, then report problems. As it
>>  is, I get an error from ide but have no clue which
>>plugin causes it.
>
>The IDE cannot be responsible for the effects of all possible plugins.

But using 'try' should prevent such errors to terminate your init 
handler. IDE should be somewhat resiliant to user-induced bugs 
EXACTLY because they are unavoidable.

>Does it work correctly with no plugins?

Yes.

>Without more info the best solution may be the ol' Mac Classic 
>Extensions swap:  move plugins back into the folder one at a time 
>until the error is reproduced.

I think you misinterpreted my suggestion. If you add 'try' inside the 
loop opening plugins, the handler should be able to finish the loop 
while collecting names of plugins that generated an error and then at 
the end just tell user that the such and such plugins generated 
errors. Then it is up to user to handle it.

All I am suggesting is to do darnest to finish IDE initialization. 
And that is not the case now.

>>And I think that the instructions should explicitely state which 
>>version of Rev a given MC IDE needs.
>
>Agreed, but if memory serves you have to go more than two years back 
>to find an engine that'll give you trouble.
>

The issue is not the trouble but the fact that the engine version is 
not matching the Rev version. And it may happen that RunRev posts a 
new Rev and then fetching the 'newest' will produce at least a 
warning and at most true trouble. For example, if I am reinstalling 
MC IDE 2.5.1 (which may be for some reason a year from now), I need 
Rev 2.1 not 2.2 or 2.3. This should be simply documented in the 'read 
me' without my having to keep track of that separately.

Robert