5

To help simplify debugging of some custom Objective-C objects in the Xcode debugger window, I've created a set of data formatter strings for each of the objects, using the related Apple documentation and Xcode's built-in data formatters as a guide.

My custom summary strings work great if I put it in /Developer/Library/Xcode/CustomDataViews/ with the data formatters that ship with Xcode. However, I'd rather not do that since a user may not have write privileges to that directory, and mixing custom formatters with the built-in ones can be confusing. Similarly, adding my own entries to ~/Library/Application Support/Apple/Developer Tools/CustomDataViews/CustomDataViews.plist also works, but that file is for user-defined values that override the defaults, and its entries are clobbered by changes in the Xcode debugger GUI. What I really want is to be able to place a file with my data formatters in a location so Xcode recognizes them, but users can still selectively override my settings (in another file) if desired.

The problem is that when I create a bundle (following the example of this Apple sample code) and install it (either in /Developer/Library/Xcode/CustomDataViews/ or any Library/Application Support/Apple/Developer Tools/CustomDataViews/ path), Xcode doesn't recognize or use the custom formatters.

The documentation on the specifics of data formatter bundles is somewhat scanty (mostly a single header file in Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin), possibly because the functionality isn't one of the headline features of Xcode. ;-) Any help would be greatly appreciated.

Quinn Taylor
  • 44,553
  • 16
  • 113
  • 131

2 Answers2

4

I've recently been able to come back to this, and I believe I've found the answer.

I already knew that a data formatter bundle must include the property list file internally, named "Contents/Resources/*.plist". However, for the bundle to actually work, it must also include an executable with the same name as the bundle in the Contents/MacOS/ directory. As far as I can tell, even a completely empty foo.c file is sufficient as long as you compile and link a binary. I didn't even have to touch the Info.plist for a stock CFPlugin Bundle project in Xcode, just include the CustomDataViews.plist in the target resources.

Since I don't need to define C functions to display any of the objects and structs I'm dealing with, the far easier approach is to just put the plist file (any name will do — mine is CHDataStructures.plist) into one of two locations:

  • ~/Library/Application Support/Developer/Shared/Xcode/CustomDataViews/
  • /Library/Application Support/Developer/Shared/Xcode/CustomDataViews/

Simple plist files are smaller, trivial to create, and easier to modify. Also, unlike when using bundles, I didn't have to relaunch Xcode when I added, removed, or modified the plist; just starting a new debugging session was sufficient to cause new the data formatters to be updated. I think I was only creating a bundle because that's what the sample code showed, but I can't determine any advantages for my scenario, so I'm sticking with the plist.

Quinn Taylor
  • 44,553
  • 16
  • 113
  • 131
  • As you pointed out, it’s not *necessary* for it to work, but it’s probably best practice to declare a pointer of type `_pbxgdb_plugin_function_list*` with the symbol `_pbxgdb_plugin_functions`, even if it’s empty. – ELLIOTTCABLE Jun 23 '10 at 13:39
2

As of Xcode 2.5 and 3.0, the locations for such things have changed to support multiple versions of Xcode coexisting on one system. You should put your custom data formatters into the directory "Library/Application Support/Developer/Shared/CustomDataViews" in either the local (/) or user (~) domain; then they should be available the next time you launch Xcode.

The Shared in the path above can be a version number such as 3.0 or 3.1 if you're creating something specific to a particular Xcode version.

Chris Hanson
  • 54,380
  • 8
  • 73
  • 102
  • It's good to know of the change (and the reasoning behind it), but I still can't make it work in either the local or user domain. I'm sure those are the right locations, but remember that the bundle doesn't work in /Developer/Library/Xcode/CustomDataViews/ either. Now when I debug with the bundle in the built-in location, it causes an internal error in Xcode. It seems to be an issue with the bundle itself. – Quinn Taylor Jun 19 '09 at 21:23
  • I eventually got both bundles and bare plists to work in Library/Application Support/Developer/Shared/Xcode/CustomDataViews/ (note the "Xcode" in the path). Probably just a simple typo, but I probably wouldn't have found the correct path without your help. Thanks! :-) – Quinn Taylor Jul 08 '09 at 05:22