You Can’t Fire Me, I Don’t Work In This Van

After a few hours of playing around today I have the Duality 5 engine running great on Intel. Here is a screenshot from a friend’s machine.

Under CPU Features, you can see SSE and SSE2. These are features only present on Intel processors.

A few things to note:

• This is a patch based theme engine. I did not swap out the Extras2.rsrc.
• The theme is Applewood by Androo. It was imported from the original tpark (everyone thank Androo for providing this ), and imported into Catalyst on my Powerbook. The resulting .skin file was sent to an Intel box running a beta version of Catalyst 0.75. The beta version of Catalyst sent the theme into it’s Theme Preview application, which is powered by Duality 5’s engine.
• The theme preview application is an Intel native, it is not running in Rosetta.
• The OS version is 10.4.5.
• The only thing changed are the PXM’s because I wanted to test one resource type before I went revising the other resource types. It’s about a 15 minute job a resource type.

For proof I’m submitting this Extras2.rsrc file. Manually applied to an Intel Machine, it will change the theme to Applewood. It has been byteswapped by my ThemeKit framework (the core of Catalyst and Duality) to work on Mac OS X for Intel.

http://homepage.mac.com/gomac/Extras2.rsrc.zip

As proof the theme application is being done without manually swapping the file, I will release the theme preview application with the next release of Catalyst. It will theme the theme preview application without making any changes within the /System directory of the computer.

I am not interested in releasing a theme changer right now (too much support work). However, in the interests of the community, I am issuing a challenge to Unsanity. If Unsanity does not release an Intel native version of ShapeShifter by April 30th (which is reasonable considering this took me 2 hours to do), I will either a) release this as an Intel native theme changer that can theme any application, or b) release the source to change themes natively on Intel using PowerPC created themes. Again, this is an effort to get Unsanity to support Intel Macs, which would benefit the entire community.

Edit: Just noticed? A challange? And Bri or I didn’t catch that…. : shakes head :

…hopefully for tomorrow.

Catalyst 0.75 is made up of a few things thats were originally meant for the 0.8 release. Given that there are some critical bugs currently present in 0.7, I don’t want to wait all the way until 0.8 to fix them. As a result, some 0.8 features will be released early.

• Unable to remove an application skin - will be fixed in 0.75 This is a leftover from when Catalyst went from using variations as the primary paradigm to using appskins. I just forget to change over this block of code.
• Overzealous app database creation - will be fixed in 0.75 I’ve received some feedback that people wish that Catalyst would just import things from /Applications initially to reduce first load time. This has already been fixed on my end.
• Manually adding/removing app skins - will be fixed in 0.75 This also will be fixed. A tab is being added in the preferences to manually add and remove applications to Catalyst’s skinning database.
• Importing an image from an image editor “destroys” the original image - will be fixed in 0.75 This was unintentional. Importing an image from an image editor should not cause the original image to be rendered in CoreImage. Editing the image in an image editor should be independent of changes made in CoreImage in Catalyst. Already fixed in an internal build.
• .tpark editor skips appskin in tparks - might be fixed in 0.75 .Tparks do not hold enough information for Catalyst to assemble a theme using them as a source. In order to make appskins from tparks import I have to cross reference against the app database Catalyst assembles.
• iTunes skins in DLTA files do not work - might be fixed in 0.75 I’ve already made the internal fixes for this. We’ll see if I actually get time to update the DLTA spooler code.

It’s day two of our Catalyst beta launch and the response has been fantastic! Thanks everyone for giving Catalyst a try. Originally I was going to wait until 0.8 for our next release but I’m prepping an 0.7.5 which should fix a few bugs (has anyone tried deleting an application skin yet?), and clean up the preferences. It will also add support for manually adding and removing app skins.

The more success we have with Catalyst, the more likely we are to decide that releasing other theme software is a good idea. Maintaining a theme changer is quite a bit of work. I’m still a full time student, and I have to pay the rent somehow. And we aren’t eager to deal with undocumented formats whose owner really doesn’t want us reading his themes, and who’s idea of compatibility is a buggy transcriber application that makes using the format in question horribly unwieldy.

