Just committed my changes to the subversion repository.
A few new features and general stability improvements, but mostly a very thorough cleanup of the source code, so you can actually compile it now.
Compilation Instructions
Open Xcode preferences, scroll across to Source Trees and add one with a Setting Name of “QSFrameworks” and path of /Applications/Quicksilver.app/Contents/Frameworks/.
Then unzip Quicksilver.xcodeproj.zip, and open the Quicksilver.xcodeproj project in Xcode. Make sure you set the Active Build Configuration to “Release”. Click the Build button and you’re away.
Note: This build appears to be incompatible with the File Tagging plugin.
Given the Quicksilver source code is now out in the open, I’m trying to learn from it while at the same time cleaning it up. Here’s what I’ve done so far.
Continue Reading Cleaning up Quicksilver
Joe Dunn is doing a nice series of articles on Quicksilver. He’s covered triggers and scripts so far with more on the way.
One thing I disagree with, though, is the excessive use of the “do shell script” AppleScript. I like the “Run Command in Shell” action just fine. But if you want an icon, writing an Obj-C wrapper isn’t too much work. Especially since you have this source code.
I’ve also got a bit more on Quicksilver coming up shortly.
Unfortunately, [[NSApp currentEvent] modiferFlags] can’t be used to determine if any modifier keys were held down during launch. To accomplish this, it seems one must delve into the world of Carbon.
Continue Reading Modifier flags during app launch
While getting rid of extraneous junk in an application package is easy using Trimmit, the only way to prevent "code bloat" (and accompanying excess RAM and CPU usage) is through good programming practices. Where most developers fall short is in poor optimization of borrowed code. Let’s take CTGradient as an example as it’s well known and used (or more accurately, abused) in dozens of applications.
Continue Reading CTGradient code bloat