Joris Kluivers

I like to build software.

Cocoa UI Spit & Polish

When playing with Interface Builder to create a UI for my application I sometimes run into the problem of trying to recreate a visual element used in Apple software. There are a lot of buttons and gradients used repeatedly in several Apple applications. When adding buttons with similar functionality I try to use the same artwork Apple uses for consistency.

The problem is that most of the buttons for example are custom designed by Apple and are not available by drag-n-drop in Interface builder.

So here is a collection of some images and custom classes that can be used for free in you application to add the spit and polish that makes your application look like a real Apple application. (Be sure to read the licenses for the specifics on copyrights).

An effort to give developers guidelines for replicated Apple interface elements was started under the name IndieHIG:
The IndieHIG Wiki is a place where developers and UI designers can come together to create a new set of Human Interface Guidelines to supplement Appleā€™s guidelines. Apple has neglected to update their HIG with modern UI designs and controls, so developers have been forced to replicate these UI elements on their own to keep their applications from looking dated. Since each developer has slightly different implementations of these elements, it has resulted in a fairly inconsistent look and feel for Mac OS users.

Maybe it’s an idea to provide implementations of interface elements that follow these guidelines? For example the Polished Metal page describes the properties of a currect Polished window, for wich an implementation already exists in the form of TunesWindow.

I’m currently working on an implementation of a RuleEditor as used by the Finder to create smart folders:

When finished I’ll document the properties of a rule editor in the IndieHIG and publish the sources of this class.



I would like to mention a similar open source project I am working on.

There is an example with NSTextField as the right expression but it virtually supports any control (stepper, date-picker ..) via the delegate object.
Mark Stultz
I’m still tackling the same type of thing. My rules need to support external plug-ins. These can add more entries to the popup lists, as well as other control inputs (additional popups, textfields, steppers, date-pickers, etc).

I need to dedicate some more thought on this, but I did decide against using the NSTableViews. I don’t believe the live-resize handles the way I want it do.
Joris Kluivers
I’m currently using my own NSView subclass, and another NSCell subclass that draws the rules and buttons within the rules. Probably not the best way to approach this, because I miss out on some functionality provided by NSTableView, but it does work.

I’m still strugling with the data structures for the rules created by the rule view. Any thoughts on how to handle this? I’m currently using a delegate for example that provides the searchable properties (nsarray of strings) that goes into the first popup.
Mark Stultz
I guess I should have stated the question was in reference to your Rule Editor.

I’m in the process of creating one. I’ve seen some implementations with table views, and so I’m curious if you are also purusing this route.
Mark Stultz
are you using a nstableview for this?