The more themes that get released, and the less proprietary things get, the more we’ll look forward to blowing your socks off with other theme software.

It seems from going over some of the forums there is confusion on Catalyst. Catalyst cannot apply themes onto your system. Catalyst is for theme creation. It can create themes to be used in a hopefully forthcoming Intel version of ShapeShifter. Catalyst, comparatively, is like an Intel version of ThemePark.

In short: If you want to create cool looking themes on your Intel Mac, Catalyst is for you. If you want to use cool looking themes on your Intel Mac, bug Unsanity.

In addition: Themechanger DOES conflict with Catalyst. This is a known bug. If you want to run Catalyst with ThemeChanger, you must revert to Aqua before launching Catalyst. Catalyst needs to build it’s Aqua database from the original files on your system, and ThemeChanger overwrites all the original Aqua files (ShapeShifter does not).

Also, if you are running a *cough*unofficial*cough* Mac OS X box, Catalyst is known to get very upset on 10.4.1-10.4.3 if you do not have OpenGL support on your system. To deal with these issues, I have enable software rendering mode in the OpenGL code, but if you don’t have an OpenGL supported card, you’re unsupported. Not that you’d be supported if you had an unofficial box anyway (go buy a real one, really).

If anyone has any bugs please submit them to our bug tracker at:
http://whitemagiclabs.com/bugtracker

Be cool and open an account. Then I can pair up bugs with people, and you can look at bugs we already know about.

The porting process for Catalyst went something like this:

(I compile and run Catalyst in an Intel development lab on the first floor of WWDC)
Me: Hey, these images look wrong. I bet bad endian stuff is happening.
Dave: Looks like the pxm header is being mixed up because it’s written in big endian.
Apple Employee: Look at these snazzy new functions we added to fix this issue!
(15 minutes later after putting NSBigShortToHost in strategic places in ThemeKit)
Me: Hey! It works. These Intel boxes are sure mighty fast.
Dave: That they are!
Me: Hey… How do we tell which endian a resource file is?
Apple Employee: Oh, we’re not going to change those. They’ll always be PowerPC endian.
Me: Huzzah!
(Six months pass)
Me: Curses Apple!

So why did themes work on 10.4.1-10.4.3 x86 just fine? Why did Apple create a second resource file in 10.4.4? This probably has something to do with the way Apple protected OS X from being loaded on generic PC’s. There was a big internal change in 10.4.4 (hint: this change lifted the requirement of SSE3 for running OS X on a generic PC for most tasks… SSE3 is required for one thing specifically…)

So how does Catalyst deal with endians? Each resource has a value inside it titled “endianness”, which either contains “TKIsBigEndian” or “TKIsLittleEndian” (as of now it defaults to TKIsBigEndian). It’s up to each resource class to make sure it’s probably endian-ified. The base TKResource can’t tweak the resource data for endian issues automatically (this may be addressed in the future). As I settle on ways to best handle the endian issue, I will start releasing ThemeKit source drops. As of now, it just works (TM). The handling of it in the file format won’t be changing, it’s the API handling that’s in flux. It’s possible to create a getResourceData:withRange: method in TKResource that automatically byte swaps.

Any outgoing resource files in DLTA files are PowerPC. Period. DLTA will stay PowerPC. It’s the changers job to automatically byte swap. Any outgoing plain .rsrc files will follow this standard, but because the handling of endianness inside the ThemeKit API is still in flux, Catalyst .7 won’t feature a .rsrc exporter.

Duality 5 has been ported to Intel, and as such the theme preview will also launch on Intel. However, because we don’t generate Intel endian rsrc files yet the theme preview application will just crash on launch. This is a known bug and will be addressed by Catalyst 0.8. Until then, a solution is to force Theme Preview into Rosetta.

Back to working out a binding bug before I release Catalyst 0.7.

http://whitemagiclabs.com/forums/

