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 Projects By Year

Information about some Summer of Code 2012 projects
Summer of Code 2011 (no participation)
Information about some Summer of Code 2010 projects
Information about some Summer of Code 2009 projects
Information about some Summer of Code 2008 projects
Information about some Summer of Code 2007 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:

Rewrite chat log backend and frontend

Our current chat log storage and viewer has only limited functionality. A proposal for this project idea should include plans to implement new backend and frontend (both, but backend is more important because frontend relies on it):

• New chat log backend features:
  • use single file (or anything less than one-file-per-conversation), like SQLite database
  • flag messages as unread until the user actually reads it, so unread messages can be re-opened after Pidgin restarts
  • conversation context
  • inline image (and custom emoticon maybe?) storage
  • backward compatibility with old log format (possible one-time migration from old log format to new log format)
  • (optional) remote log storage support
• Brand new frontend (chat log viewer - note, that it's pointless to do it without backend upgrade):
  • browsing by meta-contacts - tree view, like in buddy list
  • sorting by name, last message date, conversation frequency, amount of exchanged messages
  • search capability (with UI remaining responsive, possibly with a progress bar displayed)
  • (optional) typing name in search box could do real-time contacts filtering, like in buddy list
  • (optional) fuzzy search option
  • (optional) showing new messages in real time
  • (optional) manual import/export for old formats

Here are two mockups: ​like a current one ​better one.

Emoticon cache

(Note: There is some concern that this project is not large enough to justify an entire project.)

Currently Pidgin does nothing with received emoticons. It could save a lot of bandwidth if a cache of received emoticons existed. It could also be merged with local custom smileys so we have a unified way to manage these files. The cache can be done per session, per conversation, per account, or as a global permanent cache (just as buddy icons). The preferred method is a permanent cache so emoticons could be fetched only once.

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.
  • gillux: If that’s any motivation for anyone interested by this project, I’d like to point out that any improvment made on the gobjectification side will allow the old detachable session project to resuscitate improve and eventually get to a usable state.
  • grim: I need to take a look at the docbook and get it up to date. Also we could pull my ​GPlugin library in now too (still needs to be packaged for distros, but better than rewriting the entire plugin api)

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 and Transifex 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.

Javascript plugin loader

Similar to the Perl and Mono plugin loaders but for Javascript

• grim If gobjectification gets implemented this gets *VERY* easy with gobject-introspection.

Easy plugins with a website

Current process of installing plugins discourages users from doing it. Now, user have to run through the list, download a plugin, extract it and copy to some "magic" folder. Some things could be done to improve the situation:

• a mechanism for installing a plugin without touching a filesystem (downloading from URL, saving in user directory, loading it)
• new, (really) convenient plugins window
• plugins website with something like 1-click-install from openSuSE
• (optional) auto-update mechanism

Examples:

• ​adiumxtras.com
• ​addons.instantbird.org, ​addons.mozilla.org
• ​software.opensuse.org

See ​the mockup.

XMPP prpl improvements

• Add support for some XEPs. Here are some interesting ones with at least one other implementation (helpful for testing interoperability):
  • XEP-0184: Message Delivery Receipts - indicate when your contact's client has received a message you've sent
  • XEP-0198: Stream Management - improve reliability of XMPP connections
  • XEP-0308: Last Message Correction - ability to correct one's last message
• Temporary storage of PurpleBuddy (for information like current status) for non-buddies. It's not only XMPP issue, but affects it. See ​1 and ​2 for more info. Bug #4823
• Clean up/Finish work
  • Support for Jingle File Transfer: see ​http://hg.pidgin.im/dev/malu/xmpp_jingle_ft/
• Better Facebook and Gmail support; for example: Facebook have broken roster (without groups support), making it impossible to use it with meta-contacts
• Triaging hundreds of tickets

Android "proxy" client

This project could contain implementing a client for Android, which would act as "remote controller" of desktop client. Key points:

• mobile client registers to user's "server" and leaves all protocol-related job on it's side, phone gets only naked messages, without protocol noise;
• there is no permanent tcp connections - phone is notified via Google Cloud Messaging for Android service; it have to be power-save and lightweight
• easy to use, well designed UI (strongly inspired by existing ones from Google/HTC/whatever)
• (optional) integration with Android libpurple port, to let mobile client act standalone

Better buddy search

Bug #1710

Problem: Finding a buddy in the local Pidgin buddy list (CTRL+f) doesn't work well.

• Pidgin only finds matches if the buddy's group is expanded.
• It's hard to find a buddy when there are multiple matches for the search string.

Student should determine the ideal UI, then implement. One possibility is to trim the buddy list in real time as the user types the search term, such that only matches are displayed. This might mean temporarily replacing Pidgin's GtkTreeView? with another tree view. Or possibly removing then re-adding buddies from the tree view.

Students should:

• Look at how similar projects e.g. Adium, implement buddy search.
• Chalk out how this feature could be implemented and how much effort this would involve.
• Maybe think about alternatives, such as a separate search area or a plugin.