plugin update to Mavericks, disabled by Mail on launch

[Greg Welch]

Hi folks.

I'm the developer of two free plugins, MailRecent and MailFollowUp. Scott Morrison has been very helpful to me via email in the past. (Thanks again Scott M.)

After reading about the various Mavericks changes here, I finally paid to join the developer program so I would have access to the pre-release OS versions, and attempt to update my plugins before the release.

I am focusing on MailRecent for now. 

I have been following the posts here, including re. the code for class name mapping, etc. Thanks.

At the moment I have addressed all compile errors, and attempted to update the SupportedPluginCompatibilityUUIDs list, and yet the plugin is still being disabled by Mail on launch ("Incompatible Plugin-ins Disabled" dialog box). 

I read/see that Message.framework has been renamed to Mail.framework (and moved to the PrivateFrameworks). As some indicated, the Mail app has a UUID code (currently ending in 1AF2) but the Mail framework does not. I added that (Mail app) UUID code to SupportedPluginCompatibilityUUIDs, and still, the plugin is immediately disabled on launch.

Any ideas? I feel like either (a) I'm missing something simple, or (b) there is something about my code (e.g., plugin loading) that is causing this. However, I had the impression that the sort of disabling I'm seeing would happen before my bundle code was ever touched....

Thanks in advance.

Greg

[Adam Nohejl]

> I read/see that Message.framework has been renamed to Mail.framework (and moved to the PrivateFrameworks). As some indicated, the Mail app has a UUID code (currently ending in 1AF2) but the Mail framework does not. I added that (Mail app) UUID code to SupportedPluginCompatibilityUUIDs, and still, the plugin is immediately disabled on launch.

Hi Greg,

So you have added the UUID and the plug-in is being disabled for some other reason than a linker error (Error 3588 logged in the console, as mentioned in the "Just curious" thread in this mailing list)? Is there something else in the console?

--
Adam

[Scott Morrison]

Hi Greg

Much of the Framework classes have been renamed and their names(symbols) are no longer exposed. so there is a good likelihood of problems when dynamically loading.

For example in OS 10.8 you could refer to   a Library classMethod with [Library name:of:classMethod:]  but in 10.9 you have to look up the symbol at run time  (Similar how Mail.app symbols were not exposed since 10.6)

eg

[NSClassFromString(@"MFLibrary") name:of:classMethod:]

If you are wanting to support 10.7 and 10.8 simultaneously you have to start getting creative because of the classname changes.

Scott Little and I have developed a function wrapped around NSClassFromString that will build and maintain a lookup table of classNames to Classes at runtime

eg myClassFromString(@"Library") --> returns NSClassFromString(@"Library") for 10.7, 10.8 

--> returns NSClassFromString(@"MFLibrary) for 10.9

it does a few other things such as caching so it minimizes overhead past the first lookup.

One thing I recommend is to _NOT_ link against Mail.framework or other private frameworks -- and don't use the --undefined-supressed linker flag

It is better to get a link error when building than trying to figure out which symbol is not being found by the dynamic loader

Scott

Scott Morrison

sm...@indev.ca

--
You received this message because you are subscribed to the Google Groups "Apple Mail Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apple-mail-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Greg Welch]

Adam and Scott: THANK YOU!  Thanks to your questions/thoughts, the plugin is now being loaded. Not working, but loaded.

Answers/explanations: 

• I had read all of the posts here, including the "Just curious" and "WTF" threads.

• I am indeed using the Scott M./Scott L. wrapper function from github. I replaced NSClassFromString in my CLS macro with GFWMRClassFromString (my renamed version of your function). Although, I'm less worried about maintaining backward compatibility really. I'll be happy if I can make a version that works for 10.9!  (No time to polish, etc.)

• I am not linking agains Mail.framework or other private frameworks. Only AppKit, Cocoa, CoreData, and Foundation. (I confess I don't know that I need all of these....)

• I was seeing a console message but didn't know what to do with it:

Aug 24 18:42:50 dev-10-9.local Mail[525]: MailRecent.mailbundle failed to load. The error was:

Error Domain=NSCocoaErrorDomain Code=3588 "The bundle “MailRecent” couldn’t be loaded." UserInfo=0x6000000642c0 {NSLocalizedFailureReason=The bundle couldn’t be loaded., NSLocalizedRecoverySuggestion=Try reinstalling the bundle., NSFilePath=/Users/welch/Library/Mail/Bundles/MailRecent.mailbundle/Contents/MacOS/MailRecent, NSDebugDescription=, NSBundlePath=/Users/welch/Library/Mail/Bundles/MailRecent.mailbundle, NSLocalizedDescription=The bundle “MailRecent” couldn’t be loaded.}

• I wasn't getting any link errors, nor knowingly suppressing any build errors/warnings, but when I checked I found the "-undefined" and "suppress" linker flags in the build settings. I removed them, and then got a linker build error related to the IMAPAccount class, which is...now MFIMAPAccount. I wrapped it w/ CLS() (not sure why it wasn't before...I must have missed it). After fixing that... no more build/link errors, no console message (other than a successful load message), and the plugin is no longer disabled. Good call Scott.

Now "back to the salt mine" as soon as I can, chipping away to figure out what's going on after loading. I can see several suspicious build warnings that I'll target first. I am hoping nothing I'm using is gone/missing—just renamed or moved. We'll see. I don't touch the code very often so getting back into it requires time/focus.

THANK YOU

--greg

[Scott Little]

Greg,

To give a bit more detail, the function that Scott and I developed will try to add a prefix to the class you want to instantiate using both "MF" and "MC" (MailCore). If it doesn't find a class using that, then it will look up in a mapping file and convert from any version of Mail (10.7 or later) to another one. If you find a class that doesn't convert using the automatic method, you can add it to that mapping file (such as MessageViewingPaneController (pre 10.9) and ViewingPanViewController (10.9)).

You can access this code for your use in the github repo (https://github.com/lksoft/MailCommon). Please read the readme for an important piece of information about how to use it.

In addition, if you want to ensure that you have the latest UUIDs properly setup, see this repo (https://github.com/lksoft/MailMessageUUIDs)

Besides that follow Scott's advice below, that's want helped me figure out my issues for loading.

Scott Little

littleknownsoftware.com

—
"The men who create power make an indispensable contribution to the Nation's greatness, but the men who question power make a contribution just as indispensable, especially when that questioning is disinterested, for they determine whether we use power or power uses us."
John F. Kennedy
—  

Scott Little

scott.j...@gmail.com

--

[Greg Welch]

Thank you (again) Scott. Great stuff. I grabbed the MCC Abstractor code. 

Take care,

--greg