Wednesday, May 23, 2007

Separate, but not equal? No more.

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)