multipart-message nevyn bengtsson's blog

featured articles 🦄, about, archive, tags

How To Fix Xcode 4

People are sort of tired of me complaining; I’ve been saying I hate Xcode 4 since the first time I used it. “You’ll get used to it!”, “Learn Behaviors and everything will be well”, “Embrace the new UI model”, they said. I’ve been using it exclusively for several months now, trying to explore and use every feature of it; make sure to try to find a way in which I can confidently work in it. I failed. Launching Xcode 3 is a fresh breeze every time.

Just a note up front: I’m not saying Xcode 4 sucks. It is light-years ahead of Xcode 3 in many ways, particularly autocompletion and the IDEs idea of what the code contains (inline warnings and errors as you type is wonderful). This is just about the way it manages windows and tabs. And even then, maybe there is some mode or usage pattern that I don’t know about and would fit me better — if so, please shout in the comment or to my twitter!

Spatial Thinking

Xcode 4 works fantastically for a lot of people. How am I special? Why do I have to try to be so different all the time? Apart from just generally being an annoying sod, I imagine myself being a spatial thinker; I like to think in terms of spatially organizing whatever concepts I’m working with. I loved Classic Mac OS’ spatial Finder, where windows always appeared at the same location were it did last time, and there was a one-to-one mapping between folder and window.

The same goes for me and source code files. I used to work in Condensed Mode in XC 3; a single thin window with a project file listing, all source windows separate, and then dedicated slots for Build and Run windows on a separate screen (together with a terminal or two). I would work with a dozen source files at the same time, placing them around the screen. When I needed one I used recently, I would know where it would be spatially, and could just click a tiny corner or edge peeking out beneath whatever I was working on(1). This way I could also layer other applications in between windows, and have a rather deep pile of things I’m working on. It’s the classic desktop metaphor, and the main argument against Multiple Document Interfaces (MDIs) that we Mac nerds would ridicule Windows users for having to use every day(2).

You might be able to imagine why XC4 would then be a problem for me, with everything in a single window, everything appearing in the exact same location on screen as you instead switch between modes of operation in one screen area, rather than switching between locations and zones on the screen. It was — and is — a complete disaster for my productivity. I spend so much time switching between contexts nowadays, trying to reorient myself.

Staying In the Past?

Trying to work in an Xcode 3 manner in Xcode 4 is worse than just trying to adapt.

One of the best features of Xcode 3 is that it would remember all the open windows of a project when you closed it. In Xcode 4, closing a window is terminating it and its layout forever, and the last window you happen to close will become the main project window. Oh, you accidentally closed the window *you* consider the main window first, and then you had a reference header in a window configured for reading reference headers still open on another screen? Well, I guess that’s your main window now, and you’ll just need to reconfigure it as your main. (Update: There is in fact “Close project” in File which will remember all the windows. This doesn’t help in the situation where you close one window forgetting that you had two open though, which is quite common.)

Want a separate window for your build progress so you can keep track of what’s actually happening in your builds? That’s in a sidebar now, and if you actually want build details, you have to manually choose the latest build results in *another* sidebar, and then switch back to the first sidebar.

Want a separate window for your console output? Hey, there’s this hack where you can name a tab “console”, bring up the debug lower-pane, set that pane to console output, make the pane fill the window, turn off the left-and-right sidebars, drag the tab out to its on window. Remember to put it back in its tab before closing the window though, or it’ll become your project!

OK, this is not working.

Trying To Adapt

The way I work now is to have everything I used to have in separate windows, in separate tabs; and have Behaviors set to switch to them at appropriate times. I have one Build tab and one Debug tab, set up in a pretty nice way. I mean, this is okay, I can work this way. However, I do lose my focus a lot of the time, and I get lost trying to context switch between tabs. And I need to set this up for every project I start working on. And I can’t really use my secondary monitor for the things I like and used to do. And it’s just a pain.

Fixing Shit

Why alienate all spatial thinking developers from the Mac and iOS developer communies? I can absolutely imagine Condensed Mode working in Xcode 4. The concept of optional sidebars everywhere could still work. I’d just want to pull out the Project navigator sidebar into its own window which becomes the ‘project main’ (closing it closes all related windows); allow some of the more awkward sidebars like the Object Library to be a panel like in IB; have dedicated Build and Console windows; and have the IDE try to suggest the “one file per window” concept (but possibly allow browsing different files within one window is the user really wants to). I mocked up a horrible concept in Acorn, for your viewing pleasure:

This would make me very, very happy. Sure, it’d be half as “fast” as Xcode 3, it’d still forget how to autocomplete once a day, and crash pretty much every minute, but at least I could work with it.

Thanks to Brent Simmons for writing “The part of Xcode 4 that tires me out”, finally triggering me to write this post.

(1): This is why I hate ExposĂ© in 10.6 and 10.7. 10.5 and earlier would lay out ExposĂ© windows with the same relative position of windows as they were when non-exposĂ©d. 10.6 started organizing windows in a frickin’ grid, destroying important information about where a window came from and what role it had. (rdar://7044208)

(2): It’s worth to note that the prevalence of MDI on Windows is a symptom of not having a real application metaphor, and thus having to group all windows in a meta-window in order to regain an actual application context. Mac OS never had this problem, as an application is the primary unit of operation and the main metaphor there, and not the window.

Tagged cocoadev, macdev, iosdev, xcode, faves, flattr, xcode4, ui