Hello. This is Matt, a SoCoder working on improving Adium's AppleScript support.

I've created a page on the wiki here: FixAndExpandAppleScriptSupport

It contains an incomplete list of features that I'm planning on, or already have implemented. If any scripters out there would like to add their input to the design, now would be a good time. I'm interested in any high-level critique of the design as it is now, as well as any suggestions for features I need to include.

Thanks so much!

- Matt

Hi again,

Since there has been some confusion among libpurple developers on how the new registration I added to Adium works, I've created some screenshots that might be of interest to others, too:

1. Creating a new account is unchanged, of course.
2. This is the slightly modified account pane. Note the "Register New Account" button there.
3. After clicking that button, a new view comes up, which allows you to either enter your own server to register to, or choose one from the list (the list is automatically fetched from xmpp.net). The numbers on the right display the geographical distance to that server in km, I'm not sure yet if I should display that. The list is ordered by that number.
4. I'm entering my own testserver of my local LAN, though. You won't be able to reach that one :)
5. After clicking "Request New Account", the view switches back to the regular account pane and Adium (via libpurple of course) connects to that server and requests the registration form and displays it. This form view isn't final, I have to work on that some more to get it to look more Mac OS X-like.
6. I'm entering the data for a new test account.
7. Registration successful! Note that the values have been filled in automatically in the account editor. The account itself hasn't been created yet, though. This will only be the case when the user presses "OK" in that window.

I hope that this will solve the confusion, and why I need those code changes :)

Hi!

This year, I completely forgot to post my inital greeting blog post, so I'll do that now :)

Last year I implemented a Smack-based XMPP plugin, completely replacing the one based on libgaim (as libpurple was called back in the days). However, it got scrapped well after I finished it (more information is available in this blog post).
So, I'm doing the same thing again now, but this time in libpurple. On the one hand, this is much more difficult, since I have to learn a huge codebase, and fiddle around with it. On the other hand, I don't have to implement all the basics like buddy management, since they're already there and are working fine (more or less). So, my plan for this summer is slightly different, and can be found at the Google SoC page (this link will probably cease to work next year).

Since I've already started, there are already some things done, which I'd like to list right here:

• I implemented an XML console that logs all communication with the server, which allows easier problem tracking and enables advanced users to use XMPP features not (yet) implemented in Adium.
  
• PEP is implemented (no config, just publishing, retrieving and subscribing -- should be good enough for now)
• Based on that, I implemented user mood, user avatar, user tune and user nickname.
• I implemented fields requests, which allow libpurple to display forms in Adium and get responses. This not only benefits XMPP, but also other prpls like ICQ. On XMPP, this enables registation forms, setting the account password, setting the vCard's information, and some more I'd like to implement later.

Well, that's all for now, but more is yet to come! I'm really looking forward to having a fully featured XMPP integration right in my favorite client :)

Hey folks,

Before I start, this may all change by next week. But here's what I/we have so far with regards to 10.5

So with 10.5 we've got some issues, like we always do with releases. The main problem we're going to have here with fixing them is that folks who legally have access to 10.5 right now who are having issues are still under an NDA regarding 10.5. However, due to the GPL, any changes released in a binary must provide source code should the person request it. We typically release source with a release because that's just the right thing to do.

So we're between a rock and a hard place. It's caused at least one person (a user who is not affiliated with the Adium team in any way) to question the project in general.

Here is what we're going to do. If you have 10.5, you went to wwdc. If you spent all of the money going to wwdc, you are most likely a developer. So, we need your help fixing things. Some of our developers are at wwdc and have access to 10.5, but of course we don't have the assortment of things with the 10.5 situation that we normally would, i.e., beta testing to a mass audience.

So, if you have 10.5 and you notice a crasher or a problem, if you can create a patch which doesn't reveal any of the new API's in 10.5, that would be the best way of getting things fixed. Even a patch that disables the feature on 10.5 is OK by us, if there's no other non-compromising alternative—we've already done this with the Image Picker. (And yes, we will bring back the feature when 10.5 is released, since the changes needed to make it work will then no longer be covered by NDA.) If you have another solution, please post them in the comments here.

What we don't need are tickets saying that something crashed but with no patches. We can't do much of anything with them without asking for logging normally, which may (doubtful, I know, but still) reveal some private info which would violate your NDA in some way. Right now tickets without patches are just being closed asking folks to reopen them if they are still issues when 10.5 final is out.

Licenses suck. NDA's suck. Ugh.

Anyhow, so if you have any questions about this, have suggestions, or whatever, hop on into #adium on freenode, or comment on this post. We're open to suggestions.

If someone from Apple Legal were to give us confirmation that we could post commits with the new API's in them to our subversion repo, I'd be more than thrilled.


We basically don't want people sued over breach of NDA due to something submitted to us.

Labels: NDA