Dynamic registration lets you do things like write a bridge between different types of plugins and the host applications. In this example, I show a general way of telling the hosts about all of the Core Image distortion filters.
There are 2 important points:
1) You need to create a class which implements the PROPlugInRegistering protocol. It has 1 class method and 4 instance methods you need to implement to tell the host application about the groups and plugins that you know about. I believe that you need to set your plugin's "Principal class" entry in its .plist file to point to the class you create.
2) I've used some Objective-C magic to make this possible. But don't worry, you don't need to learn a whole bunch of new stuff. Basically, all you need to know is that you can create classes (not objects, but classes) at runtime. In the example, there is a base class which loads a CIFilter and uses it for processing, called DynRegFxPlug. So the dynamic registration code creates a subclass of DynRegFxPlug with a unique name for each CIFilter it knows about. It does this by making 2 calls into the Objective-C runtime:
Class classPtr = objc_allocateClassPair ([DynRegFxPlug class], [newName UTF8String], 0); if (classPtr != nil) { // if we allocated the new class, register it with the Objective-C runtime objc_registerClassPair(classPtr); }
This just says, allocate a new class that has DynRegFxPlug as its superclass. Then register the class with the runtime so we can access it later.
When the filter's methods are called, it checks its own class name at runtime and creates the appropriate Core Image filter to do the rendering.
There are also some methods for converting between Core Image and FxPlug parameters, and I added in the same cache that I put the straight CIFxPlug example yesterday, but those are tangential to the example.
Please let me know if you have any questions about how this works or need any more details.
Enjoy! Darrin |