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
Information about some Summer of Code 2008 projects

Notes about the following ideas

There are a few things people need to keep in mind about the ideas presented below:

• These are NOT the only ideas we will consider.
• Students are encouraged to think of original ideas. A well thought-out original idea may well win out over any of the projects listed below.
• We have not assigned mentors to projects. This will happen once we decide which applications we will accept.

---

Now, on with the ideas:

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:
  • 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 Windows 2000 is prevalent
  • If developed with Visual Studio .NET, glib and libpurple will need to be built with Visual Studio .NET as well, as explained below. (Alternatively, it's apparently possible to reconfigure Visual Studio .NET to link against the system C/C++ runtime library to resolve the issues described below)
  • If developed with Visual Studio 6, it's possible that the existing libpurple build system could be leveraged to reduce the amount of work necessary in the SoC project itself.
• If developed using .NET:
  • The actual client development should be easier than with MFC.
  • The overhead of .NET will be incurred, which will make the application extremely slow to launch on machines even just 2-3 years old.
  • Glib and libpurple must be built with Visual Studio .NET. If they're not, there will be some obscure, unfixable bugs resulting from the mixing of two different versions of the Microsoft Visual C/C++ Runtime library.
  • .NET is probably preferred by most developers.

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 and extremely helpful.

ICQ TLC

Our ICQ implementation in the OSCAR code is substandard:

• We do not have full support for ICQ's:
  • privacy (#1009)
  • message formatting (#3271)
• Buddy list management is suboptimal
• Message size restrictions are likely wrong (#4628)
• There are many open tickets about encoding issues.

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.

MySpaceIM TLC

Our MySpaceIM implementation is currently substandard. The plugin was developed as part of Summer of Code 2007 by reverse-engineering the protocol spoken by the official client (making it the first publicly-available third party MySpaceIM implementation) , and although it is functional, further reverse-engineering of the protocol and bug-fixing of the libpurple implementation is needed to bring our client up to par with the official client.

A list of known bugs is available at MsimToDo?. Areas to consider working on include, but are not limited to:

• Group chat support (#4691)
• Improved server-side buddy-list support (#4734, #5240)
• Buddy search (#2661)
• MySpace.com "webchallenge" support (#2659). Require significant reverse-engineering skills, but your work would benefit not only libpurple-based clients but other third-party MySpaceIM implementations. Please list any reverse-engineering experience you have (for example, if you've used OllyDbg or other tools) if you wish to take on this task.
• General bug fixing
• Adding new features supported by the official client, but not libpurple

Your mission is to understand what the official MySpaceIM client does at a protocol level, document what you've found ​here (if not already documented), and implement it in libpurple.

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 2007'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.

A Protocol Plugin Which Sends SMS Message via Your Cell Phone

Possibly by using a pre-existing library such as Gammu, KMobileTools or libgsm. You could also send by email using teleflip.com

Webkit Message Views

Webkit is a popular HTML rendering engine used in a number of browsers. Adium uses it for their message windows as well. Your task for this project is to rip out GtkImHtml and replace it with Webkit. This includes the input areas as well.

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
• This particular idea may not be sufficiently complex to span a summer and it may be worthwhile to combine it with other web site or internationalization improvements to Pidgin or some other type of larger project.