Time for another update on XRay 2.0.
With a little help from some friends, I have a preliminary idea of the GUI roughed out. It’s still too soon to present a screenshot, but I decided to go with the single-window idea I described previously. The main tool for the user to adapt the interface to personal needs will be the split view paradigm.
Vertically, the window will be divided into several splits, most of which will have subsplits. From the top down, we’ll have a simple file browser like XRay 1.1 has, with the Panther Finder sidebar at the left in a subsplit that can be collapsed. Below that, there’ll be a collapsible “history” list on the left, and the “Information” panel on the right. The latter will contain the actual information for any item selected in the file browser. But I plan to change from XRay 1.1’s switchable pane paradigm to an outline view, somewhat like the Finder’s “Get Info” windows.
In all probability, the information window will also be split – vertically, now – into “Metadata” and “File Content” sections, and the respective contents will be furnished entirely by plugins. Below that, there’ll be a third split for the batch processing interface, again subdivided into two subsplits, items to be processed on the left and actions to be taken on the right. Details are still hazy here, as I’ve never done batch processing before (at least not on the Mac).
After taking some time to get the splits working exactly right, I ran into serious limitations with Cocoa’s built-in NSSplitView class. For instance, programmatic collapsing/expanding of splits isn’t supported, and assigning minimum sizes to the splits works only under certain circumstances; in others, the subviews of the split can be pushed out pf view without any notice. I had both problems almost solved – the first by generating fake mouse drag events, the second by intercepting subclassing most of the default resizing methods – when I ran into some conditions where my solutions would fail to work correctly, with no alternative in sight.
So much for trying to fix NSSplitView. After examining and discarding some other fixes floating around on the net, I decided to reimplement NSSplitView from the ground up as a NSView subclass. This, in turn, launched me into writing an Interface Builder palette so I could set up my window as usual.
Unfortunately, after over a week of fiddling around, I have to report that the current documentation for writing complex palettes is almost non-existent and that there’s a serious bug in Interface Builder (at least in the current 2.4.2 version that comes with Xcode 1.5). Dragging other views into my container view doesn’t work at all and I was unable to find any workaround.
Still, I haven’t given up and I’m now deciding whether I should build my window entirely programmatically or spend a “Support Incident” at Apple ADC to get an official workaround… stay tuned.
The universe will take care of itself.
