Pidgin News

So, it seems the Facebook has finally added support for logging in to their Chat via XMPP. This is, of course, awesome so people stop asking about it, but also terrible since it took them so darn long. That meant a lot of horrible hacks just to get it working in the interim. (No offence Eion, I just mean the scraping, not the code.)

This announcement comes straight from the developer blog. You need to have set up a username (which you can check here). Casey's blog has all the screenshots you need to figure it out. The only downside is it doesn't use encrypted streams.

The biggest problem, though? Having to organize a few hundred buddies into their correct contacts.

As many of you Yahoo users out there know, Pidgin 2.7.0 and 2.7.1 introduced a challenge for you. In certain proxied environments, many of you can't connect. Quite frankly, (mostly) it's my fault. Let's start by explaining what I've done.

Direct connections for MSN! What do I mean? Just take a look at the screenshot below.

What's that? You don't see it? Just take a look at how fast it's going. Yes, that's right; it's not a pitiful 10KiB/s, but about an order of magnitude faster.

It all started with this little patch on trac. But it required a lot of work to get it going. I must have made at least 60 commits just fixing things and getting it to cooperate with aMSN and the official client. I think it should be good now, but you can always disable it in the Account options. It even makes buddy icon and custom emoticon loading faster.

Anyway, I promised I would say something about 2.7.1, and here you go. Direct connections will be in 2.7.1. In fact, I'm just about to push all the revisions.

Have you ever started committing things in Monotone and then realized "This should probably go in a separate branch"? It's somewhat difficult to fix that. You can add a new branch cert, but the old one won't go away.

I wrote a little script based on a mailing list message I saw. It removes the old branch cert, and adds the new one, moving forward along revisions. It even changes merges with "the rest" into propagate messages instead. There are limitations, though. It only works with linear history (but if you've been working alone, that shouldn't be a problem) and it requires mtn 0.45 (since it uses the binary cert format.) Of course, it goes without saying that if you've shared any of your changes with someone else, then this is pointless (or you'd have to change everyone's database.)

It's pretty short. Make sure those SQL statements don't break up when you copy it.

#!/bin/bash

set -e

DB=db.mtn
KEY='someone@domain.com'
START=0123456789abcdef0123456789abcdef01234567

OLD_BRANCH='com.domain.main'
NEW_BRANCH='com.domain.fancy-stuff'

prev=
curr=$START
while [ -n "$curr" ]; do
    echo "Changing revision $curr"

    mtn --db=$DB db execute \
      "DELETE FROM revision_certs WHERE hex(revision_id) = upper('$curr') AND name = 'branch';"
    mtn --db=$DB -k$KEY cert $curr branch $NEW_BRANCH

    parents=`mtn --db=$DB automate parents $curr`
    if [ `echo "$parents" | wc -l` -eq 2 ]; then
        # Fix a merge
        echo "Fixing merge for $curr"
        mtn --db=$DB db execute \
          "DELETE FROM revision_certs WHERE hex(revision_id) = upper('$curr') AND name = 'changelog';"
        other=`echo "$parents" | sed -e "/$prev/d"`
        mtn --db=$DB -k$KEY cert $curr changelog \
"propagate from branch '$OLD_BRANCH' (head $other)
            to branch '$NEW_BRANCH' (head $prev)"
    fi

    prev=$curr
    curr=`mtn --db=$DB automate children $curr`
done

Well, I finally managed to kick Pidgin 2.7.0 out the door, as most of you are surely aware of by now. There are several important things to note about this release:

