The main reasons I write in this blog are for the fame and the glory. These will come some day, won’t they? Running a close third is the fact that, as I accumulate entries in this repository, the articles become part of the “Internet Reference Book,” upon which we all rely for “instant and easy answers” to the problems that vex us.

I recently installed a piece of software on my blog that records the “referring site” for people who end up clicking their way onto my blog through another site’s page. It’s been illuminating to discover just how many of these visitors are sent by way of Google or other search engines. In these cases, the particular query the user entered is contained in the referral listing. It’s fun, though a bit disconcerting to see that sometimes people other than myself type “daniel jalkut” into search engines. I also get a lot of false hits – folks I feel sorry for. They were looking for “dog sweater.com” and AOL decided that this entry was the #1 hit. Rude awakening! I also gets lots of knitting hits, and the occasional Perl or UNIX nerd whose query happens to match something I wrote in my mostly Mac OS X-centric posts.

It’s really gratifying to see searches come in where I just know this was the pot of gold they were looking for. One of my most popular posts is the “Automatic Build Sub-Versioning in Xcode” entry. I get about 2-3 search referrals per day for this page, with queries like “subversion automatic build number” or “xcode subversion script.” This is very gratifying because I’ve often been that person searching Google, praying for an easy answer. I like to imagine the person stumbling upon my site and thinking, “Yes! Now I have time to watch Letterman tonight!”

By putting “gems” in my blog as I discover them or become aware of their relative uniqueness, I am also building an archive for my own future reference. If I’m at a client’s office and don’t remember the details of some particularly brilliant tip I posted to the blog, I can just search my own pages and come up with it instantly. Over time these answer boxes serve not only the internet at large, but us forgetful authors as well!

Today I was looking at some enhancements for my FastScripts utility, and I realized I could accomplish something very cool – if only I could get notifications from the system whenever the frontmost application changed. Hmph. No NSApplication or NSWorkspace notifications for this. What am I going to do? I searched the list archives at CocoaBuilder.com for “front process changed.”

A few items down the list of search results, I see an item called “Cheezy Hack To Get ‘Front App Changed’ Events.” OK, so I’m not the first person to run into this. Maybe this will help me out. Wait a minute. I’m the author of the post! It turns out that over a year ago, I figured this problem out. Before I had a blog to put bits of wisdom like this into, I would occasionally post them on lists like Cocoa-Dev.

This post is exactly the type of entry that might end up as a blog entry nowadays. A hard-won bit of wisdom that I want others to benefit from without having to work quite as hard. Thanks to Google and Cocoabuilder.com, it’s part of the Internet Reference Book, even though it predates my blog.

I took a look at my post. It started to ring a bell. I grabbed some of the sample code out of the write-up and searched my FastScripts project for it. What do you know? I’m already generating “front application changed” notifications in the application. I had to add this functionality to make application-specific keyboard shortcuts work. Doy hickey! All I have to do to leverage this into the new part of my application is add an observer for the NSNotification.

It’s amazing that I forgot this so quickly, but a powerful testament to the internet and the concept of personal “idea archives” that I was able to recover the solution so quickly.

Got a good idea? Write it down! Don’t write it down just anywhere – write it down in a Google-indexed web page. You’ll be grateful you did. And so will we!

How many times have you been bitten by the problem of moving a window in Interface Builder, for easier editing, and then neglecting to put it back before saving it? Sometimes this can pop up as an embarrassing bug when you realize that your preferences have been saving an appropriate location for the window, but now new users are seeing it pop-up in the lower left corner of the window. Where you left it the last time you edited it in Interface Builder!

One of the ingredients leading to this disaster is the relative difficulty of getting the window back to precisely where it belongs. Many times, a window is saved “centered” with the window autoposition springs set so that it will be centered on whatever screen the user has. But the tedium of getting it “back to center” can make you hesitant to move it to a more convenient position for editing. Worse, it can make it easy to “postpone” the act of putting it back where it belongs until you forget about it and ship that way.

Unfortunately, the amazingly useful alignment and centering tools provided in Interface Builder only work on view-level interface elements. They don’t work on windows. Wouldn’t it be nice if you could easily and quickly snap a window back to a centered position?

My Center Window script lets you do just that. By adding this to the Interface Builder scripts menu, you can easily bounce a window back to horizontal center at any time by selecting the script from the Apple Script Menu, or (better!) by pressing a FastScripts keyboard shortcut. I’m using Cmd-Opt-C to center windows in the blink of an eye.

