The Flaming Banker

Major Changes Afoot

2011-08-28T13:01:00.005-04:00

Well, it's been about forever since I last bothered to post anything here. Since my last post, we've released several times, introducing and fixing a bunch of bugs. Now, however, we're shifting our focus to new development of a sort that we don't do often—compatibility breakage and big internal changes. This means that our main development effort is now in working toward Pidgin and libpurple 3.0.0. I'm going to try to explain some of the work going on for the benefit of anyone who reads my ramblings, so here goes.

Versioning

First of all, there seems to be some confusion about how Pidgin and libpurple version numbers work. I'd like to try to clear some of that up.

Pidgin, Finch, and libpurple use what's called “Semantic Versioning.” That is, each part of the version number has a particular meaning for users and developers. We chose this scheme to assist plugin developers in knowing when significant changes would require effort on their part to maintain compatibility with current Pidgin and/or libpurple versions. It also helps our users by letting them know when their existing plugins will stop working. So, how does this semantic versioning work? Let's look at the format of our version numbers and find out.

Pidgin, Finch, and libpurple version numbers have three components, separated by dots. At the time of this writing, 2.10.0 is the current version number. These components are called major (currently 2), minor (currently 10), and micro or patch (currently 0). Let's look at what each means.

Major: the major version doesn't change often. The last time we changed it was in 2007 with the release of Pidgin 2.0.0, and before that was in 2004 with 1.0.0 when we started using semantic versioning under our previous name. Whenever this number changes, we've made changes to Pidgin, Finch, or libpurple that break compatibility with every UI and plugin that currently exists. Usually this means that we've removed something from the API exposed to plugins and UI's, or that we've changed something about a function (its name, arguments, return type, or the header file it's in). Sometimes plugins or UI's can just be recompiled when this happens; other times they need maintenance to become compatible with the new release. Additionally, the major version never decreases. It will always increase when it changes.
Minor: the minor version changes more frequently than the major version, but generally less often than the micro or patch version. Whenever the minor number increases, we've added things to our API that do not break compatibility with existing plugins or UI's. A prime example of this is adding the voice and video support we added in 2.6.0. We added a bunch of stuff to the existing API, but didn't change anything that would cause a break in backward compatibility with existing plugins and UI's. When the minor version decreases (gets set back to 0), it means that the major version has changed, and the whole cycle starts over.
Micro or patch: The patch version changes with almost every release. When this version increases, it means that we haven't touched API at all; instead we've done nothing but fix bugs or add small features that don't affect compatibility with plugins or UI's. When this version decreases (gets set back to 0), it means that the minor version has changed.

