| Version 85 (modified by , 11 years ago) (diff) |
|---|
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 thousands of files like now), like SQLite database
- allow marking messages as unread, so they could be re-opened after Pidgin's restart, until user actually reads it
- conversation context
- inline images (and custom emoticons maybe?) storage
- import from old chat log formats
- (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
- responsiveness while searching, maybe some progress bar
- (optional) typing name in search box could do real-time contacts filtering, like in buddy list
- sorting by name, last message date, conversation frequency, amount of exchanged messages
- (optional) fuzzy search option
- (optional) showing new messages in real time
- (optional) manual import/export for old formats (note, that import from old format should be anyway done automatically on first run)
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.
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:
- Buddies are added to their buddy list using their name/alias. This should be changed so they are added using their numerica ID, with the server_nick field set to their name/alias.
- 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.
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.
Javascript plugin loader
Similar to the Perl and Mono plugin loaders but for Javascript
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:
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
- Clean up/Finish work
- Support for Jingle File Transfer: see http://hg.pidgin.im/dev/malu/xmpp_jingle_ft/
- Better Facebook and Gmail support
- Cleaning hundredth 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
