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.

If you need clarification on anything listed below, or want to run a new idea by us to see if we think it would make a good project, or if you have any other questions please feel free to ask on our ​devel mailing list.

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

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.)

Topical Reference Tools

• In the same vein as the display of relevant advertisements along with gmail messages and in other Google tools, create some kind of interface and associated functionality to display contextually relevant information in IMs or other interface elements related to the current conversation.
• A modular or generic implementation to allow different "feeds" of information to be used.
• Implementation of this as a core plugin with dependent UI plugins might prove interesting.
• This should be able to be done asynchronously to avoid interfering with the performance of the event loop.

This sounds suspiciously like the (abandoned) ​Dashboard project – maybe some ideas from there could be adopted? —resiak

Gobjectification Projects

• Adopt a decent segment of the Pidgin source and begin to remodel it around the Gobject, such as the buddy list, the conversation interface, or something else significant and modify libpurple and Pidgin and/or Finch related objects to handle or exist as Gobjects as well.
  • rekkanoryo: Plugins should become gobjects and prpl's should be implementations of a PurpleProtocolIface (or similarly named interface) as a mandatory requirement of gobjectification.

libpurple theme support improvements

• Implement a more coherent and extensible theme manager.
• Include support for sound themes, smiley themes, and possibly others.
• Introduce compatibility for themes from other clients, such as Adium X.
• Look into ways to make the theme manager automatically install and apply theme changes in intuitive ways.

rekkanoryo: We really should have a common theme format that libpurple can support gathering information on and presenting to the UI. Adium message styles seem to be a relatively common "standard", but sound and smiley themes should be an easily managed standard format, such as XML (since we already have good XML parsing). This would make libpurple's information gathering and presentation to the UI common and simple and allow many UI's to benefit without reinventing the wheel. Mandatory here is a manner in which additional theme search directories can be added (both as a parent path with all theme types as subdirectories and as individual directories for specific theme types).

A Protocol Plugin Which Sends SMS Message via Your Cell Phone

Possibly by using a pre-existing library such as Gammu, KMobileTools or libgsm.

Implementing videoconference and VoIP

implements RTP transmission and voice communication between contacts.

Master Password Support for Multiple Platforms

An implementation of plugin(s) (in addition to the appropriate architecture modifications where applicable) to support gnome-keyring, kwallet, apple-keychain, and/or keepass.

Web site translations

• Produce a translation system for Pidgin's web site (at least the main static content)
• Implement Language auto-selection (via browser "Accept-Language" header)
• Use statically generated pages to avoid unnecessary server load and overhead (in other words, avoid pulling in the strings every time the page loads; only when they need to be regenerated)
• Make use of existing technology such as gettext or similar web projects to allow translators to submit translations easily
• Find a way to generate a translation template, identify or tag strings within pages.
• Consider ways to provide translated versions of images and screen shots