Unsanity News
Application Enhancer 2.5b1 and APE SDK 2.5b1
As I was trying to explain in my previous post, APE 2.5 will not load any APE module that has not been explicitly marked as compatible with Mac OS X 10.5. See my previous post for reasons on why. We discussed the issue with some other APE Module developers and they agreed that old modules should be disabled. Especially since it's been over 2 and a half years since Mac OS X 10.4 was released and some of these APE Modules haven't been updated since then.
If an APE module cannot be loaded, for whatever reason, the APE Preference Pane will now show the listing why it cannot be loaded. The APE Prefpane now uses the same logic to determine why something won't load as APE itself. Previously, APE itself would have a bunch of undocumented checks and there would be no way for a user to determine why their APE Module wasn't working.
The SDK documentation has also been clarified to mention the APEBundleMessage callback is not called on the main thread. If you need to call functions that are not thread-safe, call them on the main thread using something like MPRemoteCall. Not doing so can lead to unexpected behaviours. It's been an issue in the past, which is why it is now explicitly documented.
Also, the SDK documentation now has a listing of all the Info.plist keys available to APE Module developers as they were never documented before and some are required for an APE Module to be loaded.
Added compatibility for Mac OS X 10.5.
APE now requires Mac OS X 10.4 or later and will not install on older versions of Mac OS X.
Application Enhancer will now refuse to load any APE module that is not marked as compatible with 10.5 on Mac OS X 10.5.
Addressed some problems with some unpatchables due to the wonkiness of the x86 ABI (Includes APELite).
The APE prefpane now shows why some APE modules cannot be loaded.
Removed all references to the Rosetta workaround as Apple fixed that bug in Mac OS X 10.4.9 and the workaround no longer has any beneficial results.
Worked around a prebinding bug in Mac OS X 10.4.10 and earlier that made APE treat some applications as if they were on the exclude list.
So here are the download URLs for the betas, finally.
Smart Crash Reports 1.5b2
The biggest change with this SCR 1.5b2 beta is that it now supports SCR entries in the Info.plist of bundles/frameworks (just like applications always could). This was designed specifically for things like Perian, Growl, third party QuickTime plugins, and various SIMBL plugins so they could get crash reports without having to include more code into their products. Such developers should read the Read me in the SCR SDK (installed on the desktop).
I am repeating this as I find it to be very important. Important Note: On Mac OS X 10.5.x, InputManagers must not be installed in the user's home folder (~/Library/InputManagers/) as it will prevent the InputManager from loading even if the InputManager is installed globally in /Library/InputManagers/ and meets all the requirements to load. If you are a developer installing an InputManager, make sure your InputManager is not in the user's home folder on Mac OS X 10.5.x and move it to the trash (FSMoveObjectToTrashSync()) if possible.
Updated to support Mac OS X 10.5
Now supports registering for SCR in Info.plist entries of bundles (Frameworks, QuickTime plugins, Photoshop plugins, Safari plugins, et cetera). Developers no longer need to call UnsanitySCR_RegisterMatchSpecifier() bundles (in most cases).
SDK: UnsanitySCR_Install now installs Smart Crash Reports with the correct permissions required to work on Mac OS X 10.5.
SDK: UnsanitySCR_Install now pretends as if SCR is not installed if it is installed inside the user's home folder on Mac OS X 10.5.x as Mac OS X 10.5 will not load SCR from the user's home folder. Behaves as before on Mac OS X 10.4.x.
SDK: Worked around a problem on Mac OS X that led to repeated calls UnsanitySCR_RegisterMatchSpecifier creating new entries in SCR's preferences when Mac OS X thought that two equal CFTypeRefs were not equal.
SDK: On Mac OS X 10.5.x, UnsanitySCR_Install no longer allows you to install in a non-global manner due to the new restrictions in Mac OS X 10.5.x. Behaviour on Mac OS X 10.4.x is unchanged.
Important Note: On Mac OS X 10.5.x, Smart Crash Reports must not be installed in the user's home folder (~/) as it will prevent SCR from loading even if SCR is installed globally. If you are a developer installing SCR, make sure SCR is not in the user's home folder on Mac OS X 10.5.x and move it to the trash (FSMoveObjectToTrashSync()) if possible.
FontCard 1.5.1b1
As I alluded to in my previous post. There wasn't much to do for compatibility with FontCard for 10.5, except the font panel. On Mac OS X 10.5, it's like they gutted the internals of the font panel without increasing (or decreasing) its functionality, which is normally quite a feat.
Please Note: FontCard 1.5.1b1 has not been "certified" for use with Adobe CS3 products (it should work, the worst that will happen is that it won't work). Furthermore, it does not work with Microsoft Office 2008 (the worst that could happen is explosive projectile vomiting). We have not yet acquired these products, therefore we have not tested them with FontCard. FontCard 1.5.x currently has a lot of code for Word v.X and Word 2004 to work around various "quirks" in Microsoft Office. I would not expect FontCard 1.5.1b1 to work with Microsoft Office 2008.
Added support for Mac OS X 10.5 Leopard v10.5 and later.
No longer loads Objective-C dynamically.
Updated to SQLite 3.5.4.
Now attempts to open third party font sets in read-only mode (possible thanks to SQLite 3.5.0). FontCard never intended to write to third party font sets, only read them.
Now sorts third party font sets in the font panel (10.5 only).
FontExplorer stores its database in a different location if your user home folder path does not begin with "/Users/". FontCard now loads FEX sets in these situations.
Installs a busy handler for FontExplorer sets. This should fix a race condition leading to an error if the FontExplorer application is in the user's login items.
Menu Master 1.4.3b1
Getting Menu Master to work was slightly interesting. Mostly because cocoa's menu manager wrappers now insert a menu item with a NULL title. They then set some attributes on it and finally set the correct title. This was causing Menu Master to misidentify a lot of menus in Mac OS X 10.5. This has been fixed.
Also, Menu Master had to work around a lot of bugs in Mac OS X 10.4 with certain types of windows. Either the bugs were fixed for those certain types, or the bugs remain. Either way, Menu Master still does what is correct for all types of windows.
Added support for Mac OS X 10.5 Leopard v10.5 and later.
Dropped support for Mac OS X 10.3 Panther. Menu Master now requires Mac OS X 10.4 Tiger v10.4.11 or later.
No longer loads Objective-C dynamically.
Removed calls to many deprecated APIs.
No longer scans menu items if their titles are NULL or zero length due to an issue cause by the inefficiency of Cocoa menus.
Potentially addressed an issue with Adobe applications losing custom menu shortcuts when switching documents or not listing all their menu items in the Menu Accelerator window. This required a lot more work than it should have.
Silk 2.1.4b1
Really nothing special about this Silk other than the pointless new feature to re-enable the Sub-Pixel antialiasing on the translucent menu bar in Mac OS X 10.5 without being required to modify system files.
Silk now runs on Mac OS X 10.5.
Dropped Mac OS X 10.3 support. Silk now requires Mac OS X 10.4.11 or later.
No longer dynamically loads Objective-C.
Moved a lot of code to the awesomely awesome CoreText APIs (10.5 only).
Adjusted some code so it can be moved to CoreText in the future.
Attempted to make Cocoa applications respect the baseline of a font when a custom theme font is used.
Note: Classic is not supported in Mac OS X 10.5 and the fonts in the Classic fonts folder will not be loaded by Mac OS X. You may have to adjust your Silk settings to address any missing fonts.
FruitMenu 3.7b1
Added support for Mac OS X 10.5 Leopard v10.5 and later.
Dropped support for Mac OS X 10.3 Panther. FruitMenu now requires Mac OS X 10.4 Tiger v10.4.11 or later.
WindowShade X 4.2b1
Added support for Mac OS X 10.5 Leopard v10.5 and later.
Dropped support for Mac OS X 10.3 Panther. Windowshade X now requires Mac OS X 10.4 Tiger v10.4.11 or later.
