We updated the documentation with FxPlug 3.0.1 (the recent release) to show a more efficient way to do this. That said, Plug-ins built the old way should continue to work. You can still have the Protocol framework if you want to. That’s how we were originally instructed to build PlugInKit-based plug-ins. However, you don’t actually need it, and it seems like most FxPlug developers won’t benefit from structuring their bundles that way. (Some other types of plug-ins might, so it makes sense for them.) So we decided to update the Xcode template and the docs to reflect how FxPlug developers are actually going to do things. As such, you really only need the .app, which contains the XPC, which itself contains the FxPlug. If existing plug-ins aren’t working, check the console.app logs to see if it says why. Usually PlugInKit or the host app will say something about not being able to load it. You do need to ensure that the protocol listed in the XPC’s Info.plist file matches the one you’re using (or is NSObject if you don’t need a protocol because your XPC doesn’t actually do anything). If you want to send me logs or an actual plug-in to test with, let me know. Darrin
On Oct 23, 2014, at 11:43 AM, Paul Miller <paul@fxtech.com> wrote:
So I had previously converted some plugins from FxPlug to the new FxPlug3 bundle structure using the old instructions, which included a Protocol bundle as part of the structure.
With the latest instructions, now the Protocol bundle is gone and replaced by some different boilerplate code in one of the other components.
Unfortunately, only plugins built with the new 3-component bundle work in Yosemite.
I'm wondering how I missed the "we changed our minds don't do it that way do it this way or your stuff won't work in Yosemite" warning message/document/tweet/half-burnt piece of paper buried in a disused file cabinet in the basement with no stairs with a sign saying "Beware of the leopard". Can someone explain when this change occurred, and why?
_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/dcardani%40apple.com
This email sent to dcardani@apple.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com