Periodically we see or come up with ideas that would make a good Google Summer of Code project. Many of these get forgotten when we actually get around to listing ideas for the next summer. Here is a space to store them.

Some of these ideas may be insufficient for an entire Summer of Code project; in those cases it will probably be desirable to combine two or more ideas listed here into a single project.

Information about some Summer of Code 2007 projects

Write a Native User Interface for Microsoft Windows Based on libpurple

The current version of Pidgin for Windows uses GTK+ 2. While GTK+ 2 windows with the WIMP theme are designed to look like native Windows applications, they're not perfect. This task is to create a complete IM program for Microsoft Windows using libpurple as the core component.

There are a number of benefits here:

• A native UI will fit into the Windows desktop correctly
• Font sizes will follow users' expectations
• Editing of a .gtkrc-2.0 file will not be necessary to change elements of UI behavior
• Windows-specific conventions can be followed much more easily than can be done in Pidgin's GTK+ 2 UI
• If developed using MFC instead of .NET:
  • In theory, users of Windows 95 (there are still a surprising number of them!) should be able to use the application under some conditions
  • Windows 98, Windows ME, and Windows 2000 users with older machines will have a more pleasant experience, as .NET applications tend to not run well (fast) enough on older, slower hardware where these Windows versions are prevalent

This is a massive undertaking, and you should have a lot of experience creating native applications for MS Windows (experience with Visual Basic does not count here) as well as lots of experience with C. Familiarity with the libpurple source and POSIX programming in general is also very important.

Write XMPP Transports Based on libpurple

libpurple is our backend library that connects to AIM, MSN, Yahoo, etc. An XMPP transport is an add-on component that allows XMPP users to talk to people using AIM, MSN, Yahoo, etc. It should be possible to write a generic XMPP transport that supports all the same protocols supported by libpurple. Familiarity with XMPP and libpurple would be a good idea here.

ICQ TLC

Our ICQ implementation in the OSCAR code is substandard:

• We do not have full support for ICQ's:
  • status
  • privacy
  • message formatting
• Buddy list management is suboptimal
• Message size restrictions are likely wrong
• We do not support ICQ's chats

Your goal is to compare what libpurple does at a protocol level with what the official Windows ICQ client does, figure out where it differs, and to repair libpurple's implementation, extending Pidgin's, Finch's, and libpurple's capabilities where possible or necessary.

Yahoo! TLC

Our Yahoo! implementation is currently substandard:

• File transfer support is limited to the server-proxied method.
• Our support for the newest protocol revision (version 15) is sub-standard.
  • MSN interoperability isn't as good as it could be and we do not support adding buddies across the bridge at all.
  • Our implementation doesn't understand all the new status keys sent over the wire in this protocol version, which may be responsible for a number of user complaints about buddy list errors and buddies from across the MSN bridge not showing as online.

Your task is to compare what libpurple does at a protocol level with what the official Windows Yahoo! client does, figure out where it differs, and then repair libpurple's implementation. If time permits, documentation of the protocol would be a huge win, as well.

Finch Improvements

• A new window manager (or improvements to the existing ones). For example, a tiling window manager would be super awesome.
• Improve the widget-packing in a container (GntBox), may be even have a grid-like container.
• Have a spell checker, which would add some way of indicating spelling errors, suggesting possible corrections, etc.

Telepathy prpl

Currently, people wanting to use ​Telepathy have to switch from Pidgin to some other IM client (such as ​Empathy). It would be nice to have a Telepathy prpl for Pidgin, presumably based on the telepathy-glib client API (and possibly on libmissioncontrol). This would/could involve, depending on interest and time:

• Writing a prpl that speaks to Telepathy connection managers in order to connect IM accounts.
• Figuring out how to let accounts using that prpl be managed by Mission Control rather than by Pidgin, for coherence when using the rest of the Telepathy stack.
• Constructing some kind of global switch that makes Pidgin transparently use Telepathy rather than its own prpls when you flip it.
• Throwing together a hack to embed a libempathy-gtk video call widget into Pidgin when using the Telepathy prpl.

Familiarity with D-Bus would be a plus here. You should either speak C, or enough of a ninja to write bindings for your favourite language in about seven seconds.

(The astute will notice that this is the second half of last year's Telepathy SoC project, which there wasn't time to start on. Grab me on IRC if you're interested.)