There’s a subversion repository as well if you’re keen to stay up to date.

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.

CTGradient contains an incredible diversity of built-in gradients, gradient styles, and methods for creating fancy rainbows, radial gradients, linear gradients, aqua gradients, and a number of other interesting class and instance methods. It allows you to dynamically alter gradients by adding or removing colors, changing the level of transparency, filling NSRects or NSBezierPaths, rotating the gradient, etc. For demonstration purposes, all these features are excellent. For production, this is a nightmare.

CTGradient.m weighs in at over 1300 lines of code.

Ignoring Mr. Weider’s unique style of formatting, take a look through the code. If you’re putting this class in an application, you can immediately remove over a thousand lines. Just like that. But if you take some time to understand what’s going on, you can optimize this thing till it runs like a Ferrari.

You’ll notice Trimmit uses a gradient background for it’s window. Let’s cut down CTGradient until it matches the level of optimization of Trimmit’s gradient code.

Clear the junk

Firstly, let’s remove the methods we know for sure we won’t need. Remove the following methods completely from both the interface and the implementation (scroll down for more):

// We don't need the preset gradients

+ (id)dividerGradient;
+ (id)statusBarGradient;
+ (id)aquaSelectedGradient;
+ (id)aquaNormalGradient;
+ (id)aquaPressedGradient;
+ (id)unifiedSelectedGradient;
+ (id)unifiedNormalGradient;
+ (id)unifiedPressedGradient;
+ (id)unifiedDarkGradient;
+ (id)sourceListSelectedGradient;
+ (id)sourceListUnselectedGradient;
+ (id)rainbowGradient;
+ (id)hydrogenSpectrumGradient;

// We won't make any drastic modifications to the gradient once created

- (CTGradient *)gradientWithAlphaComponent:(float)alpha;
- (CTGradient *)addColorStop:(NSColor *)color atPosition:(float)position;
- (CTGradient *)removeColorStopAtIndex:(unsigned)index;
- (CTGradient *)removeColorStopAtPosition:(float)position;
- (CTGradientBlendingMode)blendingMode;
- (NSColor *)colorStopAtIndex:(unsigned)index;
- (NSColor *)colorAtPosition:(float)position;

// Now we don't need to conform to the NSCopying and NSCoding protocols

- (id)copyWithZone:(NSZone *)zone;
- (void)encodeWithCoder:(NSCoder *)coder;
- (id)initWithCoder:(NSCoder *)coder;

// We only need to fill a simple NSRect

- (void)drawSwatchInRect:(NSRect)rect;
- (void)radialFillRect:(NSRect)rect;
- (void)fillBezierPath:(NSBezierPath *)path angle:(float)angle;
- (void)radialFillBezierPath:(NSBezierPath *)path;

// Remove the entire (Private) category;
// but leave -addElement:

- (void)_commonInit;
// move setBlendingMode code into init
- (void)setBlendingMode:(CTGradientBlendingMode)mode;
- (CTGradientElement *)elementAtIndex:(unsigned)index;
- (CTGradientElement)removeElementAtIndex:(unsigned)index;
- (CTGradientElement)removeElementAtPosition:(float)position;

The following C functions are now unused:

static void chromaticEvaluation(void *info, const float *in, float *out);
static void inverseChromaticEvaluation(void *info, const float *in, float *out);
static void transformRGB_HSV(float *components);
static void transformHSV_RGB(float *components);
static void resolveHSV(float *color1, float *color2);

And also remove the following from the header:

typedef enum  _CTBlendingMode
    {
    CTLinearBlendingMode,
    CTChromaticBlendingMode,
    CTInverseChromaticBlendingMode
    } CTGradientBlendingMode;

Remove the <protocols> and unnecessary instance variables so the interface looks like this:

@interface CTGradient : NSObject {
    CTGradientElement* elementList;
    CGFunctionRef gradientFunction;
}
+ (id)gradientWithBeginningColor:(NSColor *)begin endingColor:(NSColor *)end;
- (void)fillRect:(NSRect)rect angle:(float)angle;
- (void)addElement:(CTGradientElement *)newElement;
@end

Before we go further, we’ll need to take a detour and fix the remaining code so that it compiles. That’s easy enough - just remove any references to code we’ve removed.

If you’ve been following along, your CTGradient should now look like this (also made it readable!).