• AIM and ICQ clientLogin issues have been resolved. You should be able to now use both clientLogin and SSL together.
• Our internal libgadu has been upgraded from something from the stone age to something much, much more current. This solves the issues that (primarily) Windows users had with not being able to communicate with new (> 17,000,000) Gadu-Gadu numbers.
• Our Yahoo and Yahoo Japan plugins now retrieve connect server information directly from Yahoo, just like the official clients do. This took me way too much time to implement, but I believe I've implemented a fairly stable and maintainable method to retrieve this information. During this process, I learned a lot about how Yahoo's authentication works and made some improvements there too that will make us look much more like the official client on the wire during authentication.
• ICQ now has X-Status support! It took far longer than it should have--I originally wanted this in for 2.6.0 but it was nowhere near ready.
• Minimum GTK+ and GLib requirements are now 2.10.0 and 2.12.0, respectively. This allowed us to drop some 3800 lines of code, much of which was the result of needing to bundle certain GTK+ widgets so Pidgin could function on platforms with ancient GTK+. This also makes use of many of glib's convenience functions much more convenient.
• The Windows installers have changed to be less obnoxious with respect to GTK+. We no longer install a system-wide copy of GTK+ and instead install GTK+ locally to the Pidgin installation. This may disrupt some GTK+ theming. The other big thing is that now, the default installer will download GTK+ and optionally the debug symbols (so there's no longer a special debug installer needed for crash reports!). There's also an offline installer that, while almost double the size of the default installer, I prefer to use. This offline installer includes GTK+ and the debug symbols. I prefer to call it the everything-but-the-kitchen-sink package (the kitchen sink in this case being spell checking support, which still must be downloaded).
  

Of course, any release I had a major role in is bound to have problems. I built the Windows installers this time around, and did not know that I needed to do extra work to make the online installer function. Thus, many of you complained (and complained, and complained some more!) that the installer didn't work. Even after Daniel fixed this for me, we still saw complaints. If the online installer does not work for you, try the offline installer. I tested the offline installer and it worked for me. I forgot, however, to test the online installer. I was more interested in getting the release out in order to (I thought) minimize complaints.

Additionally, after I cut the tarballs for 2.7.0, several bug fixes rolled in that will be delayed until 2.7.1. Among these are a couple minor annoyance fixes for MSN and XMPP. And today fixes for more bugs rolled in, including two for Bonjour and a fix for the taskbar entry (window) flashing on Windows. I plan to push out Pidgin 2.7.1 in a couple weeks to resolve these, and hopefully more, problems.

In the mean time, enjoy!

So it seems like I only post about minor releases (as opposed to micro), but I promise that I'll definitely say something about 2.7.1.

Anyway, Pidgin 2.7.0 should be released pretty soon now. You may or may not know that the release versions are dictated by API/ABI requirements. A minor release means we've added API. I wouldn't say there are tons of new user-visible features in this release, but definitely some developer-related things.

Most importantly, we dropped support for old GTK+ and GLib, requiring 2.10.0 and 2.12.0 respectively. Visibly, that means we can't support Windows 98 anymore, but I think we can say that's an acceptable loss by now. For development purposes, though, that means a ton of code that can be removed. It means a lot less code that needs to be maintained. We also were able to upgrade some things like from EggTrayIcon to GtkStatusIcon, which is better at integrating into the notification area.

Don't worry; it wasn't all development changes. We've also got integrated Mood setting. This interfaces to ICQ and XMPP, so I don't know too much about it. More in my area, MSN gained support for file transfer previews, which show up in the request window and the conversation.

There are quite a few other changes that I don't really even know about, so you might want to check the ChangeLog.

So last week the accepted proposals for GSoC were announced. Pidgin was given 4 slots.

First up, we have Ivan Komarov working on improving ICQ. I don't really use ICQ, so I can't say much, but if you do, hopefully there'll be a lot of great things coming out of it that will be useful to you. Next up is Adam Fowler working on a better chat log viewer. People really seem to complain about what we have now and at the very least, it's kind of slow once you have a lot of logs, so there should be room for some good improvements there. And then we have Gilles Bedel working on detachable libpurple sessions. I'm not sure how often I'd use it, but every once in a while, I feel like checking in on Pidgin from the laptop and it's a very painful process through SSH and D-Bus. This project should make that sort of thing much simpler. Finally, we have Jorge Villaseñor Salinas working on refactoring MSN.

So that last one is the one I'm mentoring. Personally, I've been wanting to re-write bits and pieces of the MSN prpl for a while now, but I've never had the time to get around to it. Jorge's already done some great work getting custom smiley support working for Pidgin 2.5.0. I'm sure he'll have no problem re-working the MSN prpl. I'm looking forward to getting a more structured and (hopefully) well-designed prpl which should make development a lot easier and quicker.

OK, maybe I'm being a bit sensationalist there, but it's my blog, so I'm allowed! Anyway, on to the subject matter.

Recently we've seen a few users in #pidgin (and I've received some emails too) with some strange issues that result from plugins doing things they really shouldn't but can anyway. I'm going to run down a small punch list of items for you, as plugin authors, to do to prevent your users having hard-to-diagnose issues.

• Never use printf() in a plugin. This causes terminal disruption for Finch users and is a bad idea in general. It will probably behave unpredictably on Windows and/or in other UI's too. We provide a debugging API to avoid this kind of stuff. Instead of printf(), use purple_debug_info() or purple_debug_misc(). You can see the debug output (even during initial startup) if you run 'pidgin -d', even on Windows and even if your Pidgin is built without '--enable-debug'. For Finch, you can do 'finch -d 2> finch_debug.txt' to get your debug info.
• Don't lie about UI requirements. If you use GTK+, you're a Pidgin plugin, not a "core" (or libpurple) plugin. If you use GNT (or if you're really brave and use ncurses directly), you're a Finch plugin. There are plenty of examples in the Pidgin and Purple Plugin Pack source trees that show you how to properly declare your UI dependency. The UI requirement is designed specifically so that plugins requiring a specific UI can't be loaded by, and thus cause problems for, other UI's. Sure, it's possible to make a UI-agnostic plugin that requires GTK+, but I guarantee it will cause at least one or two Finch users unnecessary problems.
  
• Install your binaries to the correct place. If you're installing a Pidgin plugin, install to $prefix/lib/pidgin, not $prefix/lib/purple-2. If you're installing a Finch plugin, install to $prefix/lib/finch. This will prevent other UI's from needlessly trying to probe your plugin and is just general courtesy. (Note that this particular item doesn't apply to plugins for Pidgin on Windows at the moment, but may be important later.)
• If your plugin is a protocol plugin, you absolutely are not allowed to touch UI-specific code at all. That means no GTK+, no GNT, no XUL, etc. If you need UI elements, use the request API libpurple provides. If the request API doesn't cut it, there are other approaches you can take, such as having two plugins, one of which does the actual protocol work and the other providing the UI. A better approach, though, is helping us identify where the request API is lacking so we can improve it. We know our API's aren't perfect, so when someone can show us a concrete reason why we're deficient, we will try to fix that deficiency.

Please check your plugins for these problems and help your users have a more pleasant experience with your plugins!

It feels like it's been forever since I stepped up on the soapbox to say something. This time it's just a relatively short update.

