I’d like to take a moment to explain some things that seem to not be properly understood here.
Firstly, the reason that Leopard theming isn’t nearly as broad is because of the complete difference between the theming methods. I’m not talking about the theme resource files: I’m talking about the way the theme is applied. ShapeShifter themed your system by changing code at runtime so that applications used images provided by the themer, drawn as specified by the theme, instead of the system-provided content. That is why ShapeShifter relied on the Application Enhancer, and did not simply work through system file replacement. It is worth noting that this was not a requirement for Tiger theming, as it is in Leopard: in Tiger, file replacement offered a complete theming solution.
At first, one of the major problems holding back developers from making a ShapeShifter equivalent on Leopard was the lack of a functional replacement/update to APE (Application Enhancer. Without APE, a developer cannot write code to patch both Cocoa and Carbon apps at the same time. Well, that is not entirely true. There is a system known as mach_inject that can inject code into both types of applications. Using mach_inject is difficult, to say the least, as developers have to have multiple sets of code, one in C and one in Objective C (for Carbon and Cocoa, respectively), and then optimizing code can get even more complicated, as memory issues arise when sharing allocated space with code that developers cannot always predict. It is worth noting that the same memory issues arise when using APE as well.
Now that APE has been released for Leopard, there is a new opportunity for developers to create runtime theming systems. Of course, with the addition of the half-ass CoreUI framework, any code that was written for runtime patching in Tiger is no longer feasible for use in Leopard. Gnome developed a still-unreleased runtime themer, based off of APE, that can modify the titlebar gradient, controls, and text color. It is unpolished, and has huge memory management issues, thus it still hasn’t been released. Optimizing code that is used in every single application is an extremely difficult process, and thus very time consuming.
The reason that Kameleon 2.0 was never released was due to the difficulties that were being caused by the system-file-replacement system that we had started with as a base. Replacing system files is a permanently flawed system, and continues to show its problems as operating systems migrate to more code/vector-based interface systems. For instance, the entire HUD system that the system uses is drawn entirely based on code, thus replacing system files will never be able to theme those windows. After trying to find small workarounds for the existing file replacement system, and failing, gnome and I decided it simply wasn’t worth the time to continue working on a system that was so fundamentally flawed. We (and by we, I mean mostly gnome) began work on what was jokingly called the Kaped Krusader, which was, and still is, a barebones APE module which can, as I said before, edit the last two un-themeable elements.
It is also worth noting that in Snow Leopard, it is widely accepted that the base interface will be migrating from the intermediary ArtFile system, over to the fully vector-based system. The vector UI system is actually quite genius, and provides an excellent way of theming. UI elements are drawn based on “recipes” which tell the framework how to draw the control. If some amazing programmer could create a program that allowed designers to create a raster-based button, and then generate a recipe that would be compatible with CoreUI, that developer would have found the key to the continued theming of the operating system. But being able to decode the 10.6 versions of the artfiles really doesn’t matter, especially considering how simple is was to decode the Leopard artfiles. Don’t tell me it wasn’t, gnome wrote his own artfile decoder in about a week. ;)
I am still trying to find a way to move away from our dependence on Unsanity: not that I don’t greatly admire their products. They continue to surprise me with the quality of their work. Their issue is timing. They are finally releasing working copies of their software, right before the next huge OS upgrade. It is impossible to write an app that depends on something so very inconsistent. I’ve been considering using Infinite Labs' PlugSuit system for injection: but again, it is based off of mach_inject which will still break in snow leopard.
There we go. Feels good to clear some of that up.