In Mac OS X, the terms “ejecting” and “unmounting”, as they relate to removeable media, are considered interchangeable by most end users. Most people will talk about “ejecting” their USB flash drive, even though this doesn’t cause the drive to pop out like a CD or DVD. Apple explain this thus:

Ejecting a volume may not mean that it is physically ejected from the computer, but that it is no longer available (mounted) on the desktop or in a Finder window.

There is a wide array of devices that can be attached to Mac OS X – floppy drives, zip drives, firewire and USB hard drives, DVDs, CDs, iPods and other MP3 players, flash drives, cameras, and memory cards. When devices are attached, they appear in the Finder – on the Desktop, and in Finder windows in the side bar.

Drives can be ejected in a number of ways too. You can press the “eject” icon next to a mounted drive in a Finder window, you can drag a volume to the Trash (which will change its icon to show an Eject symbol as you start the drag), and if you are ejecting an actual CD/DVD, you can just press the eject key on the keyboard.

At this point, with all these methods, why on earth would I be writing about improving ejection of removable media on OS X?

Saving to a flash drive

My wife has to use Windows at work. So she’s used to the Windows way of doing things. At home we don’t have any Windows machines, so she uses my Mac, and she doesn’t generally have a problem.

A short time back she came to me with a flash drive and asked me if she could save something a friend sent her in email to the drive. I said “of course”, and set about explaining to her how to do this.

I plugged in the flash drive, and started Mail. We found the mail item with the file attached and I said to her “Ok, we can use Exposé. We drag the attachment, and press F11, then drop it on the drive…”.

At this point, Kaoru asks me “Can you show me a ‘normal’ way to do this?”. Normal? Ok, what she meant was something a little more like you’d do on Windows. I thought for a second, and then said “Yep!”.

Back to the mail item, I clicked on the “Save” button on the mail item, next to the Attachments label. It brought up a save dialog, I chose the USB flash drive, and clicked “Save“. I laughed a little, as it was probably faster than the Exposé method I was going to use – I’m just so used to using drag and drop for everything.

At this point Kaoru asks for her flash drive back. “Ok, we have to eject it”, I said. “To do that we use Exposé to go to…”.

Ok, so here’s the issue. Without switching to the Desktop, or a Finder window, how do you eject removable media?¹

Ejecting without the Finder

On Windows, when you plug in removable media, there is a little icon in the bottom right of the start bar that you click. It brings up a dialog, and from that you can eject the media. It’s not pleasant as you have to read a lot of text and press a few buttons on a couple of dialogs, but at the same time, it isn’t too pleasant having to switch over to the Finder or Desktop to eject media.

Now, OS X actually comes with an Eject Menu Extra. I hadn’t played with that for a long time, so I set about installing it. For those who don’t know, a Menu Extra is a little icon that appears in the right hand side of the Apple bar – like Volume and the Clock in OS X. This seemed like the solution we needed – it would be like Windows, though quicker to use as you just choose the drive from the list and it ejects.

To find this menu extra, go to the root of your hard drive and open System/Library/CoreServices/Menu Extras. Inside that window, double-click on the icon labelled Eject.menu.

In your menu bar you’ll now find the new Eject icon.

But there is a problem. This menu extra only works for CD and DVD drives! The USB flash drive, iPods, hard drives etc. don’t appear in the drop down menu.

This is a good solution if you have more than one CD/DVD drive. But it isn’t a solution for our needs.

A third party to the rescue

My next thought was to build my own eject menu item. But I figured I couldn’t be the only one who’d seen this shortcoming – someone must have built one already. And yes, it turns out they have.

I soon found Ejector. Ejector gives you an eject menu, and displays all ejectable media. One click, and the media is ejected.

It does have a few issues – the icon is a little ugly (you could replace it with the one from Apple’s Eject Menu Extra), and it lists your startup drive as an ejectable volume, which it isn’t. But overall, it does the job.

One more try

I did have another thought though. What if I put the /Volumes folder in the Dock. Then I could right click on that, then right click on a Volume and choose “Eject“. No need for a Finder window to pop up.

Unfortunately though, objects in dock popups from a folder are not real objects. They do not allow context menu clicks – they act as left clicks, opening a Finder window. So this doesn’t work either.²

What can Apple do to improve here

There are two possible solutions I can see here. Either Apple updates the Eject Menu Extra to work with all volumes, not just CD/DVD drives, or Apple creates an additional ejection method along the following lines.

If the only ejectable volume on your Mac is an inserted CD/DVD, and you press the Eject button on your keyboard, the CD/DVD should eject as it currently does.

If you have other media however, OS X should pop up a dialog. A simple dialog, perhaps even a cool dark translucent window like changing volume, that shows the other items that could be ejected. Pressing the eject button again would eject the CD/DVD drive – since that is probably the default mechanism for most users. However, clicking on the icon of one of the other volumes in this dialog would eject that volume.

In doing this, the menu bar wouldn’t get cluttered with yet another icon, and the eject button would still maintain the function you’d expect – “ejecting”.

Further, ejecting media would be a very simple process, not requiring switching applications. Simple and clean.

Something for developers

I did actually play around with some code in Objective-C and AppleScript to see how you find and list removable media. The results might be interesting for developers – I’ll write another article on that soon.

¹ A friend did point out one way. You could go to “save” again in Mail, and from the side bar of the save dialog, press the eject button. This will work, but is perhaps a bit unintuitive, and is certainly an ugly hack solution.

² I’ve been told that Stacks in Leopard also do not contain real objects, so you can’t get context menus on these items either. So this solution won’t work in Leopard. I can’t confirm this, as I don’t have Leopard, but I believe my sources are accurate.

