Dark interface themes are extremely popular with a small, but very passionate, group of Mac users. Sadly, since Apple introduced Leopard (Mac OS X 10.5), the old, relatively simple method of creating such themes on the Mac can't be used, and it took the theming community a good year and a half to figure out the current, relatively hobbled tools to theme the few bits of the interface that can be themed.

Given the weakened state of theming on the Mac, it's not surprising that the number of themes available has dwindled to a mere handful. And even those only go part of the way compared with what we used to be able to achieve with ShapeShifter. Still, the yearning for Mac themes remains strong among this community, and black themes are virtually nonexistent now.

Black themes have always been a challenge, because the frameworks used to build applications were designed to assume that text would always be black and the color of windows and buttons always light. Apple introduced a dark-theme paradigm a few years ago with its Heads-Up Display window style, which, with its translucent black background actually assumes that text will be white.

Starting with Leopard, developers using Xcode could tap into the HUD window style and use it whenever they want to, but most application windows aren't well suited to this, and Apple's user interface library still assumes that regular windows will be light, with black text. 

It's not only desktop applications that make this assumption. Web pages with button widgets also assume that the widgets will be light and their text black. On the Mac, it's becoming common for desktop applications to embed the WebKit for parts of their user interface—meaning that the button widgets are HTML- and CSS-based, not AppKit-based.

In addition to this basic problem, there's also the challenge of handling legacy applications based on Apple's earlier Carbon frameworks, as well as apps that are a blend of Cocoa and Carbon. Complicating this issue is that, as it turns out, applications built for the older PowerPC processor platform use a different part of the system graphics than those built for Intel chips.

If you try to design a theme that introduces black interface controls, you run into another challenge that has nothing to do with text. Many interface widgets use images rather than text to convey their purpose, so what if—as is usually the case—the application designer provides only black images for these buttons? Is a themer supposed to provide white images for every application a themee might want to use?

One specialized case of the images problem is the Mac OS X statusbar. Here, applications represent themselves almost exclusively as images, and nine times out of ten, the images assume that the menubar is light, so they should be black. Some enterprising themers have tried to solve this one by providing alternative white images for the most common statusbar applications, but usability can still suffer if someone using a black menubar launches an application that insists on putting a black icon up there.... one for which no white alternative exists.

Given all this, why would anyone undertake an effort to introduce a fully black theme for Snow Leopard?

I suppose it's because we Martians just can't step back from a challenge. Not to mention the fact that we, too, are afflicted with the passion for dark themes that many Earthlings suffer from. I also have a good starting point, having developed some useful techniques for the challenge through building CrystalClear Interface.

That said, the best I can offer still has compromised usability, which I detail below. But for the most part, I think I've succeeded in bringing to life a useable version of the legendary Cathode theme for ShapeShifter, in a redesign appropriate for Snow Leopard. The theme covers window backgrounds, background colors for tables and outline views, interface buttons, menubar, and text colors. It also coerces various types of windows to theme themselves in HUD style.

To acknowledge the theme's heritage, I've dubbed the theme Crystal Black. Crystal Black will be available for download soon, with a 15-day trial period and a purchase price of $6.00

It's important to note that Crystal Black and CrystalClear Interface can not coexist on the same system. You can't install Crystal Black until you uninstall CCI.

For my own documentation of this work, as well as to highlight the theme's strengths and weaknesses, the following list shows the various unique challenges I've faced in building Crystal Black and the solutions, if any, devised. Other challenges have been faced—and largely solved—in developing CrystalClear Interface, so I won't spend time on them here.

In the list, I've used a small graphic to indicate the degree of success in addressing each challenge:

★ Solid solution

☆ Partial solution

∅ No solution

• Images on buttons and in column headings ★
• Images and icons in the statusbar ★
• Text color of buttons in web pages ★
• Applications that use non-standard buttons and GUI frameworks. ☆
• Text color on Finder items with color labels ∅
• Cocoa applications that can't or won't take theming by Crystal Black ☆ (Problem solved 4/13/11.)
• Cocoa applications that are on the user's "Disabled Applications" list ☆

• Text color for control widgets ☆
• Color of titlebar and toolbar text ∅
• Window and control object background colors ☆

Cocoa applications

Challenges

• All images need to be made white, but without making custom button images for every possible application. Somehow, black images must be inverted as windows load.
• Some images are already "templates," easy to invert. However, other images look like "templates," but aren't, and making them templates isn't a reliable technique.
• Images with color (hue > 0) need to be distinguished from black/white ones. Knowing the image's color space doesn't help.
• Some images are "Core Image" images, which don't have a bitmap representation that can be easily analyzed. In this case, Crystal Black must create a bitmap representation in check it out.
• Images in column headings aren't buttons, so they require extra processing. In many cases, they change often so must be analyzed repeatedly. Some have proven inaccessible.

Solution

Each button and column heading in application windows are analyzed as they load to determine whether—and how—they require inverting. If inverting is needed, Crystal Black generates a new image and sets in place of the original.

Still, there are a few cases that haven't yet been addressed. One is the case where a pull-down menu contains an image. I hope to deal with this in a future update.

Challenges

• For nearly all applications that have a statusbar item and associated image/icon, the image/icon is black in normal state and white when highlighted. This means the image is unreadable against a black menubar.
• Unfortunately, the solution to the problem of images on buttons can't be applied to images and icons in the statusbar. In a few cases, the technique of inverting "template" images works, but applications with statusbar helpers that have invertable images are in a large minority.