In a few short minutes, we’re down from more than 1300 to a little over 200 lines.

It gets better.

Optimize it

First stop, fillRect:angle:. Since the gradient for Trimmit’s window only runs vertically (angle 90), we can straight away take out the angle argument, and also cut the entire if / else structure with the angle down to the two lines that are under the if(angle == 90). Ah, much better.

Now things start getting a teeny bit more complex - and fun.

The CTGradient code is written so that one can have many different color stops. The CTGradientElement struct has a nextElement which points to the next CTGradientElement and the position of the current element is stored under the float position. However, we need just two - the starting and ending shades.

Let’s take a look at cutting the multiple elements down to just two.

The addElement: method has a lot of looping to insert the element at the correct place. However, since we know that we only ever need two, we can cut it down to this:

- (void)addElement:(CTGradientElement *)newElement {
    if(elementList) {
        // elementList exists, add second element
        elementList->nextElement = malloc(sizeof(CTGradientElement));
        *(elementList->nextElement) = *newElement;
        elementList->nextElement->nextElement = 0;
    } else {
        // no elements - add first element
        elementList = malloc(sizeof(CTGradientElement));
        *elementList = *newElement;
        elementList->nextElement = 0;
    }
}

Similarly with dealloc,

- (void)dealloc {
    CGFunctionRelease(gradientFunction);
    free(elementList->nextElement);
    free(elementList);
    [super dealloc];
}

While we’re at it, let’s clean up init as well:

- (id)init {
    if(self = [super init]) {
        CGFunctionCallbacks evaluationCallbackInfo = {0 , &linearEvaluation, 0};
        static const float input_value_range[2] = { 0, 1 };
        static const float output_value_ranges[8] = { 0, 1, 0, 1, 0, 1, 0, 1 };
        gradientFunction = CGFunctionCreate(&elementList, 1, input_value_range, 4, output_value_ranges, &evaluationCallbackInfo);
    }
    return self;
}

Now we head to the linearEvaluation function. info passed in refers to elementList (see the CGFunctionCreate call). Again, since we know that we’ll only ever have two elements we can reduce it to:

void linearEvaluation (void *info, const float *in, float *out) {
    float position = *in;

    CTGradientElement *color1 = *(CTGradientElement **)info;
    CTGradientElement *color2 = color1->nextElement;

    out[0] = (color2->red - color1->red)*position + color1->red; 
    out[1] = (color2->green - color1->green)*position + color1->green;
    out[2] = (color2->blue - color1->blue)*position + color1->blue;
    out[3] = (color2->alpha - color1->alpha)*position + color1->alpha;
}

And now we can finally remove the lines from +gradientWithBeginningColor:endingColor: where the positions are set, and also remove the position float from the CTGradientElement struct.

We’re now down to a little over 100 lines. Your CTGradientElement.m should now be looking something like this. Going well, but let’s take things up a notch.

For Trimmit’s background, we’re not interested in the red, green, blue and alpha components - we just need a grayscale shading. This is the most fun part.

Instead of float red, green, blue, alpha; in the CTGradientElement struct, we can have just float shade;.

Now, during init we have:

CGFunctionCallbacks evaluationCallbackInfo = {0 , &linearEvaluation, 0};
static const float input_value_range[2] = { 0, 1 };
static const float output_value_ranges[8] = { 0, 1, 0, 1, 0, 1, 0, 1 };
gradientFunction = CGFunctionCreate(&elementList, 1, input_value_range, 4, output_value_ranges, &evaluationCallbackInfo);

The third argument, input_value_range is the domain. This gets passed into linearEvalution through *in.This is the independent variable. When we’re drawing the gradient, linearEvaluation is called with *in (the domain) starting at the first value of input_value_range and ending up at the second. So, something like 0.000, 0.001, 0.002 … 0.998, 0.999, 1.000. The function’s job is to set the the color components for each given value of the domain.

The first optimization we can make here is to return only one channel instead of four. This changes it to:

- (id)init {
    if (self = [super init]) {
        CGFunctionCallbacks evaluationCallbackInfo = {0, &linearEvaluation, 0};
        static const float range[2] = {0, 1};
        static const float domain[2] = {0, 1};
        gradientFunction = CGFunctionCreate(&elementList, 1, domain, 1, range, &evaluationCallbackInfo);
    }
    return self;
}