As is very commonly known, Pidgin was accepted as a mentoring organization for the Google Summer of Code again this year. This year, Google has given us the privilege of mentoring four students. While less than we hoped for (we'd wanted five), we certainly can't complain about the projects we were able to accept.

First up is an MSN project manned by Jorge Villasenor Salinas, who some may recognize as having helped implement custom emoticon support for Pidgin 2.5.0. His project is to rewrite the SLP layer of the MSN plugin, simplify the other parts of the plugin, and overall make the plugin much easier to maintain and extend. I'm sure he'll be trying to squeeze some new features into his project if time allows.

Next up is one of my personal favorite projects for this year. Gilles Bedel will be working on detachable sessions. This is something a number of us have wanted for a long time, but just haven't quite gotten around to making it happen. The idea here is that we can have a daemon (service for the Windows-inclined among us) running in the background and connect to it with Pidgin or Finch at will. I feel that this is perhaps the most ambitious project this year, but the benefits it could reap are worth it.

Adam Fowler is going to rewrite the log viewer in Pidgin. This particular project will likely be the only project that visibly changes Pidgin this year. We've received a lot of complaints and suggestions over the years focusing on our log viewer. We know it's deficient in a lot of ways, and that's what Adam's project aims to resolve. I'm confident we'll get a lot of positive feedback about this project once it's complete.

And last, but not least, is Ivan Komarov's ICQ project. Ivan's aim is to beat our ICQ implementation into shape. As most of our non-US ICQ users can confirm, our interaction with the service could use some improvements. While Ivan has proposed a nice wide range of things to fix, even just a few of them being completed would make a huge difference for our international users.

So, from all of us developers, and we hope from our users too, good luck to our students!

When I started working on Pidgin eight years ago (eight years‽ holy crap!) my main focus was the code used to connect to AIM and ICQ. The protocol is called ‘OSCAR,’ and it is a proprietary protocol created by AOL.

As IM protocols go, OSCAR is actually quite decent. Flexible, extensible, reasonably concise. Could maybe be simpler.

Background

AOL’s history with public access to their IM network has had its ups and downs.

• In 1998 a few AOL employees released a GPLv2-licensed IM program called ‘TiK.’
• Sometime in 1999 this project was abandoned by the AOL employees. Some non-AOL employees created a TiK project on SourceForge and continued development.
• Things were good.
• In 2001 AOL made changes to their protocol in an attempt to block unofficial clients. Some people believe these changes were made to block Jabber<–>AIM transports, and that Pidgin (named ‘Gaim’ at the time) got caught in the crossfire. Pidgin developers were able to keep the program working for the most part, and AOL relaxed their efforts to block unofficial clients.
• Things were good again.
• In 2008 AOL announced Open AIM. Open AIM was a lot of things: A set of SDKs for interfacing with AIM and the AIM servers. Documentation for the OSCAR protocol. A forum for users to ask questions.
• Things were great… for a time.

Recent Changes

Sometime in January, February or March of this year AOL decided to shut down the Open AIM program. No more SDKs, no more protocol documentation, and no more developer outreach.

More specifically, the OSCAR documentation provided by AOL described a method of authentication (using a “startOSCARSession” API request) that required the use of a developer application key. The current Open AIM website implies that new keys cannot be created.

Now What?

Does this mean the use of startOSCARSession is deprecated? If so, what auth scheme should we use, instead? Should we go back to BUCP, the authentication scheme used by AIM 5.9? Should we try to reverse engineer the authentication scheme used by current version of AIM? Should we go back to masquerading as the official AIM client and stop politely identifying ourselves as ‘Pidgin’?

To quote the great Yoda, “the shroud of the dark side has fallen.”

As bug master for Pidgin, I bear a lot of the responsibility for triaging bugs--getting them assigned to the appropriate developers, weeding out the invalid bugs, etc. I admit that lately I’ve not been doing such a good job at this. I’ve been ignoring Pidgin so I could relax and unplug somewhat after the stress of work. Thankfully, in my increased absence, my fellow developers, particularly Paul, Daniel, and Elliott, have been picking up the slack. All the while, however, not much has changed as far as actual ticket resolution goes.

As much as I hate quoting numbers, let’s take a look at some (as of 2010-01-31, 0500 UTC) to get an idea of scope:

• Historical ticket count: 11270
• Currently open tickets: 1818
• Open bugs: 958
• Open bugs awaiting response from reporter: 11
• Bugs that can’t be fixed until we’re ready for 3.0.0: 19

Obviously, 958 open bugs is unacceptable. But to put those bugs in perspective, let’s look at how they break down:

• AIM: 64
• artwork: 9
• Bonjour: 4
• custom emoticons: 2
• finch: 7
• Gadu-Gadu: 19
• Google Talk: 3
• Groupwise: 7
• ICQ: 47
• IRC: 26
• libpurple: 68
• MSN: 70
• MySpace: 17
• pidgin: 198
• plugins: 28
• QQ: 23
• Sametime: 13
• SILC: 6
• SIMPLE: 3
• trac: 4
• unclassified: 160
• Voice and Video: 11
• webpage: 3
• winpidgin: 81
• XMPP: 47
• Yahoo!: 35
• Zephyr: 3

Now, yes, on an IM service level, MSN has more open tickets than any other listed service. However, looking at the underlying protocol for these services, AIM and ICQ combined give the OSCAR protocol a 41-ticket lead. Google Talk is an XMPP service, but even combining Google Talk and XMPP numbers, we come up with 50 tickets, trailing MSN by 20. None of our other listed IM services share an underlying protocol with another. In fairness, the unclassified bugs really should be sorted into proper components, which would change these numbers, but at this time I don’t know by how much.

Now, looking at the IM services we support, many of them don’t have a current “maintainer” who is ultimately responsible for the plugin. Currently, Zephyr, Yahoo, SIMPLE, SILC, Sametime, MySpace, Groupwise, Bonjour, and QQ either have no “official” maintainer, have no one at all working on them, or haven’t had meaningful development activity in at least three months. Obviously, protocols without an active maintainer are not going to see much in the way of quick bug resolution.

We‘re often asked, “Why don’t protocols have maintainers?” or “Why don’t you spend time working on bugs?" or a hundred other questions about the lack of time spent working on Pidgin. The reasons for this are many:

• We’re all volunteers. Not a single one of us gets paid to put any time or effort into Pidgin.
• Not all of us use all the services we support. I’ll use myself as an example here. I use AIM, ICQ, Yahoo!, and XMPP regularly. I also have an MSN account that I couldn’t possibly care less about and a couple IRC accounts for the rare instance that I need to test something with the Purple Plugin Pack. I don’t use, nor do I have interest in using, any of the other services.
• We all have families that we’d like to spend time with. Many of us have spouses/significant others, and a few of us also have children. Family is a demand on our time that should never be ignored.
• All (or almost all) of us have jobs. Since, as I already mentioned, we’re volunteers, the jobs with which we earn our paychecks have to take priority.
• We’re human too--we get burned out, experience stress, need to unwind after work, etc.
• Not all of us know anything about a given protocol, nor can we be reasonably expected to. For example, I don’t know how the MSN protocol works, and I have no desire to learn about it. We don’t have to be experts in a given protocol if we don’t want to be. Also, the fact that MSN is allegedly the most-used protocol in the world is not a valid reason for anyone to expect us all to be experts on (or even to care about) the protocol.
• Pidgin largely just works for us. If we don’t see a bug, we’re not going to be irritated by it and sit down to try to fix it.

So yes, we have been “neglecting” Pidgin to a certain extent. Our time is a precious resource, and in many cases we simply have better things to do or simply don’t have the time to sit down and attack bugs to get them closed. That’s not to say that our development process is coming to an end or that we’re abandoning Pidgin, though. We do, however, readily admit that we need fresh blood.

In that vein, I’m calling for you, the Pidgin community, to help us. Take a look at the open bugs and feature requests and submit patches to resolve them. Pidgin is a fairly complex beast, and there’s a lot of code to maintain, but it is manageable if people work on small changes at a time (instead of completely rearranging things unnecessarily). Additionally, Pidgin uses a distributed version control system, monotone. Contributors who want to seriously work on Pidgin can use this to their advantage by creating their own branches in monotone. When contributions are ready, those contributors can submit the changes from their branches either by attaching patches to tickets on trac or by asking a Pidgin developer to pull and review the changes. At that point a developer can commit or merge the changes and push them on to the central repo at mtn.pidgin.im.

The only problem with the model of a developer pulling changes from a contributor is that in order for someone to pull revisions, the contributor must be able to run mtn in server mode, which isn’t always possible or feasible. I’m trying to come up with some custom lua code to help in this regard, to do something similar to what git and hg can do with emailing patches, but that’s going to take some time, as I need to learn some more of the internals of monotone first. But none of this should stop anyone from trying to contribute! We will still accept single one-off patches or sets of patches and series of patches from longer-term contributors, and using monotone to develop against is going to produce patches that are the easiest for all of us to work with.

So, yes, in short, Help Wanted and Needed!

Sooo, Pidgin supports voice and video now.

It's only on XMPP (aka Google Talk), and only on Linux, but hopefully that will change soon. I hear it's a real pain to get all the farsight/gstreamer dependencies compiled for Windows right now.

And here's hoping we can get MSN support soon, too. I'm not too sure how well farsight supports it though.

In my last blog post, I alluded to our quest to make Pidgin perfect (in our own eyes, at least). This is a quest that by its very definition can never end, because as we near "perfection," there will always be something else that crops up to demonstrate we haven't reached perfection quite yet. This "quest" can have elements of many different forms. A few months ago, one of those forms was discussed on our development mailing list.

As a good many people are aware, Pidgin has long supported GTK+ and GLib 2.0.0. Several years ago when GTK+ 2.0.0 first came out, we underwent a nine-month rewrite of our user interface (UI) to move from the older GTK+ 1.2.10 (or newer) to the new GTK+ 2.0.0. Since that time, until 2.6.0, we've always maintained compatibility with GTK+ 2.0.0 through the use of conditional code that disabled certain features or UI elements that required newer versions of GTK+ or GLib than what was available at compile time. In some cases, we had conditional use of code to work around the lack of certain convenience functions present in newer versions of GTK+ or GLib. In still other cases, we actually carried (that is, distributed in our source tarballs and compiled where necessary) the source of several GTK+ widgets in order to make our UI work for users with older versions of GTK+. Over the years, this has become more cumbersome, to the point that for 2.6.x, it became impractical to maintain compatibility with GTK+ 2.0.0--when we realized this, we changed our requirements to GTK+ and GLib 2.4.0, which contained the features we needed.

The increased difficulty of supporting older libraries prompted me to bring a discussion up on our development list prior to the release of 2.6.0 asking for a vote, discussion, etc. on raising minimum GLib and GTK+ version requirements for Pidgin 2.7.0. This discussion has come up before and been shot down. This time, I put it to a vote and gave quite a while for votes to be cast. There were no "No" votes cast. The versions we voted on were GLib 2.12.0 and GTK+ 2.10.0. These versions allow us to support reasonably recent Linux and UNIX systems, as those GTK+ and GLib versions were 3 years old at the time of the vote, while also making our lives significantly easier since we no longer have to care about really old versions of GTK+ or GLib. Ideally, I would have liked to have GLib 2.14.0 and GTK+ 2.12.0 as the minimums, but I was trying to reach a middle ground that would avoid angering too many people.

This change in the minimum required GTK+ and GLib versions has a few consequences. Obviously, Linux and UNIX distributions that don't ship GTK+ 2.10.0 or newer won't be able to support Pidgin 2.7.0 when we release it. On these systems, users can, however, compile GTK+, GLib, and friends, then compile Pidgin. This is really a lot of work, but some users may be willing to go through it.

For our Windows users, there will be some major changes. When building and linking our releases, we'll be stepping up to GLib 2.18.0 and GTK+ 2.14.0. We already ship this version or newer in our installers, but now we'll actually be linking against these versions. The consequences of this are that Windows NT 4.0, Windows 98, and Windows ME will no longer be supported. These newer versions of GTK+ and GLib require features that just aren't present in those old operating systems. None of these operating systems have been commercially supported (by this I mean modern games, word processors, spreadsheets, etc.) for years, and even projects like Firefox have stopped supporting them.

Additionally, our Windows expert, Daniel, has made some changes to the Pidgin installer and to our crash report generation for 2.7.0:

• Instead of installing GTK+ in a system-wide configuration, we will be changing to installing GTK+ local to Pidgin. This means that it should be harder for us to conflict with other GTK+ applications on Windows. This has long been requested, but we just finally got around to doing it.
• Debug symbols can now be read from parallel copies of files. Normal installations of Pidgin ship "stripped" binaries--that is, there is no information useful for generating crash reports. Now, instead of replacing all the existing files, the installer will offer the option to install debug symbols. Selecting this option will install parallel, unstripped copies of every file with the extension ".dbgsym" to a special location.
• The installer will allow choosing which Pidgin translations to install.
• The installer will have "online" and "offline" variants. The "online" variant will include only Pidgin. GTK+ and debug symbols will be downloaded as needed. The "offline" variant will include both GTK+ and the debug symbols.

Also among the changes coming up for Pidgin 2.7.0 is the switch from the eggtrayicon widget we have carried in our source tarball for years to the GtkStatusIcon implementation that was added in GTK+ 2.10.0. There are still a few bugs to work out with this change, but I believe once we have those ironed out, our notification area icon will behave better for a number of users who have been experiencing difficulties.

Of course, these changes aren't the only ones that will make it into 2.7.0. I have my own plans for a few additions, plus I won't allow 2.7.0 to be released without a few other features being merged in. But so far, it looks like Pidgin 2.7.0 will make some long-awaited forward strides. Hopefully everyone enjoys it!

Also, to those who celebrate the holiday, Merry Christmas!

This has been on my todo list forever, and I started tinkering with it the other day. But after a mega hackathon tonight, I have a pretty functional gtkdoc plugin from trac.

The idea of the plugin is to integrate gtkdoc books into trac's interface. This is accomplished, currently, by and iframe displaying the actual htlm output of gtkdoc, as well as integrating into the search engine in trac.

There's two new user permissions in this plugin, GTKDOC_VIEW and GTKDOC_ADMIN. GTKDOC_VIEW is obviously to view the api and well as search it, where admin allows the addition and removal of books.

As mentioned above the admin interface provides an interface for adding and removing books. Books are keyed on a name given to them at the time they're added, as well as an absolute path on the local filesystem of where the book actually is. This way, you can update the documentation and not have to touch a thing in trac.

At any rate, it's still pretty rough around the edges and lacking a ton of error checking. But feel free to grab it from our extras repo (hg clone http://hg.guifications.org/extras) and tinker with it. It's in trac/gtkdoc, use the normal "python setup.py bdist_egg" to build it.

Recently I've been frustrated by the fact that we have a number of tickets open on Pidgin's Trac that deal with inadequacies in the preferences window. The biggest complaint is that in a number of configurations, the preferences window is too tall to fit on a screen. This has only recently become a problem with the advent of the so-called "netbook" with their nearly microscopic screens (seriously, how do people use those things when they have such tiny screens? It drives me absolutely nuts when I try to use one).

Prior to the netbook craze, we've always aimed for all our windows, dialogs, etc. to fit on an 800x600 screen. With the shorter and wider screens found on netbooks, 800x600 isn't realistic anymore. In that vein, I've started working on paring down Pidgin's preferences window to fit better on a netbook screen. Let's take a look at what I've done so far.

The first, and most obvious, change I've made is to move the tabs that were previously at the top of the preferences window to the side. I did this for two reasons--in my environment, I have a Browser tab because I don't use Windows or GNOME. This meant the tabs artificially forced my window to be wider than it strictly needed to be (our preference window "notebook," as it's called in GTK+ parlance, doesn't scroll or stack the tab row). Second, moving the tabs from the top to the left gains back some valuable pixels that help us fit on those really short screens. In retrospect, I didn't gain much--only about 20 pixels or so in my configuration--with the width of the actual pages of the notebook because of other changes I made to help the height. But every pixel of height counts to make us fit on short screens.

After that, I started picking on the Network tab. We have a lot of stuff that's just crammed into the Network tab. FIrst we have a bunch of stuff for automatically detecting your public IP address or optionally manually specifying one. Then we have some stuff for port forwarding. After that comes stuff for TURN relay servers, which is yet another method for traversing NAT "routers." Finally, we have the wonderful proxy server stuff. All this stuff being crammed on a single tab makes the dialog ridiculously tall and makes the Network tab tied with the Conversations tab for biggest overall height.

Clearly, a few changes were in order here. I made a minor change here that moved the port range spin buttons to be on the same "line" as the checkbox that enables and disables them. Beyond that, there were still a lot of changes that could be beneficial. For example, now that I've made the notebook tabs go down the left side of the window, that gives us a lot of room to better organize our preferences into tabs that make logical sense. Since I had this extra tab room to work with, it made sense to add a new tab to put the proxy configuration options on. While a proxy server is obviously a network configuration item, it's not always obvious to our users that the Network tab is the correct place to configure the global proxy settings.

Now, looking at the Smiley Themes tab, there's a crapton of wasted space there. Seemed to me like a perfect candidate to be the target of some moves. Over on the Interface tab, we have two theme selectors--one for buddy list themes and the other for status icon themes. I decided those were a better fit on a dedicated Themes tab, so I renamed the Smiley Themes tab to Themes and slapped those theme selectors in above the smiley theme selector. I also excised the sound theme selector from the Sounds tab and slapped it into the newly-renamed Themes tab. Elliott, another Pidgin developer, converted the smiley theme selector to be consistent with the other theme selectors. Now the Themes tab doesn't seem under-utilized, but it does still need a little work.

I also decided to reorder the tabs. I ordered them alphabetically, but intentionally left the Interface tab as our first tab. It seems to be convention that the "General" tab is the first tab in a notebook for a preferences window. In that vein, our Interface tab is our equivalent to a General tab, so I left it first to fit with convention. The order of the other tabs should be something logical. Sure, I could have grouped Browser, Network, and Proxy together, then grouped Conversations and Logging together, and later figured out where to stuff Sounds and Status/Idle, but an alphabetical arrangement is just as sensible considering that not all our tabs clearly separate into logical groups.

The next things to get rid of were the "Sound Method" section on the Sounds tab and the Auto-away section on the Status/Idle tab. Note here that I didn't actually remove any preferences; I simply removed a section and placed the relevant preferences in another section. The existing groupings seemed redundant and excessive. This seems better to me.

There, was, however, one thing I needed to give the axe to. Over on the Conversations tab, there was this annoying preference section called "Font" that contained two preferences designed to allow users to override the GTK+ theme settings, but only for the conversation history pane. This preference serves very little purpose anywhere but on Windows, so I removed it. I then made sure the Pidgin GTK+ Theme Control plugin could control the history area font. There were some objections about unconditionally removing this preference, so I compromised and made it available only on Windows, even though I fail to see why the plugin isn't sufficient to control this font.

In the end, I believe I accomplished my initial goal of making the preferences window fit on smaller screens, but I also managed to make it so the dialog still fits on an 800x600 screen. The new window measures 698 pixels wide and 492 pixels high in my configuration, which is a bit too big for 640x480, but will fit with plenty of room to spare on 800x600 and should fit pretty well on just about any netbook screen.

You can take a look at what the new window will look like with these pictures (sorry, but the order is backwards and I'm too lazy to fix it):










This will be in Pidgin 2.6.4 when we release it. Hopefully everyone enjoys the changes!

Last weekend Google hosted their 3^rd annual mentor summit, following the end of their 4^th annual summer of code. The mentor summit is when a few hundred mentors gather together and participate in an unconference style conference. I went for the Pidgin project, along with Gary Kramlich and Ethan Blanton.

• List of Pidgin projects for 2009
• Pictures from the weekend
• Notes from the sessions
• A few kind people arrived to the area early and spent a few days in a documentation “sprint.” They created a summer of code mentoring guide

The conference was super cool. I got to be humbled by talking to a whole bunch of really smart open source people. Here are my notes:

On One Laptop Per Child (“OLPC”)

I’ve been wondering for a while whether the OLPC program could actually make a difference. One session, led by Bryan Berry of Sugar Labs, makes me think that it can and already has. Bryan is the co-founder and CTO of OLE Nepal, an organization helping deploy OLPC in Nepal, and creator of Karma, a framework for creating interactive activities for the Sugar environment using javascript and html5.

Seeing demos of the exercises they’ve created and hearing his first hand stories was pretty incredible. At least some schools in Nepal teach by having the teacher recite something (e.g. “one plus two is three”), and all the students repeat it and memorize. But this often fails to teach the students why one plus two is three. In one example a student was asked “what is one plus two” and they replied with “three.” But the same student was not able to answer “what is two plus one.”

Children in third world countries generally want to learn–more so than children in the US. They realize that education can help them achieve something greater in life. And computers are interesting to them. Combine students, computers, and engaging lesson plans about math, geography, etc. and the students will have a more varied education and will learn better.

On Forking Open Source Projects

• Forking helps keep people motivated. It increases competition, keeps developers on their toes.
• A fork could be like a “research and development” branch. People work on crazy fun new features in the forked project, and the good stuff gets merged back into the original.
• The smaller the project, the more willing the maintainer should be to give people access. There is a natural inclination to be protective of your project–it’s your code, your baby. But you must be willing to give up control for there to be forward progress. This reminds me of dictator governments like Cuba/Fidel Castro and North Korea/Kim Jong-Il. The dictator is afraid to relinquish control for fear of what might happen.
• Benefits of a fork? Developers have more freedom to do what they want, which allows for innovation. The best project will survive–if developers want their project to survive then they must make decisions that benefit the community at large.
• Downsides of a fork? Development effort is divided. Users might not know which project to use. Distributors may not know which package to distribute; distributing both means more work.

Miscellaneous

• STUN – A protocol used to determine your public IP by asking a server on the “outside” Internet
• TURN – A protocol used to proxy traffic through an intermediate server. Written with SIP in mind. Increases the likelihood of being able to establish a connection to another party, but it also introduces an additional hop, which leads to lagginess, which is bad for voice/video communication.
• ICE – A protocol that describes a method for establishing a direct connection with another peer. Written with SIP in mind. It uses an exhaustive algorithm to try every possible IP address for yourself in the hopes that one will work. You construct a list of your host’s IP addresses plus your public IP address determined by using STUN. This information, along with a fallback TURN server, is sent to the other party, who begins attempting to connect.
• OpenAFS is under active development, and is used by some very large organizations
• I should change my alias for grep to enable the color option
• I should read Zen and the Art of Motorcycle Maintenance

On Trolling (this session was half intended as a joke)

• I should read the UNIX-HATERS Handbook
• I should read the Sokal paper
• “Linus==troll”
• “Version con-trolling”
• “We had this problem where people had to download our software and type ‘make’” –Marty Connor
• Adding support for the old school Unix talk command to Pidgin could be a fun April Fools joke

Have you ever taken a look at the text in Pidgin's About box? If not, do so now. Click the Help menu, then click "About." Be prepared to scroll. And scroll. And scroll some more. And again. Until finally you reach the end of the thing and see a crapton of build-related information that probably doesn't make a whole lot of sense. Along the way, you'll scroll through a list of our developers and crazy patch writers, then through a list of retired developers and retired crazy patch writers, then through translators and retired translators. The list of translators, especially, seems to go on forever. The amount of information in that box has grown nearly exponentially in the last couple years.

Get tired of scrolling through all that information? Me too. And apparently a bunch of other people--I've seen a number of complaints from people involved with several Linux distributions indicating that our about box has way too much information. Well, this morning, I set out to remedy that.

Remember that insanely long list of current and retired translators? Well, when we release Pidgin 2.7.0, it will no longer be in the About box. To excise this information from the About box, I created a new entry on the Help menu called "Translator Information" that pops up a new dialog similar to the About box. This new dialog lists all current and retired translators.

Once the translators were gone from the About box, the next largest chunk of text was the "Debugging Information" section all the way at the bottom. Considering how frequently we ask users to look at this information, it is nowhere near visible enough sitting at the bottom of the About box's scrollable area. This, too, became its own window, accessible at "Build Information" on the Help menu. (As an interesting side note, this is insanely long in code, too. In fact, it's more lines of code than the printed list of translators takes up in the new translator info dialog!)

Even losing all that text from the dialog wasn't good enough for me. Next I axed the list of developers, crazy patch writers, and retired developers and crazy patch writers. Now these lists are available by clicking "Developer Information" on the Help menu. Since I'd just added three items to the Help menu, it was time to toss a couple menu separators in there so that things look more organized and cleaner. Hey, our Help menu is kinda respectable now!

Now I looked at the about box again. It still felt too verbose to me. Granted, a lot of that information is important, but I started thinking about better ways to say the same things. For a great example, let's look at the first two blobs of text you see after the version info:

Pidgin is a graphical modular messaging client based on libpurple which is capable of connecting to AIM, MSN, Yahoo!, XMPP, ICQ, IRC, SILC, SIP/SIMPLE, Novell GroupWise, Lotus Sametime, Bonjour, Zephyr, MySpaceIM, Gadu-Gadu, and QQ all at once. It is written using GTK+.

You may modify and redistribute the program under the terms of the GPL (version 2 or later). A copy of the GPL is contained in the 'COPYING' file distributed with Pidgin. Pidgin is copyrighted by its contributors. See the 'COPYRIGHT' file for the complete list of contributors. We provide no warranty for this program.

All this information is hugely important. But it's too long. So I tried a surgical strike on the words. It took a few more tries than I care to admit, but I found that I liked this text better:

Pidgin is a messaging client based on libpurple which is capable of connecting to multiple messaging services at once. Pidgin is written in C using GTK+. Pidgin is released, and may be modified and redistributed, under the terms of the GPL version 2 (or later). A copy of the GPL is distributed with Pidgin. Pidgin is copyrighted by its contributors, a list of whom is also distributed with Pidgin. There is no warranty for Pidgin.

Obviously I took away some information, namely which IM services Pidgin can connect to. I'm not convinced that needs to be in the about box, considering the exact same text that is in Pidgin 2.6.2's About box is on Pidgin's website. So I carefully dissected the text and came up with a shorter text that gets all the important information across while cutting information most users aren't going to care about reading. I even managed to squeeze in that Pidgin is written in C, which was previously missing (it's a ridiculously frequently asked question).

Now I had something better. But I could still improve it. We had oversized text pointing to pidgin.im, the FAQ, the IRC channel, and our XMPP conference. I added a new, bold heading, "Helpful Resources," and added those items as indented, normal-sized text items under the heading. This was getting better. Now, one final improvement. We point out that help from other Pidgin users is available by emailing support@pidgin.im. I changed the heading a little so that it reads a bit better. I also changed "3rd party" to "third-party," which is the more correct form.

Something still seemed wrong about the About box, though. I experimented with the size, making it default to 450x450 pixels like the new dialogs I added. This seemed to help a lot. I'd like to make it a touch larger still, but I'm afraid that making it any larger will make it a tight fit on netbook screens. We're already getting complaints that some of our windows don't fit on these smaller screens, so I'm not exactly eager to cause more complaints.

At any rate, for me, the About box's text fits in just under two full "pages" of the scrollable area--that is, the last line of the scrollable area when scrolled all the way to the top is the first line when scrolled all the way to the bottom. There are some other minor tweaks I'm going to look at making that may make the area scroll even less.

In the end, my boredom caused me to take a look at something people have been complaining about for ages. Overall, I think what I've done is a good thing, but we won't really know for sure until we release Pidgin 2.7.0 (don't ask when--we have no idea yet!) and people see the new dialogs. I hope everyone likes what I did!

Well, by now most people probably realize that we've released Pidgin 2.6.0. It feels like this has been in the works forever, particularly these last couple weeks.

First off, some statistics for this release:

• 99 bullet points in the ChangeLog.
• 221 tickets closed for the release (that is, 221 tickets that we believe are fixed or are patches that we accepted).
• 2 major new features
• More other new features than I care to count
  

For the new features:

Voice and Video support - Thanks to Mike Ruprecht and his Summer of Code project from 2008, libpurple now has a voice and video framework that can be used to add these features to our protocol plugins. Currently we support these features only on XMPP, but Mike is working on other protocols as I write this and hopes to have more protocols at least partially supported soon. The dependencies are a bit of a mess for the uninitiated, but unfortunately that's unavoidable. I'm hoping most distributions will be able to catch up with this soon and make it completely effortless for users, but this is a headache even for some distributions. The biggest setback thus far is we're currently not able to support these features on Windows--but we're working on it! Please be patient!

Theme support - Another Summer of Code project from 2008, this time by Justin Rodriguez, adds theming support to libpurple and Pidgin. This currently isn't very well documented at all, but themes are now supported for the buddy list, sounds, and status icons.

Yahoo users will notice a few changes. First and foremost, we split the Yahoo protocol plugin into two, one to handle the Yahoo JAPAN network and one to handle the rest of the world's Yahoo network. This has the side effect that if you happen to have the exact same account registered on both networks, you'll finally be able to use both accounts in Pidgin. It's also a lot more obvious to people looking to use their Yahoo JAPAN accounts in Pidgin. Sulabh Mahajan, another Summer of Code student from 2008, implemented a ton of new stuff for Yahoo and Yahoo JAPAN. Among the changes are the addition of SMS support. You can now send SMS messages by sending to "+<country code><phone number>". Sulabh also implemented peer-to-peer file transfers for Yahoo as well as adding MSN buddies to the buddy list of a Yahoo account. Unfortunately, proper support of adding MSN buddies isn't possible to do until 3.0.0 when we can make some major changes to the internal workings, but for now, if you want to add an MSN buddy to a Yahoo account, add them as "msn/foo@bar.tld". The "msn/" is the important part--this tells our Yahoo code to look across the MSN bridge to add the buddy.

On top of all this, our developers, crazy patch writers, and contributors have been pouring a ton of work into our XMPP support. Beyond the voice and video support, we've gained a service discovery ("disco" for those familiar with the term) browser plugin, support for BOSH (Bytestreams Over Synchronous HTTP), idle time reporting (XEP-0256), attention ("buzzing") support (XEP-0224), in-band bytestreams file transfer as a last-resort transfer method (XEP-0047), custom smiley support in small (less than 10 users) MUC's via the "bits of binary" extension, as well as updated support for buddy icons (User Avatar XEP-0084 v1.1). There have also been a ton of bug fixes and other enhancements. All this adds up to 29 bullet points in the changelog for XMPP alone, and even that is surely not 100% complete.

Other notable items include our new (optional) support for GNU libidn, allowing us to support UTF-8 domain names throughout all of libpurple, three new environment variables that can help in debugging (and thus possibly help some plugin authors as well), a new authentication mechanism for AIM implemented at AOL's request, the ability to receive voice clips and handwritten (ink) messages on MSN, and a crapton of fixes and enhancements in Pidgin. Even Finch got some love this time around, gaining a new TinyURL plugin and some important bug fixes.

Of course, I'd be neglecting important details if I didn't mention the security issue we fixed for this release, as well as the 2.5.9 release. CORE Security Technologies found a way to remotely crash a running Pidgin instance that was logged into an MSN account via two specially crafted messages. They were kind and responsible enough to inform us of this privately and provide us with a proof of concept script so we could fix the problem before they made it public. The release of Pidgin 2.5.9 was done in source form only, explicitly to provide distribution packagers with a fixed release in the event they preferred to avoid the behemoth release that is 2.6.0.

Of course, since I was heavily involved in the creation of the 2.6.0 release, we have some issues that we're going to need to follow up on shortly with a 2.6.1. I'm sorry for any inconvenience this causes anyone, but hopefully 2.6.1's release will make up for it by being what 2.6.0 should have been. At any rate, enjoy all the shiny new features!

A little while ago, grim posted a link about preparations for GTK+ 3.0. I started a bit of work on it in a separate branch.

So far, it hasn't been too much trouble. I managed to fix single includes in the main branch, and all deprecated functions in libpurple core too. Finch was super-easy and required almost no work. What was left was the Pidgin UI.

The main Pidgin UI required a bit more work. Replacing GtkOptionMenu with GtkComboBox was pretty simple, just a couple preprocessor checks needed. Using GtkTooltip instead of GtkTooltips was also pretty painless, but there's still one matter left. The headline text that goes in the buddy list for mail notification used to do a hack with the tooltip to colour it correctly. At the moment, it ends up grey because I'm not sure how to get it working.

There are still a couple big changes left. I still really don't know how to write UI Manager stuff, and it's hard to find good examples. It only has to be done twice, for the buddy list and for the conversation window, but I'm not sure how much that really means. Fortunately, we are not heavily GNOME dependant, so that's probably the biggest change.