The other day I wrote about reader.mac.com – something that appeared to be an RSS feed reader web app from Apple for the iPhone. At that time it appeared the service was not yet live.

James B contacted me with some further information:

After some flailing, I managed to get reader.mac.com to spit out something other than a blank page in a desktop browser: Set an iPhone-ish user-agent string, then visit http://reader.mac.com/mobile/v1/http://your.feed/ or whatever.

I suspect the app was ‘live’ all along, and we just didn’t know the correct URL format before :)

Thanks James. James is quite right. It appears that if you enter a feed URL in to Safari on the iPhone, it redirects to reader.mac.com using the URL shown above.

If you want to see an approximation of this because you don’t own an iPhone, you can follow James’s instructions for doing this on Firefox, or use iPhoney. The image on the left is a screen shot of iPhoney using the URL to my blog’s direct feed: http://feeds.feedburner.com/curmi

The question I have is, why is this part of the .Mac domain? You don’t need a .Mac account to use reader.mac.com, yet you need one for everything else of .Mac. Why didn’t they call it reader.apple.com? Or reader.iphone.com? The own those domains too.

It all seems a bit odd – either Apple have some interesting plans for .Mac, or they care so little about it it’s become a domain they use when they aren’t sure where to put something. Given how rarely they add new features to .Mac, you do have to wonder…

According to InformationWeek, it is possible to crash Vista in 10 seconds. To do this, you hold down the Windows key and the letter ‘e‘ in Windows Explorer for 10 seconds. This opens up numerous Windows Explorer windows, and, according to the report, after about 10 seconds Vista locks up.

Reports vary on the result. Some people claim Windows Explorer crashes and restarts fairly quickly, others say they just get lots of open Windows Explorer windows and everything continues to function. We tried it ourselves on a friend’s boss’s computer (the boss wasn’t in yet, and everyone else in the company uses a Mac) and we got the following: lots of windows opened, then a dialog popped up saying that Windows Explorer had stopped working, and that “Windows is collecting more information about the problem. This might take several minutes”. The machine then seemed to lock up pretty hard. Some time in the next 30 minutes it appears the machine recovered. So it’s not quite a crash, but it certainly is an easy way to break an important bit of software with a two finger keystroke.

I am not suggesting the Mac doesn’t have a similarly trivial way to break it (though I’d love for someone to point out a two finger keystroke that can break OS X in 10 seconds – and holding down the power button doesn’t count). To be fair though, I needed to try and reproduce this on the Mac.

The Finder

The Mac equivalent of Windows Explorer is the Finder. And the Mac equivalent of Windows-E to open new Finder windows is Command-N.

So, I held down Command-N. One new Finder window opened. That was it. It seems that Command-N doesn’t auto-repeat in the Finder as Windows-E does in Windows Explorer. So, of course, my first reaction was along the lines of “In your face Microsoft! Your engineers suck dog’s balls!”.

TextEdit

I spoke too soon. Lucky I didn’t blog about it! :-)

A good friend of mine noticed that taking the application TextEdit (the Mac default text editor application), and doing Command-N (which opens new TextEdit windows) actually does auto repeat! Holding that key combination down for 10 seconds fills your screen with TextEdit windows.

Granted, TextEdit doesn’t crash. Nor does OS X. In fact, you can use Exposé and look at all the windows on screen at once (as shown here). Pretty cool!

But it seems very odd that Apple would let a menu item like this auto-repeat. Why would anyone want to do this? And why on TextEdit but not the Finder?

Carbon versus Cocoa?

My friend had a theory. The Finder is a Carbon application. TextEdit is a Cocoa application. Could this have something to do with it?

A quick test shows that BBEdit, a Carbon application, also doesn’t auto-repeat. Safari, a Cocoa application, does. Is this what is going on here?

Well, this is pretty close to the truth it seems.

When you create an interface in OS X’s Interface Builder, you can choose to build a Cocoa application or a Carbon application. If you choose a Cocoa application, the keyboard equivalents for menu bar items will auto-repeat, and Interface builder doesn’t appear to have an option to turn off this behaviour. Hence, TextEdit and Safari auto-repeat when you hold down Command-N.

However, when you create a Carbon application, keyboard equivalents by default don’t auto-repeat. There is however an option to set auto-repeat on a keyboard equivalent for a menu item (see picture to the right). As the default is not to repeat, this is probably why most Carbon applications won’t show the auto-repeat behaviour (apparently iTunes does on some menu items, and is Carbon I believe).

Question is, should this be the default in Cocoa? To me it seems an odd choice – there doesn’t seem to be many functions where I would want auto-repeat on a menu item. It would be dangerous in deleting items in an application, for example, if after deleting one item it went to the next item.

The documentation for NSMenuItem doesn’t appear to have any easy way to set or un-set auto-repeat on menu items either. So I suspect a bit of hacking is required to turn the auto-repeat off for Cocoa applications.

So there is a difference between the default way Cocoa and Carbon applications work. And the fact that the Finder doesn’t behave like Windows Explorer (I don’t mean the crash part) would appear to be purely by accident not design. Interestingly, the auto-repeat feature may be a quick way to determine if an application is a Cocoa or Carbon application, though obviously not a fool-proof way. There are claims that the Finder in Leopard is Cocoa now – I suspect it isn’t, and if someone wants to try Command-N on it, I think it will behave the same as the Finder in Tiger (I don’t have Leopard, so I can’t try it. And if I did have it I’d be under an NDA I guess, so I couldn’t talk about it).

I really like my applications to behave consistently, so this disturbs me a little. Though most applications these days are Cocoa, I think the Carbon default behaviour is better than the Cocoa default behaviour. Personally, I’d like to see Cocoa change to be consistent, with an option to turn on auto-repeat for menu items that really need it.