The Liger Door Closes

I’m out. Unfortunately I don’t have the time to work on this any more. It sucks but I’ll get over it. But it’s OK, because I am willing to tell you my secret ideas on how to solve this cookie ;)

This is taken from the dev-art page:

This version includes the Xcode projects for both LigerDock and LigerMenubar. Please finish developing these projects, as I don’t have time to currently (final semester of uni). And I would love to hear about it too — the next time I see Leopard, I will have a new iMac with the real Leopard on it. Thanks to everyone who supported this, and thanks for all the comments. Cheers! (If you make any progress, please send it to me so I can put it up here).

The Menu Extras Problem

Right now, Liger works by setting the menu bar background to a very low opacity (5% to be exact) and displaying another image right behind the menubar. The lowest opacity the menubar background can go is 5%; any lower and menu items forget about their clickable area and only work if you click actual text. This method is the reason that full-screen apps have trouble.

I’ve figured out a dirty way to get flawless menu-extras with fully transparent backgrounds (but haven’t had the time to implement it). In simple terms it means themeing SystemUIServer so it has a transparent menu background. But it’s not that simple.

1. First we need to be able to monitor when ShapeShifter changes the skin variant, and therefore the theme files stored in it’s cache.
2. Then we need to make a copy of the required resources (including Extras.rsrc) and make a false HIToolbox.framework that contains those resources.
3. Then we need to patch SystemUIServer’s CFBundleGetBundleWithIdentifier function, so that when it asks for the com.apple.HIToolbox bundle, we return the local false copy.

This would most likely be best implemented in ShapeShifter itself, as it knows about the themeing stuff and the cache, so it could run inside of the app.

It would be possible to get it working for Liger, if and only if there was one theme variant, instead of four (you picky people)!

The Dock Problem

The current method to keep to the size of the Dock is by using the Accessibility Framework and polling for it’s size and position. This is crap. That’s why the animations are laggy. It just polls (10 times per second) and then resizes a window to that same position. It contains a custom View that redraws the Dock image.

The only ideas I’ve had on this are to somehow merge the ClearDock code and also patch a resize or redraw function somewhere, to draw our own stuff. But the problem with that is the Dock does a lot of stuff (like Alt+Tab lists and Dashboard) and you could potentially screw it up.

I’m quite smitten with Tiger now anyway. Cheers :D