Red Hat Diaries/006c

Freeze-Dried Nibs

No, you can't get them from a supermarket. They're in NextStep - Cocoa. And they're great. But this is going to take a bit of explaining.

Most programmers are familiar with certain elements of object-orientation, and one in particular called archiving. Archiving is the process of saving the state of an object to disk. An object is of course a collection of data variables and functions which act on those variables. Normally archiving is thought to save the data of an object rather than its functions, but in full archiving everything is saved to disk.

Programs with a graphical interface contain both traditional code and what are known as resources. Resources give the code its graphical interface: they're menus, windows, icons, cursors, and the like. When a program with a graphical interface loads, the resources have to somehow be united with the code so it all works. So far so good.

Traditional development environments for programs of this type have graphical editors to aid in designing the graphical interface: the windows, the menus, the icons, the cursors, and the like.

Windows are stored in a script form, with information about their placement on screen, their title, various attributes, and what kind of controls are to be found within: buttons, edit fields, scroll bars, and so forth.

Menus are also stored in a script form: menu bars are defined ('File', 'Edit', 'Help', and so forth), the menu items appearing on each are defined, and for each item a numerical ID is chosen which at runtime can connect the menu to the program code through messages, e.g. 'here comes menu item 3, uh - oh yeah, that means 'Open' - and so the code will generate a box for the user so a file can be chosen.

Icons and cursors are stored in pure graphical form, no scripts involved.

At runtime the code will have access to these resources through a number of so-called APIs - functions in the application programming interface. When it's time to show a window on screen, the code will initialise the window and get data from the running program to fill it in. Perhaps the user is configuring the application, and so when the window closes, the code must get the new settings from the window and store them somewhere.

Showing a configuration dialog on screen is a laborious task, involving setting up all the controls first, initialising their values, then watching for activity (did the user change a field, or click a button), then finally grabbing all of it when the window closes - reversing the process so to speak.

If the user resizes the window, the code has to catch the event and then intelligently reposition all the controls. Perhaps the editing area is supposed to extent for the full width of the window; perhaps the push buttons are always supposed to be in the upper right corner; and so forth and so on.

It's a lot of work, because traditional environments don't have freeze-dried nibs. Resources in traditional environments are static. They're only numbers and such. They have no life of their own. The system will load them for you, and they'll have identifiers and labels and captions and such, but they're lifeless. They do nothing on their own. You - the code - has to do all the work.

But with freeze-dried nibs, everything changes.

A nib is a NextStep file - a Cocoa file. It's created by Interface Builder - the resource editor. 'NIB' stands for 'NextStep Interface Builder'. You do things just like you would do in any other resource editor for any other platform. You create a window, you position it, you set its attributes, you drag controls onto it and set their attributes, and so forth. You create a menu and you fill in all its menu items. (You use separate programs to create icons and cursors and the like.)

But here's where the fun starts, for NIB files go a lot further. When you're designing your menu, you can drag from a menu item to a piece of code in your project, and say in so many words: 'when the user chooses this menu item, run that piece of code.'

If the item represents File - Open, then you can drag right from the Open menu item to a representation of the code that renders the file dialog on screen. Your code doesn't have to sit there, watching all the events come through, and wait for something to happen - 'user clicks that over there, not interested; user clicks something on the Edit menu, not interested; whoa, here comes a File - Open...'

None of that. You drag right from the actual menu item you're designing to the code that will handle it.

You can connect controls in the same way. For example, you can tell a slider to give its floating point value to a neighbouring text field every time the user drags it and changes its value; or you can tell the text field to notify the slider every time the user types in something new. The application code doesn't have to pick this up: it's all done by dragging stuff in Interface Builder.

Interface Builder's NIB files are namely archived objects. Everything you drag onto a window represents both the physical appearance (a button, a bar, whatever) and the code in the object which takes care of it. Once you've got everything on the windows or on the menus in Interface Builder, you connect everything.

The NIB files accompany Cocoa applications. When Interface Builder saves your files, it's not just saving the actual physical appearance of your graphical objects, it's saving the code in them, and it's saving the state of that code too. The objects are 'freeze dried' - exactly as you left them when you closed Interface Builder.

Did you reposition a window? It's noted. Did you connect a button with a drawer or a slider? It's noted. Do some of your controls have initial values? It's noted. And so forth.

When your application loads, all these objects come back to life - exactly as they were freeze-dried on disk. It's possible - no, it's more than that: it's not at all uncommon - to be able to write complete non-trivial applications without ever writing any code. All the code you will need is stored in your objects - the ones you see in your windows. They're freeze-dried.

The Microsoft Windows system for doing all this is paraplegic and sloppy in comparison, and it takes a lot of code to work, no matter what development tools you use. The Microsoft Foundation Classes are of little help here. No matter how much preparation with the graphical side of your program, it's still lifeless. You have to exchange data going in and coming out of windows. You've got tons of code all over the place.

Windows hit the big time in 1990. The real definitive breakthrough came in 1992. Cocoa/NextStep was already running in its present form in 1988, when the first NeXT workstations were sold.

1988. The year is now 2002. That's fourteen years. Fourteen years in which the rest of the world still hasn't caught on, or started trying to catch up.

If you want to be the life of the party, don't forget to bring freeze-dried nibs.

Click here »