Why Macs Don’t Support Multiple Monitors

Sunday, September 27th, 2009

I have two 23″ monitors on my desktop at work, and have worked that way for about three years now (aside from a brief flirtation with a single 30″ monitor in California). On Windows and Linux this is an incredibly productive setup. I can have a full screen IDE open on one and a full-screen web browser open in the other. The web browser gives me a huge reference library and easy access to a lot of apps including e-mail, calendar, and more, and the IDE lets me do my work. I can easily switch back and forth between them to surf or edit. It’s a smooth and fluid workflow. Even a single monitor twice the size doesn’t work as well since you can’t easily organize the two applications on the screen.

I’m a programmer but the same is true for anyone who works primarily in one large application. For instance, for designers it might be Photoshop or QuarkXPress. For writers it may be Microsoft Word. For business folks it could be Excel. We all need a web browser open and we all need our main productivity app. On Windows and Linux these days, this just works. You plug-in two monitors. You open two apps. You move between them as you feel like it, and do your work. This is what it looks like:

Eclipse on left monitor with menubar; Firefox on right monitor with menubar

On the Mac, however, it doesn’t work. The Mac, which was perhaps the first platform to support multiple monitors, certainly the first consumer platform, a two monitor setup looks like this:

Eclipse on left monitor without menubar; Firefox on right monitor with menubar

Do you see the difference?

Why Does Software Assume Hardware is Reliable?

Thursday, August 30th, 2007

I am getting quite tired of Mac OS X locking itself into the spinning beach ball of death due to failing hardware. In the last year or so I’ve had two LaCie hard drives go out on me, and a third seems to be going now. In each case, the Mac got thrown into a completely confused funk because the drive didn’t respond quickly enough or at all. Note that these drives were used strictly used as external backup device. They didn’t hold any operating system or application files.

Haven’t we learned by now that I/O is an unreliable operation, and that you should never assume that any read call will succeed, or will return data in the format you want? That’s true whether you’re talking about files or FireWire packets. Furthermore, critical components like the Finder should not block on synchronous I/O. Any I/O needs they have should be serviced asynchronously.

It’s hard to take the Mac seriously as a reliable server platform when it’s so easily brought to its knees by one misbehaving hard drive.

Window Maximizing and Multimonitor Setups Across Platforms

Thursday, August 16th, 2007

For the last couple of months I’ve been working on Windows as my main desktop during the workday (not my personal choice, but I can live with it.), and that’s caused me to notice a few things I haven’t noticed before, especially in contrast to the Mac style of managing windows. I’ve task switched between Mac and Windows before–for several years in the late 90s I did all my development and book writing on Windows and all my e-mail and Internet on the Mac–but this is the first time I’ve had the chance to compare the two environments with multiple monitors, and that’s made some difference in my take on matters. Practices that work well on a single monitor system don’t work as well on multimonitor system and vice versa. After playing with this for a while, I’m starting to think that the Windows approach works better for multiple, small monitors and the Mac approach works better for a single, widescreen monitor.

To summarize, here are the critical differences between the two platforms. These are worth keeping in mind when you’re designing a cross-platform application such as Firefox or Limewire, or any web site.

The Next MacBook

Monday, July 23rd, 2007

I now know what the specs for the next, ultra-portable MacBook are going to be. Look for:

  • 32GB solid state drive
  • Intel Core 2 Duo Ultra Low Voltage chip running at 1.2GHz
  • 1-2 GB RAM
  • 802.11a, b and g wireless; built-in Ethernet
  • Carbon fiber case
  • 276 x 199 x 29mm
  • 1.15 kg
  • 11.1 inch screen 1,366 x 768 pixels
  • Integrated webcam
  • Integrated Dual-layer DVD writer
  • USB 2 and Firewire
  • 6 hour battery life
  • Price (the number I’m least certain of) $2995

No, I don’t have any inside information. These are actually the specs for the new Sony Vaio VGN-TZ12VN (except for the price). Sony’s the only manufacturer that really competes with Apple in the “cool laptop” space; and Apple is not going to let them win.

Apple Surrenders

Thursday, July 12th, 2007

I am pleased see that the just released QuickTime 7.2 enables full-screen playback for all users, not just those who’ve paid extra for QuickTime Pro.

As some of you may remember, I started the Amateur Project mostly because I was pissed off that Apple wanted to charge me again to play movies in full screen mode, even though I’d already paid for QuickTime Pro once. Amateur is written in Java on top of Swing and QuickTime for Java.

Amateur became capable of playing movies in fullscreen mode fairly quickly, and it even has a few useful features Apple’s own player does not. I’ve used it for most of my media playback needs ever since. It never achieved full parity with QuickTime Pro in other features though because:

A. Apple has more or less abandoned QuickTime for Java, and many new features of QuickTime 7 and even 6 simply aren’t available from Java.

B. I’ve had limited time to work on it for the last year or so.

C. Nobody else competent ever stepped forward to contribute. A couple of dozen people did fill out a generic java.net form requesting developer privileges without contacting me first, or giving me any indication of who they were or what they wanted to do. All I got was an opaque username and a request for commit privileges. Sorry that’s not enough. I did not get a single patch or even a usable bug report from anyone.