Cocoa and Objective C

I am currently writing a graphical user interface (GUI) for my Wavelet Image Compression Library that will allow for selecting and inspecting compression settings. As my “main computer” for the past year has pretty much been an Apple Mac mini (with an x86 laptop for Linux (work) and Windows (games)), I decided to write it in Cocoa, learning the Objective-C language and the Cocoa class library / ApplicationKit at the same time.

I quite like the language (ignoring the message send syntax in square [] brackets) as you’re always aware when you’re doing OO stuff like sending messages, or writing simple C-code. It is very dynamic as essentially all binding happens at runtime and dynamically (which you of course pay a speed penalty for, but that shouldn’t matter much for high-level GUI code).
The Objective-C class library (“Foundation”) is very clean, always making a distinction between mutable and immutable versions of objects, and seems very complete with all the conveniences of modern OO.
Using the Interface Builder to create not only the actual interface, but instantiate classes and bind actions / outlets is a very nice touch. You can usually get a semi-functional mock-up of your application without writing any code at all, especially when using things like Cocoa Bindings, which allows for introspection via Key-Value-Coding (KVC) conformant objects. In essence, the AppKit “knows” how to access your member variables and set them according to the rules you defined in Interface Builder.

There are also some things which aren’t so nice. Documentation in some areas is lacking (e.g. using NSTreeController without CoreData or a dataSource), some things that look simple on the surface definitely aren’t under the hood (Key-Value-Observation replacing some of my objects by proxies, but at least they remembered to properly override isEqual: ;)). Memory management is also something which my head took some time to wrap itself around properly: every object is reference counted, but the crux is NSAutoreleasePool which is a bit like poor-man’s garbage collection. My problem with that wasn’t what it does, but when it does it. Oh, and namespace support would be nice…
Today’s challenge was to extend the NSOpenPanel of an NSDocument-based application with an accessoryView. I got it working in the end, but it wasn’t trivial (subclass NSDocumentController, changing stuff around in the Interface Builder to make sure the subclass is instantiated first, creating a separate .nib file for the accessoryPanel and praying that the View gets released properly).

Most of the time it’s a joy to work with, and a welcome change of pace from the dreadful writing of Windows GUIs in MFC. I only wish a decent Objective-C compiler with Foundation class library were available there as well (GNUStep doesn’t count, unfortunately). Might be an interesting idea to try to get Objective-C working on Microsoft’s .NET platform…

5 thoughts on “Cocoa and Objective C

  1. apexo

    about three years ago I did some experiments with your wavelet code; result was a tile-based video-codec which used wavelets for spatial as well as temporal compression and your rice-coding backend; I gave then up since at that time DivX seems superior (although not by much) to my attempts (and since my approach was a whole lot slower)

    now I came back to that idea and stumbled across some new things like SPIHT (http://en.wikipedia.org/wiki/SPIHT), wonder whether you already did experiments with SPIHT or if I should try my luck there

  2. [maven] Post author

    Well, I’ve changed a lot in the code since then, and although it still uses the same Rice-coding back-end, it is now much closes to SPIHT as it also produces an in some sense (and under some restrictions) optimal embedded bitstream, but with somehwat simpler code.
    Now there is no quantizer-selection as such anymore, the encoded channel is simply truncated at the desired quality, which has improved the speed for target quality and target size modes considerably.
    You can find the current version (with documentation) here.

  3. apexo

    sounds promising; seems like I gotta take a closer look at the new sources … still leaves me with the non-trivial problem of how to distribute bits across tiles … well, got that solved then, think I’ll manage to do it now somehow …

  4. apexo

    very funny indeed. you modified your rice-coding backend in quite the same way i did 3 years ago (like caching the refinement bits to simplify the decoder)

    even tried to exchange the backend with something different (like an adaptive huffman encoder which huffman-encodes the exponent or a fibonacci-coder) … well; none of those were superior to the rice-coder for the given workload; wonder how many different coding backends you tried before chosing rice …

    nevertheless I still have something different to try out. maybe this evening …

  5. Kabenla Armah

    I have just started using xcode/objective-c and I wanted to know why it is not possible to drag an NSOpenpanel into my application in the interface builder, and access it through IBOutlet system (in the same way that you can with NSTextField).

Leave a Reply

Your email address will not be published. Required fields are marked *