What Dropzone learned from Google Chrome

July 28th, 2009

chrome-dropzone

Have you tried the Google Chrome for Mac developer release? It’s missing just about every major feature you might expect in a browser (bookmarking, printing and Flash to name a few) but is still plenty awesome, and mostly on account of its incredible speed. It feels even snappier than Safari 4 which is also pretty quick.

As well as being fast at rendering pages, it also appears to start very quickly. When you first launch it, you’ll see what I mean. Many people have commented that the dock icon doesn’t even bounce once during launch. Here’s Kevin Rose and Leo Laporte discussing this unusual behavior on last weeks TWiT episode:

This behavior of zero dock icon bounces intrigued me as well, so I did some digging, and Kevin’s right, they did a hack. If we look in Chromes Info.plist we find the following:

Info.plist

The key I’ve highlighted tells OS X that Chrome is an agent application, that is, a background application that should not appear in the Dock or Force Quit window. That seems strange, as we know Chrome does appear in both.

Some more digging led me to this patch which tells us exactly what’s going on here.

chrome_browser_browser_main_mac.mm - Issue 27108_ Temporary fix for the Cocoa-in-renderer problem. - Code Review

So. Chrome is initially launched as a background app and then transformed into a foreground app using the Carbon API call TransformProcessType. This means that when Chrome starts, the dock icon doesn’t bounce because OS X doesn’t think it should have a dock icon. When TransformProcessType is called to give it back its dock icon Chrome is already fully loaded, the net result being that we never see the dock icon bounce.

What’s interesting is that the Chrome developers are actually doing this to workaround a completely unrelated issue involving the WebKit UI and it has even been filed as a bug. And to think we all thought they had done it deliberately to give the impression of a faster launch. Shame on us all.

Anyhow, I was interested in adding this behavior to Dropzone, as the Dropzone dock icon should ideally not bounce either as this is more in line with the behavior of the built in dock grids that Dropzone tries to mimic, also, the dock icon bounces would occasionally interfere with the positioning and display of the grid directly above it. Therefore, I have added this same code to Dropzone and made another improvement – if you click on the Dropzone dock icon when it’s closed, the grid is displayed immediately after launch. There is also another neat feature in Dropzone that you may not be aware of – if you drag something onto the dock icon when Dropzone is closed, it automatically launches and opens the grid. I have done a quick screencast that demos both of these behaviors:

As you can see, Dropzone launches so quickly you barely even notice that it was closed to begin with. Without this code, the Dropzone dock icon would always bounce once even though before it finished its first bounce, Dropzone was already launched.

So, while I’m certainly not recommending people start adding this code to their apps to provide the illusion of a faster launch, in the special case of Dropzone this is a nice touch.

It will also be interesting to see whether Google ends up sticking with this behavior in future releases of Chrome. I think since Chrome launches so quickly anyway they are best just to leave it as is. Also, I bet people will complain it now seems to start ‘slower’ if they make it start bouncing again. Perception is everything.

5 Responses to “What Dropzone learned from Google Chrome”

  1. Pygy Says:

    By using this procedure, you prevent OX X from registering your app in the “Recent Application” special folder. It is probably a good thing for Dropzone, but may not be for other apps like Chrome, for example.

  2. John Says:

    @Pygy Interesting – I hadn’t noticed that. Yes that may mean Google will have to start it as a non-background app so as to not break this.

    For Dropzone, it will always be in the users dock and launched via a drag or click so this isn’t such a problem. But also, who really uses the Recent Items menu as an app launcher? Recently launched apps are most likely to be in the dock anyway. And if not then Spotlight is much faster.

  3. Phil Says:

    Actually, I use Recent Items constantly….not for commonly-used apps, but to access that deeply nested app that I don’t use often (particularly apps in the XCode folders) that I didn’t mean to quit just now.

  4. paul Says:

    i also using recent items a lot for app launching.
    i have the speacial recent apps stack which is very usefull to start apps

  5. ekstos Says:

    It sounds like the problem is with Apple, as they need to implement a system to make the bounce not interfere : either making it optional to the program, or having alternate animations (glow?).

Leave a Reply