This change impacts back on the linearEvaluation function - now it only needs to return one channel:

void linearEvaluation (void *info, const float *in, float *out) {
    CTGradientElement *color1 = *(CTGradientElement **)info;
    out[0] = (color1->nextElement->shade - color1->shade)*(*in) + color1->shade;
}

And don’t forget +gradientWithBeginningColor:endingColor:. We improve performance here, as we only need the shade - not a color. We can rename it to something appropriate.

+ (id)gradientWithBeginningShade:(float)begin endingShade:(float)end {
    id newInstance = [[[self class] alloc] init];
    CTGradientElement color1, color2;

    color1.shade = begin; color2.shade = end;

    [newInstance addElement:&color1];
    [newInstance addElement:&color2];
    return [newInstance autorelease];
}

Now we’re only returning one grayscale channel. But hold on, we’re still in the RGB colorspace! That’s easily fixed. In fillRect:, replace:

#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4
    CGColorSpaceRef colorspace = CGColorSpaceCreateWithName(kCGColorSpaceGenericRGB);
#else
    CGColorSpaceRef colorspace = CGColorSpaceCreateDeviceRGB();
#endif

with:

CGColorSpaceRef colorspace = CGColorSpaceCreateDeviceGray();

CGColorSpaceCreateDeviceGray is device-dependent on Mac OS X 10.3 and below, but starting from Tiger, it’s now device-independent which is good in terms of appearance.

While we’re in fillRect:, we can also make a few more improvements:

- (void)fillRect:(NSRect)rect {
    CGContextRef currentContext = [[NSGraphicsContext currentContext] graphicsPort];
    CGContextSaveGState(currentContext);
    CGColorSpaceRef colorspace = CGColorSpaceCreateDeviceGray();
    CGContextClipToRect(currentContext, *(CGRect *)&rect);
    CGShadingRef myCGShading = CGShadingCreateAxial(colorspace, CGPointMake(0, 0), CGPointMake(0, NSMaxY(rect)), gradientFunction, 0, 0);
    CGContextDrawShading(currentContext, myCGShading);

    CGShadingRelease(myCGShading);
    CGColorSpaceRelease(colorspace);
    CGContextRestoreGState(currentContext);
}

I moved the startPoint and endPoint CGPoints straight into the CGShadingCreateAxial call. Also, we only ever fill the whole view with the gradient, so just put in 0 instead of using NSMinX and NSMinY. We could replace the CGPointMake(0, 0) with (CGPoint){0,0}, but I’m not sure if that’d be noticeably faster.

Our code is at a lean 80 lines. Now for the biggest change yet.

Heading back to dear old linearEvaluation. Look at this line:

out[0] = (color1->nextElement->shade - color1->shade)*(*in) + color1->shade;

What’s happening here? Think about it like this:

Essentially, we’re just "graphing" a straight line:

y = mx + c

where x is the position, *in, and y is the shade we return (out[0]), and c is the initial shade.

Since our x value only goes from 0 to 1 (see domain in CGFunctionCreate), at x = 0, we will have y = c. At x = 1, we’ll have y = m + c.

So we only need the start shade as our *info value, since we can have m as the difference between the final and initial shades. Let’s effect this in our code.

We can get rid of the CTGradientElement struct. Remove from the header:

typedef struct _CTGradientElement {
    float shade;
    struct _CTGradientElement *nextElement;
} CTGradientElement;

Instead of the struct, we’ll use a single shade instance variable. We don’t need the +gradientWithBeginningShade:endingShade: anymore, nor do we need -addElement:. So our interface now looks like this:

@interface CTGradient : NSObject {
    float shade;
    CGFunctionRef gradientFunction;
}
- (void)fillRect:(NSRect)rect;
@end

From the implementation, we can remove the free calls in dealloc as well as the whole of +gradientWithBeginningShade:endingShade: and addElement:. We can set the shade in the init method (and replace &elementList with &shade), and change the linearEvaluation function to:

void linearEvaluation (void *info, const float *in, float *out) {
    out[0] = *(float*)info + (*in)*0.1;
}

The 0.1 is what determines how much brighter the top of the gradient is (it’s the m value of our straight line) compared to the bottom.

But since the (*in)*0.1 will go from 0 to 0.1 (as *in goes from 0 to 1), we can actually change the domain we declare for CGFunctionCreate to {0, 0.1} and have our function as:

