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
Information about some Summer of Code 2009 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:

Better chat log viewer

Our current chat log viewer has only limited functionality.

• Displays a tree hierarchy of all logs (so you don't have to use the "View Log" dialog)
• A search box that does real-time pruning of the tree as you type partial buddy names
• Grouped by contact! So if I have "markdoliner" on AIM and "mark.doliner@…" on XMPP, the logs show up in one window, with some differentiation for me to tell which IM account was used.

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

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

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.

libpurple detachable sessions

This is an often requested feature to which the response is often "run Finch in screen". Ideally, it would be possible for a user to run Pidgin and Finch simultaneously on a computer, with both programs sharing the same data and connections. This would allow users to leave Pidgin open, yet still access their IMs over SSH with Finch. This requires an implementation of some sort of libpurple server, and a method for the clients to connect to that server, and access and display the buddy list, conversations, and chats.