My old version of the Omni Frameworks is close to the branch on github called MacOSX-10.5. Back in those days, the Omni inspectors belonged to the app, which had an Inspector menu, with an item of type OIDynamicInspectorMenuItem. Instantiating that item is a complicated task, which results in the instantiation of all the inspectors and their panels and panes. Since the inspectors belonged to the app, there was a single, shared registry of class OIInspectorRegistry, which the app could get by calling [OIInspectorRegistry sharedInspector].
This model has been replaced by a new one, where inspector registries belong to individual windows, and there is no shared registry. Instead, during initialization, the framework calls on the app delegate to return an inspector for the window. The app delegate must implement inspectorRegistryForWindow:. (Of course apps that keep to the old inspector model will ignore the window argument.) Then the inspector panel will appear along with the various inspector views.
The images for inspector tabs are, however, displayed badly. The Omni extension to NSImage, NSImage-OAExtensions.m, draws the image and then covers it with a solid tint using an operation that covers the non-transparent parts of the image. I’m pretty sure this is a bug, and I simply commented out the tint operation in the source.
The old shared registry responded to a OIInspectorSelectionDidChangeNotification notification by sending the newly selected inspector a inspectObjects message, which gave the inspector the opportunity to update its view.
This notification no longer exists. The app instead calls [OIInspectorRegistry updateInspectorForWindow:nil]. The registry responds by sending addInspectedObjects to the responder chain. Somewhere in the responder chain, a class must adopt the OIInspectableController protocol, and implement addInspectedObjects, where the class adds the objects it wants to be inspected to the inspection set. After this, the current inspectors get the inspectObjects message.
Now inspector views appear and can be updated based on what is selected in the document. Things are looking good. But…
The Inspector menu doesn’t work; none of the items are enabled. The first step of the fix for this is to make the app a subclass of OAApplication. This causes validateMenuItem to be called when the user clicks on the Inspector menu. This would be great, except for some weirdness in the implementation of that method.
First of all, all inspector menu items, regardless of their class, are created with the action revealEmbeddedInspectorFromMenuItem. This is not a good idea, because only OITabbedInspectors respond to this message.
However, the situation is even worse. OIInspectorRegistry’s validateMenuItem contains an assertion that the inspector is an instance of OITabbedInspector. If the inspector is a plain, old OIInspector, then validateMenuItem crashes your app. All OIInspectors have to go.
If you want to have more than one inspector panel, they must all be tabbed inspectors. However, it gets worse. The code for validateMenuItems allows for the possibility that there is more than one controller. It loops through the controllers, and asked each one (a tabbed inspector) to return the sub-inspector with the identifier assigned to the menu item. But the code does not check whether the first inspector it asks returns nil; it accepts this, possibly nil, value, asks it if it is visible, sets the check mark on the menu item accordingly, and then return YES. It is impossible for the loop to iterate to a second controller. This means that not only can you not have an OIInspector, you can have only one tabbed inspector.
The implementation of revealEmbeddedInspectorFromMenuItem in OIInspectorRegistry.m has the same problems. All controllers are required to be tabbed inspectors, and none of the controllers except the first one will be queried for a sub-inspector matching the menu item’s identifier.
As far as I have been able to determine, if you have old style inspectors, and take all these matters into account, you will be able to adapt to the new OmniInspector framework. There may be some further issues I will encounter, or there may be some other issues I forgot to mention. In either case, I will update this post.
