Quarter Life Crisis

Cocoa Bitching¶

1800 words on Software

Arghl! From time to time I have these sweet ideas for programs which look like they should be nice and easy to do. And the wonderful thing about Cocoa is that it does most of the heavy lifting and let you get right into it to make that little project work. However, I regularly run into roadblocks with this kind of strategy. Which –  seeing that I don’t want to sit around ages trying to figure out how my understanding of the documentation differs from what it means or implementing stuff which looks like it should work out of the box – spoils the fun. Probably most of these problems aren’t all that hard to solve but doing so will likely consume a lot of time. And that’s where the line between small fun projects and professional programming is drawn.

Don’t get me wrong! Cocoa is one of the best environments I have seen for this kind of low-fi approach to ‘programming’. It probably even beats RealBasic by not being much harder but significantly more powerful. But still there are endless sources of frustration around. I’ll take the liberty to list a few examples. And invite you to tell me an obvious two-line solution for that which I would have already seen, had I read the documentation thoroughly.

NSComboBox vs. Bindings

To me it looks as if NSComboBox is a total bitch. In these modern days of bindings and advanced magic in Cocoa, I totally expected that I could just hook up an NSComboBox to a key in my user defaults and voilà, I automatically have a list of previously used values around. Let’s just say that didn’t work. Not at all. And I had to handle the storing, loading, and management of that list myself.

It turned out that the code for achieving that was neither particularly tricky nor was it particularly long. I ‘just’ needed to implement a data source for the combo box which loads the array of historical values straight from user defaults. And then I had to watch changed values of the combo box to add new items to that array of historical values in user defaults. Altogether, a simple thing to do thanks to KVO. (Let me know if you think having the code for this would help you, I’m just too lazy to prettify it for the web now.)

But while implementing this didn’t take long, learning that using bindings and controller objects for this purpose doesn’t work is a bad idea took a while. And a very frustrating while that was. In fact, it’s a common phenomenon I have experienced with bindings (or CoreData): it’s brilliant stuff as long as you want to do the same things Apple show you in the tutorials. But at least one of Cocoa or your understand of what’s going on starts falling apart quickly when you leave that realm. And as the underlying ‘magic’ is quite involved, it ends up being tricky/impossible to figure out why exactly things don’t work.

NSComboBox vs drag and drop

When you’re dealing with text views, Cocoa’s automatic drag and drop handling is wonderful. Because you get the whole deal for free. But once you start having a window with a number of text fields and the (unseen but still dreaded) field editor comes into play you (or at least I) quickly lose control about what’s going on.

In fact, this is a general problem which you can easily experience while using Cocoa applications. An example would be Mail: If your text cursor is in the To field you simply cannot drag text into the Subject field. That only works while the text cursor is in the Subject field, which is kind of pointless. Many other applications have the same problem. And – if I understand things correctly – the problem here is that when there are multiple fields Cocoa will only have the infrastructure for doing editing, the field editor, around once and simply switch it to the field you are currently editing. That’s probably a clever and economic thing to do. But it isn’t integrated with drag and drop. Which means you don’t have the field editor around when you drag to a field that doesn’t have the text cursor in it and thus things fail to work.

NSComboBoxes suffer from this problem as well. And as they are essentially text fields plus a menu, you have the additional problem that they also behave like text fields. I.e. when you happen to have the cursor inside them they’ll accept a text drag. And that drag will not replace the complete text but rather insert the dragged text. As you’d exepect for dragged text, of course. But this isn’t particularly useful when the dragged text is a file path, say.

[All right I hear you (and me) say that file paths are Wrong anyway, but dealing with proper file references in Cocoa is another of those painful topics. Generally, people tend to do what’s easy to do, so Cocoa just discourages people to do certain things properly and makes me end up with plenty of ‘evil!’ comments in source code.]

I didn’t find a way yet to solve this with reasonably little effort. Although it sounds like it should be a common combination of problems that have been solved over and over again.

QCView vs drag and drop