Related to all this, and important only for plugin and UI developers (so skip this paragraph if you're not a developer!), is the behavior of the PURPLE_VERSION_CHECK macro. Many developers expect PURPLE_VERSION_CHECK(2, 5, 0) or similar to expand to a statement that evaluates to 1 or TRUE in the case of building against libpurple 3.0.0. This, however, is not the case. Because our major versions are incompatible with each other, we have intentionally written PURPLE_VERSION_CHECK to fail if the major version is not an exact match. We understand this can be confusing and inconvenient, and we sincerely apologize for that, but we're not going to change it.

What all this means is that if the first number (major version) changes, you're going to need to update your plugins when you upgrade Pidgin, Finch, and libpurple. If the second (minor version) or third (micro version) numbers change, it means you need to upgrade Pidgin, Finch, and libpurple, but your existing plugins will still work. No matter what the Pidgin, Finch, and libpurple version numbers are, you should always be using the newest version.

Structure (“struct”) Hiding

This paragraph is for those who aren't programmers. Feel free to skip it if you don't care about it. Pidgin is written in the C language. C has a type system, which means that if you declare a variable (imagine this as a box somewhere in your computer's memory) you can store only one type of data in it. A structure, or struct in C parlance, is a type made up of other types arranged sequentially. This is pretty easy to picture if you think of Lego blocks--stack a red block, a blue block, a green block, a yellow block, and a white block on top of each other and connect them together and you now have a structure made out of Lego blocks. It's pretty similar in C, except that you're telling the compiler to assemble something out of sequential boxes of memory instead of little plastic blocks.

Pidgin uses structs everywhere. We use them to represent things like your buddies, conversations, accounts, etc. Currently in Pidgin 2.10.0, most of the structs are in the public API—that is, anyone can directly access the members of the structs and do whatever they like. This is all fine and well, but it means that if our code changes such that a particular struct needs to grow significantly by the addition of new members, we can't always do that without breaking backward compatibility. (Yes, we included padding in a number of our structs, but we've burned through the padding in several of them, and although there are ways to work around it, I and a few other developers don't like them.) It also means that if we discover, for example, that switching the order of members in a struct allows the compiler to improve its optimizations or if we think a different order makes more logical sense for those of us reading and maintaining the code, we absolutely can't do this without breaking compatibility. We also can't rename members of structs for the same reason—it breaks compatibility with existing plugins, UI's, etc.

Because having these structs in the public API limits us so much, we're striving to hide as many of them as possible. By hiding, we mean that we're removing the struct definitions from the header files and moving them to the .c files, thus making them private. Plugin and UI authors will still be able to reference the “objects” with pointers, passing them to functions and operating on them with the appropriate sections of our public API, but no longer will the members of the structs be directly accessible outside of the .c files that define the functions that interact with them. For example, we have a PurpleRoomlist struct in libpurple/roomlist.c and libpurple/roomlist.h. For 3.0.0, the struct definition is in roomlist.c; thus the individual members are not directly accessible outside roomlist.c, even in other parts of libpurple. This “hiding” of the strcuts allows us significant internal flexibility in each file to modify the struct as we see fit.

Clean-Slate API Documentation

Because we generally change so much each time we increase our major version number, the API documentation can get a bit confusing if we keep doing @since tags and whatnot in our doxygen documentation. Our general overall feeling is that we prefer just starting with a clean slate at each new major version. This means that each time we do a new major version, all existing @since tags will disappear, any functions marked as @deprecated will be removed, renamed, or replaced as described in the @deprecated statement, and so on. We realize this decision may make some things more difficult for some plugin and UI authors, and we apologize for that, but our aim is to have overall cleaner documentation for everyone.

Merging of Old Projects

Over the years that we've participated in Google's Summer of Code program, we've accumulated a number of branches that have been sitting for quite some time. Most of these need some form of TLC and integration work. We want to try to incorporate at least some of them into 3.0.0 so we can finally benefit from the fruits of the students' labor. Most notably, we've been talking about merging the webkit integration branch into what will become 3.0.0. Eventually, this would allow the support of Adium's message styles, although it may not happen right away.

Another project of notable interest is some of the logging changes that went on in a previous Summer of Code project. One of our new Crazy Patch Writers took some of that work and made some progress on it; we don't know if this will make it for 3.0.0 or not yet, but it would be nice to have some of the features, such as non-blocking log writing.

Other Changes As Wanted

We may decide to make other changes since a major version change gives us the opportunity to break so much. There have been a number of ideas floated, ranging from supporting that XDG directory spec that I can't stand to doing away with the xml files in .purple and replacing them with something else (with what, in particular, has not seriously been discussed). There is a whole range of possibilities of things we could do for 3.0.0; it's just a matter of one of us wanting it and sitting down to write it.

So everyone should stay tuned, as we'll be making more and more changes over the course of the 3.0.0 development cycle. We don't yet know when we'll be releasing 3.0.0—this is another one of our famous “when it's ready, and not a minute before” time frames. We do know, however, that it will change a lot!

Current AIM Issues

2011-02-23T20:42:00.002-05:00

Over the last couple hours, we've had nearly everyone and his/her brother in #pidgin asking about connections to AIM causing a certificate prompt. The specific prompt is for bos.oscar.aol.com. The issue here appears to be that AOL has let the certificate expire. Because our certificate validation is more strict than some other applications, Pidgin users will get this prompt at every connection until AOL installs an updated certificate.

To resolve the prompt, you can make one of a couple choices. You can choose to trust that the connection is fine even though the certificate is expired and click Accept, or you can take the safe route and click Reject until AOL replaces the certificate.

To reiterate, this is not a Pidgin problem, but an AIM server problem.

Complex Transient Statuses for Quick Effect

2011-02-04T22:36:00.000-05:00

In an earlier post, I discussed how to take advantage of Pidgin's "saved status" feature. After seeing some recent confusion in #pidgin about our status features, I decided it would be a good idea to give a quick overview on how to take advantage of a feature I never use--creating statuses (including complex statuses) from the status selector on the buddy list window.

The status selector feels like it's been around forever. Prior to this, we had a rather horrible interface to "status" whereby you could either globally set all accounts to "away" or go to each individual account and configure a given status (away, do not disturb, vacation, etc.). All this was done via a single menu. For those of you who don't remember it, let me just say that it sucked. Someone (I think it was Sean Egan) threw that whole UI out the window and came up with the current status selector that reminds me a lot of the old Windows ICQ 99 client that had a pretty similar status selector. Ours is a bit more sophisticated, though.

The simple use of the status selector is fairly obvious--pick a status and type a message. In fact, this is what the majority of our users do when they change statuses. This is what is called a transient status. What most people don't know, however, is that you can create complex statuses, such as having your MSN account set to "Busy" while your AIM account is set to "Invisible." Let's give a quick example.

I have a number of accounts in Pidgin. Let's say I want to have my pidgin.im XMPP account set to "Available" but the rest of my accounts set to "Away" to create a simplistic scenario that's really easy for me to snag a screenshot of. To do this, I'll go to the status selector and select "New status..." like in this picture:

Then I'll see this window, where I've already gone and entered a title for the status. This is the name you'll see in the status selector and in the middle section of the status selector's menu. If I wanted a message to go with the away status, I'd enter it here now, as well.

Since I want most of my accounts to be away, I'll leave the "Status" selection as "Away." As you can see, I have my mouse pointer over "Use a different status for some accounts," which when expanded will allow me to set statuses for individual accounts, like so:

I found my pidgin.im account in the list already, so I'll check the box in the "Different" collumn. That brings me to a new window:

Now I want my pidgin.im account to be available, so I'll accept what I see. If I wanted a message here, I'd type it in the "Message:" box. When I'm happy with what I have, I'll click OK. Notice that the "Status" column in the previous window changes to reflect what you selected for the individual account.

Since I'm happy with what I have, I'll now click "Use", which applies the status. If I wanted to make this a saved status that is saved permanently, I could click the "Save" button or the "Save & Use" button if I wanted to also immediately apply it when saving.

That's all there is to it!

Death of a thousand tickets

2010-10-26T00:36:00.004-04:00

Well, by now it's obvious to the world that I kicked Pidgin 2.7.4 out of the nest last week. Although that release included some nice new features for ICQ users, lots of bug fixes, and some remote crash fixes, it's not without its share of problems. Those problems are producing a bunch of duplicate tickets for us to deal with, so I thought it might be a good idea to post about them here just in case anyone bothers to read my rambling.

The first problem is the AIM/ICQ chat bug. When using a multi-user chat on AIM or ICQ, no messages can be sent. You'll get an error stating your message was too long. This was an unintended side effect of merging the work of one of our Summer of Code students. Ivan accidentally removed a line of code that he shouldn't have. Yes, you read that right--a single line of code. Apparently it was pretty important! Ivan restored that line and things will be working as they should in 2.7.5 when we release it.

The second problem is an old one that's come back with a vengeance. This one is an ICQ issue where messages that contain <> disappear because they're treated as HTML tags. This seems to be specific to combinations of Pidgin and other non-official clients. Pidgin recently gained some new ICQ protocol-level features related to formatted messages; some non-official clients, including older versions of Pidgin, don't handle it gracefully. At this point, we've done all we can do about it; the other clients will have to step up and make fixes to handle the messages correctly now.

The next problem is another wonderful ICQ encoding bug. I'm not sure if this one is a side effect of Ivan's work or not, but Ivan did do a lot of work on encoding problems on ICQ. We all thought things were improving, but apparently there are still a few odd cases (and a crapton of stupid ICQ clients that should be purged from existence) in which our handling of encodings just isn't quite right. We're aiming to have this fixed for 2.7.5, but it's not quite done yet.

Is it obvious I wish ICQ would just disappear immediately and permanently?

The last "big" problem that seems to be cropping up is a crash related to MSN file transfers. When using direct-connect file transfers, somewhere along the line we do something stupid internally that causes a crash. We thought we had it fixed for 2.7.4, but alas it still exists. We're looking into it and hope to get it fixed soon. In the meantime, it's pretty easy to prevent the crash--edit your MSN account and turn off the direct-connect file transfers. It's an option on the advanced tab of the account editor.

At any rate, since we know about these bugs already, please, please, please DON'T open new tickets about them!

The Proxy Conundrum

2010-06-25T22:36:00.003-04:00

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.

In Pidgin 2.7.0 I made some seemingly innocent changes to the Yahoo protocol plugin that I thought would magically make some problems go away. These changes make us mimic the official Yahoo client better. Very early in the connection process (in fact, it's the first step), the official clients request a specific URL from a Yahoo web server. The server's response tells the client what messaging server to connect to. The client reads that address and connects to it, then goes along its merry way. So I made our Yahoo plugins do this, once I determined the correct URL's for both Yahoo and Yahoo Japan. Everything was great when I tested.

But there's my mistake--I tested it. I don't run a proxy server--I'm an IT nerd, but I'm not that much of an IT nerd. So, I allowed this to be released, not knowing there were problems in environments with restrictive proxies. It came back to bite me hard, as I backported this stuff to Adium's build of libpurple 2.6.something for one of their beta releases and several users started complaining about being unable to connect. Then we got a couple tickets of our own. At first, I was stumped, until a user who was willing to almost bend over backwards to assist us came along.

This user worked in an environment where two separate proxy servers were in use. One handled HTTP and HTTPS traffic and the other handled IM protocols. It took me quite a while to finally wrap my head around his problem, but once I did (with the help of my fellow developer Etan Reisner), I was able to start solving the problem. It turns out I actually had two problems on my hands, but at first it seemed like none of it was the fault of our code.

The first problem is that Pidgin allows configuring proxies in two places--the "Proxy" tab shown when editing an account and the "Proxy" tab in Preferences--but does not allow specifying what ports or services are handled by each proxy. This ordinarily isn't such a big issue, except that I went to the extreme of creating an option for Yahoo accounts to help some users with weird proxies that don't handle SSL at all. This option is used to determine whether to send an HTTPS request (like Yahoo uses for login) to the account's configured proxy or to the global proxy configured in Preferences. When I did this for 2.6.0, I created a new utility function for URL requests that allowed specifying the account the request was for. If the magic value NULL is passed to this function, the request will use the global proxy instead of the account proxy. This allows our proxy code to route the request to the appropriate proxy. Being the idiot I can be on occasion, I set all URL requests in the Yahoo plugins to use the account proxy server no matter what. This is where the user's problem came in--his IM proxy doesn't do HTTP at all. Once Etan and I agreed on how to fix it, I changed the SSL option I mentioned earlier to act on both HTTP and HTTPS requests. I supplied our user the test build. It still didn't work, but the debug log showed some interesting new info.

Again, it took some head-bashing to understand what was going on, and I still wasn't the one who figured it out. In the meantime, I decided to implement a quick hack to make users at least be able to connect temporarily while we figured out what was really broken in our proxy code. The quick hack was to implement a worst-case, last-resort connection to a previously known messaging server. Unfortunately, I could implement this only for Yahoo, not for Yahoo Japan, as the Japan network appears to no longer has a single canonical hostname by which to refer to the messaging servers. I am, however, positive that even on the regular Yahoo network, this hack will eventually break, which is why I resisted it in the first place. After a couple quick bugfixes brought to light by the user's further testing, we had a working fallback mechanism.

Once this was done, Daniel Atallah, one of our co-lead developers, realized that the second problem our helpful user had was our own proxy code's fault--for some stupid reason, we would never authenticate to an HTTP proxy if we were making an HTTP request on the standard HTTP port (80). Daniel implemented some quick fixes to make our URL requesting code behave better in these proxy situations, thus (we hope) finally solving this problem completely.

All these fixes will end up in Pidgin 2.7.2. We're not sure yet when we're going to release that, but we're hoping it's soon, as we have some fixes for other annoying bugs, such as the famous MSN direct connection crash.

Now, after reading all this, some of you might think, "Why don't they just use libproxy?" Truthfully, that's probably a good idea. There are two reasons we haven't done this yet. First, we looked at this over two years ago. At that time, we were led to believe libproxy didn't handle all the proxy types we did. We were corrected on that, but I, at least, missed that correction being posted. (Sorry, sometimes I'm blind, especially if something like that is buried in a flood of other ticket mails.) I suspect I'm not the only developer who did. Secondly, we're all creatures of habit. As the old saying goes, "if it ain't broke, don't fix it." Well, quite honestly, it's not broken for us as developers! Mainly that's because either we don't use proxies or any proxies in our way don't do any of the crazy stuff we ran into in this case. If it's not broken for us, we don't have much incentive to go hacking stuff up to support new libraries that solve problems we don't experience. I know that sounds like a lame excuse to a lot of you, and I can understand how it seems that way. But if we don't experience the problem, it's hard to test that we've fixed it, and we could in fact be making matters far worse for everyone else.

All this said, we probably should support libproxy. I've been thinking about how we could do this in a quick and effective manner, and so far I've come up with a few ideas that don't feel like they work very well. I think this is a perfect case where code should talk, or at least provide an example. So, I invite people who would like to see us support libproxy to write patches. Actively engage us on our development mailing list (devel@pidgin.im), talk with us in #pidgin on irc.freenode.net, or drop by our XMPP MUC (devel@conference.pidgin.im). Or, do some combination of the three. I can't promise we'll be the most valuable resources during the process, but we do at least try.

Now supporting libproxy is one thing. Actually being able to do useful stuff with the information libproxy gives us is another thing entirely. Our actual proxy connection code is, shall we say, a bit sub-par. Quite frankly, it sucks, even ignoring the crappy configuration portions. While supporting libproxy is nice and may solve a lot of our proxy problems, I guarantee it won't solve them all. Ideas and patches to fix this are greatly appreciated too.

I look forward to hearing from those of you inclined to help!

Pidgin 2.7.0: Movin' on Up

2010-05-13T22:13:00.002-04:00

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!

Plugin Authors: Save Your Users' Sanity!

2010-04-30T01:12:00.004-04:00

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!

Time flies...

2010-04-27T19:03:00.003-04:00

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!

On The Subject of Bugs, or Help Wanted and Needed!

2010-01-31T23:14:00.003-05:00

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!

The Quest Never Ends

2009-12-17T21:44:00.008-05:00

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!

The Quest for Perfection

2009-11-13T02:41:00.010-05:00

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!

Pidgin and the Incredible Shrinking (Finally!)--And Growing‽--About Box

2009-10-03T18:50:00.006-04:00

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!

Pidgin 2.6.0--It's About Time

2009-08-18T23:50:00.004-04:00

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!

Pidgin 2.5.8 and Other Ramblings

2009-07-02T00:35:00.003-04:00

Well, Casey already pointed out that we released Pidgin 2.5.8, but I thought I would expand on that a bit.

As everyone reading this knows already, Yahoo was broken for us briefly. We rushed out a 2.5.7 release to address the problem and after release discovered that we had a number of other problems. Among these were broken file transfers, broken buddy icons, etc.

We were receiving almost as many complaints about buddies never changing to show as offline as we got about the original Yahoo connection problem. Quite frankly, I got tired of it, so I started grabbing additional changes that we had committed to the upcoming 2.6.0 and applying them to 2.5.7. Eventually this yielded 2.5.8, which turned out to take a lot longer than I expected to get released.

As the ChangeLog indicates, we fixed a bunch of stuff, including an ICQ crash, an MSN crash for users with long buddy lists, a Yahoo crash introduced in 2.5.7, as well as receiving messages from the web version of MySpace IM and signing on to MySpace IM if you have an empty buddy list.

If you're not using Pidgin 2.5.8, upgrade!

We're also busily at work on Pidgin 2.6.0. In recent weeks we've come down to just a few things holding up the release. Among the blockers are the merging of some new features and fixing a new crash that we introduced by fixing ther crashes. At this rate, we might actually get 2.6.0 out sometime this year!

On an unrelated side note, I was recruited to participate in a charity fundraiser for the Muscular Distrophy Association. If anyone would like to help me reach my fundraising goal, I'd appreciate it.

Some Clarification on Yahoo! Issues

2009-06-24T01:16:00.008-04:00

From the recent activity on our support mailing list and in our IRC channel (#pidgin on irc.freenode.net), it's plain to see there is still a LOT of confusion about the recent troubles logging into Yahoo Messenger via Pidgin. I'm going to try to clear some of the confusion up. I apologize for the technical nature of this post. Feel free to skip ahead to the last paragraph of "Solving the Problem" below if you don't care what the problem is and just want to fix it. Or take the simple approach and just upgrade to Pidgin 2.5.7 and skip down to "But I already upgraded! It still doesn't work!" if you still have trouble.

The Problem

The specific problem that affected us is the authentication mechanism. Yahoo Messenger 6 used a spectacularly complicated password obfuscation method to "encrypt" the password as it was being sent over the wire to Yahoo's servers. Back in 2004 when we were preparing our 0.79 release, Cerulean Studios, the creators of the Trillian client, were kind enough to implement this authentication mechanism for us. As part of this change, we began to identify to the Yahoo servers as Yahoo Messenger 6. This was all fine and well.

The real problem came relatively recently. At some point in our recent history, which I honestly don't feel like tracking down now, we started identifying as Yahoo Messenger 7. At some point after that we again updated to identify as Yahoo Messenger 8. Both of these changes were related to file transfer and other feature enhancements. When we made these changes, however, we never updated our authentication code. This means we were claiming to speak Yahoo Protocol version 15 but we authenticated the same way protocol version 13 clients do. Even this worked for quite some time.

Yahoo began upgrading their servers at some point recently to phase out the old Yahoo Messenger 6 client. In effect, they want to force users of older software to update to the current client. Whether this is a good thing or not depends on your perspective. From Yahoo's point of view, I'm sure this is an excellent move, as it should make their server software simpler (speak one less protocol, one less auth scheme, etc.) and reduce their support load (fewer client versions to deal with). Where it became a problem for us is that at the same time, they started requiring protocol version 15 clients to speak the version 15 authentication scheme, which we never implemented. Since we still spoke version 13's authentication, this cut us off entirely.

[Note: Some users have discovered that not all of the Yahoo Messenger servers are rejecting the old authentication mechanism from Pidgin. The number of servers that still accept it appears to be shrinking, however. We advise upgrading to Pidgin 2.5.7 as soon as possible.]

Solving the Problem

A few months ago, a kind soul pointed out to us documentation he had assembled on how the current Yahoo Messenger client authenticated and communicated with the servers. It turns out that the convoluted authentication mechanism we had used for years was replaced with a significantly simpler one that uses a few simple HTTPS requests. The beauty here is the login data is encrypted in the same manner as your communications are encrypted whenever you purchase merchandise at a retailer like Amazon. This makes it significantly simpler for us, and probably allows Yahoo to simplify things on their end as well while increasing security during the login process for all their users.

As I mentioned in my previous post, two of our Summer of Code students, Sulabh Mahajan and Mike Ruprecht (keep an eye out for these names--they're responsible for chunks of Pidgin 2.6.0's changelog!), implemented this new authentication scheme. We eventually merged it into what will become Pidgin 2.6.0. This code has had some quality testing already, thanks to the guys over at Adium.

In response to the Yahoo server changes, I (quickly) yanked the most important changes for this new authentication scheme and slapped them onto Pidgin 2.5.6. After some testing and some other important bug fixes, we kicked Pidgin 2.5.7 out the door. In theory, upgrading to Pidgin 2.5.7 should make most people's Yahoo problems go away.

But I already upgraded! It still doesn't work!

Yeah, we have had a few people with this problem. Here are a few suggestions:

Change your Yahoo account's Pager Server field (located on the Advanced tab when editing the account) to 'scsa.msg.yahoo.com', especially if you previously read this document
If you're crashing when you connect your Yahoo account, again, set your Pager Server to 'scsa.msg.yahoo.com' and try to log in again. If you can't edit your account, you have two options:

Run Pidgin from a shell (command prompt). 'pidgin -n' will cause Pidgin to start up in an Offline status, thus allowing you to edit your accounts. Set the Pager Server as described above.
If you know the name of the server that you entered in the Pager Server field, you can change this manually. Locate your .purple directory (covered in the FAQ!). In this directory is a file called accounts.xml. Open this file with an editor (Wordpad on Windows; any text editor will do on Linux and other Unix-like systems) and find the server name you entered. Change this value and save the file. Start Pidgin and you should be fine.

If you upgraded by compiling Pidgin yourself, make sure you removed your distribution's existing libpurple package (for Ubuntu and Debian users this is libpurple0; for RedHat/Fedora users it should be libpurple). Then run 'sudo ldconfig' (or 'ldconfig' if you have a root shell already) and try again.
If you're behind a proxy server that proxies HTTP connections but not HTTPS connections, and you have to explicitly configure the proxy in Pidgin, you're probably not going to have any luck. Our current proxy code can't handle this kind of configuration. Sorry.
If you're on Windows and you get errors about a corrupted installer, clear your browser's cache, then restart your browser and try to download again.

But I can't upgrade!

If you really can't upgrade, then try setting the pager server to either 'scsc.msg.yahoo.com' or 'cs101.msg.mud.yahoo.com' and try again. But you really, really, really, really should upgrade. If you do eventually upgrade, you'll have to change this again, as I describe above.

I upgraded but now ______________ doesn't work!

We've had some reports that after upgrading there are some issues such as missing buddy icons and buddies never being shown as signed off. We are looking into these issues and hope to have them fixed for Pidgin 2.6.0. These issues didn't show up in my testing before the 2.5.7 release.

Tracking Yahoo Problems

Please don't open any new tickets about these issues or about not being able to log in. There are already open tickets to track them. Please also don't comment with "Me too!" or similar on these tickets--it just creates more noise for us to sort through when we're working on Pidgin. If you want to express a "Me too" on one of the tickets, click the arrow near the top of the ticket page that's pointing up. This will cast a vote for the ticket.

I hope this information is helpful to people.

The Great Yahoo Debacle

2009-06-20T19:28:00.003-04:00

By now it's no great secret that Yahoo has decided to break clients that use outdated authentication code. The result of that change is that Pidgin 2.5.6 and older no longer work unless you connect to one of a very few servers left that still speak the old authentication mechanism. We knew this change was upcoming, but all indications we saw pointed to us having almost another two months to push a release with updated authentication code.

All that aside, we've had some updated authentication code for a while now, and were originally waiting to include it in the Pidgin 2.6.0 release. However, since Yahoo made the authentication changes earlier than we expected, we had to react as quickly as possible to stop the flow of incoming complaints. As a result, we backported the Yahoo authentication changes so we could cut a Pidgin 2.5.7 release fairly quickly.

Pidgin 2.5.7 is now released and does work to connect to Yahoo.

Just for the record, I'd also like to point out to those who complained about waiting three days to get a working release that the last time Yahoo screwed with authentication, it took over a week to even get code to fix the problem, let alone prepare a release and actually get it out to users.

Additionally, we fixed the annoying MSN disconnect-on-block issue and changed AIM's behavior such that the "could not retrieve your buddy list" error appears only once per AIM account.

Enjoy the new release!

Random Monotone Hacks

2009-05-28T20:14:00.003-04:00

I imagine most people who bother to read this blog know that I am rather fond of Monotone, the distributed version control system (a.k.a. DVCS) that we use to maintain Pidgin's code. One of the most convenient features of monotone is that it's extensible via the Lua scripting language. Over our time using monotone, some of us have come across (or written!) some useful snippets of lua code that can be tossed into ~/.monotone/monotonerc to make things easier on us.

The first such snippet is pretty simple. I have three monotone keys that I use for various purposes. One is for Pidgin development, another is for my work on the Guifications project and the Purple Plugin Pack. The third is for my private projects. Instead of needing to remember to specify which key I want to use in specific circumstances, a small snippet of lua can take care of this for me (of course, anyone wanting to use this will need to edit branch patterns and key names appropriately):

function get_branch_key (branch)
    d = { ["im.pidgin"]="rekkanoryo@pidgin.im",
          ["org.guifications"]="rekkanoryo@guifications.org",
          ["org.rekkanoryo"]="rekkanoryo@rekkanoryo.org"
    }

    for k, v in pairs(d) do
        if string.find(branch, k) then
            return v
        end
    end
end

Monotone also has the ability to cherry-pick revisions from one branch to transplant into another. (Of course, I recognize that other DVCS tools have this capability too.) To do this, ordinarily we would issue a command like mtn pluck some_revision_id within a working copy of the branch we want to transplant the revision to. In our experience, the default log messages for a pluck leave some to be desired. My fellow developer Sadrul wrote this cool bit to add a pluck-log command to Monotone.

The pluck-log command takes a series of individual revision ID's as arguments. For each revision ID in the list of arguments, the command will execute mtn pluck $REV to grab and apply the changes to the workspace. Additionally, the plucked revision's original changelog entry will be inserted into the changelog for the new commit on the current branch. This is particularly useful if you're creating a new release branch by branching from a previous tag, then grabbing individual revisions from your main development branch. This command became popular among us Pidgin developers while we were preparing the Pidgin 2.5.6 release.

Here's the code:

--[[
  Pluck a revision with the log and authors filled in for the next commit log.

  @author: Sadrul Habib Chowdhury (updated for mtn 0.43 by John Bailey)
--]]

-- pluck-log command
function pluck_log(...)
  local revs = {...}
  local result
  local topsrcdir
  local logfile
  local log

  -- mtn_automate() returns a pair of a boolean and a string; we don't really
  -- care about the boolean here, but we need to do something with it.
  result, topsrcdir = mtn_automate("get_workspace_root")
  topsrcdir = string.gsub(topsrcdir, "\n", "")
  logfile = io.open(topsrcdir .. "/_MTN/log", "r")
  log = ""

  if logfile then
      log = logfile:read("*all")
      logfile:close()
  end

  table.foreach(revs,
      function (index, rev)
          r, sel = mtn_automate("select", rev)

          if r == false then return end

          for rev in sel:gmatch("%S+") do
              r, certs = mtn_automate("certs", rev)

              certs:gsub("%s+key \"(.-)\"\n%s*signature \"(.-)\"\n%s*name \"(.-)\"\n%s*value \"(.-)\"\n%s*trust \"(.-)\"",
                      function(key, sig, name, value, trust)
                          if name == "changelog" then
                              log = log .. "*** Plucked rev " .. rev .. " (" .. key .. "):\n" .. value .. "\n"
                          end
                      end
                  )
              execute("mtn", "pluck", "-r", rev)
          end
      end
  )

  logfile = io.open(topsrcdir .. "/_MTN/log", "w")
  logfile:write(log)
  logfile:close()
end

register_command("pluck-log", "REVISION1 [REVISION2 [...]]", "Pluck a revision with a good log",
      "This plucks a list of revisions, each individually, and adds the changelog of each revision for the next commit log." ..
      "\nEXAMPLE:\tmtn pluck-log h:im.pidgin.pidgin deadbeef\n",
      "pluck_log")

The resulting log entry will look something like this:

*** Plucked rev 074c5aedf9bbc512331f0d3130f076190b290676 (rekkanoryo@pidgin.im):
Set the default pager host to scsa.msg.yahoo.com; this seems to be what the
official client uses.

Originally, Sadrul wrote this code for mtn 0.42 and earlier, which did not have the mtn automate get_workspace_root functionality. I updated the code to call mtn_automate("get_workspace_root") instead of finding the workspace's root with successive checks of parent directories. The revision ID printed in the log was also truncated to the first 8 digits. Ordinarily, this is fine; however, it's possible that in the future a new revision will be created that has the same first 8 digits and thus the short ID will be ambiguous. I wanted to avoid this situation, so I removed the truncation. I also rearranged a few things to make it easier for me to read. I also have to credit my fellow Pidgin developer Elliott with figuring out that I needed to kill the trailing newline in the string returned from mtn_automate("get_workspace_root").

Hopefully we're not the only ones who find this stuff useful. As I make frequent use of other useful monotone lua hacks, I'll probably post about them here too.

Pidgin 2.5.6

2009-05-24T14:32:00.003-04:00

Well, as most people have noticed by now, we recently released Pidgin 2.5.6. This release was simply a bug and security fix release. Hopefully it will hold everyone over until we can kick 2.6.0 out the door!

Linux Journal Readers' Choice Award

2009-05-02T09:41:00.003-04:00

Yesterday, Linux Journal issued a press release announcing the winners of its annual Readers' Choice Awards. It's an annual event that attracts a lot of attention in the magazine. In their effors to "take the pulse of the Linux community," they run this poll and announce the winners and grant honorable mentions to "strong contenders" in the pool of runners-up.

This year, it's been announced that Pidgin has won a Readers' Choice award for Favorite Communications Tool, a category that we're no stranger to winning--we won this same category last year as well. The landscape is similar as well. This year, we won with 42% of the votes, beating out honorable mention Skype, which received 18% of the votes. Last year, we also garnered 42% of the votes, with Skype and Kopete earning honorable mentions at 17.8% and 12.8% respectively.

Winning this award for the second year in a row reminds us that our work is quite well appreciated, something that is often easy to forget. It also reminds us that every once in a while we need to stand back and thank everyone involved in making Pidgin such a popular project. In this case, we need to thank the 2,000+ people who voted for Pidgin in these Readers' Choice Awards, as well as all our developers, Crazy Patch Writers, drive-by contributors who spot a simple bug and fix it, and our users. All of these people in our community come together to make Pidgin a success as a project, and while we'd be just as happy to work on Pidgin if we had only a few hundred users, we certainly appreciate all of the contributions to our success. Thanks!

And the Summer of Code is set!

2009-04-20T23:57:00.002-04:00

Well, Google finally announced the list of accepted students for this year's Summer of Code. You can read about our accepted proposals here. Of course, we're all very excited about the projects we've chosen for this year. We have two students returning to us this year, both with projects that will be hugely important moving forward. Those students are Eric Polino and Sulabh Mahajan.

Eric has chosen to work on GObjectification, which will move libpurple from using our own object system to taking advantage of the GObject capabilities of GLib, one of our existing dependencies. As a result of this project, a massive amount of libpurple infrastructure will change, allowing us to leverage a tried and true typing system and giving plugins an incredible amount of increased flexibility by allowing them to subclass objects and providing interfaces they can implement. This will, of course, have huge rammifications for everyone using libpurple--us, plugin authors, Adium's authors, and even the Instantbird authors. We're confident the result will be worth the effort, though.

Sulabh has volunteered to take on the Privacy Rewrite. What makes this such a daunting task is that the protocols we support provide a very wide range of privacy options, some of which are unique. For example, ICQ supports an "invisible" list and a "visible" list in addition to a "block" list and probably a number of other things that I'm forgetting. Sulabh will have to look at what all our protocols support and provide a foundation in libpurple for all the protocol plugins to provide the privacy options their protocol allows for. Additionally, he'll have to smooth over the differences between protocols to make things consistent.

In addition to these projects, we've accepted two proposals for native Windows user interfaces. Each project will take a different approach to achieve the same goal--providing a user interface that fits better into a Windows desktop than Pidgin currently does. I've already seen a few complaints that we accepted two projects for this. Quite frankly, I don't understand the complaints. We chose two projects for two reasons--first, we want to have the highest possible chance to better serve our Windows users, and second, it's entirely possible that a single Windows UI project won't be able to do enough to satisfy all our users. Having two Windows UIs will allow each to focus on whichever set of users it is more appropriate for.

We've also accepted projects that will make XMPP transports based on libpurple, allow libpurple to use telepathy protocol support in addition to or instead of our own, and using webkit for our message displays. Each of these projects is going to be challenging in its own right. Of all the projects, the XMPP transports will certainly be the least user-visible, as the transports will run on an XMPP server. Conversely, the most visible will probably be the webkit message view, as this will completely replace what we currently use to display messages. By using webkit, it's possible that we'll eventually be able to support Adium Message Styles (no, I'm not promising this support will happen, but it will be possible). The Telepathy plugin will provide some interesting functionality by allowing us to use nothing but telepathy for protocol support if the user so chooses.

There are other deeper details in these projects, but I've already wasted too much time obsessing over this post and discussing the larger projects in detail. I'll leave further discussion of the technical merits and details of projects to the students and mentors. Needless to say, this post could have gone on just about forever. ;)

Overall, this Summer of Code looks like it will be one of our best. Good luck to all our students!

It's that time again...

2009-03-26T23:00:00.004-04:00

Well, once again we've come to the student application phase of Google's Summer of Code program. We're several days into the process, and we've seen a marked decrease in our intake of student applications compared to prior years. Why is anybody's guess, but I'm personally hoping it means that potential applicants are spending more time polishing their applications before submitting.

Based on the applications we've seen so far, I'd like to publicize a few notes for applicants:

Provide a detailed timeline for your project. "I expect to complete work in 10 weeks" doesn't cut it here. Tell us what milestones you expect to achieve and how far along. You could instead estimate how long a specific goal will take to implement. Yes, your estimate could ultimately prove wrong, but that's not necessarily the end of the world. We really want to see that you have a concept of time management and prioritization.
Don't plagiarize. If we know you're plagiarizing, we'll invalidate your application. If you can't deliver an application without plagiarizing, you shouldn't be applying. We don't mind if you use some of the text on our ideas page to help with the abstract, but keep in mind that a serious application won't rely on simply copying and reformatting what we've already said.
Don't be afraid to come up with a unique idea! The ideas page are not the only ideas we'll entertain. We love to see well thought-out, original ideas, especially ones that make us wonder why no one proposed it before.
Make sure your proposal is for a specific project idea. A general "I want to work with Pidgin for the summer" is a sure ticket to the reject bin.
You don't have to write an encyclopedia for the application, but you do have to give us something to work with. There's an old adage that "less is more." Sometimes that's true. Sometimes the opposite is true. The point here is that you should be verbose enough to explain your idea, but don't ramble. I know this can be difficult to judge. Just re-read the application, make sure it makes sense, and make sure it doesn't drag on needlessly.
You have to apply using the SoC webapp, not our mailing lists. We have to have applications submitted via the SoC webapp in order to review them and have them in the running for our student slots. This is a Google thing, and it makes everyone's lives a lot easier.
The application isn't final until submissions close. We will provide feedback on your application if it needs work. You can modify your application to address our feedback until applications close. Use this to your advantage!
We don't yet know who will mentor any given project. We don't assign final mentors and backup mentors to projects until we have decided which projects we want to accept. Asking us about this is just wasting your time.
We expect you to treat the project as a full-time job. That means at least 35 hours per week. We want to make sure everyone gets the most out of Google's money, and this is one way to do that. Since you'll technically be a contract worker, we expect the contracted work (your project) to take priority.
We expect you to remain actively involved with us after the Summer of Code finishes. Quite frankly, if you're going to collect the checks and run, you're missing the entire point. The Summer of Code is intended to attract new contributors and get them involved in open source software, turning them into long-term contributors. Participating in the Summer of Code and then disappearing isn't serving that intention, and leaving us with code we have to maintain ourselves is quite rude. If that's your intention, please don't apply. Let the potential for acceptance go to someone who will stay with us.

Keep these in mind, and happy applying!

Saved Statuses for Fun and Profit

2009-02-26T01:29:00.010-05:00

From my limited experience with Pidgin users among my family and coworkers, I've discovered that a number of users don't know about Pidgin's saved status features and instead use only the transient statuses created directly in the status selector by typing a message. Some users don't even realize that they can select a previously used transient status from the middle section of the status selector's menu. As an attempt to spread deeper insight into Pidgin, I submit for your reading this saved status tutorial.

Overview of Saved Statuses

In Pidgin, a saved status gives you a considerable amount of flexibility. For example, if you use six accounts, three of which are personal and three of which are for work, you can use a saved status to have your work accounts away while your personal accounts are available and vice-versa. Or, if the text box you get from using the status selector irritates you, you can use saved statuses to get rid of it forever.

Creating a Simple Saved Status

Let's start with two basic saved statuses--one Available status and one Away status.

Click the status selector at the bottom of the buddy list window. You should see something like this:

Select the "New status..." entry. You should see something similar to this:

The fields here should be pretty obvious and self-explanatory. The title will be what you see in the status selector menu. Generally, I use a descriptive title, such as "Away - Sleeping" or "Available - no message," that will quickly identify the message's contents to me without needing to read the message. For this example, I'll use "Away - example."

For Status, obviously you want to choose one of the basic statuses listed--Available, Away, Invisible, Extended Away, Offline, Do Not Disturb, or Invisible. If you use only one account, your choices could be significantly different. For this example, we'll accept the default of Away.

in the Message box, type your status message. For my example Away status, I'll use the message "Away for the sake of being away."

Click Save. Alternatively, if you want to use this status now, click "Save & Use." You could also click "Use," but then the status would not be saved.

Now, repeat the process for an Available status. In this example, I'll have a title of "Available - no message", a status of Available, and a blank message.

Now, if you select "Saved statuses..." from the buddy list window, you should see something like this, but probably with a lot fewer statuses listed:

Creating a Complex Saved Status

A complex saved status is where the real power of saved statuses becomes obvious. Let's modify the existing away example we created. Select it in the saved status list and click "Modify..." Now click the expander just to the side of "Use a different status for some accounts" and observe the list of accounts that appears.

Put a checkbox in one of your accounts. For this example, I'll use my pidgin.im XMPP account. Now you see a much simpler new dialog:

For simplicity's sake in this example, I will choose "Extended away" as the status and use "test" as my message. After clicking OK, I return to the modify status dialog, to see something similar to this:

Now you can click "Save" or "Save & Use." This gives you essentially the simplest form of complex status--one in which only one account differs in status from the other accounts. Using this status will cause all but that one account to appear as away, and cause that one specific account to appear as extended away (note the clock vs. the circular sticky note).

Using a Saved Status

To use a saved status, you can select it in the status selector's menu if it's listed. If it's not listed, simply click "Saved statuses..." in the status selector to bring up the Saved Statuses dialog, then select the status you want and click "Use." The status should now be remembered in the "popular statuses" (middle) area of the status selector menu. Of course, with disuse or use of a large number of statuses, a given saved status can fall out of the saved statuses list, in which case you'll need to repeat the process of finding it again. If you use the statuses a lot, though, this won't be a problem.

Practical Applications

Saved statuses aren't for everyone, of course. They do provide a number of possible complex status combinations limited only by the number of accounts you have in Pidgin. They also let you get rid of the ugly text box for status messages for as long as you use saved statuses. They also offer a relatively quick setup time that allows you to create your status once and use it as many times as you want without ever having to think about how to configure the status again.

Enjoy playing with your newfound saved statuses!

You Can't Please Anyone

2009-02-26T00:27:00.004-05:00

Occasionally we make changes to Pidgin which displease some subset of our users. For an example, I'll give a brief history lesson.

We released a series of six betas leading up to our name change to Pidgin. In our first beta, 2.0.0beta1, we introduced the concept of the status selector. At this time it was a rather crude creation; it simply mashed a few widgets together to accomplish the basic tasak. When we introduced this status UI, we also introduced the concept of two ways to handle status messages. The first, and most obvious, way to handle status messages was to present a text box when selecting a basic status from the status selector in which to enter the status message. The other method was a bit more complex but significantly more powerful--this was the saved statuses feature accessible from the "Saved statuses..." entry in the status selector's menu.

When we first inroduced this UI, the behavior of the text box was to retain the status message whenever the status changed from, for example, available to away or from away to available. A number of people, myself included, were not happy with this. Eventually we changed the behavior to clear the message on status change. This displeased another group of users. Now here we are, two years later. We changed back to retaining the status message on status changes pursuant to a discussion on the development mailing list. Again, we've displeased a group of users.

The problem with this particular change is that both behaviors are valid, and fans of each behavior think their preferred behavior is the only correct behavior. Of course, now that we acknowledge that both behaviors are valid, many users' first reaction would be to say "Make it a preference!" Of course, that's a whole new argument in itself, but this is such a minor feature that it's not important enough to warrant a preference.

Note that the people who don't like the retention of the status message are inconvenienced by a single keystroke if the intended result is to clear the message, and not inconvenienced at all if the intention is to use a new message. This inconvenience, or lack thereof, is because we chose to implement the retention such that the retained message is highlighted. This means that simply hitting backspace will clear the message and typing an entirely new message will replace the message text with what you've typed.

Simply put, this change is just further proof that when you're involved in a project of any significance, you're damned if you do and damned if you don't, no matter what you do or don't.

I'm sure this post will inspire some criticism. For the time being, though, I think it's best if we ride this wave of criticism out for a bit and see if this is simply resistance to change or a genuine "problem."

MSN Issues

2009-01-12T12:19:00.004-05:00

Since last evening, we've had an influx of users into #pidgin, trac, and the support mailing list because they're not able to connect to MSN. Initially, we thought this was a server-side issue, because the error message we receive from the server makes it look that way. However, we've come to find that it is actually a minor protocol change in which the server now expects us to send a piece of data we don't send. We are working on a solution. There is no need to send further mail to the support list, open new tickets, or pour into #pidgin.

Again, we know what the problem is and are working to fix it.

And the survey says...

2009-01-09T22:59:00.009-05:00

Well, we got quite a lot of user feedback in the survey that Casey ran on our site. I've read through a lot of it and thought I'd share some replies to specific comments. Keep in mind that we received many thousands of comments, so your exact comment may not be addressed here. With so many comments, it's very time-consuming to go through them all, so I just picked a few that stood out to me. At any rate, here we go:

Complaints

"Could be clearer how to set up pidgin with ssh." - This request isn't quite clear, but I'm going to assume that the person wants to know how to use Pidgin either with an ssh tunnel or with ssh acting as a proxy. In the former case, ssh tunnels are documented quite extensively; you would configure your tunnel, then configure the Pidgin account to connect to localhost on the port you're forwarding. Using ssh as a SOCKS5 proxy is also well documented; you would set up the ssh proxy according to the documentation and then configure Pidgin's proxy settings to use the proxy on localhost. We haven't documented this ourselves because a lot of good generic documentation already exists, and it's not exactly a common use case that we see.

"I would like to see auto-reconnect be more resilient. I tend to have to manually reconnect after actual network outages. Also, it'd be nice if the encryption plugin knew when to get out of the way." - This is actually two comments, but I'll address them both. The auto-reconnect feature uses an exponential backoff that starts at just a few seconds between attempts and backs off to a maximum retry time of 34 minutes. If your Pidgin is compiled with NetworkManager support, NetworkManager may cause some delays due to not realizing the network is back. On Windows, there are some interactions with the Network Location Awareness features in Windows XP and Windows Vista that can cause delays in the reconnection as well. As for encryption, we didn't write the encryption plugins; that's a complaint/suggestion best taken up with whoever wrote the plugin you're using.

"Fix the chat input box please, or I'll switch to Carrier/Fun Pidgin." - Isn't Carrier dead? Anyway, if you feel the need to switch clients, that's your prerrogative. We've debated this at length on numerous occasions and we've decided to stick with the autoresizing input area, at least for now.

"Have the buddy list show up when i open pidgin, and have a popup when a person says something in a conversation." - There are two plugins already that provide popup notifications. One is called Guifications, the other is pidgin-libnotify. Windows users need to use Guifications. Users of other operating systems can use either. As far as the buddy list visibility goes, if you want to see the buddy list when you open Pidgin, either set "Show system tray icon" to "Never" in preferences, or have the buddy list open when you close Pidgin. The ability to start with the buddy list hidden was a feature request we chose to implement, and it would cause too many complaints for us to remove it.

"Better memory usage on windows or an up to date GTK included." - We do actively try to reduce Pidgin's memory usage where we can see room for improvement; patches are welcome for conditions we don't see. Our Windows person bundles new GTK+ runtimes as it's confirmed that new WinGTK+ releases don't introduce problems for us.

"crashes, crashes, crashes" - We do our best to fix the crashes that get reported. Perhaps you should read "Tips for Bug Reports" and then open a ticket.

"Docking pidgin in windows vista rearranges my icons on the desktop, but this is a problem with all programs that dock so not really important." - You've correctly realized on your own that Pidgin is not at fault here. This is a bug in Windows' desktop management, which we can't do anything about. I remember seeing this bug as far back as Windows 98, so it's not exactly new either. Maybe Microsoft could be convinced to fix this 11-year-old undesirable behavior?

"None. Keep it simple. I love that." - Thanks! We love simple. Clean, too!

"File transfer speed in MSN protocol" - We know a lot of our users are dissatisfied with the state of MSN file transfer support in libpurple. We're sorry you're not happy with it, but it's just not a priority for us. If someone comes along and implements a good (or even semi-reasonable) patch to do this, we'd be happy to work with that person to include better transfer support.

"Startup time. It takes about 10 seconds for me to get Pidgin 'usable'." - 10 seconds is not an unreasonable amount of time. Remember that Pidgin has to connect to all your accounts (MSN can be particularly slow here!), load your buddy list from the server, apply your saved preferences, load your saved plugins (including the protocol plugins), etc. There's a lot of work that goes on in those 10 seconds that is difficult, if not impossible, to streamline any further. You may, however, be able to shave some startup time off by removing any plugins you don't use (you can see paths and filenames by going to the Plugins window, clicking on a plugin's name, and clicking the expander by "Plugin Details").

"Some XMPP contacts are added twice." - We've had this bug forever, and it irritates us too. There has been some recent work on this. It should be better in 2.5.3 and 2.5.4 than in previous releases.

"1) One thing that confuses me...when a pidgin window aside from the chat window has focus (Buddy List, Manage Accounts, etc), and you type, it opens up a little window with that text in it...I probably just need to RTFM and it's working as intended, but who knows... 2) When setting status to Away, you are allowed to enter a message. Prior to version 2.5.2, when setting status back to Available, this message would be cleared automatically. From version 2.5.2 and after, it is now highlighted for manual deletion, which I find annoying. 3) Animated smileys would be awesome (but I assume that is more so on Hylke). I do love the current smileys though!" - Three points, so three answers: 1. This is a feature provided by GTK+ sometimes called "typeahead search." If you type text that matches a buddy's name or alias, that buddy will automatically be highlighted. 2. We discussed this a couple of times. Both use cases are valid, but it's our opinion that it's less annoying for people who want new messages to have to type a single backspace than it is for users who want to keep the same status message across multiple statuses to have to retype their whole message. Sorry. 3. Yes, animated emoticons would be something Hylke would need to create for us if he felt so inclined, but I think we'd all be better served if animated emoticons were a separate theme from the default.

"GTK" - I'm going to go out on a limb and say the person who wrote this complaint is a Windows user. We use GTK+ because Windows was not our first platform, and GTK+ was the best toolkit for the purpose when Pidgin was started in 1998. We would love to see someone write a native Windows interface for libpurple, as we know it would serve most Windows users better than our GTK+ interface ever could.

"It is not very easy to install Pidgin on Linux distributions, especially because of dependencies." - This is true of source-based installation of Pidgin for those who don't compile many applications themselves or those new to the world of compiling applications. Pidgin is provided in a pre-packaged, dependency-tracked format by all the major Linux distributions, as well as through the BSD ports system, Fink on Mac OS X, and Macports on Mac OS X. All of these distributors provide an extremely simple way to install Pidgin.

"Using special characters in statuses crashes Pidgin. With MusicTracker, this can happen a lot... and crash my client. Pidgin ought to replace these characters with question marks or something. Also, file transfer is very slow and erratic, especially with non-Pidgin users." - I've covered the file transfer above, to an extent. Special characters themselves don't crash Pidgin. MusicTracker could probably prevent some crashes by making sure that all strings it passes into libpurple are UTF-8. We have recently made some changes that should help in this regard, but plugins should still make sure they hand us only valid UTF-8 strings.

"Pidgin steals keyboard focus when it raises a conversation window, which is very bad. I want windows to raise when I receive new messages, but without stealing keyboard focus, especially from another conversation window I'm actively typing in...." - I have trimmed a longer user submission here to a specific issue to reply to for clarity and brevity. Pidgin doesn't ask for focus. Some window managers, however, treat a raise request as a focus request. These window managers should be fixed. Trying other window managers and seeing their behavior would confirm this.

"I'd like to see some new looks available by themes (sounds included would be nice) so long as they don't change the position and location of various options. I know skins and themes are mentioned already in the survey but I've wanted them for a while and it's the only thing I can think of that I really want to see." - Some theming support, including sound themes, was worked on during the Google Summer of Code for 2008. We expect to release this work in Pidgin 2.6.0, but no promises.

"Wrong encoding for incoming messages from 'QIP' users (icq protocol) writing with diacritic marks in czech/slovak (encoding central european, both iso 8859-2 and win 1250)." - I really wish everyone would just use UTF-8 already. All these problems would magically go away.

"x-status support for ICQ protocol" - This is something else we expect to release in Pidgin 2.6.0.

"doesn't always connect to a network" - More details are necessary to help in this case.

"A two pane plugin-preferences dialog would be nice. You select the plugin on the left pane and the preference are displayed in the right pane." - It seems that no matter what we do for plugin configuration, no one's ever happy with it. If someone can come up with a plugin configuration dialog that everyone can live with, I'd gladly fight (if needed) to get it in a release.

"Please fix the auto-away option - it's been broken since at least version 2.1 or 2.2. For example, when status is set to 'Invisible', it changes to 'Away' after been idle for a while (this shouldn't happen when offline) - and then, when initiating a conversation with someone, it changes back to the original offline status ('Invisible' in this case)! Peer-to-peer MSN file transfers would also be nice, as that function is almost unusable in its current state." - Again, I have already covered MSN file transfers, but I'm responding to this for the auto-away complaint. I'll admit that the behavior you describe is undesirable, but it is working as designed. It might make sense to exempt an original status of "Invisible" from auto-away, but this is a slippery slope in some respects--we make this change for Invisible, and people will want all sorts of unique exceptions.

"Too many dependencies, make it lighter!" - Yes, we have a lot of dependencies, but very few of them are requirements. If you're building Pidgin yourself, you can disable all but the absolute minimum required dependencies by making use of the "--disable-????" family of arguments to the configure script ("./configure --help" will show you the options). We are very cautious about adding new dependencies unnecessarily.

"MSN protocol seems buggy, IRC isn't very customizable" - The MSN protocol plugin has had some major cleanup work done on it recently. In Pidgin 2.5.4, MSN support should be better than it was in 2.5.2 without the crashes we had in 2.5.3. The IRC protocol is somewhat unique in that it doesn't really fit well into Pidgin's IM-centric model. Pidgin really isn't designed to be a fully-featured IRC client; however, recent releases of Pidgin have functionality which allow plugins to interact with the raw IRC protocol data; someone so inclined could write plugins to extend IRC functionality.

"Chat timestamps on same line as name (not have a hole line devoted to timestamps." - Make your conversation window bigger or turn off some plugins to find the culprit, as there are a few that might be capable of doing that.

"I still miss protocol icons. Green "balls" suck hard." - Sorry, but this is something we're always going to disagree on.

"MSN extra forming like this: [c=61]NICK[/c][c=55]" - We currently have no intention of supporting this "feature" of MSN Plus. I would certainly be open to a patch that just stripped that garbage out, though.

Feature Requests

"An 'official' portable version." - We already provide one. Configuring a portable installation is explained in the FAQ.

"Close all the bugs. That's a major feature." - Oh, how I wish that were true.

"Skype support" - It's our opinion that Skype integration into Pidgin is not possible in a legal manner.

"Being able to add your own emoticons in msn" - This was added in Pidgin 2.5.0. See the Tools menu, and look for "Smiley."

"link to open mail inbox, even when there are no new emails to read." - At least our Yahoo! plugin provides this feature (Accounts->Your Account->Open Inbox). MSN does too, via Accounts->Your Account->Open Hotmail Inbox.

"Video and Voice" - This is currently in the works. We hope to have this out for 3.0.0 (no, we don't know when that will be).

"Major Changes to the interface should be supported as plug-ins. Functionality should NEVER be removed from a product unless that same functionality is re-included via a plug-in or an interface option." - This is, of course, your opinion. Our opinion is that if we were to do this, we'd have an unmaintainable mess of options and plugins. It would be impractical to implement and impossible to manage.

"I'd love to be able to set different notification styles for different groups/users; something like setting different ring tones on cell phones. Also along these lines, I'd love to be able to show different groups different status messages; for instance, if I'm at work and appear offline to everyone but my work buddies group." - Notification styles on a per-group or per-buddy basis is possible by using the Guifications plugin and installing and loading multiple themes. Then you can right-click a group or buddy and you'll find an option to change the Guifications theme for that group/buddy. The status messages per-group could be interesting if all the protocols supported it. However, to the best of my knowledge, no protocol (except possibly XMPP) supports such a capability.

"A Native Windows Interface or QT4 interface (also ports over to windows / Linux / MacOS quite easily from what I understand)" - We have no intention of developing such interfaces ourselves, but we would love if someone made a libpurple interface that fit natively into a Windows desktop environment. We certainly have no objections to someone creating a libpurple interface with Qt, either. None of our current development team has any interest in starting these projects, but I'm sure we're certainly willing to help (to the best of our abilities) with any issues we can.

"Expanded SIP support to replace Windows Messenger 5.1 (not Live Messenger!) since I use it all-day at work." - None of us use Microsoft's corporate instant messaging software, so it's difficult at best for us to make sure that such a protocol plugin is maintained. We also really don't want to pick up any additional protocol support, given our history of protocol maintainers disappearing. There is a team of developers working on the SIPe plugin with the explicit purpose of working with Microsoft's products. Perhaps you should investigate this plugin.

"Better password security. Please, encrypt the passwords inside your config files." - We have an entire wiki page devoted to this topic. Encrypting passwords in accounts.xml is pointless, as it would be trivial to use our own code in an attack. Further, password security is one of the topics of our most recent participation in the Google Summer of Code. We're hoping to have the work that was done on it released soon.

"more support for 3th party protocols like xfire etz meaning box release with these protocols etz" - Um, no. I already discussed the reasons we don't accept additional protocol support.

"Protocols as PlugIns (maybe selectable witch should be installed), AutoUpdate (not only tell about new Versions, also [if user agrees] download, close the client and open setup)" - Protocols have been plugins for many years now. We don't really see a point in making it possible to choose which protocols to install with the Windows install program. Automatic updates would only be useful on Windows, and could actually be done with a plugin if someone were so inclined to write one. We don't have any interest in making it happen though. Sorry.

"It'd be nice to see a version for Windows Mobile... maybe this is already out there and I need to Google... ?" - Pidgin requires GTK+ and Glib (among other libraries), neither of which are available for Windows Mobile yet. Pidgin and libpurple are also a bit heavy in terms of memory and processor time consumption for most devices that run Windows Mobile. You'd be muchbetter served by a client designed specifically to work within the limitations of the Windows Mobile platform.

"Skype support (I've tried the plugin, but it requires Skype client to be running and has no video support, so it's worthless)" - I've covered Skype support already, but I'm going to again point out that we feel this plugin is a violation of our license terms and should not be used by anyone.

"Facebook chat support would be an awesome thing. I'm using the plugin now, but it's got some quirks." - There was a discussion on the mailing list about Facebook support. We came to the conclusion that we don't want to deal with it. If and when Facebook ever rolls out their XMPP interface, we'll be able to support Facebook Chat effortlessly.

"Organize contact list by user by protocol. This way I have a single entry for the user and expand them for multiple ways to contact. It would clean up my contact list significantly." - We have supported combining buddies into contacts for years. Perhaps you should take a look at this FAQ entry?

"Integrated music player support for changing the status based on what I'm listening to...." - I trimmed this down too to get to the important point here. We don't want this in Pidgin. People wanting stuff like this is exactly why we have a plugin system.

"Add a spell check feature!" - We've had one for years. Install an appropriate dictionary for the language you're running Pidgin in.

"1. Support for buzzing/nudging 2. Mass inviting to chats 3. ability to receive MSN voice clips" - 1. We've had this support for years. Use the /nudge command on MSN and /buzz on Yahoo. 2. As soon as someone comes up with a sane UI for it, we'd be happy to accept the patch implementing it. 3. I personally wouldn't mind if this never landed in libpurple, but again this is something that would have to be implemented by someone who wants it.

"Being able to update Pidgin without having to reinstall the whole thing." - That's precisely what an update is--the whole application is replaced with a new version. What about this is unacceptable?

"Multiple user support. Set up a master password for each user to access their accounts." - We've discussed this on numerous occasions. We are not interested in implementing something that the operating system already handles perfectly with its native user account support.

"A plugin for general IMAP mail check. frameless contact list window like adium offers on OSX." - Pidgin is an IM client, not a mail client. That said, anyone who wants this feature is welcome to write a plugin to implement it. Frameless buddy list windows are much easier said than done. Remember that Adium supports precisely one platform, Mac OS X, and as such can do whatever they want to fit better into their environment. Given that we support more platforms than Adium, it makes it particularly difficult because we'd have to have hacks in the code for every platform we support, as well as multiple variations of each plugin. There's not enough benefit to warrant the increase in complexity and the inclusion of such ugly hacks.

"Database logger. There was a SoC project out but it never got completed. Probably due of developers not accepting the student's patches? Support for mIRC srcipts." - If you're referring to the "remotelogger" SoC project, there are some adjustments necessary, and ideally we'd be able to kill off some of the API that it supersedes, thus requiring a 3.0.0. It is, however, in our monotone repository. As far as mIRC scripts, again, this could be done by a plugin. We have no intention of having an internal scripting engine just for mIRC scripts.

"* Cook breakfast" - If Pidgin could cook my breakfast for me, I'd save a LOT of money by not needing to go somewhere for breakfast when I'm too lazy to cook for myself.

"Encryption for chatlogs, auto updating." - This can be provided better by the operating system than by anything we could possibly implement. NTFS filesystems on Windows support encryption, and there are many encryption options for Linux and UNIX environments. Storing your .purple folder in an encrypted area (by symbolic link/junction point or by wrapping Pidgin with a script to point to a non-default configuration directory) would thus give you encryption on your logs. I've already covered automatic updates.

"My opinions refers to Pidgin 2.5.2. Spanish support please and other languages." - We have an active Spanish translator. We have a total of 73 translations, over 2/3 of which are very actively maintained.

"A plugin manager that you could install plugins with, without having to manually place the dills inside of the folder would be nice. Something simialr to mozillas addon managers." - I actually have a plan for something like this, but I haven't been motivated to implement anything for it yet.

"UPDATE OPTION! Once I was running like 2.3.1, when 2.5.2 was out, and I had no idea, pidgin does not have any update monitor to let me know when updates are out, the actual process is simple and i love it." - Take a look at the Release Notification plugin that's included with Pidgin by default.

"More accessible extensibility. Having to write plugins in C and compile them is out of reach for many folks who would write decent plugins." - Perl and TCL plugins are already possible. On Linux/UNIX systems, it's possible to interact with libpurple over D-Bus as well.

General Feedback

"Please switch from Monotone to a wider-known DVCS like Git, Bazaar or Mercurial." - We chose our version control system very carefully several years ago. We went with what we felt was the best choice at the time, and currently, the effort involved in a switch incurs a much higher cost than it's worth.

Why the name change? (I paraphrased this question from several statements) - We entered into an agreement with AOL to avoid being sued for infringement on the "AIM" trademark. The agreement required a name change. This was discussed at length two years ago when we made the change. For the record, we can no longer use our former name, even in technical discussions. This too was part of the agreement.

"I've been always been happy with this product and think it is a fine example of Open Source software and Free Software ideals. Thank You." - And thank you for the kind words. There were a lot of people echoing this sentiment in the general feedback section. In fact, there were far more of this type of comment than I expected.

"Try not to be jerks when people are providing feedbak or suggestions trough mailing list." - It's always interesting to see this come up, because most of the time when we get these complaints, I find that our reactions are quite justified. I'd also like to point out that if you don't like us, you don't have to interact with us. I'm sorry, but we don't exist just to babysit all our users. We have over three million users, and we just can't do it for all of them, or even for a fraction of them.

"The development process should be more transparent, we the users have no idea what's coming next (and when), and if we want to find out, we have to browse dozens of pages of bug reports or some weird wiki page. I'm thinking about the whole 'MSNP15/Personal Message' thing, especially." - We don't know what's coming next or when it will show up either. The development process is transparent; come to our IRC channel, our XMPP chat, and the development mailing list. We have a lot of very public discussion on what we should and shouldn't do and what direction development should go in.

"Don't get me wrong, I appreciate all the effort made by Pidgin. But it seems to me the strong feelings of a few are getting in the way of a real, quality IM client. I understand the desire to remain lean and modular, but that only works up to a point. Of course voice and video chat make more sense as being plugins, but must there really be a plugin just to enable "hiding the buddy list when it's created" ? Pidgin is too complex for the average user. Firefox has struck a moderately good (I'll never say perfect) balance of what basic features are required for any browser and which ones require extensions. I think Pidgin can do the same for IM clients. I'm always looking forward to new releases. Thank you for your work." - Complexity is relative, and in the case of a web browser, it is significantly clearer what belongs in the application itself and what requires extensions/plugins. In an IM client, it's not so clear. This is why we have a plugins system--things we think don't belong in Pidgin itself can be developed as plugins. The strong opinions I and others express are a check and balance to make sure we don't as a project go to extremes, and also serve to keep us focused on important things like fixing bugs instead of pointless political stuff and catering to every person's whim. The thing a lot of our users forget quite easily is that we work on Pidgin for ourselves, so if we don't like an idea, we're going to rally against it and block its inclusion.

There are many more comments I'd have liked to address here, but there are just too many of them and I don't have the time to draft individual responses to all of them. I hope these responses show that we do listen to user feedback. We always listen, but we don't always act. There is a difference there that a lot of people don't understand.

The sheer number of responses we received, including the comments expressing what a good job we've done, have shown me that we were correct when we asserted that we had a huge portion of our userbase that is either indifferent to many of the changes we make or mostly satisfied with us in general and don't feel the need to send feedback.

In short, thanks for the feedback!

I love Windows. I really, really do. (Yeah, right)

2008-12-31T02:09:00.004-05:00

Well, it's been eight days since we released Pidgin 2.5.3. In that 8 days, we've had more duplicate tickets than we care to count over the all-too-common hang on exit on Windows systems. In the faint hope that people actually read my ramblings, I'm posting this here to give a brief synopsis of the problem and to discourage further duplicate tickets.

On Windows sytems, Pidgin uses threads for a few things, namely DNS lookups and Network Location Awareness (NLA) stuff. For the Linux-inclined, NLA is somewhat similar to NetworkManager. When we released Pidgin 2.5.3, we started getting a bunch of reports about hangs on exit (including a number of people who don't know the difference between a hang and a crash, but that's another post in itself). All the debug logs pointed to wpurple_cleanup(), a function we call on close to tie up some loose ends, or "clean up." One of the areas this function cleans up is NLA-related stuff.

This code hasn't changed meaningfully in quite some time, but magically it became a problem for users of 2.5.3. It doesn't really make any sense to me why this would suddenly stop working in the current release, but the previous release seems to be almost entirely problem-free in this regard. Confusion aside, however, we have a proposed fix that will be reviewed and possibly tweaked.

So in summary, we know what the problem is and we are working to fix it. Please, please, please don't open anymore duplicate tickets about it!

Pidgin 2.5.3 (Finally!)

2008-12-21T11:39:00.002-05:00

Well, we finally kicked Pidgin 2.5.3 out of the nest, two days late. It's spreading its wings and flying.

Noteworthy in this release are that 58 bullet points are in the ChangeLog (not counting the headers for libpurple, Pidgin, Finch, and the protocols) and 85 tickets were closed, 40 of which were marked in trac as patches. Also of note is the insane amount of work Mark Doliner put into our MSN and MySpace plugins, which should resolve a number of crashes and the MySpace "doesn't sign off" issue.

A few big items to summarize:

Mark did massive code cleanup in MSN
Mark fixed a number of shortcomings in the MySpace IM protocol as well as doing code cleanup.
We accepted a ton of patches.
ICQ typing notifications should work for some third-party clients now.
XMPP resources now default to the empty string, causing modern servers to assign us a resource via a bind. In the event of an ancient server, such as the one DreamHost runs, we will detect the lack of this capability and enforce the default "Home" resource if a user hasn't set a resource.
XMPP resources can now include __HOSTNAME__ as a special token that will be replaced with the hostname of the machine being used. For example, if I run Pidgin on my MacBook and configure the resource on an XMPP account to be __HOSTNAME__, the resource sent to the server will be "macbook", since this is the hostname of my MacBook.
Some long-outstanding patches have been applied for Gadu-Gadu, implementing IM images.
Apply some patches for Zephyr, enabling autoreply when away to emulate zaway and some bugs with the 'use tzc' option.
We no longer get certificate errors for rsi.hotmail.com when logging into MSN and retrieving offline messages.
Many, many other things best read about in the ChangeLog.

Enjoy this release, which I'll call the "Thank-a-patch-writer" release!

Patches, Patches, and More Patches

2008-11-30T15:01:00.003-05:00

On November 13, I mailed our development list about our open patches. At the time we had 93 patches open on our Trac. Since then, some work has gone on with respect to patches, a lot of it from me. In the last 17 days, there have been 23 patches committed. Not all of those tickets were marked as patches, however. There have also been a number of new patch tickets opened, bringing our total patch count down by only 11 to 82.

Now, out of those 82 patches, if we ignore the ones we've put on the Patches Needing Improvement milestone, we have 57 patches. Here is where we see a significant difference, as out of the former 93 patches, 75 were not on a milestone, indicating that the patches that have changed to the Patches Needing Improvement milestone had not been previously reviewed, or had been reviewed but not marked appropriately on Trac.

Among some notable patches that were accepted include MD5 authentication support for ICQ; fixes for Gadu-Gadu, Zephyr, and SIMPLE; ICQ X-status support (which can't be included until at least 2.6.0); and support for connecting to an XMPP server without specifying a resource, thus causing compliant servers to generate a resource for us. Aside from the X-status patch, all the ones I've just mentioned will be in 2.5.3.

But the work isn't done yet! We still need a lot of patch review from Pidgin developers. Also, a lot of patches need work, so there's still plenty to do if anyone wants to help! I, for one, certainly won't complain if someone comes along and fixes up a patch that needs work, and such fixing will make it much more likely that the patch will be accepted.

For reference, I also mailed the development list earlier today to discuss patches again, here.

Ah, how our work never ends...

The Hosting Game

2008-10-07T23:18:00.009-04:00

Well, by now probably everyone's aware that our (Pidgin's) sites had been down for several days. Here's the basic rundown of what's happened with our servers over the last couple years.

Prior to our going public with our rename, Luke Schierer secured a donation of a virtual server from DVLabs. This server was intended to enable us to migrate away from SourceForge's web platform and tracker. It allowed us to have our own domains, and thus host and control our own e-mail services, mailing lists, and Trac. This server did its job for us quite well, even though we did occasionally push the server to or beyond its limits. (Note that in these instances real hardware would actually not have made a noticable difference at all, as all the resources of the real hardware would have been utilized just as we had experienced in the virtual machine.)

Even though we were extremely grateful to DVLabs for providing us a server, we did realize that having only a single server presented us with some limitations, the most important of which is "graceful" failure of core services if the server goes down. It also presented a single point of failure in that the web server getting pounded (such as a posting to Slashdot causes) could potentially cause all our services, including monotone and mail, to grind to a halt. Because of this we had tossed around the idea of finding another host two or three times.

When we most recently thought about hosting, Evan Schoenberg from the Adium project (who also happens to be a libpurple developer) put us in contact with NetworkRedux, who generously provides Adium's hosting. Thanks to Evan's intervention, we spoke with NetworkRedux about our hosting, and they were willing to donate not just one, but two servers and a ton of bandwidth to our project. Thanks to NetworkRedux's generous offer, we're getting the potential to have a lot more raw computing power at our disposal (including more memory to help increase caches, thus hopefully improving speed), as well as the ability to spread our services out a little so that a heavy hit to the website or to trac won't have a detrimental effect on all our services.

We were still discussing details of migrating to these two new servers when the server at DVLabs unexpectedly went down. It turns out that some miscommunication and bad timing caused the guys at DVLabs, who were migrating their own stuff, to down the server hosting our virtual machine, thinking we were no longer using it. We were, of course, confused at first, but once we determined what was happening we were much more at ease. None of our data had been lost. DVLabs were kind enough to supply us with the raw VM image for our own use to recover our data and complete our migration.

From these events we have learned a lesson--redundancy is not only good, it's pretty much a must-have. In the interests of redundancy and graceful failover, we've taken some steps to help prevent future long-term outages. One of those steps is that Gary Kramlich and I decided that we would help out by providing some service redundancy on our server, guifications.org. The biggest, and most important, service we are helping with is monotone. If for some reason the monotone server is down, guifications.org can seamlessly stand in for the mtn.pidgin.im server through the magic of DNS. We're also looking at potentially acting as a backup for more services.

So all in all, the commotion about our sites being down was really just a lot of noise about nothing truly significant. Yes, our sites were down, but this wasn't the end of the world. Google's massive cache had pretty much all the critical information anyone could need from our wiki. Yes, monotone was down, but guifications.org was ready to help--I had been running a read-only mirror for nearly a year which was ready and able to stand in as a production service if needed. Our mailing lists were down as well, but again, it wasn't the end of the world. Overall, we have weathered a prolonged service outage pretty well and taken some lessons from it to help us in the future.

In closing, I would like to extend my deepest, most heartfelt thanks on behalf of all Pidgin developers to DVLabs for their hosting services over the past two years and to NetworkRedux for the services they are now providing for us. We truly appreciate these donations!

It's a bit late...

2008-08-24T12:11:00.003-04:00

It's a bit late for me to be posting this now, but we did recently release Pidgin 2.5.0. There are a few things about this release that I'd like to discuss:

MSNP15 support
Custom smiley support
The Windows and *BSD AIM tooltip crash

Let's hit these in the order I listed them.

MSNP15. Finally, we have a release which includes updated MSN protocol support. We now support the personal message, current media, and offline message features of recent MSN official clients. We do not, however, support fast file transfers. We still support only the MSN-server-proxied transfer method, which while slow is 100% reliable. Quite frankly, file transfer isn't a high priority. If someone wants to implement fast file transfers, feel free to submit patches to us.

Custom smileys. During the development cycle of 2.5.0, a patch was accepted that implemented custom smiley support on MSN and provided a framework within libpurple for other protocols supporting the feature to grow support. There is one issue with this support--we can't save an incoming animated GIF emoticon. This is a limitation in gdkpixbuf, which doesn't support saving the GIF format by default. There are perhaps some additional dependencies we could incur for this, but nothing has been done in this area yet. To set up your custom smileys, go to the "Tools" menu on the Buddy List window and select "Smiley."

AIM Tooltip Crash. We've had a number of duplicated reports of crashes when "mousing over" an AIM buddy. The crash happens when trying to display the tooltip, and only appears when Glib uses its internal vsnprintf() implementation (which happens on some non-glibc systems, such as Windows and the BSD flavors of UNIX). An updated liboscar.dll that fixes this problem is available on ticket #6627. Please don't open any more tickets about this bug!

There is one other AIM bug I'd like to mention, since we're aware it exists. Not too long ago it came to our attention that when a Pidgin user joins an AIM chatroom and tries to send messages, less than 25% of the messages actually make it to the other members of the room. We are aware of the bug, but I believe we're not yet fully certain of the cause. A bug report already exists (#6590), so please don't open any more tickets about this bug either!

Hopefully all you MSN users out there enjoy the new features. It's taken a long time to get the features out there, but I think in the end the wait is worth it.

The Holy War of Tool Choice

2008-07-31T02:57:00.004-04:00

Tools are vital to any open-source project. Because of that, tool choice is critical. You really don't want to be switching tools frequently, because doing so is more work than you'll ever be able to put into the project. By that same token, you don't want to pick tools no one in the project wants to use. This leads to the problem--tool choice is often a "Holy War", so to speak, because everyone has their pet tool and thinks everything else to be inferior.

Let's use Pidgin as a practical example. Prior to our most recent legal problems (which prompted our rename), we had been evaluating new version control software for some time. At that time, we were using CVS. Almost everyone who has developed on a project as large as Pidgin will agree that CVS sucks. You can't rename files unless you rename them in the repository itself, branching and merging are a pain, etc. I wasn't involved with the project at this point in time, but I do know that every distributed VCS in existence at the time was evaluated. After the evaluation, Monotone was the preferred choice. Keep in mind that this was over two years ago, more likely closer to three.

We continued to use CVS, and later made an ill-advised switch to Subversion. Sticking with these tools was mainly due to our complete reliance on SourceForge, who offered only CVS and SVN. Finally, when it came time to rename our project to Pidgin, we had a donated virtual server on which we could run (essentially) whatever we wanted. Ethan Blanton used tailor to convert our SVN repository into a monotone database.

We also set up Trac for bug, patch, and feature request tracking. The built-in wiki was a bonus. We ended up installing a number of plugins for Trac to customize it and provide some additional features, such as restricting some ticket fields from those who we feel should not be able to modify them.

All was well initially. We had a few complaints because we chose to use monotone instead of sticking with SVN, but these were users who had no intention of contributing patches, so we were (mostly) happy to see them angrily go back to using our "blessed" releases. We did, however, have a lot of confusion initially about what monotone was and how it related to Pidgin. A few hundred explanations later and those questions faded too.

Trac proved to have some scalability and performance issues for us on numerous occasions. Eventually we were able to narrow the biggest issues down to their causes and implement fixes. Some of this involved a LOT of poking and prodding, as well as some assistance from Trac developers, who we thank profusely for their time in resolving the issues. I am quite surprised, overall, that we haven't had any real complaints about Trac. For a while it was frequently completely unusable, and of course we saw a number of complaints related to that, but since the issues have been resolved we've seen no real complaints.

As for monotone, fast-forward a year from the announcement of the rename. We consistently get complaints about having to download a "huge" database just to get the latest development source for Pidgin. We do also get a few complaints that it's hard to use, but almost all of these are solved simply by pointing people at the UsingPidginMonotone wiki page. As for the huge database, we do acknowledge that it is inconvenient for some people, but "shallow-pull" support is coming to monotone. A shallow pull would be similar to an svn checkout.

I don't mind the database, myself. I have 11 working copies (checkouts) from my single pidgin database (8 distinct branches, plus duplicates of the last three branches I worked on or tested with). Each clean checkout (that is, a checkout prior to running autogen.sh and building) is approximately 61 MB. If this were SVN, each working copy would be approximately 122 MB due to svn keeping a pristine copy of every file to facilitate 'svn diff' and 'svn revert' without needing to contact the server the working copy was pulled from. Now, let's add that up. For SVN, I would have 11 times 122 MB, or 1342 MB, just in working copies. For monotone, I have 11 times 61 MB for the working copies (671 MB), plus 229 MB for the database, for a grand total of 900 MB. For me, this is an excellent bargain, as I save 442 MB of disk space thanks to the monotone model. For another compelling comparison that's sure to ruffle a few feathers, let's compare to git. If I clone the git mirror of our monotone repository, I find a checkout size of 148 MB after git-repack--running git-gc also increased the size by 2 MB, but I'll stick with the initial checkout size for fairness. If I multiply this by my 11 checkouts, I will have 1628 MB. This is even more compelling for me, as I now save 728 MB of disk space with monotone.

Richard Laager also took the time to point out an interesting, but as yet unexploited feature of monotone--the use of certs allow us to do a number of useful things while being backed by the cryptographic signing of certs. For one, we could implement something similar to the kernel's Signed-Off-By markers. We could also have an automated test suite run compiles of each revision and add a cert indicating whether or not the test succeeded. We could also include a test suite using check (we do already have some tests) and use more certs to indicate success or failure. The extensibility of monotone using lua and the certificates is truly mind-boggling.

I think I've picked on version control enough here, but before I move on, I'd like to say that I don't specifically hate any one version control system. Ok, maybe I hate CVS and Subversion, but I'm certainly not alone in that. I don't, however, hate git, bzr, hg, etc. In fact, I think hg looks quite promising--the Adium folks have decided to switch to it, and are currently in the process of trying to convert from SVN. However, given that for us monotone was the best choice when we made our decision, and given the extensibility of monotone, I think it would be foolish of us to choose another tool at this point. Perhaps in a few more years when all the DVCSes have had time to mature further it will make sense to revisit this decision.

Another tool choice involves communication between developers and users. Specifically, forums. We have elected not to have forums for Pidgin, although as a legacy of our continued involvement with Sourceforge for download hosting we are stuck with the forums they provided us. We are quite frequently belittled for our choice to forego widely visible forums. At least four of us that I am aware of have a strong distaste for forums. I find them to be worse than the ticket system for attracting duplicated questions which most users won't search beforehand. All the useless extra features, such as emoticons, formatting, etc., are a waste, as well.

It's also been my experience with forums that one or two people will start answering others' questions with misinformation that will sound legitimate to those receiving the bad answers. I've seen this numerous times, but it comes to mind so quickly as I've seen it quite recently on Ubuntu's Launchpad "Questions" forum or tracker or whatever you call it for Pidgin.

Instead of forums, we have chosen to use mailing lists. We receive complaints about this too. These complaints run the gamut from "mailing lists are hard to use" to "but you can't search the mailing list!" In reality, the mailing lists are searchable--Google indexes our mailing lists, as do a number of other search engines. Perhaps we could provide a nice search box or something that does the necessary google magic (make the search query "terms site:pidgin.im") to make it a bit friendlier, but searchability exists. Not that it matters much in my experience, but hey, I'm just a developer; what do I know?

I'd also argue that mailing lists are easier to use than forums, as all you have to do is, y'know, send an e-mail. With a forum, you have to register, log in, find the right forum if there is more than one, then post your question, and check back for answers. With the mailing list, those genuinely interested in providing assistance will helpfully use the "Reply All" feature of their mail client to provide the answer both to the user requesting help and the mailing list's archive, thus providing an answer that is both helpful and searchable.

Even so, all the choices made during the evolution of a project will result in people trying to start a crusade, holy war, revolt, ..., over the chosen tool. Unfortunately, it's a fact of life. The best we can do is take it in stride, justify our choices, and move on.

Note: It's come to my attention that I had missed the ability to share a git database across multiple working copies. In that scenario, the total size of the database and 11 working copies is slightly under 750 MB, and thus a space savings in the neighborhood of 150 MB over monotone. It had been my understanding that I needed a copy of the database per working copy. I stand corrected. I don't use git on a daily basis, as the projects I work with currently use CVS, SVN, or monotone, so I am bound to miss finer details of git here and there. There are other reasons I prefer to stick with monotone, but I won't get into them here, as they're not important to the point of this post.

"State of the MSN Plugin Address"

2008-07-13T10:35:00.005-04:00

Yes, the title is intended to be half joking. Just a few days ago I made a comment to a fellow developer that "someone needs to make a 'state of the msn plugin' address," meaning that someone needs to let people know what's happening. Well, looks like that someone's going to be me. So here's the outsider's summary of what's happened.

In current Pidgin releases, the default MSN plugin uses the old MSNP9 protocol. This protocol doesn't support Personal Status Messages (PSM, also called "personal messages"), nor does it support offline IM, current media (a field that shows what music you're listening to or what video you're watching), or messaging while invisible.

Two years ago, for the 2006 Summer of Code, we had a student whose project was to update our MSN code to MSNP13. MSNP13 supported the PSM and current media, although at the time libpurple didn't support the status attributes for "now playing" or "current media" or whatever you prefer to call it. MSNP13 may also have supported messaging while offline, but I can't recall for certain and I don't, at the moment, feel like looking it up in the documentation we have online. Later this was updated to MSNP14 for Yahoo! interoperability support. At the end of the summer, the code wasn't of a quality we were ready to release. The code sat.

Last year, we had another student take on MSN protocol updating. This time the student updated the code to support MSNP14, starting from the previous work. This supported offline messaging for sure, and there were a lot of commits that dealt with the OIM features. Again, at the end of the summer, the code wasn't release-ready in our opinion, so again the code sat.

Earlier this year, one of our developers started working on the MSNP14 code in a side branch, and eventually merged it to the im.pidgin.pidgin branch in our monotone repository. Because the code still wasn't release-ready, we disabled it and forced the MSNP9 plugin to build by default. The more clever users were still able to figure out how to get MSNP14 going, but there weren't too many until we introduced an argument to the configure script to enable the MSNP14 plugin.

A new "crazy patch writer" appeared and started to work on MSNP15 support. We eventually gave him write access to the central monotone repository at pidgin.im. This has paid off for us very well. Elliott has done a LOT of work, including some necessary cleanup, stability improvements, etc. MSNP15 was finally merged to im.pidgin.pidgin this morning. Currently it is also the default MSN plugin, and I hope it stays that way, but it might be changed if anyone objects to it.

This would not have been possible without the work of Elliott, the two Summer of Code students, one other crazy patch writer (known as Masca on #pidgin), our XMPP Voice and Video Summer of Code student for this year (known as Maiku on #pidgin), and Dimmuxx and other Adium users' testing. I'm sure there are a number of other people I've forgotten to mention who have made contributions to this progress, and I apologize. My memory isn't what it used to be. To all these people who have helped with the long road of updated MSN protocol support, I give well-deserved thanks.

So what does all this mean? Well, simply, a lot of the feature requests we've been getting are finally resolved. Ideally we also will stop seeing people asking why they don't receive offline MSN messages, why they can't message while invisible, and why they can't see personal messages. For these reasons alone, I can't wait for the release of Pidgin 2.5.0!

Pidgin 2.4.3 and ICQ

2008-07-04T15:01:00.002-04:00

Well, this week has certainly been interesting with Pidgin development. On July 1, AOL made a small change to the OSCAR servers that affected our ICQ users. A lot of misinformation was spread in #pidgin about what really happened, so here's my best attempt to explain it.

Libpurple (and thus Pidgin and Finch) identified itself as ICQ basic 14.34.3000. Of course, we sent a version string that included our real identification ("Purple/2.4.2" for example). This has worked for us for years. We send the version bytes from official clients to the server because if we don't mimic an official client, we get locked out of some features. Which features, I'm not really sure, since I don't really know or care about the internals of the OSCAR protocol.

Suddenly we started seeing reports about ICQ no longer working in #pidgin. Upon investigation we discovered that apparently the client ID has been "retired", and any logins from that client ID are immediately met with a message from the server demanding an upgrade to ICQ6. The server then forcibly disconnects us. We catch this error and display a somewhat different message instructing our users to go to pidgin.im to get an update.

Stu Tomlinson found the version identification information for the most current official ICQ client and changed our identification. Magically logging in and holding a conversation works. This patch became the reason for the release of Pidgin 2.4.3.

So to summarize, this was NOT a protocol change, merely a tweak on the server side to disallow logins from "old" clients. I suspect this is to try to weed out older, buggier clients and get the users on current software.

Google Summer of Code, Pidgin, and Announcing Vulture

2008-04-21T12:26:00.004-04:00

Well, as probably everyone reading this blog knows, yesterday was the day that accepted students were announced for the Google Summer of Code. I think I can safely say that for the most part we Pidgin developers are happy with the results. That said, I do wish we could have accepted two students who did not make the final six.

One of those two students applied for the native Windows user interface project. The student in question was actually our top-ranked Windows UI application, and was going to be accepted until we yielded to another organization when a conflict arose. He has been very good about all this and wants to work on his Windows UI project anyway, once the Summer of Code is complete. To that end, I have set up a project called Vulture (in keeping with the bird theme for libpurple UI's--Pidgin, Finch, Adium, Instantbird). I've also created a basic svn repository for the project, done because Trac integration with monotone really sucks at present. If it turns out that monotone would actually be more useful, we can always use tailor to convert later.

Since the student will be participating in another organization's Summer of Code, at the moment I'm basically flying solo, but I do welcome any help others can provide, as I'm not a Windows developer. I can dabble in a bit here and there, but I'm far from well-enough versed to be an effective developer on this project. I will do what I can, but it's always been my intention to be involved in a support capacity and also to help shape the progress of the application (in so much as the active developers are willing to put up with me and consider my opinions). I would, of course, also act as a representative within the Pidgin project to help ensure that any needs Vulture may have of libpurple are met as best they can be.

It's my hope that the buzz Summer of Code created around the native Windows user interface project remains and attracts people to actually work with us to produce a .NET libpurple client that can really fit the needs of Windows users better than Pidgin can. It's also my hope that it can be done while remaining as similar to Pidgin as possible. I think that these two hopes are completely compatible and doable--Pidgin represents a pretty reasonable UI as it stands. There are, of course, a few points of pretty hot contention, but we can deal with that in Vulture by developer consensus at first, and let user input shape the decisions beyond that if we want.

So, happy Summer of Code to our accepted students, and for anyone who cares to join us at Vulture, feel free to drop us a line! :)

Purple Plugin Pack 2.3.0--Finally!

2008-03-17T21:33:00.002-04:00

Yes, you read correctly. We finally quit being lazy and released a new Purple Plugin Pack. Ironically, this comes barely after our Debian packager uploaded a build of version 2.2.0 (our last release) for inclusion in unstable (cue evil laughter here).

New in this release is the inclusion of Andrew Pangborn's Enhanced History plugin that replaces the stock History plugin by adding several excellent features useful for the obsessive-compulsive who close their IM windows as often as possible. It is, of course, also immensely useful for the more normal people among us. :)

I also ripped out a plugin I never should have included in the first place--the broadcast plugin. Never again will it see the light of day.

The biggest thing in the release though is the major bugs we've fixed. We've been plagued with build system bugs that I couldn't fix. Gary finally got around to fixing them, so hopefully never again will we hear people having trouble because they have to build all the plugins all the time. We also fixed several plugin bugs, including the crash in the xchat-chats plugin that Pidgin 2.4.0 caused.

Enjoy!

The Cost of Progress and Options

2008-03-09T00:02:00.009-05:00

We recently released Pidgin 2.4.0 with a UI change that seemed inocuous to me. The change was actually in four parts.

We've had the idea for quite some time to put typing notifications in the conversation history area in Pidgin, just like Finch has always done and Adium has done for as long as I can remember. Code wizard that he is, Sadrul pounded this out in pretty short order. Sure it had some bugs, but given enough feedback, he was able to fix most of the issues with it. There are a few minor problems left, but I'm confident they can be worked out over time. This change proved controversial. At least one of our developers still doesn't like it. I do, but I'm a fan of a few different UI changes that have been made in the last year. I think it's safe to say we're going to stick with this change.

After the typing notification change, the old icon in the menutray was removed. The same developer who dislikes the history area notification also hates the removal of this icon. I personally don't care one way or the other--both notifications affect only the currently visible conversation, and other notification methods exist, such as the Guifications plugin. This change has also proven to be controversial, but I believe that's mostly because this change and the history area notification happened in the same release.

The next big change was the removal of the bar that allowed manual resizing of the conversation input area. This has caused far more uproar than I ever expected. The closely-related fourth change is that the auto-resizing of the input area is now a first-class citizen and cannot be disabled. Again, this caused much more of an uproar than I expected. The same developer I mentioned above also disliked these changes quite strongly.

These changes are each quite innocent on their own. The combination, however, has caused a flood of complaints over the changes in behavior. I'd like to detail some reasons for the changes and why there is a cost associated with restoring them.

The typing notifications in the history area have been requested numerous times over the years. To me it seemed reasonable, considering that libpurple's other two UI's have the same behavior. Granted, there is no real reason for the change to have happened, but it's not the end of the world. There is no loss of functionality and no "usability" issues as have been claimed. Anyone who wants the old typing icon back can fairly trivially write a plugin to restore it.

The input area is a whole new beast. We introduced an autoresizing input area sometime back in the 2.0.0 betas, before we renamed to Pidgin. Most people never saw this because we showed the buddy icon of the person we were conversing with to the left of the input area, and we forced the input area to be the larger of the minimum size (1 line, I think?) or the height of the buddy icon. This had some interesting bugs, too, as under some circumstances the size would be saved there because of the manual resizing option, so the input area would not autoresize. Another fun bug came with pasting text. Pasting sufficiently large quantities of text with a sufficiently small IM window would cause the autoresize to expand the IM window in very strange ways, sometimes resulting in conversation windows larger than the screen. There was also a bug in which dragging the manual resizing bar would not save the size of the input area correctly, so using it to work around the other bugs wasn't guaranteed to work either.

Sean decided to scrap the manual resizing because it significantly simplified fixing some of the autoresize bugs that he had fixed. Anyone thinking it's laziness may be justified in that opinion; I don't really know or care. I don't think it matters much, but apparently some users think it does. Yes, there are some bugs still, the most notable being the 1-pixel bug where a new conversation has an input area that's only about 1 pixel high. The changes also seem to have caused a crash in the xchat-chats plugin, which hijacks the history area of the conversation window and replaces it with the same widget xchat uses for irc channels. The plugin does this only for chats. There's also the fact that the lower and upper thresholds for resizing don't work well for rather large IM windows. On the mailing lists, we've already determined that what we have is not the optimal solution (thanks to a few helpful users--a very rare breed), and we are working towards making it better. We won't, however, bring back the manual resizing anytime soon.

The whole debate over manual resizing brings us to another debate--a ton of users are demanding that the automatic resizing vs manual resizing be a preference. We're not willing to do that, as it incurs a cost we're not willing to bear. Ethan Blanton said it best himself in a message to the support list:

Each individual option may be simple or trivial, but they add up. Options to do with UI behavior are _particularly_ expensive, due to their frequent interactions with the vagaries of UI toolkit behaviors, etc.

This expense takes the form, mostly, of subtle bugs and extra programmer effort. We have had numerous examples of options which appear to be simple on the surface causing numerous bugs and undesirable behaviors. A recent and memorable example of this was the option for persistent conversations -- I think we all agree that the ability to have conversations "open" without an open window is one which is appreciated by many users, but this seemingly simple feature has caused quite an avalanche of small and not-so-small bugs. In fact, there is speculation that the one pixel high input area which some people are seeing stems from this very option.

Anyone who tells you that options are not expensive is either not a programmer, or has never worked on a large program. It is true that orthogonal options in a clean code base can be implemented with little cost in *many* circumstances, but even the most forward-thinking and competent programmers will be blind-sided by subtle interactions on occasion, especially when throwing third-party libraries and code into the mix.

Making both behaviors available will certainly cause additional bugs and stupid behaviors that would not appear if we were to leave well enough alone or even to revert to the previous behavior. Reverting to the previous behavior, however, again introduces complex interactions that we're not exactly excited about having, not to mention brings back the bugs that were successfully eliminated with its removal.

Aside from all this is the fact that while we could keep the same interface forever, we don't feel it's necessarily a good idea. Experimenting with the user interface is a way to achieve progress--we can't learn without experimentation, and what we learn from said experiments helps us to make Pidgin a better application. Yes, it causes friction with users and some developers, but it is a necessary process. That's the important thing to keep in mind--we're not taking features away in an attempt to punish users or see how far we can push users. Our changes are legitimate attempts to improve Pidgin's interface, reduce the number of bugs present, and make Pidgin the best we can for our own needs.

In that vein, we are fully aware that we cannot make everyone happy with our UI. It's simply impossible. There are numerous other messengers out there, many of which will certainly meet some users' needs better than we can. We also now have libpurple as a real, usable entity which anyone can use to get our protocol support while getting a UI completely different from ours. This raises my final point--there are options in the IM application space, even though they may be expensive for users to bear the consequences of.

Why I Hate "Modern" IM

2008-01-04T23:51:00.000-05:00

There are few things I dislike about "modern" instant messaging. I really do miss the days of old, when IM was text only and the most complicated thing we had to worry about was emoticon display and whether ICQ's or AIM's protocols were going to change while we slept. Yahoo was a joke, MSN was an afterthought, Pidgin was still known by its former name and still used GTK+ 1.2.x, and a few disgruntled people would decide to fork on occasion. Even emoticon display wasn't that important--the focus was communication by a faster method than e-mail.

I, like many of my generation, discovered "web mail" and then graduated into more advanced things that this magical "internet" had to offer. Quickly, I started using e-mail for communication purposes instead of random notifications that were overall meaningless. Thankfully, my school's internet service provider offered a way to have students and teachers each have their own e-mail address. When one of my classes required a school-sanctioned e-mail address, I was assigned the 354th e-mail address issued to my school. The ISP used an HP-UX machine for mail. With trusty old telnet and the MacOS Classic application BetterTelnet FAT as our new best friends, we would log into the mail host (omalp1; I'll let the obsessed among you see if you can figure out the rest of the hostname even though it doesn't exist anymore--good luck!) and be presented with a shell. None of us had any clue about UNIX in those days, so we knew of only two commands, pine and exit, and these were taught to us as the only "blessed" commands to use at the "dollar sign thingy."

My classmates and I started using e-mail to communicate both in and out of classes. At some point I finally got dialup internet access at home, albeit absolute trash, and joined in. We used this e-mail like it was IM--we would religiously check our e-mail and reply as soon as we received the other person's message. This worked pretty well until someone among us discovered ICQ. Soon we all used it. Ah, this brings back the memories. Mirabilis' official ICQ 98b client, as I recall, was my first ICQ client. I don't recall if emoticons worked at this stage or not; I don't believe I ever used them at that point. Some time later, an AOL user among us discovered that AIM and AOL's built-in messaging component could talk to each other. A few of us migrated to AIM, but most of us ran both AIM and ICQ together. All was still good with the world. AIM 3.x, with all the neat little back doors to get around AOL users being able to be invisible to AIM users, was the client of choice. Basic HTML formatting, emoticons, sounds that didn't drive us crazy when we got messages. Ah, these were the days. I miss it!

At some point later, IM started to go down hill. Someone decided that file transfer needed to be a first-class citizen in client features. Yahoo grew webcam support. MSN became a contender despite its stupid design (I'll come back to this). Third-party clients actually became useful and welcome, especially the multiprotocol variety. And the spiral continued.

Today, we have a disaster area of IM features that everyone demands of every client, even the ones without the resources to develop and provide such features. Yahoo has more file transfer methods than I care to count, and changes them about as frequently as necessary to irritate the crap out of third-party client developers. MSN has enough file transfer methods to make AIM's newly increased three-count look like a fledgling effort. I won't even speculate on how many methods other protocols have or bother to find out how many XEP's exist for file transfer over XMPP. The exact numbers here are all irrelevant--the point is that we have a landfill full of code to cope with these bajillion file transfer methods and scenarios.

Webcam support comes to mind next. Suddenly these USB camera devices exploded onto the market and now everyone had to be able to use them in their IM clients. Then came the wave of "You don't have a webcam? Why do you bother to be online?" from those so addicted to their webcams that textual communication seemed like the stone age. Every IM provider that implements this is hell-bent on world domination or something and decides to pick protocols that are completely different from the "competitors' products," eliminating any hope of sane interoperability between these features of the services. Some of these protocols provide features others don't. Users blindly used whatever was thrust in front of them. Pornographic use of the webcam appeared. Stupidity ensued, while valid uses of the webcam, such as family communication and distance learning, didn't become major factors until far later in the game.

As if webcam support wasn't bad enough, some morons in MSN's management and development ranks decided they needed to introduce custom emoticons, winks, and nudges. Custom emoticons, of course, allow any user to send any random image to replace any specified text. MSN being the world of frequent abuse (again I'll come back to the abomination that is MSN later), users quickly took advantage of this and soon we had users replacing literally all of their commonly-typed text with obscure, crappy multicolored flashing emoticon crap that should never have existed in the first place.

Enter the nudge, now. Nudge a user and cause whatever stupid effect in the official client. Suddenly it too was all the rage for no real reason. Somewhere along the line Yahoo introduced a similar feature called buzz that shakes the message window. This too was hotly demanded. And let's not forget about the winks. Flash objects, I believe they were. More crap that doesn't belong in IM. Seriously, take this stuff to poorly-designed personal web pages, or even MySpace, and keep it out of IM.

And MSN as a whole. What a wonderful disaster area. When MSNP2 was around, I suppose I could excuse the lack of a status message--after all, ICQ didn't have them for a good many years either. But I won't excuse it--AIM had user-definable away messages from the beginning of my recollection, although available messages and invisibility are relatively recent additions by comparison. To me this negates any valid reason for MSN not to have supported some sort of status message. Then we have the friendly name, which I swear was invented solely to give users something not to use, but to abuse in ways unimaginable to those who implemented it. The ability to have graphical emoticons render in the friendly name comes to mind. So does the use of the friendly name to compensate for the lack of status messages. By this point, the protocol's usage had devolved into a cesspool anyway, so who really cared about the addition of custom emoticons, winks, and nudges, right? Apparently someone thought so, because now we have all that crap on top of it.

Now it's too late in the game, but MSN decided to implement another new feature--Personal Status Messages. Wow, now MSN joins the ranks of sane IM protocols, right? Not quite. The PSM now gets abused almost as badly as the friendly name is. I submit that it's called a "personal status message" for a reason, and that the reason is not to provide another field for users to abuse. But, as I said, it's too late in the game now. Users don't change unless you force them to, and this feature-too-late-to-really-matter certainly doesn't give us any evidence with which to claim that users change.

If I haven't alienated everyone who would bother to read this post by now, those reading this far are probably wondering what relevance this has to Pidgin or the Purple Plugin Pack, given my repeated prior related postings about both. Well, it's relatively complicated.

A couple years ago, long before our renaming fiasco started, Pidgin had a contributor who was submitting pretty large chunks of code to our MSN support. I wasn't around much for this; I was mostly just a user at this point and hadn't even attempted to contribute yet. Somewhere along the line, communications broke down, frustrations came into play, like probably a million other things I don't know or care about right now did. The bottom line is that the patch sat and the contributor left.

Fast forward to now and look at Pidgin's MSN support. No one can look at it and say with any seriousness that we support MSN features well--granted, we do a decent job but we don't support status messages and still use MSNP9. After two Google Summer of Code projects, we have an MSNP14 protocol plugin, but it was merged into our main development line too soon and still isn't ready for general consumption. As a result of this, we still ship MSNP9 and disable MSNP14 by default. We have a new Crazy Patch Writer who has implemented some elements of MSNP15 support. If and when any of this new MSN code becomes release-ready is really anybody's guess. (Not trying to slight anyone here; stabilizing new protocol support is work.)

The same contributor I mentioned earlier has now returned with a fork of the MSN protocol plugin for libpurple. He implemented server-side alias storage and some parts of the MSN peer-to-peer file transfer methods. Near as I can tell from the mailing list discussions, this is all still our existing MSNP9 stuff with some modifications. All fine and well, I suppose, but really these patches should have been submitted to us for review before forking, in my opinion.

In the ensuing discussions over the forked protocol plugin, the Personal Status Message issue has come up again, and there seems to be a difference of opinion on what the intended use of such a status message is. One side of the debate insists that this message has nothing to do with status but is instead for advertisements that allegedly are completely unrelated to status. The other side, which I find myself firmly rooted in the ranks of, argue that this PSM is a status message and ought to be treated as such. It seems the battle lines are clearly drawn for a war over how to implement this stuff.

All in all, I come back to the simple statement--I hate "modern" IM with a passion. I want to return to the days when there were no graphical emoticons, no webcams, no nudges, nothing that caused this kind of crap to turn up. Amazingly, this comes from someone who still refuses to use a text-mode IM client for routine IM needs and instead runs Pidgin all the time; go figure.

In closing, why can't we all just use XMPP and forget about voice and video, nudges, winks, emoticons, etc. forever?

Long time...

2007-12-04T13:01:00.000-05:00

So, I guess it's been ages since I made a blog post. A lot has happened in that time:

We released Purple Plugin Pack 2.2.0 without the ignorance or smartear plugins being properly fixed and included. It's not looking particularly promising for 2.3.0 either.
We adopted new plugins into the plugin pack:

dewysiwygification - An old plugin written by Tim Ringenbach
enhancedhist - A plugin written by Andrew Pangborn.
timelog - A plugin written by Jon Oberheide.
buddytime - A plugin written by Martijn van Oosterhout and Richard Laager.

Sean Egan promoted me to Pidgin developer.
I rewrote over half of the Pidgin man page to reflect the current features present in Pidgin.
I've continued to slack off on the Guifications 3 project.
I hatched a plan to remodel the living room in our house without letting my parents know. I'll probably be yelled at endlessly for this one.

I've also been trying to watch more movies. Recently I've watched Dangerous Minds, A Beautiful Mind, and Mentor. All interesting movies in their own right. I also started to watch Tin Man, the new Sci-Fi channel reinvention of The Wonderful Wizard of Oz. So far I've only seen the first part, and it is quite a trip. I'll be catching up on it when I have a chance to watch my backlogged DVR stuff this weekend.

At any rate, time to go to work, I suppose. Maybe I'll post something later.

Purple Plugin Pack 2.1.0 and 2.1.1; Plans for 2.2.0

2007-08-19T13:24:00.000-04:00

Well, last night I released two versions (yes, two!) of the Purple Plugin Pack. The initial release was 2.1.0, which included a new plugin and the completion of a plugin that's been in our tree for ages. However, what I did not catch in this initial release is the fact that there were files missing from the convbadger plugin that would prevent it from building on any platform. I didn't want a duplicate tag in our monotone database, so instead of trying to rerelease the same version, I just did a quick micro version increment, added the files, tested the new version, then tagged and released 2.1.1. As a result, I called 2.1.1 "The rekkanoryo is an idiot release" to indicate it was largely my stupidity that caused two releases in such close proximity.

That said, I'm sure I'm going to hear complaints because I signed the packages. With the 2.0.0 release, there was a complaint because I signed the package with my GPG key, which has no signatures. Because of that I'm reasonably sure I'm going to hear complaints again about my signature being worthless because there is no relation to the web of trust. To that I have one response--find me a key-signing party within a 45-minute drive of my home and I'll show up with all the identifying documents I need for someone to verify my identity and sign my key. Otherwise, shut up and don't ever complain to me about it. I live in an area where technology seems to be a foreign concept, and anyone having a clue about GPG or any other sort of useful technological tool just doesn't happen. People here have trouble determining whether a website is SSL-secured or not, let alone something more complex. I work a full-time job which does pay my bills but doesn't provide me with the luxury of enough money (or time off at the correct times!) to travel to random conferences where I would be presented with keysigning opportunities. Because I attended a local school for postsecondary education, I didn't exactly gain exposure to any keysigning opportunities there either.

With that out of the way, I'll get to my plans for Purple Plugin Pack 2.2.0. I have a few things in mind:

Merge autorejoin and irc-more. Autorejoin is IRC-specific, as is irc-more, so there is no need to have two plugins whose function is to enhance IRC.
Add processing capabilities for libpurple's blist.xml file into the listhandler plugin so that users who have managed to destroy their server-side buddy lists can import their backed-up blist.xml file to restore the server-side list.
Split the alias list support that was patched into listhandler into its own files.
Hopefully finish the smartear plugin integration work I've had on the back burner for way too long.

I'm already working on item #1 there. At this rate, I might have the entire list done in weeks instead of eons.

The downside to popularity

2007-08-16T01:38:00.000-04:00

As many people reading Planet IM know, I am a developer on the Guifications project and the Purple Plugin Pack, and a "Crazy Patch Writer" for Pidgin. Over the course of my time with these projects, we've seen our fair share of...well, pretty much everything. New developers; departing developers; people stepping back due to frustrations, busy schedules, etc.; and the biggest of them all, spam.

Not too long ago, Guifications and the Plugin Pack were hosted at SourceForge. Back then, things were pretty good--our website was pretty well static, although it was done in PHP so we could do cool stuff like pull in our SourceForge project news feed to use as our home page and have extensible menus with XML and whatnot. We also operated under one project at SourceForge. Over time, we (Gary most of all) became displeased with and irritated by things that we saw happen and things we experienced while there, and we eventually decided to leave SourceForge for self-hosting.

When we began self-hosting, Gary started renting a virtual private server from Steadfast Networks while waiting for a dedicated server to become available. It was a bad time for us to have been VPS customers, though, as performance was bad due to overloading. We were finally able to move to a dedicated box and couldn't be happier with it. I personally rented a VPS from them as well, and initially had similar frustrations. In the 9+ months since we've had Guifications and the Plugin Pack hosted on the dedicated server, the VPS performance issues have been resolved. The VPS I have is fast enough that I can barely tell the difference between it and a real box.

With the move to self-hosting, we needed something that could replace SourceForge's trackers. The solution was simple--we'd heard quite a few good things about Trac and tried it out. We've been with it ever since, and Gary even went to the trouble to update the SourceForge to Trac migration script to migrate our tracker items into tickets.

Over time, we discovered issues on one of the two Trac environments we were running--spammers were attacking us. At first it was comment bombing, where the spammers would flood us with links in comments on tickets--primarily closed tickets, but any ticket was a target. After the third attack, we cracked down and locked our Tracs to the point that only developers could open tickets or edit the wiki. This caused some friction in our user community, because we had bugs that no one could report and no one could make feature requests. Our apache logs showed a continued series of attempts to attack, growing similarly to our popularity with Pidgin users.

Thankfully, several people pointed us toward the Spam Filter plugin. It's a great plugin because now we can have authenticated users making ticket submissions, comments, wiki changes, etc. but at the same time we have blacklisted regular expression filtering, IP throttling, evaluation via Akismet, and external links filtering. Since installing and configuring this plugin we've had a whopping three successful spams. The monitoring feature is useful for adding blacklisted regexes, as well.

The only problem with the spam filter is that it requires work. That is, it's not perfect. On occasion it will have false positives, although this has happened significantly less frequently since we moved to requiring new registered users supply a first name, a last name, and an email address at the time of registration. Also, on occasion, we have to teach it about new bad expressions by editing the BadContent wiki page. It is sometimes funny, though, to see the karma scores assigned to some of the spam attempts. The karma can go wildly negative, especially if multiple filters are invoked multiple times on the same message. Currently the record for our Tracs is -41, due mostly to external links subtracting 35 points from the post's initial karma.

And this, my friends, is the downside of popularity--the spammers are out and ready to strike, and we have to fight them at every step of the way. Thankfully, for every group of spammers that don't deserve the privilege of using a computer, much less the privilege of an internet connection, we also have at least one talented programmer creating a tool to help in the battle against spam. It does make you wonder at times, though, what the spammers can possibly gain from attacking us.

Random Ramblings

2007-08-02T02:24:00.000-04:00

This blog post is going to be a bit of . . . well, quite literally, random rambling. I guess the title of the post should make this a dead giveaway, but I'm in a bit of a weird mood tonight so I'll just get to the topics I was thinking of.

I'll start off with music. My tastes in music are a bit eclectic in some respects, and usually downright unpopular. I was raised primarily on country and oldies. In the US this means late 80's and 90's country music, which isn't a whole lot different from pop, and music from the 50's and 60's that fit into pretty much any genre but country. My one older sister (I have two older sisters and no other siblings) has always liked music in general, and so growing up with her around I occasionally picked up on some other forms of music, including rock. I find myself now, at 25, to be a somewhat picky music lover. For example, I despise rap, although a few mainstream country songs that have introduced some rap elements fall within my range of acceptability. My usual fare (as is quite obvious from my Last.fm profile) is country, although I branch out into Bon Jovi, Kelly Clarkson, and others. There's even a bit of Japanese music in there for good measure.

There's nothing specific that I look for in music to make me say I like it or I don't. I usually disagree with the majority of critics, although exceptions to the rule have happened. For example, the Dixie Chicks released an album called Taking the Long Way, their first album since being shunned from the music world following their criticism of President Bush (who I was stupid enough to vote for in 2000 as an 18-year-old first-time voter because I thought Gore was too stupid). Several critics loved the album, giving it very high praise. I too enjoyed the album. It had a pretty solid pissed-off tone throughout, while still covering a diverse range of stylistic influences and topics. Wow, I sound like a critic myself now. I need to stop that.

At the same time as I agree with some critics on select albums, I often disagree with critics and find myself quite liking albums that the critics have written off as pathetic. Essentially my musical taste runs the gamut from Neal McCoy's fun "Billy's Got His Beer Goggles On" to Sophie B. Hawkins' "The Darkest Childe", hitting numerous high points on the way, such as Massive Attack's "Teardrop" (House fans will recognize this as the theme song) and the entire body of Martina McBride's recordings.

The real point I am getting at here is that while I may gravitate towards some artists or styles, my taste is not limited to such. Even so, I've taken quite a bit of flak over it. Coworkers, codevelopers, etc.; you name the person, I've gotten remarks from them ranging from well-meaning jabs to acid-infused comments. I don't really care what people think of my musical tastes; I don't ask them to pay for the music I listen to, nor do I force them to endure it. It's my life, my money, and my ears. It's a legal practice, so I will use them in the way I see fit. I also won't take any crap from anyone over it.

With the music topic pretty much resolved to my satisfaction, I'll move to the other topic that I had in mind when I started this post--development fatigue. Every developer at some point reaches the point of being fatigued from the process. Every developer has his or her own breaking point, so there's obviously no sure-fire way to tell when this is going to happen. The important thing here is that we realize our limitations, push them at the appropriate times, and step back to take a breath when needed. The point of fatigue is the most important time at which to step back and breathe. If we don't stop at that point, burnout will follow soon. Stepping back before burnout happens and taking the needed rest and relaxation time away from the world of computers and code is an important step for both our mental health and our continued productivity as developers.

If a developer allows him/herself to burn out, it will likely take longer to "recover" from the burnout and return to productivity. If development projects are taken too personally, that burnout can also spill over into other aspects of life quite easily and cause a whole host of problems. Furthermore, once you've burned yourself out once, it's easier to do it again.

This all seems pretty obvious, right? Really it is; it just isn't a thought that occurs to us frequently. These are all pretty easy things to overlook. They're important, though, so we should try to be a bit more aware of them. When we're feeling particularly stressed over our projects, it's time to step back and go read a book or take a walk or something else relaxing. Maybe even do some manual labor like mowing the lawn or doing a home repair/improvement project. Or kick back, watch TV, and be lazy for a while. There's nothing wrong with any of these, most especially if it helps you take your mind off the problems for a while so you can come back later with a clearer head and attack from a different angle.

Several people have noticed the C Plugin HowTo that I've been writing on the Pidgin wiki. It's far from complete--I'm less than halfway through the libpurple part, and I intend to give a brief overview of writing UI-specific plugins for Finch and Pidgin. This project, though, is an exhausting one for me. It takes a lot of thought to write a how-to document that I'm willing to publish, with or without my name on it, and I'm trying to strike a balance between people who are starting out like myself, with a basic understanding of the C syntax and concepts, and those who have a firm grasp on it all but just need to see the structure of a plugin and how to interact with the libraries and application. For the most part I'm striking this balance by focusing solely on the former class--the ones who started like me. The latter class is generally intelligent and/or experienced enough to read the API documentation, use existing code as examples, and come away with the necessary understanding of what needs to be done. This isn't to say that the inexperienced or beginning plugin developer is stupid; it often takes a bit of orientation for these less experienced developers to be capable of finding their way through the plugin API.

Being an exhausting project, this how-to series has gotten me to the fatigue point more quickly than I expected. I realized this, however, and have taken the appropriate steps backwards to try to catch my breath. I'm still poking and prodding here and there, but so far the mini-vacation from wiki editing is proving to be a good thing, and I think I'm ready to start attacking the wiki again. I hope to pound out the Request API how-to, which will likely be the hardest one for me to write, this weekend. If it's not done by Monday, I will finish it the following weekend.

On an unrelated note, I'm messing around with CentOS 5 on a test server at work for use as replacements for our public DNS servers running older versions of the OS. The installer impressed me by having more granular package-level control, although I'm still having to go through and rip out a ton of crap that a public DNS-only server with ssh for the only allowed remote access has no need for. Once I have it pared back to bare minimums, the real fun starts.

Now I think I'll go to bed, since I have to be awake in two hours to go to work.

Everything Changes (a.k.a Pidgin-SNPP is dead; long live Purple Plugin Pack!)

2007-07-19T20:58:00.000-04:00

Ok, I know the title of this post is a bit lame, but you'll have that. Deal. :-P

The title is supposed to be an obvious reference to the maintainer of the Pidgin-SNPP protocol plugin for the Simple Network Paging Protocol has accepted a long-standing invitation to bring his plugin to the Purple Plugin Pack.

rizzo, the maintainer of pidgin-snpp, had mentioned that he needed to set up a Windows Pidgin build environment and work on his plugin. I reextended the offer to join the Plugin Pack by saying that the plugin would already have been released, and rizzo accepted. We're working on making the plugin compatible with Pidgin 2.x.y now.

Hopefully we'll release again around the time Pidgin does, new plugin and all. :)

Projects, Progress, and Competition

2007-07-17T01:09:00.000-04:00

In my last post, I mentioned that I was wanting to push a release of the Purple Plugin Pack. Hard to believe it's been over two weeks ago already. Friday night, just before midnight, I finally released Purple Plugin Pack version 2.0.0. We changed our versioning scheme in the process too. The biggest, and most important, thing to mention here is that our major version will always match libpurple's. The other numbers have their significance as well, but they're not all that important--users should always be using our most current release. This release was significant in a number of ways--we introduced a few new plugins, added new features to several plugins, and also fixed a number of bugs.

In other areas I'm involved with, progress continues, even if it is slower than anyone would like. Gary's work on Guifications 3 has had some progress, and Pidgin has had some progress toward a 2.1.0 release. I wouldn't call this progress significant yet, but hopefully things work out with both projects.

For Pidgin, I'm hoping the infopane Sean is implementing improves significantly before the release of 2.1.0. If it doesn't we're never going to hear the end of it, and a ton of people are going to demand plugins to fix the many deficiencies currently present. The issues are numerous:

Infopane-as-single-tab introduces dancing UI. This is very bad. If I have one conversation open, the infopane takes the place of the tab that used to always be displayed. When a second tab opens, the notebook magically appears, shrinking the history area and throwing off the history pane's scrolling. Keeping a second tab open at all times to avoid this dancing UI is stupid at best and a pathetic hack at worst.
There is still no tooltip for the infopane. The whole point of the infopane was to provide blistnode-like functionality in the conversation window. We don't have any of this functionality except a status icon and buddy icon yet. No tooltips, no context menus, nothing.
It appears the infopane will be fixed at the top of the window. I disagree with this design decision, but a preference for this does seem overkill. I'm hoping a plugin will be able to change the widget order so that I can have a plugin to move the infopane below the history pane like Sadrul had in his screenshots of changes he had made.
Window size history is constantly being screwed with. It seems to me that I was once able to have my chat and IM windows (since I had them separated via the tab placement options) have their own sizes be remembered correctly. Currently I find myself having to resize every window when one gets created, because the most-recently-resized window seems to win out with remembering size.
Not strictly related, but the argument about the status icon on the tabs is somewhat flawed. The close button on each tab wastes just as much space on the tab as the status icon yet provides no useful information to the user. I still know several users who dislike the close buttons on the tabs, even after nearly three years living without them (the prefslash days of 0.78 or so killed the ability to turn this stuff off, as I recall). I strongly advocate a boolean preference labeled "Use simple tabs", which defaults to false. When set to true, both status icons and close buttons would not be shown on the tabs.

Don't get me wrong--on the whole, I'm happy with the direction Pidgin seems to be moving in. Simplicity and consistency without getting in the way too much. This is a very elusive and quite respectable goal, but getting there is a painful process which unfortunately requires a reasonable amount of experimentation and willingness to give into what the other developers and contributors want.

Speaking of Pidgin, Luke Schierer made a blog post the other day mentioning forking. In it he specifically stated that I was correct in closing a ticket on the Pidgin Trac that was soliciting a fork. I would like to take this opportunity to thank Luke for his support on my actions. Thanks, Luke. I may have been condescending and/or rude to the user who opened the ticket, but I feel justified in my response, especially given that the user actually agreed with me on all but one of the points I made.

When I started this post (roughly 0110 US EDT), I had initially intended to complain about the complaints I see on the Pidgin Trac. However, I've proven that I'm not much better than the users complaining in the tickets. Instead, I'll comment on something that I wish a few more users understood.

Occasionally a user in a ticket will have a complaint that, while valid, the user tries to justify by comparing to so-called competing IM clients. I would like to note that Pidgin is not in competition with any other IM client. There is more than adequate room in the IM client space for the myriad of IM clients that exist. This is simply proof of a point that Luke Schierer made, which is that no single IM client's user interface can satisfy everyone. Yes, Pidgin lacks features other clients have, such as default keybindings for smileys (a triviality to begin with that can be resolved within the realm of reasonability with .gtkrc-2.0), voice and video conversations, or more configuration options than ten copies of the Linux kernel combined. If the user interface doesn't meet your needs or wants, you probably should be using another interface. Ideally we'd love to see many different clients using libpurple as the backend code, enabling libpurple to serve a much wider audience in a better way by providing the facilities for others to reinvent the UI without having to reinvent the entirety of the backend.

On another Pidgin-related note, we've recently had a number of complaints about the lack of documentation on plugin development. Apparently the insanely large body of existing documentation--the doxygen docs and all the existing plugins--is not sufficient to satisfy some would-be plugin developers. In an attempt to address this, I've started to write a basic how-to series on the Pidgin Trac's wiki. I started by taking Gary Kramlich's existing start to a C Plugin HowTo and migrating it to the wiki, and I am now adding additional "chapters" to it. I'm not necessarily following any fixed format, but I'm trying not to half-ass this thing. My hope is that when I'm finished, I'll have a solid set of documents and accompanying plugins that will silence this set of complaints.

I think I'm done ranting for now. I might have more later.

The frustrations of development and work

2007-06-27T02:33:00.000-04:00

The last week or so has been an interesting love-hate relationship between me and all of my assorted projects and my regular job. I'll try to summarize:

The Purple/Pidgin Plugin Pack

I had wanted to push a release of this on June 21. This didn't happen for a couple of reasons. Stu Tomlinson wanted to test, which was a quite understandable request. For this reason I delayed until June 23 (my birthday, too!). On June 23, it was difficult to find the time to do anything code or computer related because of the family. Ok, no problem, let's delay one more day. Well, Sunday I realized I had no environment in which to compile our plugins for Windows. This is a no-go any time we release because literally within half an hour of release we get complaints about the lack of a Windows package. Well, long story short, thanks to VMWare 6 and its VNC server capabilities, I now have a Windows Pidgin Build Environment and I'll be using it to build the plugins whenever we do release.

Internet Banking

At work, we performed a migration on Wednesday, June 20. We used to host our internet banking system in our own datacenter/server room. As a way to potentially save money in the long term and also dramatically reduce the liability the bank shoulders for the security of the internet banking site, we outsourced the IBS to the datacenter run by the company that provides our IBS.
The actual site migration was trivial. Everything else, on the other hand, has been a royal pain. We've been on the phone with our conversion "experts" every day over the issues that just don't go away. The daily reports and end-of-day processing is generating tons of errors, flagging customers as overdrafting with their transfers when the customers in fact have more than sufficient funds, and for a time today the application that interfaces with the bank data for new account entry and password resets and whatnot refused to work at all. Our onsite person who enters new accounts into the IBS and does password resets and whatnot is frustrated enough that I wouldn't be surprised if she quit over it.

Bank conversion and consolidation

The bank I work for is owned by a holding company that the bank's board of directors formed in the early 80's as a way to buy other banks and run them as separate entities under one corporate umbrella. When the holding company was formed, it bought another bank that had a couple locations of its own. In 1998, a third bank was bought and added to the mix. In 1999, the bank I work for and the bank purchased in the 80's were consolidated into one larger, stronger, and more profitable institution. The third bank went along on its own quite happily. Last year, however, there were some massive losses at the third bank and their board of directors voted to allow my bank to take them over. Now, effective July 1, both banks will be divisions of the same bank in order to maintain their separate identities. Routing-transit numbers will be retained and everything. Processing will still be separate.
To facilitate what management wants, a contractor has been brought in to develop some conversion tools and some reports that can combine data from both banks, as well as some new replacement programs to work around some limitations of our current core processing system's security model. This contractor is actually very good and very efficient at what he does, which was quite a pleasant surprise. All of the development needed to satisfy management has caused tremendous headaches, and will only get worse as this weekend approaches--this end of month is the end of the quarter, and also a double processing night (the 1st of the month has to be seen as a business date for the vast majority of core processing systems, and it's generally easier to run two processing dates than to use the "combined" or "split" update features present). To top it off, the second processing date, July 1, is the start date for the merger. Fun, fun, fun.

At any rate, business as usual for the working guy--headaches, headaches, and more headaches!

Hopefully I'll be pushing a plugin pack release this week!

Projects for the Banker

2007-06-12T01:33:00.000-04:00

Given that I called my blog "The Flaming Banker" (in reference to the fact that I work for a bank and I start more than my fair share of flame wars), one would think I'd make a few more posts leaning toward the "flaming" part of the name, right? Well, apparently I'm incapable of doing too much of that. Every time I have something that I could rant about here, I end up distracted long enough that I'm no longer irritated enough to post it here. I just can't hold a grudge or stay angry for extended periods of time--don't get me wrong, that's almost certainly a good thing.

But enough of that. :) Let's get to the title of this post, shall we? Projects for the banker.

I recently, for some unknown reason, agreed to implement a feature in my listhandler plugin for libpurple. This feature would allow the importing of NotesBuddy exported buddy list files with a .dat extension. I spent a couple hours total on it before giving up on it as a useless, impossible task. My reasons for giving up on this were that I do not use sametime, nor do I have access to a server that provides the sametime protocol. The format was also completely incomprehensible to me.

I also received a patch for listhandler to implement the ability to export an XML list of aliases and then import said list without actually adding buddies to the list. I'm still undecided on this (mainly because I'm lazy and don't want to spend the time to fix the deficiencies I see in the implementation) but will probably rush to squeeze it in before Thursday, in hopes that we'll release the plugin pack to coincide with Pidgin 2.0.2.

The Pidgin FAQ...that's an interesting labor of torture and love. Luke Schierer simply does not have a block of time he can dedicate to sitting down and pouring a ton of documentation into the wiki at developer.pidgin.im. Nor does Stu Tomlinson, original author of the SSL-specific "FAQ." Stu nominated me to transcribe the SSL information to the wiki, which I was crazy (stupid?) enough to do. It took several days, on one of which I lost several hours' work and had to reconstruct it, but I managed to get it done. Following that, I noticed that what Luke had managed to put in the wiki was a bit anemic compared to the old FAQ. As I said, he simply does not have enough time to do all the bajillion projects that have resulted as a side effect of the name change and the migration away from Sourceforge. Given these two facts, I decided to pitch in and help beef up the FAQ on the wiki with more useful info. Amazingly, in just a few short hours (spread across a few days) I managed to migrate over half of the old FAQ to the wiki. I still have more questions I need to move over, and a few I think I need to add, but the most important stuff is there.

The downside to Pidgin having a wiki now is that anyone with an account can edit the wiki. I'm not so sure I like this idea. I was opposed to it from the start, then grew indifferent, and now am starting to come back to the opinion that it's not worth the trouble. As I mentioned, I spent several hours on the FAQ transcription. A couple days after I made my last changes, someone came along and butchered the careful wording that both I and Luke had previously placed into some questions, and added a new "question" that was completely incomprehensible. It took me literally half an hour to figure out what the person was trying to communicate. I have, however, fixed the offending entries.

I'm not going to bother lobbying for more restrictive wiki permissions, as I know it's a losing battle. There are apparently benefits to this approach that I'm not seeing right now. I've also started enough arguments within the Pidgin camp, and don't particularly feel like starting another.

And now let's get to the mother of all projects--Guifications 3. Gary Kramlich created this brainchild before I even became involved with his projects, and it's still in development. While Gary is frustrated with this (and rightfully so, as the rest of us developers have been mostly lazy bums in the process--no offense intended), he and I both realize this is probably for the best in the long run--as Gary has progressed, he's found some major flaws in his initial design that he's able to fix now, while we're still pre-alpha and mostly unusable.

Now, Gary would be quick to discredit my classification of myself as a "lazy bum," as he did last night in an IM conversation when I called myself useless. He does correctly point out that I have done a bit here and there and also taken some of the administration load from him, which helps him because it frees more of his time to work on the hard stuff in Guifications 3. I also try to take on the support role as much as possible when users come to us with issues involving Guifications 2 and the plugin pack.

At any rate, however, Gary decided that he needed to change some API by renaming GfFeedPool to GfFeedManager. He also needed to design a new API component, so he asked me to handle what I could of the Pool -> Manager transition. I spent a couple hours on this, more than Gary would have, I'm sure, but the end result is I did finish the conversion. I also found a few issues that resulted because Gary had split some functionality out of gflib and into gflib-ui, but had forgotten to update #include statements. Because of this work, I built and installed over half of Guifications 3, which roughly corresponds to how many of its modules are even remotely close to hackable, usable, or functional.

After all this discussion of Guifications 3, I'm sure some people are going to wonder what Guifications 3 is and why it's taken well over two years to develop while still not producing a usable "product." Without giving too much away, I'll try to answer that here. Guifications 3 is a modular framework for notifications, similar in purpose to libnotify and Growl, but with a much broader scope. We make heavy use of dbus by default and will support xmlrpc and a variety of other communication methods. And yes, that means that we're expanding our horizons beyond Pidgin. Far beyond. Yes, I know that's horribly vague, but until we've reached "hackable" there's not much point in laying all the cards out.

Also, since my last post I've had the pleasure of talking with Jennifer twice. She seems to be doing better than she was, but seems to be still very deeply hurt over the events that led up to our five-plus-hour conversation. I'm glad to see, though, that she is taking a sensible route on the matter and somewhat distancing herself from the situation. In the end it will make a huge difference for her, as she'll know some different aspects of life she hasn't yet explored. She will end up a much stronger person because of this, and I'm sure I'll find myself respecting her even more than I do already. Indeed, this too is intentionally vague, as I do wish to protect her privacy and avoid causing her any pain myself.

At any rate, I now need to go to bed.

Paying for friendship

2007-06-02T19:44:00.000-04:00

By reading the title of this post, I'm sure someone's going to get the wrong idea about this post. The title is actually a joke cracked by a friend of mine in reference to something I'll explain a bit later in this post.

Wednesday night was a good night at work in many ways--I was able to get my work done quite early and fast, and I learned a few things about how NCR MP-RAS handles different terminal types, including AT386, its default term type for /dev/console. (If you haven't gathered by now from reading my posts, I'm a UNIX geek of sorts.)

Seeing as how I had to get up early to go to work Thursday morning, I went home and eventually went to bed. Thursday was an interesting day for me. I flew through an absolute ton of stuff and accomplished more in a single day than I normally do in three. Between Wednesday and Thursday alone it felt like I had worked well over a full work week.

Thursday night, I went home, ate and took a shower, and proceeded to go about my Thursday night routine of playing catchup on all my trac email from Pidgin, a usual inflammatory comment or two in the Guifications IRC channel, etc., when I saw a notification pop up to say that a friend of mine had signed on. I looked at the notification and discovered that it was Jennifer, a friend from New York City who I hadn't had the pleasure of talking to in 224 days (according to Stu Tomlinson's lastseen plugin for Libpurple).

I proceeded to talk to Jennifer and was astonished at how open she was being with me. In my previous conversations with her spanning over the last six years of our lives, Jennifer has never been one to discuss her personal life so openly and freely. It was an amazing thing to finally be let into her world completely and really find out what's been bothering her. We talked for over five hours straight with me attempting to help her through her problems, or at least give her food for thought. I think it's safe to say I gave her plenty of food for thought, but I haven't really helped her much other than being a sounding board. I wish I could have done more for her; it always breaks my heart to see her sad or hurt. She finally decided to head to bed around 1 AM US EDT; I too called it a night at this point.

Friday morning I woke up at 4:30 US EDT to my alarm because I had to go print statements. Dead tired, I drag my sorry rear into work at 5:48 AM US EDT and have a host of problems, including a leaking toner cartridge for an HP LaserJet 5SiMX printer, a bad drum in the same leaking cartridge, statements that needed reprinted because of the bad drum, and a host of internet banking and voice banking problems. Essentially, everything that could go wrong did.

To make matters worse, when I got home I found out that my wireless router (a Linksys WRT54G version 2--one that OpenWRT would run on quite happily) was no longer forwarding packets from the outside to my internal boxes. I started investigating and in the end unplugged the router and plugged it back in to power-cycle it. After that, the WAN interface worked, but the router refused to route packets between the inside and outside worlds. I unplugged the cable modem from the router and attached it to my Dell Inspiron 6000 laptop and everything magically worked. So I unplugged the router again and let it cool off for a while. Once I plugged it back in, the WAN interface stopped working entirely. The switch ports are getting flaky too. The only thing working reliably is the wireless interface. So, for the time being, I'm stuck with only one machine having internet access, since i'm not willing to turn this laptop into a router.

I discussed the router problems with my friend Brandon, who had similar issues a couple weeks ago except in reverse (wired worked but wireless didn't) and his were fixed by a reboot and switching to a wired connection. Then I told him about the problems at work and the conversation with Jennifer and how long it had been since I talked to her, and he comes off with "You're just paying up for that friendship now." We laughed and that became the basis of this post's title. :)

All in all, given that I've been able to talk to Jennifer again, all the trouble is worth it. I've missed Jennifer more than I realized I could, and her friendship is worth more to me than any I've had in quite a while. Definitely worth the trouble. :)

Maybe I'm not such an idiot after all...

2007-05-24T00:28:00.000-04:00

I finally got my powerbook back! Yay!

Even nicer is that my boss in on vacation this week, meaning the workplace is more peaceful for me. It's also given me a chance to get caught up on some miscellaneous tasks at work. Once I crash for my four hours of sleep before heading back to work (really, kids, don't get a job where you work part of the week on a late shift and then turn right around and do an early shift the rest of the week--it really sucks!), I'll find myself going to work to play round with CentOS 4 in a virtual machine (VMWare player is a godsend at times, especially when you work with someone who has access to Workstation to create the virtual machines you need for testing purposes).

I know someone will inevitably want to point out that CentOS 5 is released. I'm well aware of this, but I haven't yet had the chance to nitpick CentOS 5 and get a setup script to customize it directly to our needs. Until I can do those two things, it's largely useless for us (no offense intended to anyone involved in the project!).

Now if I could just con my boss into installing rxvt-unicode termcap stuff on the UNIX box and letting me run Linux on my work machine...

Separate, but not equal? No more.

2007-05-23T02:00:00.000-04:00

Many Pidgin users who have tried to seek support on IRC know that the inhabitants of #pidgin have historically been quite hostile to Windows users landing there. The standard response was to always send the person to #pidgin-win32. Well, this has all changed. I'll come back to this.

Gary Kramlich, a friend and the founder of the Guifications project, took offense to some comments made in Pidgin's XMPP conference. While in retrospect I'm not sure whether Gary overreacted or not, it prompted Gary to announce that he wanted to take a break from Pidgin development, and that he wasn't sure if it was going to be a permanent step back. This is a matter on which I am as of yet unsure of his decision.

Part of the discussion that triggered Gary's announcement was a reiteration of the desire some members of the development team have to kill off Windows support in Pidgin. Note that this does not mean they want to discontinue Windows support for libpurple--in this case they are preferring that a native client would appear, much as AdiumX did on Apple's Mac OS X platform. I, too, would like to see a native Windows libpurple client happen. This is another issue I'll come back to shortly.

As a result of some of the discussion that ensued after Gary's e-mail stating his desire to take a break, it was proposed by Ethan Blanton, another Pidgin developer and supporter of the removal of Pidgin Windows support, that #pidgin-win32 be closed and all support take place in #pidgin. In many ways this proposal makes a lot of sense. As Ethan rightly pointed out, we often ended up with Windows users in #pidgin, and we would need to redirect them. Some of these users grew quite frustrated as it was often difficult to receive useful responses in the Windows channel in a timely manner, if at all. As others have pointed out, GTK+ has improved vastly on Windows to the point that there are few Windows-specific bugs to worry about. For some time now, the distinction between #pidgin and #pidgin-win32 has been artificial and unnecessary. There were at least two vocal supporters of the closure of #pidgin-win32 who made their position completely clear. I didn't have an opinion one way or the other but was quite shocked that it was actually being considered.

Now #pidgin-win32 redirects to #pidgin, and we can all bask in the elimination of the IRC segregation that once ran so deeply in the Pidgin camp. Now to complete the goals of making Windows support less of an issue, we simply need a native Windows IM client utilizing libpurple and remaining similar enough in look and feel to Pidgin that people will feel comfortable in switching.

I have wanted to have a project to develop a native Windows frontend for libpurple since before the rename and the tree restructure. When Sadrul Habib Chowdhury began his Google Summer of Code project to implement an ncurses-based UI around the then-nonexistant libgaim, one of the goals of the project was to complete the core-UI split and restructure the tree so that libgaim and Gaim itself were completely separate entities. With the completion of this project, the source tree was restructured. Following the name change, we now have Pidgin, Finch, and libpurple, all separated cleanly in the source package. This means that libpurple now officially exists and is possible (and now much easier) to develop against. When Sadrul started his project, I began to formulate the idea in my mind that I really wanted to have a native Windows UI for libpurple to eliminate the remaining deficiencies
with Windows GTK+.

The problem with my desire for said Windows application is that I don't know how to develop any graphical applications for Windows. Because I'm ignorant in this area of development, but want to be involved, about the only role I could serve is Support, Quality Assurance, and sounding board. Consider this a call to arms for capable developers. Contact me via the e-mail address listed here if you're really serious about doing this.

Best of luck to Pidgin in their new IRC support model!

(Updated 2007-05-23 12:26 to fix a typo)

Idiocy strikes everyone from time to time...

2007-05-20T21:30:00.000-04:00

It's just that it strikes some of us a bit more frequently than it does others. Take me, for example. I am a first-class idiot. My idiocy in the case I'm posting about is a direct result of me being a generally nice person in real life. Let's run down my stupidity, shall we?

I agreed to work on a computer for a co-worker. She had just decided, after years of being on dial-up internet service, to switch to a wireless internet service provided by her town. The "tech" finally showed up and installed the equipment. Signal was good and everything. Internet is insanely slow. A couple days and an hour long phone call with me later she brought the computer in for me to look at. I (and here's where the stupidity kicks in) let her use my powerbook while I had her computer.

Over last weekend (May 12-13), I brought the computer home and poked and prodded as much as I could. I could find nothing wrong. Even so, I tweaked a few settings here and there, ran the usual Windows Update crap, etc. I returned the computer on Monday (May 14). My powerbook still hasn't been returned.

Oh, and for laughs, let's explore my other instance of stupidity where this woman is concerned. She bought a Dell back in September. She complained endlessly about the keyboard, so I offered (sometime in October or November) to trade her my Microsoft keyboard for her Dell keyboard, assuming she liked the Microsoft. She wanted to try it first, which seemed a reasonable request. Now, several months later, I have neither keyboard.

I'm beginning to think being nice is a personality flaw...

The use of arbitrary status icons in Pidgin

2007-05-17T23:00:00.000-04:00

Before I go any further with this post, I want to make a couple things abundantly clear.

I have given up on this argument; I am expressing my opinions solely for posterity.
I don't care about right or wrong, because in this debate there is no right or wrong, no matter how strongly I feel my own opinions are right.
I do not want to start another flame war in the Pidgin camp; I inadvertantly caused the last spat on the mailing list by speaking up in the XMPP chat and wish I had kept my mouth shut.

In the text to follow, my recollection of history may be slightly incorrect; the exact history isn't important here. Only the general context matters, which what I present here is intended to illustrate.

IM applications use arbitrary icons for pretty much everything. This started ages ago with whatever IM client happened to be the first to use icons. I got my start on IM back in 1999 with ICQ. I believe I used ICQ 98b at first, then 99a and 99b, but can't recall at the moment. Whatever versions I used, they all shared a common feature--a fixed set of icons that meant something. For example, a green flower (the ICQ logo) meant said contact was online. Several other icons existed that I don't care to do research on to verify. The point is that these icons were chosen arbitrarily for whatever reason.

I next ventured into the world of AIM. When I started, AIM was still at some ridiculously primitive version compared to what we see now. I believe the version was 3.0.something. AIM used no logo on available buddies--they showed up as normal text. Idle buddies were dimmed--grey. Away buddies used a notepad icon. I can only assume the notepad was a reference to the sticky note left on the office door by some when they step out. As an aside, note that my introduction to AIM came before server-side buddy lists were actually used. I don't know if the capability actually existed at that point or not, but it certainly wasn't used.

Next I moved into Yahoo! Messenger. This application used their logo, a bright yellow smiley face (coincidentally only resembling the Wal-Mart smiley face in shape), to indicate available. Idle contacts were again dimmed (greyed). At this time Yahoo had no real sense of what Away truly meant. There were a ton of statuses, probably 10 or so; but while their names indicated that they meant away, they shared their icon indicator with the "busy" status--the yellow logo with a red sign in the lower right corner. You could set your own custom status messages, but the only thing you could do to even come close to visibly showing away status was to set the "busy" flag on the message you typed.

By this time, we're into early 2001. I had just been introduced to Linux via a classmate who ran SuSE 6.4 on a Sony VAIO. I started experimenting at home and finally got online with Linux (at this time I used Linux-Mandrake 7.2--those were interesting times!). I used official linux clients for a while for AIM and Yahoo. I found licq for ICQ. I disliked all of these applications for various reasons.

I had been experimenting with GAIM at the time (yes, in this case that capitalization was correct). Version 0.43 was installed on my machine. I don't recall how, as Mandrake 7.2 shipped with 0.48. I was a clueless newbie at the time and couldn't really figure much out but was eventually able to get online. I then stepped up to GAIM 0.48, then 0.53. From there I continued the upgrade path. All through these versions of GAIM, the available indicator seemed unimportant. What matters in the scope of this post is the away icon--it was the same notepad icon AIM used. It seemed natural, as this was primarily an AIM client.

I happily contiuned along the upgrade path--0.54, 0.55 ... 0.59 ... 0.59.9, 0.60cvs from Sourceforge's nightly CVS tarballs, 0.60 ... 1.2.o, and finally onto CVS HEAD once it became functional. Somewhere along the line there GAIM became Gaim. It was somewhere after I started using CVS HEAD that I started contributing to Gaim. At any rate, Gaim continued to follow the paper == away concept, and had gone to prpl icons to indicate available and dimmed prpl icons to indicate idle.

Now, during this time, I just took for granted that paper meant away because it's what i'd seen for so long. Now that Gaim has become Pidgin and changed its artwork, I find myself displeased with the icons for both Away and Extended Away. I have grown accustomed to the clock == away metaphor established here, even though I disagree with it. Now, this is not to say that I find the paper an adequate away icon, but more on that later. Also changed is the sticky note icon is now a sheet of paper (no complaints there). That icon, however, was moved to represent the Extended Away status. I don't agree with this assessment either.

At minimum, I would prefer to see the icons' positions switched. A clock indicates time, of course. A compelling argument is made in favor of using the clock for away, as most definitions of away do deal with time. The same arguments can be said for extended away. All these arguments are perfectly valid. I can't disprove them or rebut them with anything but my own feelings.

I feel that the clock would be a more adequate representation of the "idle" status, by indicating that it has been some time since the remote user sent a message or touched his/her keyboard or mouse. I also feel that the paper fits neither away nor extended away. I would propose a sign, similar to Adium's away sign, for extended away. I justify this proposal with an argument Sean Egan himself made in favor of the paper--if a shop owner closes shop for the winter, he puts a sign on the door saying "closed till spring" or somesuch.

As for the away icon, I've been thinking about that for quite a while now. Initially I thought a red circle with an X in it might be good, but that's a better representation of "busy" or "do not disturb." A yellow circle with some sort of symbol or something inside might work, but would be hard to distinguish from a white background and impossible to distinguish from a yellow background. In a fit of smart-alleck tendencies, I sarcastically suggested a big red A in the XMPP chat. Dumb idea. Finally I came to a blue icon of some sort. Not necessarily a circle, but not necessarily any specific shape, either. It would of course need to be unique and identifiable. I would do some mockups of this myself, but I royally suck at doing anything with graphics.

In conclusion, I will say I'm dropping this issue from this moment forward. I've vented about it, so it's out of my system. I'll live with whatever icon decisions remain.

I hope that if anyone on the Pidgin development team reads this they are not offended by anything I have said here, particularly Sean himself. I don't intend any of the comments above to be inflammatory, insulting, etc.; instead, I intend them merely to be a final expression of my opinion as my way of accepting the current state of affairs with respect to the icons before moving on to bigger and more important issues.

The true purpose of blogs?

2007-05-17T22:15:00.000-04:00

As anyone reading this post may or may not know, I am a huge Stargate fan. As such, I've been slowly getting into the blogs (thank you, Gateworld, for linking them so I could be lazy!) of those who are involved with Stargate. One of those blogs belongs to Kate Hewlett. For those who don't know, she played the sister of Dr. Rodney Mckay, who happens to be portrayed by David Hewlett, Kate's brother.

All this is pointless drivel meant to provide a bit of backstory and beef this post up a bit. The real point I'm trying to make here, alluded to by the title, is that in reading Kate's blog, I discovered a comment attached to the post stating that the commenter had come to the understanding that "blog" was actually short for "bitch log." (Sorry for the language, everyone. I do try to keep my posts clean.) After re-reading my previous posts here, I think I have to agree. I complain/whine/whatever a lot, and that shows in my posts. I promise I'll eventually post something meaningful :)

So, let the true purpose of blogging begin! :)

Pidgin and the status and protocol icons

2007-05-17T01:46:00.000-04:00

Ok, so by now everyone knows that Gaim has become Pidgin. Well, the name isn't the only thing that changed. Pidgin has decided to demote the protocol icons to second-class citizens. I love it. Being one who uses IM for communication, I find the protocol information almost completely useless.

Many users have complained about the lack of protocol icons. Ticket #414 is a prime example. There are others that have been opened and subsequently closed as duplicates, including at least one that I personally slammed shut within 45 seconds of its opening. I'll share my personal views on a few issues brought up as arguments to have the protocol icons back:

File transfer, you say? What's that? No, seriously! I don't use file transfer. No one on my buddy list ever sends me files. They use web servers, e-mail, or even sftp. Granted, for the most part I have much more technically inclined friends than most IM users. I will admit that I have occasionally taken the lazy road and attempted to send a file over IM; these attempts are futile as the only people I would send files to use XMPP or Yahoo! Messenger. Pidgin's file transfer support in these areas is somewhat lacking, and that's fine for me. I have a virtual private server from Steadfast Networks that I can host whatever legal content I desire on. I also have access to a dedicated server, also from Steadfast, and can place files I wish to share there as well.

Work vs. Personal. Doesn't apply to me currently but has in the past, so I do have an opinion. Pidgin has supported the notion of buddies and contacts for a very long time. Sean Egan, the lead Pidgin developer, prefers to call contacts "Person"s now. Adium and Trillian call them contacts and metacontacts, respectively. The simple answer to this is to use two contacts (or metacontacts if you prefer) for each person. One of these contacts would be for the personal accounts and the other for the work accounts.

But I want to see it! Wah. I want to get rid of the clock for away, but we don't all get what we want. Suck it up. I was initially against this change myself, but after using Adium on my powerbook and macbook for a while, I had gotten used to the lack of protocol icons. After a couple days I adjusted to it in Pidgin as well and learned to really like it.

Were it not for wanting to avoid being the root cause of trouble, any time someone comes into #pidgin whining about the protocol icons I would point out that each and every user has the freedom to do one of the following: a) suck it up and live with it; b) fork Pidgin and take it back to the old Gaim look; or c) find another IM client--there are many clients available to choose from.

I think this ends my rant on this subject for now. I would like to state for the record that the views and opinions expressed in this post do not necessarily represent the views of Pidgin, Finch, libpurple, Adium, Instant Messaging Freedom Incorporated, their developers, members, and board of directors, or any other software package or entity mentioned herein or related to this issue in any way.