Adium

Tips and Tricks for Coding on Adium (and in general)

Finding Things

The biggest difficulty for many people working with the Adium code is finding the code you want among the hundreds of other files. Because of this, any tool that lets you sort through the files quickly will help you a lot.

  • Command-double-click is your best friend. It looks up the definition of the symbol you click on, so if you cmd-dbl-click on AIListWindowController, it'll open AIListWindowController.h. It works on methods and functions too. This can be useful in subtle ways; as an example, if you're looking for the code for the message view, but you aren't sure where it is, you can start from the code that controls the message window, find a reference to the message view in its header, and cmd-dbl-click that to get to the message view code.
  • Xcode's file list view has a search field that filters by the text you type. Once you get a feel for the naming, you can often find the files you want very quickly with this. Once you find it in the list, right click on it and choose "reveal in group tree" to see where it is in the sidebar.
  • Project- and Project+Frameworks-wide search is where you turn if 1 and 2 don't work. Type in a related term, hit search, and wait for a while; it'll often turn up the file you need.
  • File -> Open Quickly (cmd shift D). More often than not this will open the correct file. It also searches system headers, so you could, for example, ask it for NSException.h. This also works if you put the insertion caret in a file name (e.g. #include "AIContactContro|ller.h").
  • Spotlight. Generally a last resort, but sometimes it turns up something of interest.

Debugging

  • Make sure you compiled development, not deployment. Breakpoints don't work in deployment, which has led to much frustration.
  • AILog() is a valid debugging tool. Some types of bugs are timing dependent (the server might disconnect you if you spend 20 minutes examining the state at a breakpoint), so you can put logging in around the suspicious area and check on the state that way. It's not as nice as the debugger, but it can prove very useful. Note: AILog goes to the Debug Window (in the Adium menu); NSLog goes to the Console (in /Applications/Utilities).
  • The other use of logs is to leave logging code in beta/alpha builds and ask users to post the data from it. This has solved many hard to reproduce bugs.
  • Xcode's "attach" feature. If you forgot to launch in debug mode, or if Adium starts misbehaving and you want to set a breakpoint to examine it, check out the attach button in Xcode's build results panel. It hooks the debugger into a running program.
  • Apple technotes 2123 (interpreting crash logs) and 2124 (osx debugging magic) are amazing. A brief glance over them can get you such important tools as mallocstacklogging (for finding memory leaks), NSZombie (for finding memory crashers), and the idea to set a breakpoint on -[NSException raise].

Using SVN

  • svn help commandname will get you the info for that command. Very handy when trying to remember arcane svn merge syntax.
  • Before you commit, make sure it compiles!
  • Before you commit, use svn st to see what files are changed (or even better, use svn diff and read through the diff to see if what you're actually committing matches what you think you're committing).
  • Before you commit, make sure that you svn add any new files that you created. Non-compiling code gets committed very frequently when people forget this, because necessary files aren't committed.
  • Here's a quick tutorial on how to merge a commit from trunk to branch: 
    % ls
trunk    branch
% cd trunk
% svn commit -m "Making a change. Fixes #2001."
Committed revision 1234.
% cd ..
% svn merge -c 1234 trunk branch
% cd branch
% svn commit -m "Merge [1234]. Refs #2001."
Committed revision 1235.

Getting Help With Something You're Working On

  • Google. 'nuff said.
  • The Cocoa developer community. That means #macsb and #macdev on IRC, the Mac developer forum on macnn.com, the wiki at cocoadev.com and the tutorials at cocoadevcentral.com. Apple's mailing lists can occasionally be useful as well.
  • The Adium community. We have some truly amazing users, who have made very significant contributions in ticket triage, icons, interface ideas, and other areas. Not sure which way to do something? Take some screenshots of both options, and post a poll on the forum or blog. Don't let it influence you too much though: the development team is the final word on how things should be. Catering to every niche user request leads to preferences bloat, because for every user requesting it, there will be a user requesting the ability to turn it off.
  • The wider development community. Don't remember how static works on global variables? Look it up, there's lots of C tutorials out there. The comp.lang.c FAQ is particularly helpful.

Documentation

WARNING: All of our documentation is incomplete, and the accuracy of it is not guaranteed. However, it can still be a useful resource.

  • Map of Adium This is probably the best documentation resource at the moment. It contains a list of how to accomplish many common tasks in Adium.
  • Doxygen Documentation Less useful until we get more of the code doxygenated and implement a system for updating this page regularly. See this page for information on documenting the code.