Note: This script requires the Jon’s Commands scripting addition. If you don’t want to install that, you can modify the script to define the width and height of your main screen manually.

It should be pretty easy to modify the script to also position the Y-axis as you see fit.

Suppose you want to throttle the rate at which a continuous NSSlider sends its action. To save you from the same fate I met, I will talk you through some of the avenues you might pursue, and ultimately describe the simple solution I adopted which is both easiest and is the only solution I know of that actually gets the job done.

Searching the documentation, you might discover the very intriguing “getPeriodicDelay:interval:” method of NSCell. The description of this method in the Apple documentation is as follows:

Sounds like a winner! Sigh. It’s not.

The problem, as I’ve deduced after several hours of beating my head against a wall, wondering whether I am in fact not cut out for a programming career after all, is that “continuous” means two distinct things, depending on the type of NSCell you are dealing with. The documentation rarely addresses this, and even misleads us with documentation like this where outright promises are made about the relationship between “continuous actions” and the periodic delay attribute.

The two categories of continuous controls in Cocoa are “periodic” and “send on drag”. Hints at this distinction in the documentation are few and far between, but if you look in the description of NSCell’s “sendActionOn:” method, you’ll see this line (emphasis mine):

What does it mean by this? It means that controls whose cells are continuous in a user-driven nature, like a user tweaking a knob or pushing a slider, shouldn’t send their value continuously when the user is not … uh, tweaking. Controls like NSButton, which are simply pressed as the user tracks them, need some stimulation for the periodic send: a periodic timer. Controls like NSSlider can rely on the user to move the mouse when the action needs to be sent.

Unfortunately, what I’ve discovered is that the timing of “send on drag” controls is completely un-throttled. The control’s cell appears to send out actions as fast as the user can generate drag events. If drag events were only generated every pixel or whatever, that would be fine (* See End of Entry), but drag events come pouring through your application as the user makes the slightest nudge of their pointing device. Depending on what you’re doing in your slider response, this might be highly undesirable.

Ideally, I would expect that “send on drag” cells should also limit their sending to the interval identified by the getPeriodicDelay:interval: method. “Send on drag” cells should be an optimization of “periodic” cells, not a completely new implementation. This would make all of Apple’s documentation correct. As it is, most of Apple’s documentation having to do with “continuous controls and periodic events” is pretty misleading if not downright incorrect.

Working Around the Problem

It turns out that this problem can be worked around in a pretty simple way that doesn’t even require subclassing the associated control cell. It’s too bad that the documentation was confusing and nothing worked like it said it would(*), but now that I’ve come to this solution, I’m happy it’s the simplest of them all.

Instead of limiting the frequency of the “send” action, just nip it in the bud. Whenever the cell for your control ultimately decides it’s ready to send an action, it goes through the sendAction:to: method. By subclassing the control and placing a date throttle on the method, you can achieve whatever throttling you feel is appropriate.

Note: Several readers noticed a shortcoming in the original version: the final value was often not sent because the throttling prevented it from being sent when the “expiration date” had not yet arrived. Special thanks to Jack Nutting for observing that a quick check of the current event type would solve the problem nicely. The only reservation I have about this is whether there are automated ways of manipulating a slider that might not involve mouse ups and downs. Does anybody know if this is possible?

The code below has been updated to include a check for this “final value” condition. Let me know if anybody spots other problems that should be remedied!

	static NSTimeInterval kTimeBetweenSends = 0.2;	// 1/5 second

	- (BOOL)sendAction:(SEL)theAction to:(id)theTarget
	{
		BOOL handleEvent = NO;
		
		// Always send action when the mouse comes up. This means that the final 
		// send is probably coming through, which we don't want to miss!
		if ([[NSApp currentEvent] type] == NSLeftMouseUp)
		{
			handleEvent = YES;
			
			// We also want to clear the "next time" so 
			// we start fresh if the user quickly clicks again
			[mNextSendTime release];
			mNextSendTime = nil;
		}
		else 
		{	
			// Only pass actions on if we're not waiting for a throttling date to pass
			NSDate* nowDate = [NSDate date];
			if ((mNextSendTime == nil) || ([mNextSendTime compare:nowDate] == NSOrderedAscending))
			{		
				handleEvent = YES;
			}
		}
		
		if (handleEvent == YES)
		{
			handleEvent = [super sendAction:theAction to:theTarget];

			[mNextSendTime release];
			mNextSendTime = [[NSDate dateWithTimeIntervalSinceNow:kTimeBetweenSends] retain];
		}
		
		return handleEvent;
	}