void linearEvaluation (void *info, const float *in, float *out) {
    out[0] = *(float*)info + *in;
}

You can now add accessors for shade if you need to change the shade of the gradient or you could even have an initWithShade: method. In fact, here’s an Xcode project with the gradient.

Lean Gradient Xcode Project

We now have our gradient code down from 1300 lines to just over 30 lines.

We’ve almost reached a similar level of optimization to Trimmit’s gradient. There will be further optimizations you can make, but it depends on what you’re using the gradient for. For example, if the gradient you’re drawing is always the same, you can optimize further by removing the shade instance variable and all references to it, and hardcode the value into the linearEvaluation function.

Getting to the end of this article, you’re probably thinking that it would be a bit of a waste to use CTGradient if by the time you optimize it for your application, it doesn’t resemble the original at all. And you’re quite right. The documentation already shows you how to draw gradients, yet the number of applications using CTGradient - the whole 1300 lines of it - is astonishing.

Please: When you use other people’s code, don’t put it in without a thought. Go through it, understand it, and optimize it for your specific need. For the better performance and reduced RAM usage, computers will thank you.

Here’s your answer.

AppleScript can be handy sometimes, but when people release applications like this, and get awards for it, alarm bells should be going off. WallSaver is almost two megabytes in size. For a single command-line.

Just reinforce the point, I wrote another wrapper for the same command in Objective-C. It’s 100 kb, or 60 kb without the icon. It can pause the screensaver (which brings it down to 0 CPU usage), resume it or restart it. And not once will it throw an “AppleScript error” . Download it and see for yourself.

As for the source code, all you need is:

/System/Library/Frameworks/ScreenSaver.framework/Resources/ScreenSaverEngine.app/Contents/MacOS/ScreenSaverEngine -background

Finder info, .DS_Store files, resource forks, debug symbols… They do nothing for the user short of wasting disk space. For the developer, extra bandwidth costs. Do people not realise this is a problem, or are they just too lazy to act? Either way, the solution is simple.

You can clean apps (sometimes to less than half their original size) with some basic commands in the Terminal. But this takes time, and what’s more, Mac users in general have an aversion to the command line. Enter Trimmit.

Trimmit is a svelte utility which takes the pain out of keeping your applications as tight as possible. I use it on Flow each time I seed a build, and I seriously doubt the process could any easier.

Brian Amerige

Trimmit uses superfast UNIX APIs, Apple’s own developer tools, and the rock-solid Cocoa framework to automate your cleaning process. Just drop your built app onto it, maybe configure a few settings, and you’re away. It doesn’t get any easier - or faster.

Other applications claim to save disk space by stripping universal binaries, or removing languages. Trimmit does all of that - and more. But it works. Look at this screenshot from Xslimmer regarding Xcode:

Xslimmer naively believes that only two architectures can exist in any application, but the truth is revealed by Trimmit:

Because Trimmit interacts with the shell (zsh, in fact), no similar application can even come close to it’s level of power, accuracy and performance.

The results speak for themselves.

Use Trimmit to recover disk space that third-party applications so rudely waste.

Go get Trimmit.

I’ve recently started using Inbox for organizing and collecting all my various projects as well as study materials and schedules. Although it took a while for me to get used to the whole GTD concept, I now use the application constantly.

Midnight Inbox implements David Allen’s GTD approach

One of the great things about Inbox is that it looks so good. Good enough to forgive make up for its relatively frequent crashes. The interface is really well designed, keeping in line with many of the Mac metaphors while adding a few unobtrusive features that are generally easy to work out.

It’s clear this is a great application. It has major potential and version 2.0 looks exciting. Congrats to the developers.

Going through the contents of the application, I found CGS.framework and thought, “Interesting. They’re using Core Graphics”. It didn’t occur to me that I released a framework with the exact same name. Well, I’ve finally realized that one of my favorite apps is possibly using this framework and … [speechless].

This is the first application (to my knowledge) to use that particular framework, and only the second to use code that I’ve posted. (Logan Rockmore’s Assignment Planner was the first, using the AnimatingTabView).

I’ve never used another GTD program before, but after trying this app, I doubt I’ll need to. Go check out the fantabulous Midnight Inbox and get things done with style.

