« A new blog, for a new Mac developer.
Where have the months gone? »

iLifeControls 1.0

Finally, the first release of my iLifeControls framework is available! Currently, there aren’t any samples included in the distribution, but using the classes is simple enough. One thing to note is that by default, the framework is built to be linked internally, so when you add it to your project, be sure to create a build step to copy it into your bundle’s internal framework directory.

Right now I’d like to take the time to talk a little bit about why I started this framework, and what I’d like to see from people that use it in their projects. The main reason I decided to take a set of controls that mimic the iLife interface and combine them into a framework is to provide developers with a one-stop shop for their Apple-style interface needs. Looking at the third party Cocoa applications floating around on the Internet, it’s common to see applications that mix and match interface schemes taken from several different types of Apple products, as well as interface components that aren’t quite implemented properly. In order to try and remedy this situation, I’m trying to create a framework that’s geared towards proper implementation, and interface consistency. All of the controls in this framework will be modeled after the iLife applications (you won’t see any ProKit elements in this framework), and a lot of effort will go into making sure they behave as the user would expect them to.

I hope that by providing developers with a free solution to getting the look and feel of Apple’s iLife suite, I’ll be able to help eliminate some of the inconsistencies between third-party applications’ interfaces, and give developers the opportunity to produce more professional looking products. I ask that if you do use this framework, please don’t mix and match control styles from other Apple product lines. For example, mixing a ProKit style HUD with an iLife style main window would fall under this category. I created this framework because I want to help maintain a level of distinction between different types of applications, and to prevent the confusion that could arise for a user moving from one application to the next, realizing that an interface component from one piece of software resembles that of another, but has a completely different function. Keeping interface schemes consistent gives the user a sense of familiarity, and ultimately makes our software more easy to use.
But enough philosophical crap; here’s the source code.

Let me know if you include the framework in your project, and I’ll put together a list of apps that use it.

This entry was posted on Thursday, September 28th, 2006 at 2:21 am and is filed under Development, Cocoa. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