So if you find yourself in my position someday, my advice is this: ignore Apple’s documentation on this issue and implement something like the above instead. Easier to subclass, easier to inject, and it actually works.

Update: If you’re inside Apple and are wondering whether I wrote a bug or not, here it is: 4365583.

* Update 2: When I said it would be “OK” if it only sent the value when the pixel changes, I was wrong. It’s not OK. In fact, that’s what it does. Kudos to Apple! But… it’s still not OK. I don’t want the changes as fast as the user can move the mouse. That’s too fast! My need for this subclass still stands, though the argument about the pixel-based notifications is null.

Scenario

If you’re developing software with Xcode, you’re familiar with the typical process of adding a new source file to your project. You hit Cmd-N, and then either navigate or typeselect to the desired file type. Usually, if you’re a Cocoa programmer, this means getting past all the AppleScript, BSD, and Carbon templates you don’t give a rat’s ass about. Even if you use the disclosure triangle to “close” those sections, they’ll reopen the next time you open the dialog.

Wouldn’t it be great if all the file types *YOU* care about were at the top of the list, beckoning you to instantly select them and get on with your job, hobby, or ascetic pursuit of nirvana?

Here’s a trick I discovered that allows just that: place a custom category of templates at the top of the list, with symbolic links pointing to all the desired items in their proper home folders. The best news? Xcode chooses the name of the template for the dialog by the name of the file, so you also rename the link to accurately describe the template in question. For instance, there are templates called “C File” in both BSD and Carbon sections. By linking to the items but renaming the link, I end up with a clear and useful Favorites section that works best for my current workflow:

Note that because the templates in the “Design” section are not true templates, there is no way that I know of to include them in the Favorites section. These items must by dynamically injected by Xcode, because they are not represented by “.pbfiletemplate” files, and include a custom UI in the New File assistant dialog.

Step by Step…

Just so it’s exceedingly clear how this is done, I’ll describe the process as a series of simple steps:

1. Create a Custom Favorites Folder
   To get your folder to show up above all the other categories, you’ll want to name it so that it sorts alphanumerically early. A trick I’ve used is to insert a space before the word, to make sure it sorts early. The following example shows how you might create the required folder from the Terminal:

   % cd ~
   % mkdir -p "Library/Application Support/Apple/Developer Tools/File Templates/ Favorites"

2. Find Existing Templates to Link To
   Unless you have existing custom templates in your home directory, you’ll find that all the templates worth linking to are located in Xcode’s File Templates folder. Navigate in the Finder to this directory (Cmd-Shift-G): “/Library/Application Support/Apple/Developer Tools/File Templates/”. You should be looking at a a list of folders in the Finder, each containing a number template items. Items ending in “.pbfiletemplate” are templates folders. These folders are what you want to link directly to.

3. Add Links to Favorites
   The easiest way to add links to the Favorite folder is to open up a Terminal window, change to the Favorites directory, and use Drag-and-Drop to easily drop in the full paths of templates you want to include. Type “ln -s “, then drag in the pbfiletemplate folder you wish to add, hitting backspace a few times to remove the trailing slash. After your link has been created, you can rename the link to avoid naming collisions with other templates, or to increase the clarity as you see fit. For example, here are the commands I used to add the “BSD C File” template to my list of favorites:

   % cd ~/Library/Application\ Support/Apple/Developer\ Tools/File\ Templates/\ Favorites
   % ln -s /Library/Application\ Support/Apple/Developer\ Tools/File\ Templates/BSD/C\ File.pbfiletemplate
   % mv C\ File.pbfiletemplate BSD\ C\ File.pbfiletemplate
   

   Note: Unfortunately, Mac OS Aliases do not work. You must use a link. I recommend symbolic links because a hard link would not allow you to rename the link as described above (without also renaming the original). (Update: 12/20/2005: Kyle Dean points out in the comments that this is not true. See the comments for discussion.End update.)

Summary

Adding a list of favorites to the Xcode file templates will only save you a few seconds here and there, but the clarity of focus and satisfaction that your tools are working for you and not against you can improve your productivity and increase your desire to work. Enjoy!