It was the home for our private Catalyst testing forum. Sadly it was never used. Now it’s open to the general public. Maybe it will now be used.

Yes, if you haven’t already guessed it, we’re about to leap back into the theme market.

Catalyst has been our in development theme editor for a very long time. In fact, the first builds date back to 2002. The first idea of Catalyst came about in 2001 (yes, this is a very old program). Back then I had just written XMorph, which has the dubious honor of being the first theme changer on Mac OS X. I had been talking with one of the theme creators at the time and he came up with the crazy idea of not only theming the Extras.rsrc, but the login window too. I told him that it wouldn’t be much of a problem and added the code to do it. Well, quickly more items were added to the basic theme format of the time and it became too complex to build themes by hand. While themers were using Sprocket and Theminator (yes kids, this is before ThemePark) to edit the Extras.rsrc, there was still no nice front end to packaging up a theme once you had created it. This was done all by hand by making the bundle from scratch. So, I threw together a quick packaging program called “Theme Builder”, which was met with rave reviews on VersionTracker. (One memorable quote from a reviewer was that if I was a woman he would sleep with me).

When Duality first began development, themes on OS X were facing several issues. The largest one was that 10.1 had just come out, and applying a 10.0 theme on 10.1 was known to bring the computer to it’s knees and cause the blue screen of death. Not fun. The second of which was every themer had decided the hip and cool thing to do was to make a version of their theme for every color under the rainbow. This was also a mess.

So, I designed a format to take care of both these problems in one fell swoop. The DLTA format was designed to be interoperated. This way the theme could issue one set of directions for one operating system, and an entirely different set of directions for another. It also had a slight hack so that you could load more than one theme into the same bundle. I titled this “variations”, and the concept lives today in every other theme format and every other theme changer.

The problem was you couldn’t expect everyone to learn how to write in this new scripting language. So, the idea of a theme builder was resurrected. The hot new program at the time was ThemePark, but ThemePark lacked any sort of packaging at all. Again, it was just a bare resource editor. So, the idea of Catalyst was born. Catalyst would be were theme creators would start their theme. As they went they could import and create files, and Catalyst would package the files for them. In addition, Catalyst ran side by side ThemePark, with Catalyst handling the packaging, and ThemePark handling the resource editing. Double clicking a resource file in Catalyst opened the resource file in ThemePark. (As a side note: Adam Betts volunteered to do the icon for Duality 3.1. Along with doing a new icon for Duality, he did one for Catalyst. Because Catalyst and ThemePark were designed to work side by side, he also did up a new icon for ThemePark last. This formed the trio of icons. Duality had the theme changing icon. Catalyst had the packaging icon, and ThemePark had the “building the resource file” icon. Sometime afterwards Adam Betts left the theming community, and at the least, the original Duality and Catalyst vector icons were lost, leaving us with only the 128×128 exported ones.)

The original build of Catalyst, running alongside ThemePark on 10.1. (Click to enlarge)

ThemePark gained a DLTA exporter, and built in support for variations, before Catalyst was ever released though. This made Catalyst redundant and Catalyst was never released. Duality 4 would come and ThemePark would be the primary editor, supporting the ill fated XScheme format out of the box (XScheme was one of those things where I woke up one day and decided “Maybe XML WOULD be a good idea”). The positive thing was out of XScheme came ThemeKit, our standard API for working with themes.

If this were all to the story it would be a very boring story and I would lose the readership I don’t have. Fortunately this isn’t the end of the story.

When Duality 4 had come up we had licensed several bits of ThemePark’s source for the changer, and Jason was charging us for a royalty of the code. The compiled framework he sent us was very small. The fee he was charging us for that code was relatively large based on the size of the code (In hind site, the whole agreement was a very dumb move). So, it was decided that an in house resource editor had to be created in secret. This meant we wouldn’t have to license bits of ThemePark anymore, we could make more profit, and we would have a theme editor if we ever decided ThemePark was holding us down. We set to work, and it wasn’t too long before we had something working. (It was significantly longer before editing worked, but display wasn’t too hard).