Solution

Most of your applications that have a presence in the statusbar—including all of Apple's—must have custom-built images. In Crystal Black, these images are installed in the application's Resources folder, while maintaining a backup of the original images. Crystal Black also runs an inversion method that works in a few cases, but can't be relied on for most.

Challenges

• Requires digging through the page's document object model and checking for buttons. Technique for theming push buttons is quite different from that for pop-up buttons.
• Many pages use nonstandard button styles, themed through CSS, and these are much trickier to coerce into using white text.

Solution

Crystal Black installs a custom CSS style sheet, which can be used with browsers that support custom style sheets. In the case of Safari, Crystal Black enables the style sheet automatically. Although this works, it manages to destroy a lot of custom-designed buttons along the way...

Challenges

Many newer Mac applications have buttons that are subclassed from the standard Cocoa button class and therefore don't respond to theming. Similarly, various open-source frameworks for building windows and buttons are in use, with similar challenges to theming.

Solution

Unfortunately, since Crystal Black cannot convert such buttons to its dark theme, it must apply a custom modification for each application to ensure buttons are readable. This means that some apps will have buttons with white text, since they aren't accounted for in Crystal Black.

Challenges

• When the Finder is in column or list view, and these views have the dark background users normally prefer in themes like Crystal Black, the names of files and folders that have colored labels cannot easily be read.
• Despite numerous attempts, I have not discovered any method for changing the colors of these labels to provide ☆suitable contrast for white text.
• In addition, because of the way the Finder's file browser works, it's not possible to coerce a specific file or folder to use black text instead of white, when the item uses a label.

Solution

There is no good solution to this problem. To keep Finder's column and list views readable, Crystal Black prevents the background color for these views from darkening to the point that would trigger the use of white text. In other words, the names of files and folders in the Finder will always display as black.

Challenges

If a user disables Crystal Black for a specific application, the software no longer has a way to transform text or images from black to white.

Without some action, this would be the same as a user downloading the (free) Crystal Black system graphics files and installing them without the software: You wouldn't be able to read a lot of the interface elements.

Solution

The problem can't be totally solved. However, Crystal Black does three things to maintain usability. First, the CB filter module (which is what determines whether to load Crystal Black or not) installs a minimal set of color instructions before declining to load the core software. These colors keep text on buttons readable. Second, the old Extras resources files have a few text-color settings that still have an effect, and these take care of text color on segment tabs. Third, Crystal Black sets some specific defaults for the disabled application that prevent it from using a totally black window frame. These defaults are swapped out if the user re-enables the app for CB.

Carbon applications

Carbon applications are incapable of loading Crystal Black to any meaningful extent. However, some such applications have components built with the Cocoa frameworks, and these components will load Crystal Black (unless the app is in CB's disabled apps list). An example of the latter is Adobe Photoshop CS4, which itself is a Carbon-based lifeform, but may have plugins that are Cocoa-based. In this case, the plugin will load Crystal Black as long as Photoshop itself does not have CB disabled.

At the time of this writing, the Carbon universe is split into two difference species: Those that will only run on PowerPC chips, or under Rosetta on an Intel chip, and those that will run natively on both kinds of chips. The distinction is important, because the different species, it turns out, use different system resources for some of their graphics.

In any case, the challenge for affecting Carbon applications with a dark theme is that it must be done in the "old-fashioned" way—using the graphics files that used to enable theming in the age of ShapeShifter.

Challenges

How to enable white text on black buttons and other interface elements without using software or the post-Leopard system resources.

Solution

To a large extent, this is solved by relying on the pre-Leopard Extras resources files. Carbon applications make more use of these than Cocoa ones do, and Carbon apps that require Rosetta under Leopard make even more use of them.

Challenges

How to enable white text on the labels of toolbar buttons and on window titlebars, without using software or post-Leopard system resources.

Solution

No solution found. This is one challenge Crystal Black has been unable to overcome. Since toolbars are an interface element that's uncommon on Carbon applications, the toolbar label problem isn't a huge issue. (The only such app I use is Yummy FTP.) However, nearly all windows have a title, and it remains black against a black background.

Challenges

• The background colors of various objects on a Carbon window are drawn from ancient system resources that aren't straightforward to use and that can mix with unexpected results.
• The elements that must mesh to make a smooth, pleasing, darker-than-white color are nested, and some resources are used for more than one level in the nest.
• One complication that became clear from this exercise is that resources used differ between Universal-binary applications and apps that must run under Rosetta.
• The background color must remain light enough to provide contrast for both white and black text.

Solution

Ultimately, this goal required detailed mapping of resource "PPAT" (pattern) objects in the Extras files to observed results.  Thereafter, a good deal of trial and error was required to get the colors to mesh—for example, the background color of a "group box" nested in a "tab view", and the background color of buttons and other controls nested inside the "group box." 

I couldn't theme some elements to my satisfaction, however. In particular, I wanted the background color of a group box within a tab view to be lighter than that of the tab view. This isn't a problem, but, because the background color of objects within the group box use the same pattern resource as the tab view, the objects have a darker background than that of the group box itself. You can set distinct background colors of control objects that are inside a tab view from those that are outside the tab view, and of those that are in a tab view from those that are nested inside "secondary group boxes" within the tab view. But you can't do the same for objects within the tab view and those within nested group boxes.

    

• 
• 
• 
• 
• 
• 
• 
• 
•