Plug It In, Plug It In
Subject:   complex Plug-Ins
Date:   2002-11-08 11:34:18
From:   mikebeam
Response to: complex Plug-Ins

These are good points you raise here. For handling a great number of plugins I would agree that initially storing a path to the plugin would work. It doesn't take all that long to load a bundle, and the user probably wouldn't notice it. Plus, once it is loaded, it wouldn't need to be reloaded. Some might take this idea further and do something like keep a count of how many times certain plugins have been used over all sessions in the application. The application could check at startup if this count is above a threshold, and if so preload the plugin in anticipation of the user needing it.

As for complex plugins, a bundle is like a mini self contained application. I've made plugins that work with the architecture we setup here that will load a window with controls that let you tweak how the plugin operates. For example, in the method filterImage: you could load a nib included with your bundle's resources that contains a UI for interacting with the plugin. This would load a window with all of the controls for the plugin. there would probably also be OK and Cancel buttons. Cancel would cause filterImage: to return the original image, and OK would be made to execute the core filter code.

There are lots of possibilities with this, and quite likely this architecture may not be the best for many people. It is, however, one way of solving the problem, and gives an idea of the mechanics involved.