Adium

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

Getting Started

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.
  • F-Script has many uses, one of which is allowing direct inspecting of objects in a running application. Especially "Select View" can be helpful when working with Adium's Preferences window (or other parts of the GUI) to figure out which objects are connected to which interface elements.

Debugging

  • Make sure you compiled debug and not release as breakpoints don't work in release builds which has led to much frustration.
  • AILog() and AILogWithSignature() are valid debugging tools. 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].
  • Learn dtrace. Introducing it is beyond the scope of this wiki page, but it's an astonishingly powerful tool for gaining insights into what Adium is doing.

Using Mercurial

  • hg help commandname will get you the info for that command.
  • Remember that many hg commands run on the root folder of the repository rather than the current working directory
  • Before you commit, make sure it compiles!
  • Before you commit, use hg st to see what files are changed (or even better, use hg 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 hg add any new files that you created. Non-compiling code gets committed very frequently when people forget this, because necessary files aren't committed.

Getting Help With Something You're Working On

  • Google. 'nuff said.
  • The Adium developer community. That means the adium-devl mailing list, #adium-devl on IRC, IM with one of the team, email, etc...
  • 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.
Page last modified by wixardy, 4 years ago