A sub-project of Shiira is a HUD-type window class. While they’re not completely accurate to the specifications used by Apple, these are probably the best HUD windows I’ve seen from a third party developer by a long shot.

The HUD Windows have the funny name of HMBLBlkAppKit. The Shiira team has really done a great job!

Absolutely — I’ve got all the time in the world to answer everyone’s questions. That’s what I’m here for.

How’s the Flow development going? What sort of feedback are you getting from the private beta testers?

Flow development is going really well. As I’m sure any other developer could tell you, it’s just an amazing feeling to wake up everyday and be consistently amazed how far things have progressed in just a day. The private beta testers have been absolutely invaluable to Flow. While I know the topic is a bit controversial, I don’t believe in unit-testing. Wil Shipley made a great post (http://wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html) a while back on it, which really hits the nail on the head. My private-testers are not only rigorously using Flow with the intention of breaking it (I always say, don’t test if a feature works, test if it can be broken), in addition to the fact that they all use it in a practical sense — they’re building websites and transferring files — because real world testing is irreplaceable.

So apart from Objective-C and web development, is there anything else you’ve tinkered with?

Hell yes!

Before I even learned Objective-C, I ran a small-hosting company named Extendmac. We did a bunch of things in unusual ways (giving users a Plesk Control Panel for $6 USD/mo.), and the customers we had absolutely loved us. Unfortunately, once education and software entered the picture, it became pretty clear that I couldn’t keep all three up at once. Web-Hosting was obviously the weakest link, so I was forced to give it up. That said, I have to say it’s really a shame the hosting services never saw much of the light of day. The hosting system, user control panels, Direct-Support (I had actually written an entire ticket-based support system, which to this day I consider one of my finer creations) were all really well done, all definitely things I’m proud of. If only I had the infrastructure or team behind me (at the time) to have continued, I believe it would have turned into something really phenomenal.

Aside from business, I’ve tinkered with lots of other things. I’ve hacked and modified Roombas and had ‘TiVoToGo’ on my TiVo long before it was ever publicly available (in a different way of course — I just wrote some backend to give me WebDAV access to the hard drive, which is particularly funny, because it’s the first thing I ever saw appear in Flow’s Bonjour -> WebDAV category.) As you might expect from a developer, I’m constantly making easier solutions to everyday things — just part of the lifestyle I guess!

How do you find the Xcode IDE?

What can I say? I feel right at home in Xcode, and I can’t imagine developing anywhere else. Apple’s done a great job with Xcode, but if I were to change one aspect, it’d be a few of it’s UI concepts. Then again, many of those (collapsable code. Xray) seem to be addressed in Xcode 3.0, so I can’t complain.

What are you looking forward to most in Leopard and why?

As you might expect, I’m most excited about Xcode 3 and IB. Obviously that’s because a large majority of my time is spent in there! Also, the addition of Core Animation opens us (developers) up to many new opportunities, and I can’t wait to see where others (and myself) will take that into their apps. I’m all about creating rich user experiences, and Core Animation is definitely going to help.

Anything else?

Aside from development additions in 10.5, I’m most excited about time-machine. I use subversion internally for keeping a running source-record of each progressive build of Flow, but it’s nice to know that in the event that I need it, time-machine can act as a “backup to my backup”.

How different is Objective-C to other programming languages that you’ve encountered? Do you like working with object-oriented languages or do you not worry about the technical aspects of the various languages?

I guess the best way to describe Objective-C is that it’s very very well-thought out. I love Cocoa, and have immense respect for those responsible for it at Apple; they’ve created a plethora of technologies which let me spend time developing new features rather than just getting things to work. While I tend not to look at the technical aspects of the languages (writing great code is very important, but in the end it needs to build a better product), I do prefer working with object-oriented languages.

You say you’ve worked a lot on little personal projects in various languages. When did you decide you were proficient enough to tackle writing public application, or did you just decide to tackle it and worry about the details later?

I’m not sure the issue was ever whether or not I was proficient enough to tackle a public-app, but whether or not the app could serve a larger audience than just myself. When I think back, there really wasn’t ever a question in my mind for Flow — knowing that the public could benefit from it just as much as I could, I don’t believe I even thought twice about keeping it private or not.

Writing your first public application must be a good lesson in itself. What’s one of the things you’ve found out by undertaking this project?

Writing software is less about programming and technology than it is about people. It’s surprising to me how many people still fail to realize it, but regardless of how technically challenging your app is, you’re writing for people, and they’ve got to be your focus. In the end, an app with less features that’s more enjoyable to use is always more valuable than it’s competition.

You obviously decided to write Flow when you found (like a lot of others before you) that something needed to be fixed in the FTP department on the Mac platform. Using an external text editor with an existing FTP client is one that you found needs improvement. Are there any other issues you’re trying to address with Flow?

Two words. User Experience. FTP clients don’t feel right today. Many people aren’t comfortable with them. That just blows me away — how has this been ignored? I whiteboard my ideas, workflows, and designs quite often, and in the upper right corner, it always says “Make it feel beautiful.” It’s just a core value to me. An app that doesn’t feel great isn’t one worth using, regardless of what it does.

In continuation of the previous question, I’ve spent a lot of time learning what feels natural, and maintaining user-comfort is always my topmost goal.

You obviously planned the application meticulously before you started developing it. How has Flow evolved and changed during its development?

Flow has changed dramatically since the original planning — but mostly in technical aspects. I’ve kept consistent with a large majority of the design and feature concepts because something that feels right 6 months ago still feels right today. So in a way, I’m tackling the same problems, but how I do so programatically is always flexible.

You say Flow is more of a connection client than an FTP client, as it handles a number of protocols. How do you decide which features are worth keeping and which ones would be bloat?

I’m so glad you asked this question. The ideology behind this is pretty much the same as that behind preventing piracy. I won’t spend massive amounts of time preventing piracy because that’s time that should be spent evolving the app for paying customers. In that way, the moment a feature becomes detrimental to the core features, it’s bloat and should be removed.

Am I correct in thinking Flow does not use Apple’s FTP framework? Could you elaborate on why you chose to go with Connection Kit instead?

Yep! I chose to go with the Connection Kit for a few reasons. First, I think those in charge of it are doing a terrific job with it. It’s powerful, robust, efficient, and clean. Equally important, however, is that I get the chance to work really closely with its developers (Greg Hulands, who I can’t thank enough for all his hard work), which ensures beautiful integration with Flow. There’s no way I could get that type of relationship with the Apple FTP framework, and as a result it would be foolish of me to pass up on it with CK.

Eye candy and GUI has been a very controversial topic in the Macintosh community in recent months. From a usability point of view, what is your stance on interface customizations? How much time do you spend designing and writing the interface in comparison with the bulk of the application?

Another great question. A while back when I was messing around with some phrases for Flow, I hit on “Sizzle, meet Steak.” I think that’s the very core of my perspective in this case. As I’m sure you’ve noticed, I absolutely support making applications beautiful and fun to use — but there are limits. Compromising the consistency of Mac OS X applications is dangerous water as Apple has worked very hard to maintain consistency in the past. At the same time, Apple is almost always the first to introduce new UI elements — so where’s the balance?

In my opinion, the HIG (Human Interface Guidelines) is dead. So if I were to choose a new golden rule, it’d succinctly state: “Make your applications look beautiful, compliment existing elements of OS X, and act even more intuitively.”

Where did you get your inspiration for the Flow interface, or did you design it from scratch?

Flow’s interface is very complimentary of the Mac OS and it’s applications. In some aspects, Flow’s interface was designed from scratch and yet if you look at it now, it’s friendly and recognizable. To me, this says that Apple and others got it right — and that’s a terrific thing.

Do you have any plans or ideas for development after Flow?

Absolutely. We’ll see where they take me

Any tips for budding developers?

Consistently remind yourself to think of your application in terms of a solution. Every feature, behavior, and action should be focused on that solution, and those that aren’t should be left out. Remember that applications are for people, and they should be engineered as such.

Brian Amerige, thanks again. Best wishes for your future development and endeavours. May the Force be with you ;).

Haha. It was my pleasure! Cheers!

I’ll still be using Quicksilver’s Clipboard History (you know how much I love Quicksilver), but this iClip really takes things to a new level in ease of use and appearance. I can talk about it, but it’s probably better if you see it for yourself. Check it out.

Just goes to show what one little mistake in your code, or an unforeseen circumstance can do to your code. The file was only a few megabytes.

Remember kids, test your apps in every possible way, and then some. And encourage feedback.

Now, any ideas on what I can do for the next 230,000 years?