My next idea was to accept drags in a QCView. That may seem exotic, but I figured it should be possible (and I’m still puzzled why this didn’t work). QCView is a new X.4 class, so perhaps it’s just buggy or something, no idea.

As this is a plain old NSView subclass I figured I should just be able to subclass it, register for drags in an overridden -initWithFrame: method and then also reply to the dragging protocol methods. I did just that, plus using my own subclass in the nib file of course. And it seems to do exactly nothing. Which I don’t get. The debugger says that the class used actually has the type of my subclass but my overridden -initWithFrame: is never called, which probably accounts for the rest not working. No idea what’s going on there. Perhaps something’s wired up wrongly? But what could that be?

Solving this problem turned out to be nice and easy after Steffen reminded me that objects coming from NIB files will not be inited when being unarchived, but they do receive the -awakeFromNib message which is the correct opportunity to listen for drag and drop. Bad thing is, I actually used to know that at some stage…

NSDocument

TextEdit implements a neat feature that camouflages its rudeness of always opening an empty document when the application is launched or clicked in the Dock: If you open a file with TextEdit while it’s just displaying that blank document, then the opened file simply replaces the empty document. That’s a reasonably good compromise and I thought I want it as well.

Probably the way to get this behaviour is to implement application:openFile: in the application’s delegate and do the necessary replacing there because it needs to be done before a new document class is initialised. Oddly, the TextEdit example project doesn’t seem to use the normal NSDocument class, so I was left a little puzzled at least.

UTIs

UTIs are a great idea and the way to go for the future. In fact they were tacitly introduced in X.3 and see quite a bit of usage by Spotlight these days and allegedly also in pasteboard handling (although it’s admittedly not really clear to me how exactly that works and how it plays together with the older way of doing things).

But apart from that there just seems to be extremely little support for UTIs in Cocoa. Say your application can open movie files. Shouldn’t it be enough to tell the system that it can open anything that conforms to public.movie? At least I thought that should do the trick. Just that it doesn’t work. So what else can be done about this? Particularly if you don’t want to be too specific and need to update your application whenever QuickTime learns new tricks.

A nice thing of the hierarchy in UTIs is (would be) the inheritance. There are gazillions of movie file types identified by numerous things in the range between a ‘MooV’ creator code and the characters ‘.avi’ at the end of a file name. Shouldn’t it be reasonably simple to handle all of these in a single go?

Admittedly the file types as they exist today don’t work 100% here either. Which is the curse of container formats that carry information about their content hidden inside rather than sharing it with the system. From the outside a QuickTime VR file may come with the same ‘MooV’/’TVOD’ type and creator codes as a film (only the really old school ones will have a ‘vrod’ creator code), yet it is quite a different beast. And, similarly, very few AVI files can be played by an out-of-the-box QuickTime but once Perian has been installed, they’ll play just fine. It’s really hard to judge what works and what doesn’t in this context. And I wonder how long it will take to get an operating system that handles this well enough so your Dock icon already refuses accepting the film drags you cannot handle.

Another question is: How can I learn the UTI of a file? Say I accept file drags and only want to accept files of a different type. If I can learn the UTI of a dragged file, it should be possible or even easy to check whether it conforms to whatever I am able to accept, public.movie, say. But I didn’t find a way to learn the UTI of a file type directly. I assume that using Spotlight and doing something analogous to the mdls command could achieve that. But ever since Spotlight broke on my computer and the system stalls every process that dares to touch Spotlight for half a minute, I started thinking that it’s probably unwise to use Spotlight in your application unless you really need to search and are willing to handle such failures gracefully. Which leaves me clueless who such basic 21st century file type information could be found out by a Cocoa application.

Thanks to Michael’s helpful comment I was pointed towards LaunchServices for this which do the trick. It’s not nice angle bracket Cocoa but it’s not obscenely complicated either. I found Apple’s slightly more specific and complicated QA 1518 technote helpful here which demonstrates the relevant calls in practice along with the proper use of CFRelease.

Altogether I am not particularly amused. Everything sounded so good on paper but then things just started breaking down.

August 23, 2007, 0:57

Tagged as software.