FileMerger.app (callable from the command line) has I nice built in file tree comparer. To run:

$ opendiff project1/ project2/

This opens FileMerger with a special databrowser for comparing file trees.

Merging can be done using keyboard commands. Useful.

When I first added a new file to my XCode 2.1 project I ended up with something like this:

/*
 *  untitled.cpp
 *  FooProject
 *
 *  Created by Brian H Ray on 11/5/05.
 *  Copyright __MyCompanyName__. All rights reserved.
 *
 */

#include "untitled.h"

The MyCompanyName macro was easily accessible:

$ defaults read com.apple.XCode PBXCustomTemplateMacroDefinitions
{ORGANIZATIONNAME = "__MyCompanyName__"; }

Changing this value with write does the trick. See 'man defaults'. However, I still do not like this header on every file. I want to customize these templates so they are more friendly to doxygen, subversion, and some common class definitions I use with most new files. Here I will use C++ as the example file, although these customization tip works just as well with Java, Cocoa, or any other languages already defined or you define (I added Python). The files I need to customize are located under "/Library/Application Support/Apple/Developer Tools/File Templates". The C++ header looks like:

/*
 *  «FILENAME»
 *  «PROJECTNAME»
 *
 *  Created by «FULLUSERNAME» on «DATE».
 *  Copyright «YEAR» «ORGANIZATIONNAME». All rights reserved.
 *
 */

#include <Carbon/Carbon.h>

So here is the complete list (I think) of the macro available for expansion. WARNING: when opening these templates open the as Unicode, otherwise you will see junk for the start and stop character.

My result template looks like this:

/*!  
   \file «FILENAME» 

   $Id$
   $URL$
   
   \version   $Rev$
   \author    «FULLUSERNAME»
   \date      «DATE»
   \namespace «PROJECTNAMEASIDENTIFIER»
*/
#ifndef «PROJECTNAMEASIDENTIFIER»«FILEBASENAMEASIDENTIFIER»
#define «PROJECTNAMEASIDENTIFIER»«FILEBASENAMEASIDENTIFIER»


namespace «PROJECTNAMEASIDENTIFIER»
{

/*! \class «FILEBASENAME».h "$URL$"
 *  \brief «FILEBASENAME» class from «PROJECTNAME»
 *
 *  
 */
class «FILEBASENAMEASIDENTIFIER»
{


  public:

    //! «FILEBASENAMEASIDENTIFIER» constructor.
    /*!
      
    */
    «FILEBASENAMEASIDENTIFIER»();

    //! «FILEBASENAMEASIDENTIFIER» destructor.
    /*!
      
    */
   ~«FILEBASENAMEASIDENTIFIER»();

};

}  // end namespace «PROJECTNAMEASIDENTIFIER»

#endif // «PROJECTNAMEASIDENTIFIER»«FILEBASENAMEASIDENTIFIER»

When creating a new file from XCode the result looks like:

/*!  
   \file Test.h 

   $Id$
   $URL$
   
   \version   $Rev$
   \author    Brian H Ray
   \date      11/5/05
   \namespace Foo___Test_Project
*/
#ifndef Foo___Test_ProjectTest
#define Foo___Test_ProjectTest

namespace Foo___Test_Project
{

/*! \class Test.h "$URL$"
 *  \brief Test class from Foo & Test Project
 *
 *  
 */
class Test
{


  public:

    //! Test constructor.
    /*!
      
    */
    Test();

    //! Test destructor.
    /*!
      
    */
   ~Test();

};

}  // end namespace Foo___Test_Project

#endif // Foo___Test_ProjectTest

For further expansion of the Subversion Keywords, I added the meta data for these in subversion:

$ svn proplist --verbose test.h
$ svn propset svn:keywords "Id Rev URL" test.h 

The file of course needs to be added/committed to subversion before these are expanded. XCode supports subversion, btw so I do not need to leave the IDE.

Tonight is the monthly meeting of Chicago's Cocoa User Group CAWUG Cocoa and WebObjects.

I emailed the list (the discussion thread) and asked there was any interesting in merging (actually starting) a chapter of Cocoa Heads Chapter. Luckily, there sounds be some interest. Also I was happy to see some members are already listed on PlanetMacDev.

Now all I need to do is to see if they could also cover Carbon, at times--seeing I am more familiar with C++ than Objective-C, personally. If you ask me I would like to see one large group dedicated to Macintosh Development in general: Java, Python, Perl, Cocoa, Carbon, Ruby...there is so much cross over. I would even like to cover people who like to use apple tools to make software for other platforms. Although, I certainly ok with Cocoa being the primary focus for now.

It is fun to see these things come together. So all of you Cocoa Heads, come to the meeting tonight and see what this group is all about. There may be some conversation at the bar after. I can not make it to the bar after, but I encourage all to attend. See their website for more info.

Will the champions of the digital photography world accept Apples new Aperture software without a SDK/API?

Aperture is iPhoto on steroids with a super steep $499 sticker. Competition for Adobe Photoshop? Probably not. However Aperture touts lossless RAW and some seriously cool apple'esk workflow options. But with no DNG or SDK/API Aperture still is no Photoshop.

It is good Aperture aims to gap the lossless image editing gap. This needs done. But as a developer, I imagine the finicky Pro Photography Apple crowd will not be happy to hear there is no way to add features, integrate with specialized devices, or integrate with a larger production workflow.

If Jobs thinks Aperture investment in R&D will help compete with Adobe's Macromedia line and Adobe's highly customizable line of products, he may be missing the mark by not appealing to the large pool of third party developers. Or maybe getting access to the API is only for the privileged, say Motorola in the case of their Rockr phone's use of ITunes.

To me, good R&D requires allowing integration across a broad range of products. For this, a good, open, and solid SDK/API is proof this diligence has been done.

The file merger app which ships with apple developer (/Developer/Applications/Utilities/FileMerge.app) is nice. However, as with all version control systems and desktop diff GUI, there may need to be some glue to hold things in place. Tonight, I wrote a little script to help launch diffs from version control into FileMerger (or any merger application).

Get the DiffBack.py Current Version.

You just run at the command line (or with some small tweaks can be put in IDE menus):

(your local repository) $ ./diffback.py <filename>

And what you will see is something like this:

This show the old version on the left (starts with BASE) and your working copy on the right. Do not save changes to the left version--it will be purged with the program exits.

sudo ln -s  diffback.py  /opt/local/bin/diffback

Well, here you go Mac Developers, Planet MacDev has launched! AFAIK, this is the first Planet Blog for Macintosh Developers. Now there is an aggregated source of developer blogs. Keep them coming.

If you have a blog you want added, sent me a note.

Tonight I wrote a small scripting suite for adding documentation comments to code for doxygen to parse in xcode.

Check it out.

It's very small and not very well tested. But I noticed apple's own HeaderDoc support and wanted support for doxygen as well. These tools parse source code and look in the commented section for documentation keywords. From there, they produce high quality dynamic documentation in html and other formats. Doxygen produces some nice UML type class diagrams as well.

I always saw projects documented with doxygen and wondered how they do it. It's really quite easy. Mac OSX comes with a gui. However, I prefer making a separate build target in xcode and compile my C++ code with a simple shell script. Here is mine if your interested:

#!/bin/sh

# clean the directory
rm -r docs/doxygen

# generate docs
/Developer/Applications/Doxygen.app/Contents/Resources/doxygen  doxygen/Doxyfile

# open the html documentation
open docs/doxygen/html/index.html

I add this a separate build target and then used a Run Script Build Phase. I use xcode 2.0 however these scripts work even back in Project Builder, AFAIK.