Since Mac OS X Leopard (10.5) apple has dedicated API for these kind of things. And by writing “kind of” I’m going to quote the Apple developer documentation itself:

The Shared File List API is new to Launch Services in Mac OS X Leopard. This API provides access to several kinds of system-global and per-user persistent lists of file system objects, such as recent documents and applications, favorites, and login items. For details, see the new interface file LSSharedFileList.h.

Read on if you’d like to know how to add your app to login items list.

Getting login items list

First off – we’ll fetch login items to see if our app is already in that list. Well, at first it won’t be there, but it will pay off in the future, trust me. So here’s the code snippet for fetching existing login items and assigning them to an NSArray:

// Some seed data
UInt32 seedValue;
 
// Let's create reference to shared file list
LSSharedFileListRef loginItems = LSSharedFileListCreate(NULL, kLSSharedFileListSessionLoginItems, NULL);
 
// Then just pop values from referenced list into array
NSArray  *loginItemsArray = (NSArray *)LSSharedFileListCopySnapshot(loginItems, &seedValue);

You can now use this array as any table’s data source to see what this list contains. If you’re too lazy, then I can tell you that each item has “assigned display name, icon, and url as well as other optional properties” (quote from source code).

Now that we’ve got the list of login items – it’s really easy to add/remove our app to/from the list of login items. But for starters – we’re going to check for item’s presence in the list.

Checking for item’s existence

Since it is my first experience with login items and LSSharedFileList, from what I found on the net, I believe that main criteria is to check item’s url against given one. This code snippet shows how it should be done:

