This is primarily a bug fix release. And I'm using it as a chance to get SCR included with FC. SCR install has now moved to be a part of UI instead of part of the FC PP.

If all goes well, this version will be shrunked (yes, I said shrunked) and released to the internets sometime early next week. I'm pushing out this release before I leave for Japan for 2 months Friday (the 4th).

When you first start up this version in an app with FAP sets enabled and inactive previews on, you should see an unsexy FontCard icon in the menu bar and a progress indicator.

Yvan Eht Nioj

If you have any crashing issues or stalls with this beta, please turn on logging in the FC preference pane, make the application crash, and email me the crash log and the console log (/Applications/Utilities/Console).

Version 1.3.2b2

• Fixed the icon for the "Global" entry in the preference pane.
• Changed a Crash Catcher for Macromedia applications as Marcomedia's lame use of Macrovision "protection" caused it to go crazy when enabling Crash Catcher.

Version 1.3.2b1

• Fixed a combinatorial speed hit when opening or scrolling a font menu with inactive fonts in it.
• Fixed a crash when opening a popup menu if FontCard was not ready for a menu to open yet.
• Fixed a problem that prevented inactive font previews from working if the name of the home folder differed in case (Bob vs. bob) from the name specified in NetInfo.
• Addressed an issue that would cause the FontCard menu to appear in places it shouldn't, especially in the various palette menus of Adobe Illustrator CS.
• Fixed a delay that could occur when opening menus if calculating the contents of their submenus was compute intensive.
• FontCard should now list FontAgent Pro sets that only contain other sets and do not contain any fonts themselves.
• Addressed a problem that caused some incomplete font items in a FontAgent Pro sets to slow down inactive font displays.
• The mark duplicate fonts option works again.
• Fonts are now sorted in all font sets except for Recents and Favorites, which are sorted by use.
• Fixed a problem in which the FontCard menu would be appended to the end of the font menu in some Cocoa applications.
• Increase compatibility with Macromedia Fireworks.
• Added support for Photoshop Elements (it is treated in the same manner as the regular Photoshop).
• Improved support for applications that insist on supporting bitmap only fonts (like Aachen) even though Mac OS X has very poor support for bitmap fonts.
• The Crash Catcher works correctly again and now catches crashes caused by corrupted name entries in a font.
• Addressed a problem in QuarkXPress that would cause the font menu in the Usage dialog to be disabled if the font menu in the menu bar had been opened beforehand.

Get it at: http://www.unsanity.net/beta/fontcard-132b2.dmg (3.57 megs)

Is this just me, or the Apple Aperture QuickTour features menu feedback sounds? ;) Which either means:

1. These sounds were added at the presentation editing stage to highlight the process of selecting menu items
2. Apple has added menu feedback sounds to Aperture
3. Someone at Apple who did the movie is using our own Xounds

Seriously, Apple should bring the interface sounds back, many people miss them (according to our sales figures, at least). Given that some sounds are in already ("Play user interface sound effects" in the Sounds preference pane), why not add in the rest? And hey, if Apple wants, we can help! ;)

What's your take on this?

