This is an Apple store:

and this is a Mac store:

Now you know the difference, and I trust there will be no more mistakes.

P.S. Don’t even think about calling it the “iPod store”.

I just pushed an update to my YRKSpinningProgressIndicator projects on github. Eric Roccasecca (from Startly) was kind enough to send me a patch to improve a few things in the code.

I applied the fixes to both the CALayer-based and NSView-based versions of the project. See the diffs and commit messages here and here (respectively) for more details.

Thanks again to Eric for taking the time to send in the improvements. Also, be sure to check out the product where they are using it: QuicKeys 4 for Mac. I’m even in the credits in their About window.

This is just a quick post to let google and friends know how I solved a problem setting up the svn post-commit hook for Trac on Dreamhost. (As a side note, I noticed they just introduced a 1-click install for Trac, and I’m not sure if it includes the post-commit hook or not. I installed the old-fashioned way.)

The problem was that svn is run as a different user, and since I want to keep my Trac SQLite database file locked down (so only my user can read/write it), the post-commit hook script did not have permissions to do what it needed to do. The solution was to make the post-commit hook script just write the repo and rev number to an intermediate file, and then have cron run a script (as my user) that actually runs the Trac script every so often, using the args from that intermediate file.

I put this as the actual svn post-commit script (in the file ~/myUser/svn/myRepo/hooks/post-commit):

#!/bin/sh

REPOS="$1"
REV="$2"

# Just append this info to the log file
echo "$REPOS:$REV" >> /home/myUser/trac_projects/myProject/queued_post_commits.txt

It simply writes the repo and rev to the intermediate file. This log file has to be writable by the svn user, but it’s the only file that has to have relaxed permissions, and should be pretty safe to do so. Better than opening up your whole Trac project, at least.

Then, I added this to my crontab:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * ~/trac_projects/myProject/run-queued-trac-post-commits.rb

Which simply runs this script every 5 minutes, which does the actual processing of the queued commits. It lives at ~/trac_projects/myProject/run-queued-trac-post-commits.rb.

As a warning, I went a little overboard with logging of successes and errors, but didn’t get crazy enough to actually clean out those log files (especially queued_post_commits_done.txt). So, if you have a high volume of commits, you might want to improve that situation a bit. But it shouldn’t be an issue if you have relatively few commits, like I do.

Thats it. I hope this helps somebody out there!

[Update: June 2, 2009] I pushed a few fixes (sent to me by Eric Roccasecca) to the projects. See this post for more details.

I saw this question about different-colored spinning progress indicators come by on the feed of cocoa-tagged questions over at Stack Overflow a little while ago, and finally got around to putting up this response. I’m not sure if the original question was answered satisfactorily by using a UIActivityIndicatorView, but I hope my code can be useful to someone.

I have implemented two different clones of the spinning NSProgressIndicator, which can be drawn at any size and in any color. One is a subclass of NSView, and can be used on OS X 10.4, and the other is a subclass of CALayer, and can be used in a CoreAnimation-based project on OS X 10.5, and presumably on an iPhone (though I haven’t actually tested that yet).

I put the code up on github (both the NSView-based version and the CoreAnimation-based one), under the BSD license. They each include the spinning progress indicator classes and an example app showing how they can be used. The code should be pretty straight-forward. One caveat is that they might not be super fast performance-wise, but should be good for most uses.

Read on for some screenshots.

(more…)

A recent comment reminded me that I alluded to a way to call scripts when Cleaning a target in your Xcode project, as opposed to a normal “Run Script Build Phase”, which does not get run during a clean. So, here is how you do it. I admit, it’s a bit of a hack (in a good way, I like to think), but it gets the job done, and I couldn’t find any other way to accomplish this.

The trick is that you create a new “External Target”, and set that as a dependency of your main target. This External Target lets you run any script (if you change the “tool” from /usr/bin/make to /bin/sh) and, most importantly, will get run while Cleaning (with the $ACTION environment variable set to “clean”).

Read the rest of this post for detail instructions and notes.

(more…)