The beta of the next Adium release is now up on the beta page. :)

As many of you know, blocking is currently not functioning very well. Some fixes that jmelloy introduced, which I backported to the 0.8, should clear this problem up. Hopefully. We've also added some console logs to help us debug any problems you're having.

By the way, anyone in Hawaii looking for a programmer? I'm currently looking for a job out here. I've worked as a web developer in the past, but, ideally, I'd like to do something OS X related. Feel free to contact me directly.

- Visiting the blog from our atom feed should now work correctly
- Community links have been added to the main page, along with a source download link
- The documentation has been seriously beefed up and now includes an easy to use side-navigation-thing

I hope the documentation and bug reporting / requesting are easier to understand now. It's pretty exciting (and scary at the same time) to see all the tickets that have been file so far - but I love having all those bugs on file, so keep up the good work :)

I just wanted to stop here for a moment to announce that we have now a screenshot gallery engine that is more user friendly and leaves the visitor with some stuff to click in order to go back to the image index or another tab. We also have a nice fixed footer for the main page so it doesn't look too weird on big screens (unless you are using IE/Win, we feel your pain).

And in unrelated news, I recently got a job as tech support guy in a local Apple Reseller, so my spare time is scarce. On the other hand, I'm almost free of my WoW addiction and my mind is more open to use that spare time in different stuff, so I expect to continue helping with Adium when I possibly can, like this small improvement to the fantabulous new site.

So I guess I'm supposed to talk about things in here which pertain to adium right? Or something like that. BLA!


So in case nobody noticed we rearranged some things on the website. This was done in the hopes that the website would be easier to use. We've killed the bugs forums and moved that over to trac. This is important because now it's really easy to search through open tickets before making a new one. This should hopefully make maintaining the stuff you guys are submitting to us easier.

One important thing that would really help us is if you guys set a version and a component. Let me explain these fields a little bit, so that hopefully some people have a better understanding of the situation. Basically it's as follows:


Version: Version shows what version this is currently affecting. Say you have a problem with dock icons in version .81. You would set the version to .81 in the trac ticket. This helps us to know easily which version this affected you in, and helps us to reproduce things.

One other field to be concerned with is the component drop down. This allows you to say easily that "this is for the message window" or "this is if the ICQ protocol". If you set this it helps us when we look for similar issues with the same component. There is a rather silly component called "El vision del Tick". Leave that one be, it's something we're using to play with new ideas. All other components should be useful to you guys and girls, so have fun.


Setting these fields correctly will really help us. We can spend less time maintaining the tickets, and more time working on the actual problems.

so I'm working on a completely new version of AIKeychain, the class Adium uses to access the keychain. the new version is more of a wrapper of Keychain Services, the Carbon API for working with keychains.

my problem is how to deal with the error codes that Keychain Services returns. I don't want to just throw away the errors, as they could be important (most of them anyway - does anybody think that SecKeychainGetVersion is likely to return an error?). neither do I want to throw an exception - handling exceptions makes for messy code. and returning BOOL is:

1. not much better than throwing away the error completely - fine, it failed, but how?
2. unwieldy, as it means that all the methods that return anything must return it by reference

the solution I currently have in place is to return an NSError by reference. this works well because:

• the error can be ignored if desired (pass NULL).
• the error contains the OSStatus returned by Keychain Services as its error code.

the problem with this is the method name. consider:

+ (BOOL)allowsUserInteractionError:(out NSError **)outError;

I don't like how 'Error:' runs right up against the actual name of the method. ideas?

In most IM applications the contact list is the primary window. However, I think that a transparent, borderless, buttonless window makes for a very poor primary window. The instinctive solution would be to make the contact list larger, less customizable, and more conveying of functionality... but is this really what the contact list needs? Would the contact list somehow be a better way to display buddy presence if it was larger and contained more buttons? I don't think so. Why, then, is the contact list our primary window?

Also, is all the information on your contact list equally important? Is there information on the contact list that isn't important at all? Are there people on your contact list whose presence you care more about? Think about it for a bit. There are three types of buddies: 1) Those whose presence is very important 2) Those whose presence is sometimes important 3) Those whose presence is rarely important. Why are all those clumped together in a giant list? Why do I need to keep them all on my screen in this funky tall and skinny window?

Furthermore, if the contact list is such a natural window, why are people so obsessed with customizing it? Why do users feel the need to camouflage the buddy list into their desktop or modify it to blend in with their system in some way? Why aren't the same demands applied to an FTP client or a web browser? I've certainly never seen someone tweaking out iPhoto to make it match the desktop picture. It's because that window HAS to be on our screens so that we can keep dibs on our buddies whose presence is very important. It has to be there, we have no choice, so lets do our best to make it blend in.