- (BOOL)loginItemExistsWithLoginItemReference:(LSSharedFileListRef)theLoginItemsRefs ForPath:(CFURLRef)thePath {
  BOOL exists = NO;  
  UInt32 seedValue;
 
  // We're going to grab the contents of the shared file list (LSSharedFileListItemRef objects)
  // and pop it in an array so we can iterate through it to find our item.
  NSArray  *loginItemsArray = (NSArray *)LSSharedFileListCopySnapshot(theLoginItemsRefs, &seedValue);  
  for (id item in loginItemsArray) {    
    LSSharedFileListItemRef itemRef = (LSSharedFileListItemRef)item;
    if (LSSharedFileListItemResolve(itemRef, 0, (CFURLRef*) &thePath, NULL) == noErr) {
      if ([[(NSURL *)thePath path] hasPrefix:@"/Applications/MyApp.app"])
        exists = YES;
  }
  return exists;
};

Adding an item to login items list

Method for adding an item to login items list is LSSharedFileListInsertItemURL. – method for inserting. This method accepts 7 parameters, but only 3 of them will be of interest to us. These are the accepted parameters:

1. Reference to login item list (created in the code above. Do not mix up with array of items)
2. Position of where to insert new login item. To insert item to the beginning of the list use kLSSharedFileListItemBeforeFirst. To insert item to the ending of the list use kLSSharedFileListItemLast. Otherwise pass LSSharedFileListItemRef.
3. Display name of new login item. Can be NULL. Defaults to app name.
4. Icon of the login item. Can be NULL. Defaults to app icon.
5. CFURLRef of item to insert. This usually is a path to your app (like /Applications/MyApp.app)
6. CFDictionary – dictionary of options for new login item.
7. CFDictionary – dictionary of options to clear if item already exists in the list.

The ones interesting for us are 1, 2 and 5. So the code for adding an item to login items list could be as follows:

// Reference to shared file list
LSSharedFileListRef theLoginItemsRefs = LSSharedFileListCreate(NULL, kLSSharedFileListSessionLoginItems, NULL);
 
// CFURLRef to the insertable item.
CFURLRef url = (CFURLRef)[NSURL fileURLWithPath:@"/Applications/MyApp.app"];
 
// Actual insertion of an item.
LSSharedFileListItemRef item = LSSharedFileListInsertItemURL(theLoginItemsRefs, kLSSharedFileListItemLast, NULL, NULL, thePath, NULL, NULL);
 
// Clean up in case of success
if (item) 
  CFRelease(item);

Removing an item from login items list

Method for removal of item in question is LSSharedFileListItemRemove. This method contrary to the one for adding the item to login items list accepts only two parameters:

1. The reference to login items list
2. The item reference in question

It could not get simpler than this:

LSSharedFileListItemRemove(theLoginItemsRefs, itemRef);

Conclusion

This is the first part of managing login items in Mac OS X. In next part I’ll show you how to keep track of changes while your app is not running and adding/removing your app to/from login items isn’t handled by your app.

Please note that I found code samples in one place on the internet but was too lazy to bookmark it, hence this code was extracted from the app. If you recognize your stuff – please post a note/link in the comments. Thanks a heap for reading this!

Then the light bulb lit above my spiky head. I present you with the solution:

// Place this code into your apps delegate class
+ (void)initialize {
  NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
 
  // initialize the dictionary with default values
  NSDictionary *appDefaults = [NSDictionary dictionaryWithObjectsAndKeys:@"fooValue", @"fooKey", @"barValue", @"barKey", nil];
 
  // and set them appropriately
  [defaults registerDefaults:appDefaults];
}

Now for refactored and more comfortable version you should use a separate plist for initializing user defaults. I believe it’s easier to add a row to plist file than add key/value pair into dictionary:

+ (void)initialize {
  // get the filename for "default defaults"
  NSString *defaultsFilename = [[NSBundle mainBundle] pathForResource:@"Defaults" ofType:@"plist"];
 
  // initialize a dictionary with contents of it
  NSDictionary *defaults = [NSDictionary dictionaryWithContentsOfFile:defaultsFilename];
 
  // register the stuff
  [[NSUserDefaults standardUserDefaults] registerDefaults:defaults];
}

The advantage of this approach is that even after updates to your app even unset defaults will be initialized (in case of newly added preferences).

That’s it! Kudos goes to Laurent Etiemble and Johan Kool for their answers to my question.

From time to time while programming you’ll have to draw custom window. If it’s more often than “from time to time” you’ll find yourself writing the same code again and again. Of course it’s easy to extract repetitive code into separate class and include that class in every project (or few times into the same project), but this still not the prettiest solution. Im suggesting you an approach that exploits XCode’s customization – template for custom class that you’ll be able to include into your projects anytime you need it. In this case – it’s custom NSWindow subclass.

So here’s how we’re going to achieve this:

1. Create project in XCode where we will code a template for custom NSWindow. If you are really good with Objective C – you can code our custom class in any text editor (TextEdit, TextMate) or in an IDE of your choice.
2. Create custom NSWindow class
3. Replace hardcoded constants (class names) with identifiers
4. Move created class files to a location where XCode can consider them as being custom template files

Creating XCode project

This part should be really clear. Create simple cocoa application project. Let’s name it “CustomWindowTemplate”.

Custom NSWindow subclass

Now we need to create the meat of our custom NSWindow class that will serve as template for future implementations. When I was googling around for custom NSWindow drawing I found this very useful and concise tutorial on how to easily draw custom NSWindow. I present you Matt Gallagher’s Cocoa With Love post “Drawing a custom window on Mac OS X“. I’d suggest to go through all of that tutorial for deeper understanding of how window drawing is done in Cocoa.

Once you’re done with the custom NSWindow class (you can download the prepared XCode project from the same tutorial page), you need to replace hardcoded class names with XCode identifiers, so that upon new class creation they would be replaced with your provided name.

Custom XCode identifiers

The identifier we are interested in most is «FILEBASENAMEIDENTIFIER». It plays the most important role as it’s the placeholder who’s value will be used for our newly created custom NSWindow class. Here’s the list of other interesting identifiers you may have a use for (like constructing the comment above the declaration of the class).

• «FILENAME» – the actual file name that will be created (will be substituted for both .h and .m files);
• «PROJECTNAME» – the name of the project you’re creating new custom window class;
• «YEAR» – pretty much self explanatory;
• «ORGANIZATIONNAME» – self explanatory as well. You can change that via defaults;

If you’re interested, the default one looks like this:

//
//  «FILENAME»
//  «PROJECTNAME»
//
//  Created by «FULLUSERNAME» on «DATE».
//  Copyright «YEAR» «ORGANIZATIONNAME». All rights reserved.
//

So the declaration of custom NSWindow class in our header template should look like this:

...
@interface «FILEBASENAMEASIDENTIFIER» : NSWindow {
...

Hence the declaration of the class in implementation template should look like this:

...
«OPTIONALHEADERIMPORTLINE»
 
@implementation «FILEBASENAMEASIDENTIFIER»
...

The «OPTIONALHEADERIMPORTLINE» identifier I haven’t mentioned is the one replaced with #import statement of custom class’s header file.

Now for almost-the-last step we need to create template’s meta-data file which is practically a simple plist with a few properties. Or you can just copy paste the following XML markup code:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>MainTemplateFile</key>
	<string>class.m</string>
	<key>CounterpartTemplateFile</key>
	<string>class.h</string>
	<key>Description</key>
	<string>A custom NSWindow subclass.</string>
</dict>
</plist>

All tags and values should be self explanatory: we define two template files (one is the counterpart of the other, like .m and .h) and add a description that will be shown in XCodes “New File…” dialog window.

Final destination

Now open up finder and go (⌘ + ⇧ + G) to ~/Library/Application Support/Developer/Shared/Xcode. Create a folder named File templates (if it’s not already there). This folder will keep your all custom file template categories as folders. Go inside that folder and create Cocoa Class folder. This folder will serve as a “category” for custom Cocoa classes. Now for the final destination go to that newly created folder folder and create another one named Objective-C NSWindow subclass.pbfiletemplate (mind the “extension” of the folder). This is the final destination for all template-related files. Now move template meta-data file (the plist) together with your header and implementation files to that folder. Just to check – your final path for files should be this:

• ~/Library
• /Application Support
• /Developer
• /Shared
• /Xcode
• /File templates
• /Cocoa class
• /Objective-C NSWindow subclass.pbfiletemplate

Note that your header and implementation files must be named class.h and class.m accordingly.

Now if you’ve done everything correctly – fire up XCode and create a new project or open up any existing one. After that – try adding new file to your project. In new file dialog you’ll see this:

Now press next, type a name for your custom NSWindow subclass and you’re good to go!

Things not included here

As you may have noticed in the tutorial – this one does not include content view that fills the transparent window. Well, it’s not here ’cause it’s impossible so far to create two files out of template while creating “New File…” in a project (we’d need to create the subclass of NSView to fill our custom NSWindow). At least if it IS possible – I’m yet to find that out. Or if you know – please feel free to share that with me in the comments.

But there is still solution for that – you can create custom NSView class that does some simple drawing and create a template out of it using the technique above (by replacing the classnames with identifiers and writing template meta-data file).

Things that’ve changed:

• Up to 10 items in history list (suggestion from Perspx).
• App is UI agent now (pseudo-background app). Activates via ⌘+⌥+⌃+B.

To download click this link: Change Background 0.0.2

Neato!!!

NSTimeInterval interval = [endDate timeIntervalSinceDate:startDate];

I presume you DO know how to get endDate and startDate object. Otherwise you shouldn’t be reading this. You’ll get the difference in seconds with fractions which is pure double. So you can do with it whatever you want. Feed it to some fancy number formatter, start countdown or what not. None of my business ,)

Oh, and btw, here’s a demo project for you to see this code in action: DateDifference XCode project.

Main snippet that does all the job is put in 7 lines of code:

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
  NSDistributedNotificationCenter *dnc = [NSDistributedNotificationCenter defaultCenter];
  [dnc addObserver:self selector:@selector(processNotification:) name:nil object:nil];
}
 
- (void)processNotification:(id)notification {
  NSLog(@"Notification: %@", notification);
}

So here’s another idea for another developer tool. Maybe there’s one that already exists, but it’d be really cool to have an app that registers all your your wanted notifications (either by name, app or any other parameter).

Had to google around for some tips and tricks. First results disappointed me much since they referenced usage of Carbon and AppleEvents. Oh yeah, and they were dated back to 2004 or so. Then one post here had what I needed: a ChangeBackground and a [private] notification.

After couple of hours of trial and error I came up with this application that you can download and try out. I think I’m going to work on this app a bit more so it’d become more decent product.

It’s so rough that I can’t guarantee it will work on your Mac. But here’s the requirements so far:

• Snow Leopard

Download and [try to] enjoy. Needless to say – I accept any feedback.

UPDATE: Perspx found a bug which I successfully reproduced and fixed. You can download updated version here.

[window center];

Note: it does not show your window on screen. This method only sets it’s frame to the center of the main (read – the one that has menu bar on top) screen.