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!