So, is there a better way to do this? What if we removed the responsibility of being the primary window from our contact list? What if there was some way for us to see type 1 contacts all the time, have type 2 contacts within easy reach, and have type 3 contacts retrievable when necessary with a bit more work? What if we didn't have to work so hard at blending that awkward little reject of a window into our computing environment? What if we could IM, better than we do today, without a contact list window at all?

I guess since we're doing a roll-call of summer plans, I'll sound off. By the way, hello! I hope you like the new website, I know I do.

I'm hoping (knock on wood) to be employed this summer at a large software firm in the MD/DC/VA area. Since I'm still talking with them about things, sending in my resume, etc., I can't reveal any details just yet. However, I am curious to see what it's like working there. I'm also concerned about is wether or not they wiil let me work on Adium while I'm working for them (they do share a very similar market with Adium).

If all goes well, I will have free time to work on Adium this summer. The next six months or so are going to bring a lot of cool new changes, so keep your eyes peeled.

Unfortunately (although exciting) for me the summer's not going to be a vacation from the real world, but more of a dumping into it. I'm only one quick summer class away from graduating, which means that I'll be searching for a job soon. I'm still not sure what I want to get into, it seems like there are too many choices :-)

If anyone has advice (serious job offers welcome as well ;-) ) on the best way to go about this whole process I'm all ears and feeling a bit in over my head at the moment.

I want to find someplace where I feel productive, yet I don't want too many restrictions placed on what I can do outside of work (I'd prefer to keep chugging away at Adium in my spare time). I think the latter restriction is going to be the challenging one, but I'll admit that I haven't really started asking around yet.

The summer is upon us... I'm looking forward to having a much-needed vacation from the "real world" and having some extra time for Adium work, and I know a lot of the development team feels the same. Bright things are still ahead for Adium... and we're thrilled with the response we've gotten thus far, with over 100,000 downloads of Adium X 0.81. :)

I hope everybody likes the new site design! We're still ironing out a few issues but overall things are complete.

The good news is that we have Trac going now (On the support & dev tab), which should help us keep all our information organized and up to date. It's also got a bug and request ticketing system which I'm sure may of you will be happy to see, and a wiki for documentation. The wiki is brand new, but I expect it to flesh out nicely in time and hopefully contain enough information to answer any question that comes up.

If you haven't noticed, the site is less orange now too. Which, depending on the health of your retinas, could be considered a good thing. :-)

There are currently problems connecting via Adium to the default Yahoo server, resulting in the error "Unable to read." A temporary workaround is to change the Login Server to scsdcntest-c.msg.yahoo.com in the Options tab of each Yahoo account's preferences.

This minor update to Adium 0.80 primarily fixes issues for non-English users, including resolving crashes when working in the Events preferences and when initiating OTR sessions. Localization isn't easy! Other notable fixes include dock icon updating to reflect status, minor improvements to blocking support, and automatic compression of folders for file transfers. See the version history for all the details.

The Adium team is proud to announce the availability of Adium X 0.80, a major update to its multi-protocol instant messaging application. Adium 0.80 brings a completely new status system with available messages and invisibility on supported protocols, built-in secure encrypted messaging via Off-the-Record Messaging, the long-awaited file transfer progress interface, customizable built-in Growl notification system support, blocking, customizable service and status icons, full OS X 10.4 compatibility, and much, much more.

See the Version History for a summary of changes, or the full change list for a mind-boggling look at just how much we've accomplished in terms of new features and bug fixes since work began on Adium 0.80 in October 2004.

An exciting highlight: Adium 0.80 is now officially multilingual! Adium is now translated into Danish, Dutch, French, German, Italian, Japanese, and Traditional Chinese. This is the first translated release, so please remember that translations are a work in progress; there are still some small parts of Adium which remain in English. The Adium forums now have an Adium Localizations subforum where you can help if you're so inclined.

We'd like to thank our hosting providers for their donated bandwidth, storage space, and time. The Adium 0.80 download is hosted by Cache Fly whose high speed and low latency we're sure you'll appreciate. The Adium code repository and email accounts are hosted by Penguin Militia Networks who will donate $5 to Adium for every new account which lists us as the referral. And, if you enjoy Adium 0.80, please consider showing your support directly.

A lot has changed; we've made every effort to migrate preferences from Adium 0.7x, but some components -- notably the Events system -- were so completely rewritten as to make that impossible, so please explore the redesigned preferences before reporting issues. :)