A theme editor became more important when the Themer project adopted our open source ThemeKit framework as their base. The ThemeKit platform now needed an editor. However, XScheme had proven itself to be a stillborn format, and ThemeKit’s format was scrapped. In addition, ShapeShifter had arrived was eroding at Duality’s user base. ThemePark could no longer be used as the default editor for the ThemeKit platform.

So, we started on ThemeKit version 2.0. ThemeKit 1.0, to put it bluntly, sucked badly. ThemeKit 2.0 was vastly improved. First, the API was restructured to be fully object oriented, unlike ThemeKit 1.0’s parser design. This meant, when you loaded a theme into your program, you were given an entire object tree to work with, right down to resource objects. With this new structure, we embedded our resource editing code right into the ThemeKit 2.0 API. PXM resources in the object tree contained the code necessary out of the box to be rendered and edited. We were pretty excited about this. The idea of working with a theme as an object tree instead of a messy query based system was pretty cool on it’s own. We also beefed up some of the more traditional aspects of theming. Theme’s now used full HTML for their descriptions (with preview pictures depricated).

Building the API for a new theme format (at that time known as XScheme2) was the easy part. It didn’t take long for us to get Duality 5 running on the new API. But designing a new theme creation program was a problem.

We started playing with interfaces and ran into walls everywhere we went. Finally I settled on something sort of like XCode.

Catalyst for XScheme. What were we thinking? Microsoft Task Based Catalyst? (Click to enlarge)

This is better I suppose. Looks… complicated… and… brushed… Don’t we have any other themes? (Click to enlarge)

Ahhhh… this looks a little better. Not great yet. This is probably late 2004 or early 2005. App skin templates my ass… (Click to enlarge)

By early 2005 I had decided the name XScheme2 would be ditched and we’d just call Catalyst’s format .skin. The format wasn’t done developing yet. In fact, for all the trouble that went into making it, it would never be used. More on that later.

In June we waltzed into WWDC, into the keynote, and were told by Steve Jobs that the entire Mac platform would be switching to Intel, which also would break our theme changer we were working on. Great. But how would our ThemeKit API fair? ThemeKit contained all our theme editing code, and Catalyst was built on top of it. That night we went into the Intel lab, and with the help of a few quasi-unwitting Apple engineers, had ThemeKit ported over within an hour. Catalyst, because it was built on ThemeKit, became one of the first 3rd party applications running on the Intel Mac platform (even though at the time it wasn’t a pleasure to look at.) While ThemePark still is not Intel native, Catalyst has been Intel native, quite literally, from day 1.

WWDC was also when the XScheme format was killed. After sitting through the whole series of CoreData presentations, I decided that CoreData seemed much more suitable for building a theme format on than XML. I set about rewriting ThemeKit on top of CoreData, so that our theme format would be CoreData based.

Mid way through the week we got a visit from the Unsanity gang (by “we” I mean Carpe Stellarem, the software group I was part of at the time). They asked if we had anything, and not wanting to show off any of our GUI stuff (at that time I had done major work on getting CoreImage themes working, while Unsanity didn’t have any CoreImage based changers.) So, I set about getting Duality running through the command line so that I didn’t have to open up the Duality application and expose any features. While I struggled to get Duality running through the command line on the loaner iBook I had (my untrusty 15″ Powerbook was in the shop), Unsanity eventually lost interest and wandered off. They never knew that we had an Intel native theme editor running on that machine and the Intel box we were sitting at, and I had assumed Jason Harris had already ported ThemePark over to Intel. After all, it was an hour long port for us. Why would an Intel native theme editor be anything special? Of course to this day, ThemePark still isn’t Intel native…

As the school year rolled back around I became extremely busy. Our theme changer was dropped as I was the only one with interest in it and I didn’t have time for it. Catalyst didn’t die however. The testers were still eager to see it. A lot of people weren’t happy with ThemePark and wanted an alternative. So, work continued.

