|
|
|
|
November 4th, 2011
I’ve been quiet for a while – a lot has been going on both within St. Clair Software and around it. For starters, we’ve had a number of updates:
App Tamer is up to version 1.1.1 now, addressing compatibility with Alien Skin’s Photoshop plug-ins as well as improving on App Tamer’s own miserly CPU usage. There was one problem in particular that was interesting: When people update to Lion, there are often background or helper applications that are no longer configured correctly (components installed in /System or /Library are missing, for instance). This can result in startup applications launching over and over again. As a user, you often never see this, but if you look in your Console log, there are heaps of messages documenting it. Because App Tamer does some work each time an application launches, customers were complaining that it was using lots of CPU time – an investigation turned up this repeated-launching problem on their machines. App Tamer has now been tweaked to minimize the impact on CPU usage, but the solution is really to fix whatever’s broken on your system.
Jettison was updated to version 1.1 in the Mac App Store, giving you the option to hide its menubar icon and working around a bug in Lion (a bug in OS X, not Jettison) that delayed Jettison’s “it’s ok to unplug” beep sound until the Mac woke back up from sleep. Which, yeah, made the beep totally useless…
Finally, there have been some compatibility issues with Default Folder X, the worst of which actually caused some applications to crash. Versions 4.4.4, 4.4.5 and 4.4.6 addressed various problems that resulted from architectural changes in Lion and the corresponding adaptations in Default Folder X. So things are once again right in the Default Folder X world. The latest beta (more on that in the next post) closes the last issue that I’m aware of.
Posted in App Tamer, Default Folder X, Jettison | No Comments »
August 23rd, 2011
App Tamer 1.1 is now available! It reduces App Tamer’s own CPU usage to save even more battery and CPU power. It also corrects some compatibility issues with Lion to ensure that everything runs smoothly as you upgrade.
For more information, download links and an introductory screencast, go to the App Tamer page. The What’s New page lists the specific changes.
Posted in App Tamer, Lion | No Comments »
July 22nd, 2011
Well, more trouble has turned up on Lion, primarily with Carbon applications that have been released recently such as BBEdit 10 and Filemaker Pro 11. Default Folder X 4.4.3 was released today to address the issues, as well as a problem with Lion’s full-screen mode and several other less crucial bugs. You can grab your copy from the Default Folder X Release Page.
I’m finally heading for bed…
Posted in Default Folder X, Lion | 6 Comments »
July 18th, 2011
Today’s update of Default Folder X adds a couple of important fixes for everyone upgrading to Mac OS 10.7 Lion. We’ve tracked down a couple of bugs that could cause crashes of both Default Folder X itself and of applications that you’re working in. It’s very important that you update to this new version – there’s more information and download links on the Default Folder X Release Page.
Posted in Default Folder X, Lion | No Comments »
July 12th, 2011
App Tamer 1.0.9 is available, delivering compatibility with Mac OS 10.7 Lion. Older versions could crash when your Mac woke from sleep. This version also improves gaming mode by stopping Time Machine backups and Spotlight indexing – things which tend to cause annoying stutters because of all the disk I/O they perform.
Grab your copy from the App Tamer release page. If you’ve got an suggestions or feedback, don’t hesitate to drop us a note!
Posted in App Tamer, Lion | No Comments »
June 15th, 2011
Default Folder X 4.4 shipped this morning – finally! I’m very happy to have implemented some suggestions from Default Folder X users that add greatly to its capabilities:
1. Offline Favorites: Default Folder X now shows you favorite folders even when the disk they’re on is not available. If you click on one of them, the disk will be mounted if possible, and then the folder opened. This helps immensely if you do any work with file servers.
2. Preloading of Recent and Favorite folders: Default Folder X has to check to see whether folders are available and load their icons. Doing this ahead of time makes the menus drop down almost instantaneously.
3. Swipe left to go up a folder: Three finger swipe up or to the left to go up a folder – thanks for the suggestion Ben 🙂
And of course, there’s additional compatibility with Firefox 4, Chromium, Brother ControlCenter, Shimo and Neu; a new scripting verb; fixes for some pretty uncommon bugs (but important, nonetheless for the few people that encounter them!) and tweaks to hotkey handling.
Grab a copy from the Default Folder X Release page – the update is free for all registered version 4 users. One word of warning: If you downloaded a copy early this morning, go back and re-download and install it again. The first build that was posted (version 4.4(13515)) had some problems due to some Xcode funkiness. These were fixed in 4.4(13531).
Oh yeah – and it supports Lion too, though not fully yet. Sandboxed apps (TextEdit, Preview, and Safari’s plugin helper) don’t get Default Folder X with this release – that’s hopefully coming soon.
Posted in Default Folder X | No Comments »
May 6th, 2011
You may have noticed that HistoryHound can’t see your browser history when you’re using Firefox 4. The Firefox team used a new version of the SQLite database to store the history and bookmark info in version 4, and that new version actually uses a new file format. Here’s a pre-release build of HistoryHound that’s been updated to understand the new files:
http://www.stclairsoft.com/download/HistoryHound-1.9.9fc1.dmg
This will be released officially next week (both through our store and the Mac App Store) but we’d like everyone to download and double-check to make sure we haven’t missed anything. Please give it a spin and let us know if you encounter any issues.
Thanks!
– Jon
Posted in HistoryHound | No Comments »
March 30th, 2011
Thought I’d post about this little developer experience because it was incredibly frustrating and not at all obvious. Maybe this will save someone else the headache that I’ve been through.
Background: When preparing an application for release on the Mac App Store, you code sign your application, then bundle it into an installer pkg which is also code signed (using either Xcode organizer or the productbuild command line tool). When the application is installed, it gets extracted from that .pkg file, the user runs it, and it checks for a Mac App Store receipt. If there’s no receipt, OS X checks to make sure that the application is signed correctly, then contacts the Mac App Store to get your receipt.
Problem: This would all work for me as advertised except that when the receipt check failed, OS X would complain that my application wasn’t code signed, and therefore wouldn’t contact the App Store to get the receipt. From a user’s perspective, the app would just fail to launch.
I’d followed all the instructions. I double- and triple-checked to make sure the application was signed before I built the .pkg file. I tried building the .pkg using both the Xcode organizer and productbuild – they both worked with no problems or error messages. Yet when the application came out of the .pkg file on the other end, it was always unsigned! I deleted all of my certificates, regenerated them, and redownloaded them from Apple’s developer site (several times). I checked every step along the way in my build process – they were all working. It was incredibly frustrating because the signed app went into the ‘black box’ of the .pkg file just fine, but came out on the other end without its code signature.
Solution: After tearing my hear out for a while, googling for answers, and checking the developer forums, I finally tracked down the solution. I had a single image file in my application’s resources that had its permissions set to 640 instead of 644, meaning that it was not readable by everyone. That threw the entire game off – apparently when the installer unpacked the .pkg file, it ran into this problem file and either stopped short of installing the code signature, or invalidated the signature. Either way, the application it installed was useless. Simply changing the permissions on that one tiff file fixed the problem I’d been fighting with for days.
Soooo…. If your app builds and runs fine UNTIL you package it, and then comes out unsigned on the other end, check the permissions on the resources in your application. And Apple, please emit some kind of warning when hapless developers feed productbuild a file with the wrong permissions that’s gonna screw up the whole process.
Tip: There’s a really cool developer utility called Cong, written by Stephane Sudre. It checks your application for all kinds of minor errors, from localization goofs in .strings files to incorrect Info.plist entries to missing files in your package. I’ve contacted Stephane and checking file permissions is now on his To-Do list for Cong. If you’re a developer, get a copy of Cong – a simple drag-and-drop could save you a lot of time and trouble!
Posted in Development, Random Ramblings, Tips | 2 Comments »
March 29th, 2011
There are just two days left to purchase the MacUpdate Spring Bundle and save a bundle on App Tamer, Parallels Desktop, 1Password, Hands Off, DVD Remaster Pro, Mac DVDRipper, TehcTool Pro 5, and more. You get 10 apps worth $367 for only $49.99 – it’s quite a deal if you’re interested in even two of them!
Posted in Default Folder X | No Comments »
March 14th, 2011
This App Tamer update fixes compatibility issues with Parallels Desktop and the developer release of Mac OS 10.7 “Lion”:
In past versions, if you used App Tamer to pause Parallels Desktop, you’d get these annoying, 3-5 second pauses in mouse and keyboard input whenever Parallels stopped. This was due to the way Parallels handled the mouse and keyboard. App Tamer now only pauses the Parallels virtual machine processes and leaves the Parallels Desktop app running – that works around the issue and still cuts nearly all of the CPU use associated with Parallels. Thanks to the excellent tech support folks at Parallels who helped us find this workaround!
In Mac OS 10.7, Safari is based on WebKit 2, which does more ‘sandboxing’ of web content. It basically puts many tasks (like Flash plugins and JavaScript scripts) in separate processes. App Tamer already handled this sort of thing adeptly, but in 10.7, downloads are also done by a separate process, and that broke App Tamer’s download checking. This new release fixes that – if Safari is downloading something, App Tamer won’t stop it in the background even if AutoStop is turned on.
And finally, there are some new features and tweaks in version 1.0.5, as well. The list of stopped processes at the top of the App Tamer window gets a new contextual menu. This lets you easily turn AutoStop off for the selected process, or quit, force quit, or relaunch that app. Also, double-clicking an app in the list will activate it, and selecting it in the list will show it in the Details drawer so you can see more information about it.
If you’re already running App Tamer, you can get the new version using its “Check for Updates” command in the App Tamer menu. Or you can hop over to http://www.stclairsoft.com/AppTamer and download it from there.
Posted in App Tamer | No Comments »
|
|
|
|
|