Reducing Xcode's Window Clutter

If you do a lot of work in Xcode, your desktop can quickly become cluttered with windows, which can make finding the window you want difficult. This post shows you what you can do to reduce the number of open windows in Xcode.

Grouped Editor Windows

When you open an editor window by double-clicking a source code file in the project window, you will notice a toolbar button in the upper right corner of the window. The button's text will say either Grouped or Ungrouped. Clicking the button changes the text from Grouped to Ungrouped and vice versa.

Grouped editor windows tell Xcode to open only one editor window. When you double-click a source code file in the project window, Xcode places the contents of the file in the single editor window. Ungrouped editor windows tell Xcode to open a new editor window every time you double-click a source code file in the project window. Grouping editor windows eliminates a lot of window clutter.

Editing in the Project Window

If a single editor window is too much clutter for you, you can edit source code in the project window. Click the Editor button in the project window toolbar to open an editor in the project window's detail view. Clicking the Editor button a second time brings back the original detail view.

All-In-One Layout

The first two tips eliminate the clutter of editor windows. But Xcode's default layout still creates lot of external windows: run log, debugger window, build results window, search results, and SCM results. How do you keep all these windows from opening? The solution is to switch to Xcode's All-In-One layout, which places all the external windows in the project window.

To switch to the All-In-One layout, open Xcode's preferences window by choosing Xcode > Preferences. Click the General button in the preferences window toolbar. Choose All-In-One from the Layout pop-up menu. The following screenshot shows what the All- In-One layout looks like.



The All-In-One layout looks similar to the default layout, but you will notice a Page area in the upper left corner of the project window with three buttons. The left button is the Project page, which looks like the default layout, but with two tabs for search results and SCM results. The center button is the Build page, which gives you access to the run log and build results window. The right button is the Debug page, which gives you access to the debugger window.

New Xcode Tip: Supplying Launch Arguments for Command-Line Programs

I added a tip to the Xcode Tools Tips page on supplying launch arguments for command-line programs from Xcode. This information is tucked away in the excerpt from the Xcode chapter, but it's difficult to find. I saw a question about supplying launch arguments on a message board, and another person emailed me about it. When multiple people have the same question, it makes sense to add a tip so everyone can benefit.

New Xcode Tip: Changing the Executable Name

I added a new tip to the Xcode Tools Tips page on changing the executable name in your Xcode projects. If you don't want to read the whole tip, I can summarize it in one sentence. Change your target's Product name build setting, which is part of the Packaging collection.

New Bundles Article

I have a new article on bundles available. It introduces bundles, focusing on application bundles. After reading the article, you will know how to create a bundle, add files to the bundle, and retrieve files from the bundle.

Leopard Delay a Blessing for Me

Apple did me a favor as a writer by delaying the release of Mac OS X 10.5 from June to October. With a June release I would have had a difficult decision to make: delay updating Xcode Tools Sensei until I finished the OpenGL book, or delay development on the OpenGL book to update the Xcode book. Apple gave me another four months to finish the OpenGL book.

All updates for Xcode 3 and Leopard will come in a new edition of Xcode Tools Sensei. Xcode and Interface Builder are going to have major updates. Trying to juggle Xcode 1.x, 2.x, and 3 in one text would be difficult for me to write and you to read. I also will have to take a bunch of new screenshots so it makes sense to have two versions of the book: the current version that supports Xcode 1.x and 2.x, and a new version specifically for Xcode 3. The electronic edition of the Xcode 3 version would be available at a discount for everyone who has the current version of the book.

Skim PDF Viewer

Skim is a free, open-source PDF viewer for Mac OS X. Mac OS X comes with Preview, which views PDF files, and Adobe Acrobat Reader is freely available so what makes Skim special? Skim has features that make reading technical articles and academic papers easier.

The first of these features is the ability to add notes to a PDF document. It's the electronic equivalent of adding sticky notes to a paper document. When you're reading difficult material, being able to make notes to yourself helps in understanding the material.

A second useful feature is the ability to highlight areas of text by putting a circle or box around it. A third feature is snapshots, which let you keep important pieces of a document in easy reach.

Skim is at version 0.2, which means it's far from a finished product. But if you read a lot of PDF technical articles, you should give Skim a test drive.

Using Saturn on Intel Macs

I read a post on Apple's performance and optimization mailing list that tells you what to do to use Saturn on Intel Macs. This information may be useful to some of you so I am writing about it here.

To use Saturn to profile your code, you must compile your code with either the -pg compiler flag (Generate Profiling Code build setting in Xcode) or the -finstrument-functions compiler flag. The -pg compiler flag is the flag most people use, but Apple hasn't added the support for -pg on Intel Macs yet so using the -pg flag won't allow you to run your code with Saturn on an Intel Mac.

The solution is to use the -finstrument-functions flag to compile your code. I didn't see an Xcode build setting for this flag so you'll have to add the flag to the Other C Flags or Other C++ Flags build setting in Xcode.

I don't have an Intel Mac so I can't test this for myself, but the information came from an Apple engineer so I will assume the information is accurate.

OpenGL Book Progress Report for March 2007

I haven't posted anything about the OpenGL book for a while, but I am writing to let you know I am still working on it. Progress has been excruciatingly slow, which has been very frustrating to me. On the code front, I've been working on the physics code. On the writing front, I have a lot of material written on several chapters, but I still don't have a finished chapter. Whenever I write about something, it brings up several additional topics I have to write about. When I write about those topics, it brings up more things to write about, which makes finishing difficult.

I'm Changing Website Hosts

I have started moving the Me and Mark Publishing website to a new host. Everything should be transferred within the next 1-2 days. Hopefully there won't be any problems. I will add an item to the Latest News section about the switch. If you see the item on the Me and Mark Publishing home page, you're viewing the site with the new host.

Seeing Xcode's Build Errors

When you build an Xcode project, Xcode tells you whether or not the build succeeded. If the build succeeded, that's all you need to know, but if the build failed, you want to know what the errors are so you can fix them. Xcode has two places to look at your errors: the Errors and Warnings smart group and the build results window.

Errors and Warnings Smart Group

In the project window's Groups and Files list, you will see the Errors and Warnings smart group. Select the Error and Warnings group and the project window shows the build errors. Double-clicking an error or warning takes you to the line of code where the error occurred.

Build Results Window



When you need to see more detailed information about your build, use the build results window. Choose Build > Build Results to open the build results window. The build results window has three sections. The top section is the build results, which shows the high-level build steps. The middle section is the build transcript, which shows the low-level steps Xcode takes to build your project. The bottom section is the editor. Selecting an error from the build results or the build transcript shows the line of code in the editor where the error occurred.

Showing the Build Transcript

If you open the build results window for the first time, you won't see the build transcript. The build transcript is initially invisible, and you must tell Xcode to show it. Below the build results are four small buttons. Click the third button to show the build transcript.