This goes out to whichever engineers at Apple fixed the Image Unit template to not suck.
Before Xcode 2.5, that template was useless. Now, it contains everything I need already set up, to the maximum extent possible.
Thank you, Apple engineers.
Make RAM Disk is a simple app to create and mount a RAM disk on Mac OS X 10.4 or later. It encapsulates my previously-stated series of terminal commands into a tiny little app—just launch it and go.
I use my RAM disk for three things:
Enjoy!
If you attended WWDC, you can head over to ADC on iTunes and see what you missed.
It's a minute and a half, and it's 200 K, and you'll need QuickTime 7 to watch it.
pragma mark at work in Xcode's editor.
Useful as #pragma mark is, I wouldn't recommend it for cross-platform code. GCC's documentation of #pragma mark seems to suggest that it's Darwin-only.
Maybe it will come with Xcode 3?
UPDATE 20:55: Never mind.
You may remember Daniel Jalkut's blog post about resolution independence, with its demonstration of the superiority in quality of vector graphics over raster graphics (using an EPS file that I created for him ☺).
The problem with using an EPS file, as I pointed out to him when I emailed him the file originally, is that EPS files are very slow on OS X. The current (Tiger) implementation of NSEPSImageRep uses Quartz's CGPSConverter to convert the EPS data to PDF data, then instantiates an NSPDFImageRep (kept in a private ivar) that it has do all the real work.
That PostScript-to-PDF conversion is the bottleneck. You don't want that multiple-second delay (yes, really) at runtime. Better to take it before runtime. At the time, I suggested that he use pstopdf to convert to a PDF file, then put the PDF file into his Xcode project to be copied into the app bundle.
But what if you decide later to change the PostScript file? You need to remember to run pstopdf again. EPS files are just PostScript source code, so why not treat them like any other source code file? Or, a better question: How?
The answer is quite simple: Add a custom rule to your target in Xcode that runs pstopdf over EPS files. Then, you add the EPS file — not the PDF file — to the project, and Xcode will exhibit normal build-only-when-necessary behavior on the EPS file and copy the generated PDF file for you. And of course, you can have as many EPS files as you want — they're source code files just like any others.
When you build a program in Xcode, you may have noticed that error messages from GCC look like this:
error.c: In function `main':
error.c:2: warning: implicit declaration of function `pirntf'
This shouldn't happen on a modern operating system with modern text capabilities. Fortunately, it is easy enough to make it do the Right Thing, which is to use Unicode quote marks.
First, figure out the correct ISO 639-1 language code for your preferred language. I use English, so mine is “en”. The Library of Congress has a list of ISO 639-1 language codes. In addition, you may want to append a region code; I use American English, so mine is “US”. These should be separated by an underscore; my full language specifier, then, is “en_US”.
Then, append “.UTF-8” to this (= “en_US.UTF-8”), and set it in your LC_ALL environment variable. You can do this by adding this variable to $HOME/.MacOSX/environment.plist. If you don't already have one, you can create it with Property List Editor; you will need to move it to the proper location with Terminal. Either way, you will then need to logout and login.
GCC will then use nice Unicode quote marks in its output:
error.c: In function ‘main’:
error.c:2: warning: implicit declaration of function ‘pirntf’
There's extra work to do if you also invoke builds from Terminal or xterm (whether you use xcodebuild, make, or gcc directly).
In your .Xdefaults file, add these lines:
xterm*font: -*-clean-medium-r-*-*-12-*-*-*-*-*-iso10646-* xterm*boldFont: -*-clean-bold-r-*-*-12-*-*-*-*-*-*-* xterm*utf8: 1
Note that you can specify any font for the two font values; however, “clean”'s Unicode version only exists in plain, not boldface.
This bug is Xcode: Use standard Xcode text view as field editor. It was filed on 2006-04-21 at 22:03 PDT.
Xcode's field editor should be an Xcode text view rather than a plain NSTextView, so that completion and ctrl-left/-right are supported.
The insertion point moves to within the class name.
Xcode/NSTextView beeps.
None.
None.
Technorati tags: Apple Bug Friday, applebugfriday.
This bug is Xcode: Cocoa Document-Based Application template uses old-style document methods. It was filed on 2006-04-21 at 21:19 PDT.
NSDocument documentation recommends using -readFromData:ofType:error: and -dataOfType:error:, but the project template uses the older methods.
MyDocument, from the new document, implements -readFromData:ofType:error: and -dataOfType:error:.
MyDocument implements the deprecated methods -loadDataRepresentation:ofType: and -dataRepresentationOfType:.
Prior to Mac OS X 10.4, this wasn't a problem, because -loadDataRepresentation:ofType: and -dataRepresentationOfType: were not deprecated.
One could make the argument that the deprecated methods should still be implemented so that the new application is compatible with 10.3.x and earlier. But a new application is not likely to require such compatibility. Also, if this argument is indeed the motivation, then the project should target the 10.3 (or an earlier) SDK.
Technorati tags: Apple Bug Friday, applebugfriday.
A couple of tips for using Xcode more efficiently.
Most commands that start an operation stop it as well. ⌘B, for example, starts and stops a build. ⌘⌥R will terminate a running subprocess.
Rule of key commands: With ⌘ and no other modifiers, the key command does at least a build. ⌘⌥ will do that thing alone, without building first. ⇧⌘ opens the progress window for that operation, without actually doing it. This applies to:
Any other suggestions? Please post them in the comments.
Technorati tags: Xcode.
This bug is Xcode's Condensed layout does not have scrollers. It was filed on 2006-04-07 at 23:42 PDT.
The Condensed layout for Xcode's project window does not have scrollers.
The window has or gains scrollers.
No scrollers.
The Default/Detail view, which is the only layout in all Mac OS X versions of Project Builder and the pre-Condensed versions of Xcode and the default in versions that do have Condensed, does not have this problem.
The All-in-One layout does not have this problem either.
The window can be scrolled using a scroll wheel or scroll-capable trackpad, or software such as Catchy Software's MaxiMice. The window can also be indirectly scrolled by using the arrow keys to select the next item up/down.
Technorati tags: Apple Bug Friday, applebugfriday, Xcode.
Xcode comes with a number of document templates. You see the list of them when you choose File→New Document in Xcode. The templates are actually stored at /Library/Application Support/Apple/Developer Tools/File Templates. Most files contain a header comment that looks like this:
/* * «FILENAME» * «PROJECTNAME» * * Created by «FULLUSERNAME» on «DATE». * Copyright «YEAR» «ORGANIZATIONNAME». All rights reserved. * */
The problem is ORGANIZATIONNAME. This gets replaced with “__MyCompanyName__”, and there is no obvious way to change this other than by changing it every time (or by editing the templates, a solution that gets clobbered when you upgrade Xcode).
I was reading Step into Xcode, and found that on page 53, it gives instructions for defeating __MyCompanyName__. Here's the important part, from the book:
defaults write com.apple.xcode PBXCustomTemplateMacroDefinitions '{ ORGANIZATIONNAME = "Joan Smith"; }'
This information is also available on this Xcode release notes page. It's slightly inaccurate (__CompanyName__ rather than __MyCompanyName__) and well-buried, but it documents the same thing as the book.
Presumably, you could override any macro name or add your own using that default. But ORGANIZATIONNAME is the important one.
I debated about posting this here (publicly, rather than only privately to the Adium and Growl developer lists), because I got the info from the book. But I decided that it's OK because (1) it is also documented by Apple and (2) it's an example of the good info in this book. So here it is.
UPDATE 2007-04-07: Markus Magnuson sagely points out that you must relaunch Xcode after making this change. This really applies to any application whose prefs you plan on hand-modifying; Xcode is no exception. Thanks for the reminder. ☺