I’m spending a lot of time now with my new friend, the AppKit object NSOutlineView. Right now I’m trying to implement drag and drop, which is easy if you actually look for the documentation for NSOutlineViewDataSource, which, silly me, isn’t mentioned in the “Drag and Drop Programming Topics for Cocoa.” Instead, the documentation outlines how to create drag and drop for tables–and silly me, knowing that the NSOutlineView inherits from NSTableView, started writing the data methods for table drag and drop instead of outline view drag and drop.

The other thing that is extremely disappointing are NSViewControllers. When I first read about them I thought “oh, cool; the perfect class thingy to insert into the view hierarchy to provide the functional equivalent of a NSWindowController but for just a subclass of the window view hierarchy!”

Uh, no.

First, the NSViewController only exists for 10.5 as far as I can tell–and any application development I want to do should be 10.4 backwards compatible. (Many corporations such as Yahoo! are still using 10.4 internally, as corporations tend to be about one to two years behind in deploying new operating systems.) Second, it seems NSViewController objects are designed to allow and control views that are “out in space”–that is, that are not associated with a window, or that are programmatically associated later on with a window.

To do what I want to do, I simply created a custom class and hooked the responder chain in my class. It’s ugly as hell–but it’s exactly what I want: a way to handle just a subset of controls within a region of my window to properly manipulate the events. (Think of a group of radio buttons or check boxes which change the state of other radio buttons or check boxes in a group box of controls–at a higher level you may just want the abstraction “I’m in state ‘N'”–which translates to some combination of check boxes being enabled or disabled at the lower state. By placing the functionality of translating “N” into the state of a bunch of controls, I’ve isolated key functionality somewhere else–which is, to me, the whole point of object oriented programming: hiding the ugly details in reusable classes.)

Every framework I have ever encountered, every API, Toolkit, or whatever, consists of (a) a specification, (2) an implementation, and (3) a whole bunch of bugs which require experience to understand and work around. In many ways one could say that the difference between one who is just learning a framework and one who understands the framework is in part measured by how many bugs one “just knows how to work around.”

Here is what I’ve learned so far about Apple’s AppKit:

(1) If you want to make Apple’s synchronized scrolling hint work, you need to make sure the document views across the different scroll windows have the same frame origin. In order to guarantee this, the following snippet of code seems to work for me:

- (id)initWithFrame:(NSRect)frame 
{
	/* Kludge: Modify the origin to be 0. This forces the value to be 0 so
	 * we can do synchronized scrolling across multiple desparate objects.
	 * Otherwise, we don't have a common origin, so things don't synchronize
	 * as the value of the origin is essentially random from the nib.
	 */
	
	frame.origin.y = 0;
	frame.origin.x = 0;
	
    self = [super initWithFrame:frame];
    if (self) {
         ... the rest of your initialization goes here ...
    }
    return self;
}

(2) (And the subject of my last rant post) If you embed a your own custom view within an NSScrollView, if your view implements either -(NSView *)headerView or -(NSView *)cornerView, you’ll get either a horizontal header or a corner view a’la the NSTableView’s documentation on both of these methods. (In other words, NSScrollView handles and manages the NSClipView for the table view by seeing if the document implements these methods.) Handy if you need a custom header along the top of your document view–though honestly, if you’re creating a table or a drawing program, you’re better off using the built-in NSTableHeaderView or NSRulerView classes instead.

For example:

- (NSView *)headerView
{
	if (fRuler == nil) {
		NSRect r;
		
		r.origin.x = 0;
		r.origin.y = 0;
		r.size.width = 320; // default width; resize frame with correct width as frame resizes
		r.size.height = 16;
		
		fRuler = [[ResourceRulerView alloc] initWithFrame:r];
	}
	return fRuler;
}

(3) Oh, and to answer the off-asked question how do you get your content view document to grow from top down rather than from bottom up, and how to stick to the top:

(a) Implement -(BOOL)isFlipped in your custom view. Return YES. Yes, this flips the coordinate system so the upper left corner is the origin, instead of the lower left corner. No, I don’t know how to do this without flipping the coordinate system: I’m new to this whole thing. 🙂

(b) Make sure you flip the autosize parameters as shown below:

Disclamer: All of these things seemed to work for me. However, I reserve the right (as always) to be a complete idiot and get the details wrong.

Several months ago there was a flame war amongst many of the better read technical blogs, and from what I read in places such as Daring Fireball and Thought Palace was that Java sucked–and part of the reason why it sucked was that Java Swing sucked.

By extension, of course, the Objective-C Application Framework was a very well thought out framework designed by people who knew how to do user interface design–and beautiful user interface design–as opposed to those neanderthal Java developers at Sun who, in a massive language land grab, built a user interface environment which was so horrific that it doesn’t even entertain being taken seriously as a user interface API.

Okay, I will admit Swing has its places where the designers made some really bad design decisions. The whole Swing pluggable L&F environment, while that may be cool in theory on platforms like Linux (where the idea of a design language is either C or C++), but really blows on Windows or on the Macintosh as it requires extra work to make your application fit in rather than look like a refugee from a 1980’s Motif concentration camp. And the fact that it took Sun until v5.0 of Java to realize that floating windows aren’t a bad thing–a fact that some Window Managers still haven’t figured out, combined with a lack of a reasonable serialization standard–okay, I could bitch about Swing on and on and on. (And please don’t get me started on keyboard shortcuts or the fact that you have to write extra code to make the escape key cancel a modal dialog box.)

But now that I’m starting to crack the mysteries of the Objective-C Application Framework, I’m not exactly seeing the nerdvana of a perfect and well designed UI construction environment created by experienced user interface designers.

To whit, I give you–NSScrollView.

I only have three words for those who think the Objective C Application Framework is superior to Java Swing: What The Frack?

First, NSScrollView really really wants to pin your document to the lower left, according to the Application Framework’s insistence on using a mathematically correct coordinate system with the origin to the lower left. That’s great for the 5 programmers out there who are creating statistics and mathematical plotting packages. But for the rest of us, who are creating text and textually-based packages, flipping the Y axis isn’t just an exercise in mathematically imprecise masturbation. Documents–and by extension computer displays–tend to be read top down. Scrolling tends to focus on top-down reading. Documents should start at the top and go down.

And don’t give me this “just use -isFlipped;” nonsense, as without knowing the magic size settings to fiddle in the Interface Builder, when you have a document that is bigger than the window, on resize you’ll find that your document expands upwards, not downwards like every fracking window out there. (You need to select your custom view, then set its size in the inspector to pin to the lower left instead of the upper left. By pinning it to the lower left, after the coordinate system is flipped, document resizing will fix the upper left as you expand your window. Yes, that made no sense. But it works.)

But that’s not what brings me here today; oh, no. I can live with the quirkiness of some stupid design decision made early on that now everyone winds up living with because it’s too deep in the underlying framework to fix. And God knows there are plenty of these in any framework, where you wish some early on design decision could be taken back, but it’s too late now, and now everyone has to just learn the quirk to get along with your code.

No, what I want to talk about is creating custom horizontal and vertical headers.

In Swing, this is a relatively simple proposition: when building your JScrollPane, you also create a view which manages your custom column header, then add it with jScrollPane.setColumnHeaderView(). This may make creating a table view a little harder–you have to tell the JScrollPane holding your table to use the table view passed to it from your constructed table view item, but it’s all fairly well documented in the Sun “How to use Tables” docs. And for the small percentage of us who want to roll our own tables–because we have a complex drawing task we need to accomplish or because we need to draw something that is almost, but not entirely like, a table–well, we can just build a document view and a header view, and pass them to JScrollPane.

So I went to figure out how to create my own custom header view for my NSScrollView. Okay, perhaps I was going about it the wrong way: perhaps I should have just constructed a table view then used a very large hammer to bang the damn thing into the precise shape I wanted. However, that’s not what brings me here either.

What brings me here is the following snippet of code which I ganked from GNUStep. (As a footnote I find that, for understanding the fringe cases and the assumed design models of an application framework–and every application framework has underlying assumptions as to how the pieces will be strung together which seem obvious to the initiated, but are often completely undocumented by the developers.) What’s great about GNUStep is that, at least for the core elements, at least you can look at the code and learn how things are actually built under the hood, so when gaps show up in Apple’s documentation (and Apple’s documentation has gaps that you can drive a truck through–which disappoints me, given how great pre-NeXT Apple docs were), you at least have a fighting chance to figure out what’s going on without wasting a day.

And here is what I found:

- (void) _synchronizeHeaderAndCornerView
{
  BOOL hadHeaderView = _hasHeaderView;
  BOOL hadCornerView = _hasCornerView;
  NSView *aView = nil;

  _hasHeaderView = ([[self documentView] 
                        respondsToSelector: @selector(headerView)]
                    && (aView=[(NSTableView *)[self documentView] headerView]));
  if (_hasHeaderView == YES)
    {
      if (hadHeaderView == NO)
        {
...

In other words, deep in the bowels of NSScrollView, in order to allow an NSTableView to build a custom table column header, NSScrollView gets the current document being scrolled–and if that document responds to headerView, uses that view as the header.

And notice that unnecessary cast to NSTableView. Not to belabor the point here, but what the hell is this? In any case where you have an undocumented (at least in NSScrollView) hook, mentioned in passing in NSTableView, which provides a hook for giving a header to your custom view–to me, it’s a sure sign of a hack. A kludge. A piece of code tossed in (and this is not GNU’s fault–GNUStep is simply implementing to the best of their ability the OpenStep specification on which Cocoa is based) in order to support a specific case behind the scenes–the need to build a custom table view–rather than creating a general solution then implementing the specific instances for specific cases.

WTF?

Any time in your class hierarchy where you use “supernatural knowledge” of another class–and one of the things that irritates me about Objective-C is how easily someone can create hooks which creates this “supernatural knowledge” through querying an object to see if it implements a poorly documented hook–its a sure sign of something that congealed, rather than something that was designed.

And while that wouldn’t matter much to me: after all, any software project is about making compromises to get something out the door–it wouldn’t irritate me quite so much if the accusations of poor design weren’t leveled so fiercely by those who think Objective C is the epitome of good UI framework design. And I speak as someone who once built my own framework.

Feh!