37 Responses to “iLifeControls 1.0”

  1. Michael Tsai - Blog - iLifeControls 1.0 Says:
    October 5th, 2006 at 5:43 pm

    […] Sean Patrick O’Brien (via Matt Gemmell): […]

  2. Tony Arnold Says:
    October 5th, 2006 at 7:02 pm

    Hey Sean, want to turn these into an Interface Builder palette? I’d be happy to give it a swirl - I’ve just started doing something similar for non-iLife Apple-bizarro controls (like the label button in the get info window). I reckon it’d make using this framework a lot easier spacer Shoot me an e-mail if you’d like to head down this path.

  3. Gus Mueller Says:
    October 5th, 2006 at 7:35 pm

    What, not even a screen shot? Throw us a bone! spacer

  4. Gus Mueller Says:
    October 5th, 2006 at 7:36 pm

    Oh geeze- I spoke too soon. I guess that’s what you previous post was about.

  5. Mike Ross Says:
    October 6th, 2006 at 10:42 am

    Hey Sean,

    As I was in the middle of writing such controls for my app, I throught I’d check yours out. Looks interesting. With the very little testing I’ve done, your NFIWindow class needs to handle the customize toolbar runtime support. If I use your window in my nib, run the app and choose customize window, things get quite messed up. Just a little nit.

    Mike

  6. sean.patrick.obrien Says:
    October 6th, 2006 at 10:47 am

    Currently, NFIWindow doesn’t handle toolbars at all, so it’s not just confined to customization. I’m looking into making the controls resource-independant at the moment, and will look into toolbars next. As iLife apps don’t have standard toolbars, this wasn’t really a priority in the first release. If you look at iLife apps like iPhoto, the toolbar is actually down at the bottom, and isn’t done using the standard API (this is another control i’m working on).

  7. Mike Ross Says:
    October 6th, 2006 at 1:30 pm

    Yea, noticed that spacer Appreciate your efforts sean.

  8. sean.patrick.obrien Says:
    October 7th, 2006 at 2:33 pm

    I’ve done a little bit of work on getting toolbar support. It’s a little rough around the edges right now, but hopefully i’ll have a working version up in a day or so.

  9. Chris Long Says:
    October 7th, 2006 at 8:36 pm

    Looking great man, thank you for this.

  10. Drew Hamlin Says:
    October 7th, 2006 at 9:49 pm

    Hey, this is pretty nice looking. Good work. I was surprised not to see a build target for a sample app (like the one in your screenshot from the previous post). You should totally put that in for those of us who like instant gratification. spacer

  11. Wolfgang Ante Says:
    October 8th, 2006 at 6:39 pm

    Very nice, thank you for the effort!

    One thing I noticed: The window does not ask the delegate if it should close (i.e does not call windowShouldClose:). I use this to say no and then smoothly fade out the window myself. But that’s easy to add, just thought I’d let you know.

  12. Frank Lloyd Says:
    October 15th, 2006 at 5:45 pm

    THE COWS ARE COMING! AHHHHHHHHHHH

  13. Greg Says:
    October 16th, 2006 at 6:44 pm

    Hi,
    Can you email me so I can send some enhancements your way. Are you planning a public svn repo?

    Thanks,
    Greg

  14. Colin Barrett Says:
    October 26th, 2006 at 6:27 am

    Very cool spacer I wonder how much overlap there is with your work and the OpenHUD stuff?

  15. EB Says:
    October 27th, 2006 at 6:45 pm

    Hi,

    I can’t get the frame at the bottom to work. (NFbr). I’m trying to import the file to Interface Builder but get the following error: “Interface Builder cannot find the superclass of one of the classes found in this header file.” It seems that NSGrayFrame.h is missing when i built the framework?

    PS: I’m new to Cocoa programming

  16. Mike Says:
    October 30th, 2006 at 11:04 am

    Whoa! Nice work. I’ll definitely be checking it out!

  17. orta Says:
    October 31st, 2006 at 8:12 am

    Hi, I’ve just been messing with your framework, very nice! However, I’ve not yet managed to get the frame at the bottom to work, similar to EB. Here’s my work in progress; iLife Vienna. Can you give any pointers at how this can be added?

  18. sean.patrick.obrien Says:
    October 31st, 2006 at 2:08 pm

    If you’re having trouble getting InterfaceBuilder to recognize NFbr, you just have to drag the headers for NSFrameView, NSTitledFrame, NSThemeFrame and NSGrayFrame into IB and it should be able to work with NFbr.

    As for getting the bottom bar, you currently have to do this in code. NFbr has two methods, setBottomBarand setMiddleBarorigin: which you have to call. The NFbr class includes a middle bar which isn’t visible in the screenshot i’ve posted, but it’s similar to the middle bar in GarageBand, which is visible when the loop browser is open.

  19. orta Says:
    November 2nd, 2006 at 12:18 pm

    Thanks! For clarification (because I’m sure more people might be interested) its just a matter of literally setting setBottomBarHeight on the custom NSWindow class, silly me for not reading the provided source codes spacer finished

  20. Jonathan Saggau Says:
    November 5th, 2006 at 11:39 pm

    Haven’t been able to find your email on here. Perhaps the NyQuil running through my veins… I was hoping to send you a patch. I hope blog comments will do!

    Anyhow, during a shark session with a small app of mine, which I have “skinned” with your (seriously awesome!) controls, I noticed a lot of string comparisons. As it turns out the (id)frameworkImageNamed:(NSString *)name method is actually faster (for me) when I comment out the “check to see if we’ve already loaded this” code. I assume that cocoa is caching each image for you, so it only goes out to disk once for it. The act of checking if there is an [NSImage imageNamed:name], is actually slower (due to the string compare) by far than just letting cocoa grab the image again (or whatever is is *really* doing behind the scenes).

    To clarify. The code below is faster for me in a very limited project. Surprising.

    //
    // NSImage FrameworkImage.m
    // iLifeControls
    //
    // Created by Sean Patrick O’Brien on 9/25/06.
    // Copyright 2006 Sean Patrick O’Brien. All rights reserved.
    //

    #import “NSImage FrameworkImage.h”

    @class NFIWindow;

    @implementation NSImage(FrameworkImageAdditions)

    (id)frameworkImageNamed:(NSString *)name
    {
    // if([NSImage imageNamed:name])
    // {
    // return [NSImage imageNamed:name];
    // }
    NSBundle *bundle = [NSBundle bundleForClass: [NFIWindow class]];
    NSImage *image = [[[NSImage alloc] initWithContentsOfFile:[bundle pathForImageResource:name]] autorelease];
    if(!image)
    return nil;
    [image setName:name];

    return image;
    }

    @end

  21. Jonathan Saggau's Blog Says:
    November 5th, 2006 at 11:42 pm

    implicit HIG: toys from others…

    As apparently have a number of other developers/bloggers, I’ve been reading and thinking about the implicit HIG since John Gruber spoke on the topic at the C4 conference. It seems the consensus thus far is: 1. Apple isn’t likely to……

  22. Silverfish123 Says:
    November 6th, 2006 at 12:04 am

    I would love these as an Interface Builder palette, anyone considering coding one?

  23. wpsept06 Says:
    November 6th, 2006 at 5:16 pm

    Dont delete this comment - wpsept06

  24. Vacuous Virtuoso » Blog Archive » iLife Controls; HUD windows and more Says:
    November 10th, 2006 at 8:15 am

    […] Sean Patrick O’Brien, a fairly new Cocoa developer has recently released an iLife Controls framework. This allows you to create HUD Windows and controls such as buttons, sliders, popup menus etc. and also a smooth metal type window (again with controls such as buttons and frames). […]

  25. malcom Says:
    November 11th, 2006 at 12:35 pm

    Is possible to make a sort of NSBrowser/NSTableView as HUD control? Is it difficult?

  26. Fancy Windows, &c. « Important Shock Says:
    November 20th, 2006 at 4:19 pm

    […] Lately, inspired by John Gruber’s recent assertions that the Apple Human Interface Guidelines are no longer relevant (a good summary can be found here), the new, fancier widgets made by various Cocoa developers have come into the spotlight. Daniel Jalkut, a Very Cool Guy, developed a bunch of very nifty widgets while revamping the interface for his unbelievably cool application FlexTime, and was so kind as to blog about his thought process while doing it. His blog entry pointed me to Matt Gemmell’s enormous stack of custom-made widgets, replete with shiny screenshots. My interest piqued, I fired up Google and found Sean Patrick O’Brien’s iLifeControls framework, a class-dumped version of Disco’s Smoke framework, Toxic Software’s Toxic Progress Indicator and TXTableView, Chad Weider’s badging and gradient code, Blake Seely’s BSRoundedBox, Andy Matuschak’s Polished Metal buttons, AMViewAnimation, and OpenHUD framework, Andreas M.’s jaw-dropping amount of custom widgets, Erling Ellingsen’s CGSWindowWarp exposé, John Pannell’s PSMTabBarControls, Uli’s freakin’ plethora of awesome doodads, Rainer Brockerhoff’s RBSplitView, and Ankur Kothari’s CoreGraphics framework. […]

  27. Jonathan Saggau Says:
    November 25th, 2006 at 10:54 pm

    No NyQuil this time, but I did find a little behavioral problem. Using an NSToolbar works only if you don’t resize the buttons within dynamically. Changing NFbr.m to the below fixes this. It looks like you had [self titleBarHeight] there at one time and then hard-coded the number 25. Perhaps this was a debugging thing that you forgot to change back? (I do that all the time).

    - (NSRect)contentRectForFrameRect:(NSRect)frameRect styleMask:(unsigned int)aStyle
    {

    frameRect.size.height -= [self titleBarHeight]; //25
    return frameRect;
    }

    - (NSRect)frameRectForContentRect:(NSRect)windowContent styleMask:(unsigned int)aStyle
    {

    windowContent.size.height = [self titleBarHeight]; //25
    return windowContent;
    }

  28. sean.patrick.obrien Says:
    November 26th, 2006 at 3:10 am

    It’s hardcoded at 25 for drawing/control placement. I’ve been too busy with school lately to work on this much, but I seem to remember having issues where an interface similar to iTunes can’t be recreated unless the value returned by titleBarHeight is smaller than the drawn titlebar.

  29. Jonathan Saggau Says:
    November 26th, 2006 at 11:22 pm

    The change above looks great in my app (which has an iTunes vibe, I guess). Without it, the user changing the size of toolbar icons caused problems. Great framework, by the way. Very clever how you’ve subclassed apples frames. spacer Cheers.

  30. Nick Brawn’s Weblog · Coding is Hard Work Says:
    December 5th, 2006 at 8:27 am

    […] Much of my work, specifically in the interface arena has been helped immensely through the use of publically available source code. Specifically, I’ve been using iLifeControls (interface controls), Omni Group’s Appkit (gradient tableview), BLAuthentication (simplified authorization for running command-line programs as root). I’ve bookmarked more code to look into down the track, including the Sparkle framework for automagically updating your application (think RSS for app updates). […]

  31. Eloy Duran Says:
    December 5th, 2006 at 4:29 pm

    Could anybody that’s using a toolbar explain to me how to set the fillcolor of the NSToolbarView to transparent,
    so that you’ll just see the toolbar items on the gray background?

    Thanks in advance,
    Eloy.

  32. Eloy Duran Says:
    December 5th, 2006 at 4:47 pm

    As always I find it after first searching for a long period and then posting a question….. spacer

    Anyways, if anybody runs into this; in interface builder, you need to check the “Unified title/toolbar look” checkbox
    for the nswindow that will hold the toolbar.

    Eloy.

    PS: Nice framework btw!

  33. Thomas Says:
    January 2nd, 2007 at 5:36 am

    Has anyone succeeded in creating a palette for the interface builder with these controls? I’ve tried to use them by adding the iLifeControls framework library to my project and then, in interface builder, changed the custom class of my main window from NSWindow to NFIWindow. But this doesn’t make my window transparent. Neither in IB or at runtime. Am I missing something?

    Cheers

    Thomas

  34. Mac Developer Center, Bulgaria Says:
    January 17th, 2007 at 5:18 am

    Thank You! Very great framework, everything is clear and userful. We use it in database application called DIR.

  35. Mark Alldritt’s Journal » Faster iLifeControls Says:
    February 8th, 2007 at 1:05 pm

    […] I’m working on a project that uses Sean Patrick O’Brien’s iLifeControls. My application is a QuickTime editing tool, and I quickly ran into performance problems that I traced to the NFbr class within iLifeControls. Here is an updated version of NFbr that consumes ~50% less CPU time doing a window refresh. […]

  36. Aaron Scott Says:
    February 21st, 2007 at 7:45 pm

    Does anyone know how to correctly create a NFHUDButton programmatically. I can create everything else I want to, but the button doesn’t draw correctly. I am currently using the code below:

    NFHUDButton *checkNowButton = [[NFHUDButton alloc] initWithFrame:NSMakeRect(0,7,82,10)];
    [[window contentView] addSubview:checkNowButton];
    [checkNowButton release];

  37. Espen Says:
    March 17th, 2007 at 4:53 pm

    Hi,

    Are you still developing this framework? I have a problem with the NFIWindow.. I have set the title of the window to bind with the mainFrameTitle from WebView, but the title doesn’t change before you do a change on the window (for example resize the window). Do you have an solution to this?

    Cheers!

Leave a Reply

Related searches:
framework interface october window patrick
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.