The very recently released iTunes 6.0 (which still doesn't have an icon color change) is incompatible with Silk's font substitution. I've made available Silk 2.1.2 to fix this problem. The problem stems from some very, very old (few years old) code in Silk.

My bad.

Just wanted to make a quick note about my anger that Apple has removed FireWire from all iPods. That means you can no longer boot from them (to use them as easy, portable tech support drives) and the charging takes much longer with USB (including USB "2.0"). You also cannot daisy chain them to other devices (my iPod is currently connected to my external FW HD) Sigh. That extra mile that Apple used to go for Mac users is now gone. We've been regulated to be constrained by the least common denominator that is the PC. Especially since most Macs in the installed base don't come with 480mbps USB 2.0.

Get it at: http://www.unsanity.net/beta/silk-212.dmg (1.98 megs)

Later on, Apple released iTunes, and that basically killed Unsanity Echo. Interestingly, it also used the Library approach. Granted, it did it differently, and probably better than we did, and I don't know if they had any inspiration from Unsanity Echo, but still, it's an interesting point to mention. Unsanity Echo lived for a few more months, but after some time it became apparent it wasn't going to compete with iTunes.

Then we released Mint Audio, which was a lightweight player that had the same visualizations as Echo, but also had a small memory and screen real estate footprint. We still miss it, especially during these long winter nights.

Ah, a lot of stuff has happened in these years. We have updated our logo:

 

During these past five years, we have created quite a few products. We brought the term haxie to the scene. Some people love it, some people hate it, but the fact remains: with your feedback, we have been able to create software that helps people in their every day life. Most of it is pretty transparent, as it becomes a part of your workflow, so you don't really notice it is running until you somehow lose it.

The bottom line, we turn five on October 12. We wanted to celebrate this somehow, and say "thank you" to all of our customers. We will be giving a 50% discount on all purchases made on October 12 and October 13, 2005 if you use the coupon code UNSANITYFIVE. Note that the coupon will only work from midnight (EDT) of October 12 to the end of October 13. Use this opportunity to buy haxies you've been thinking of getting, or to present a license for our products to people you care about.

Again, thank you for all your support and contributions - we will surely try to impress you with something new in the future.

I was hanging out on the internets complaining about things as I always do. This time I was complaining about how the Safari downloads window doesn't track files if you move or rename them. I thought this was unacceptable since the Mac OS has always had an excellent method of tracking files. The problem is that these Unix/Cocoa programmers that are new to the Mac OS don't know about them or have no way of using them in their "preferred" API set. And they won't dare use an API that isn't their preferred one even if it gets the job done, does it a lot better, and presents the user with a much better experience. Anywho, I took these complaints somewhere and was basically told, by an engineer that will remain nameless, that I should just write a haxie to fix it. So I did. Since the Safari problem and the extremely lamely responded to Preview bookmark bug are the same core problem, I decided to tackle them both at the same time.

Both of these problems are similar to iSWAD in that they address a bug in Mac OS X before Apple could. In this case, I don't care if Apple obsoletes this piece of third party software. In fact, I yearn for it.

Safari

The Safari problem was a lot more daunting than it seemed to be at first. The problem with Safari is that it stores paths for everything, everywhere. The DownloadProgressEntry class has an instance variable of a DownloadFile instance. This instance then contains some paths. And there's a dictionary somewhere that contains the paths to files that Safari constantly queries to get a path. What I ended up doing here was patch the getting of the DownloadEntry*Path keys to look for an alias in the same dictionary prefixed with SPWW. I create these keys when Safari goes to save new downloads to its preferences file (~/Library/Safari/Downloads.plist). So then when Safari loads its downloads history, it gets the aliases along with it, and when it asks for the path keys, I redirect it to the alias keys and resolve the aliases then to get a path that it is expecting. Really simple.

The hard part was attaching an alias to DownloadFile instances. I can't add an instance variable to the class. So I ended up creating a new global variable that used the pointer values of the instances of the DownloadFile class as keys. Using the pointer value instead of the instance itself was done so that there would be no recursive retains. So I could patch the -[DownloadFile dealloc] method to release the memory used by the alias that was being used to track the download file. I also had to patch -[DownloadFile setPath:] so I could replace the alias with one with the new path.

This was all working quite nicely and I begun to test it out. It backfired. My alias resolving was working too well. When you download a zip file or some disk images in Safari, Safari will automatically decompress them and throw the original in the trash or mount the image, copy the application of the disk image, and throw the disk image in the trash. Safari checks to see if the trashing was successful by seeing if the file exists at the path and expects it to not exist. The problem was that my alias tracking was updating the path to the file's new location in the trash. So I'd see errors that said "Cannot Move File" in Safari's download window. Argh. Luckily DownloadFile has a method that tells whether or not the file was moved to the trash. If this returns true, I delete the alias tracking information from the global dictionary. This fixed the problem and all was well with the world.

This fix only works for new downloads in Safari, not existing ones. For Apple to fix this bug, they'd have to add an FSref instance variable to DownloadFile and resolve that whenever the path is requested. And then whenever Safari saves these to disk, convert them to an AliasHandle. Then when loading, convert the AliasHandle back into an FSRef and initialize the DownloadFile with that. Make sure to check -isTrashed first!

Preview

Preview's a much funnier case (funny like a clown being blown up in front of small children). It doesn't use aliases to track bookmarks or the last page you had open in a document. So if you move a bookmarked PDF, you lose the ability to use the bookmark. As you can see from the previous link, this was reported to Apple. Some engineer said it wasn't possible. Everyone laughed in the previously described manner. And I got slightly ticked off.

The most amusing part about this is that NSDocument (the thing that handles basic document operations in Cocoa applications) actually uses FSRefs to track the document. So you can move and rename an open document in the Finder then go back to Preview and see that the window title for that document has properly updated itself. But all bookmarks for that document are now broken. Sigh. The other sad thing about NSDocument is that although it uses FSRefs to track files, it does it in a horrible way. Rather than resolve the FSRef whenever someone asks for a path, it updates the path whenever its owning window is brought forward. This is just pointless, really. There is no reason whatsoever to update it then compared to converting it to a path on a "just in time" basis. FSRefs don't have the larger overhead of Aliases either and, like aliases, they can still track files if moved or renamed. The only problems with FSRefs are that they cannot refer to files that don't exist and you cannot save them to disk and expect them to work when loading them back into memory. They are not persistent while aliases are.

What SPWW ends up doing for Preview is to patch out -[NSDictionary objectForKey:] with the same idea mentioned above as Safari. It checks another key in the dictionary and resolves the alias then, on the fly. The problem becomes the bookmark menu items, which are just... dumb. I have no other way to describe what is happening. It sets a represented object on the NSMenuItem. This object is just the path to the file. When it validates the menu item, it checks to see if this path is valid. Understand that this path is not attached to the dictionary at all. It is completely independent. SPWW sets an AliasHandle on the menu item instead and resolves that into a path when it is asked for (Preview still gets a path, it's just the correct one).

The tricky part about Preview is how it saves bookmarks. SPWW was correctly adding aliases to the bookmark, but Preview wasn't seeing that because it wasn't reloading its information to be in sync with the SPWW modified dictionary. So now SPWW just resets Previews' preference dictionary when a bookmark is saved. This works very well.

In order for Apple to fix this one, they'd have to create a new instance variable for PVPDFBookmarksController. It'd be an array that contained instances of a brand new bookmark class. This bookmark class would contain an FSRef and would be resolved and initialized the same was as the DownloadFile class should be in Safari.

End Thing

In a perfect world paths would never be used in software. They're evil.

Just like iSWAD, the source for SPWW is available. It also demonstrates some concepts used when writing APEs like context patching. This is when you patch something that isn't called a lot and patch something inside of that patch that is called way too often and finally remove the patch after the original returns. It also uses the method of providing a context (in this case a controller instance) so the inner most patched function has some idea of what called it so it can call functions that affect the controller. SPWW also demonstrates modifying the Info.plist of the APE Module so it only loads in two applications. It won't even load outside of Preview and Safari.

The linked disk image contains the source code and the compiled APE module. You'll need to download Application Enhancer to use the APE module (install it in ~/Library/Application Enhancers/, create the folder if it doesn't exist) and if you want to compile the project you'll need Xcode 2.1 or later and the APE SDK. Remember, you must log out if you are installing APE for the first time.

Download Safari/Preview Whine Whine.dmg (65k)

It's worth noting that Smart Crash Reports now store the crash logs it receives in a database and allows developers who has obtained an E-mail Ticket to view and search the crash logs they got online, all with nice coloring and highlighting (thanks to Timothy Hatcher of Colloquy fame for providing the scripts that I've tweaked around and expanded a bit).

Check out a live demo of the web interface or login with your E-mail Ticket (obviously, only the crash logs received since today will be in the system).

Smart Crash Reports remains free, and we're quite happy about the adoption rate. Don't forget to submit your SCR enabled product so it appears in the RSS feed and on the Smart Crash Reports homepage.

Thanks to all for your continued support!