I was still unhappy with Catalyst’s UI. So I went back for one final review. With the recently released Aperture as inspiration, I came up with something like this:

Hey, this looks kinda hot (Click to enlarge)

I’ll talk about other cool stuff we’ve put into Catalyst after the official release, but here is what it looks like as of tonight with only a few icons missing:

The near-release UI as of tonight (Click to enlarge)

One thing I will mention about the GUI is one thing I did was add the preview image in the resource table. This means you know what the resource looks like before you click on it. A lot of time is wasted in ThemePark’s gui looking for images and not finding them.

Speaking of ThemePark, I’ve had ShapeShifter reject a DLTA exported from ThemePark tonight. After I tried importing a non-resource based one ShapeShifter crashed. Now it crashes every time it launches. These are empty DLTA’s… exported from ThemePark. Don’t even get me started on DLTA’s exported from Catalyst. Irony is when ShapeShifter lectures me on files in a format I designed. I’ve taken to calling ShapeShifter something else tonight.

Well, last time I wrote my optimizing for Intel entry the Intel chips hadn’t actually been released yet. Instead of getting HyperThreading chips we got full blown dual core processors.

Another tact to take in optimizing for dual core processors isn’t necessarily a technical one as much as it is a physiological one. In document based apps, don’t leave situations in which one document ties up the entire application. Thread nicely so that an intensive application only locks up the document it affects. This leaves the user free to edit another document utilizing another core, increasing productivity. There are a lot of applications which could make good use of this (I’m looking at you [insert Adobe app here]).

It used to be dual cores was reserved for high end Powermacs. At that time, threading wasn’t as efficient, only really used in keeping the UI redrawing as normal. I’m surprised when the switch to Intel was announced more people didn’t start looking at threading. Intel CPU’s are famously deficient at handling large amounts of data at once. They simple choke when lots of operations are being thrown at the CPU. Dual core CPU’s give you the advantage of Intel’s very fast speeds, while solving the issue of the CPU choking by giving the programmer the ability to use multiple CPU’s. It’s an overall win.

I know… I missed the date. With any luck we’ll do this Friday instead of last Friday. Bri came to town, I had a final… so I took a bit of a break. It’s nearly ready, tonight I’ve been redoing any code that’s shaky and fixing any interface issues.

Don’t despair. We’re working on it.

Apple hater verification check
rev 2.3

[ ] Called Apple users “fags”
[ ] Used “OS/X,” “OSX,” or “OS-X” instead of OS X
[ ] Used the word “overpriced” while ignoring previously published price comparisons
[ ] Described a Mac as “cheap PC parts”
[ ] Vaguely accused iPod users of falling for marketing
[ ] Confused install base with market share
[ ] Referenced Xerox Sparc
[ ] Referenced “Pirates of Silicon Valley”
[ ] Posted list of fictional cliches in a Slashdot discussion to avoid discussing a point
[ ] Used the words “evil” and “DRM” in one sentence
[ ] Gave someone else credit for an Apple innovation
[ ] Made fun of a Switch commercial
[ ] Ignored a valid point in favor of bashing Apple users
[ ] Made a one-button mouse joke
[ ] Made reference to “white plastic”
[ ] Called 99 cents “too expensive”
[ ] Victoriously made reference to Microsoft’s monopoly market share to avoid addressing a point
[ ] Referenced a “lack of games” for Mac despite all big-name titles having Mac ports
[ ] Pretended that normal computer users actually want to have to build an entire computer by themselves piece by piece, have knowledge about every transistor in the machine, and hand-tune C code for any piece of software the user might have an issue with
[ ] Ignored when someone mentions that you’re not a mechanic and didn’t build your own car either
[ ] Used the word “cult”
[ ] Ignored that Apple was the first consumer GUI with built-in audio and graphics while PC users were staring at C:\> for the next 15 years

BONUS
[ ] Claimed to hate Apple yet drooled over running OS X on generic PCs

(Shamelessly stolen from here: http://apple.slashdot.org/comments.pl?sid=179695&cid=14880918)