| Version 112 (modified by , 10 years ago) (diff) |
|---|
Overview
This page lists project ideas that may or may not be good for Summer of Code or as standalone bounties.
Please feel free to ask our devel mailing list or XMPP chat room for clarification, or if want to get feedback on an idea, or if you have any other questions.
Disclaimer
This list is editable by anyone with a wiki account—not just Pidgin developers. These projects are not necessarily endorsed by the Pidgin project. It's possible we don't even like these ideas. You're encouraged to talk with developers (see links above) before undertaking a large project.
Summer of Code-specific information
- Ideas on this list might be too easy or too hard for Summer of Code. In such cases you may wish to combine projects or reduce them.
- 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 don't see a need to choose mentors ahead of time. We typically choose the most appropriate developer for a given project and assign them as the mentor once we've accepted each project. We also have no problems with you requesting a specific mentor (e.g. if you've been talking to a developer about a project).
Bounty-specific information
- We have traditionally not funded development or bounties ourselves. We have no problems with 3rd parties or bounty websites funding development. Our standard code acceptance criteria applies (the change must be desirable by Pidgin users, code must be clear and concise, etc).
- If you wish to work for bounties, you'll need to be responsible for nagging Pidgin developers to determine what types of changes we're willing to accept. And we can't guarantee any sort of turnaround time on review patches or releasing things that have been committed.
- 3rd party bounty websites you might be interested in (again, these are not endorsed by the Pidgin project)
Project Ideas
Encryption for XMPP
Possibly implement OpenPGP on Jabber? Possibly something else? See EndToEndXMPPCrypto and talk to Ethan Blanton.
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 libpurple does not store received emoticons. It could save some bandwidth if a permanent cache of received emoticons existed. It could also be merged with local custom smileys so we had a unified way to manage these files. The cache should store distinct sets of unique identifier indexed smileys for every protocol, so each protocol could use different checksum type. These smileys could be mapped to sha1-indexed (or any other, common hash) image files, that could be common for all protocols.
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
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.
Reproducible hosting
This project does not deal with the Pidgin codebase. It deals with the servers that host the Pidgin website, mailing lists, this wiki, etc.
Project: Create configuration for a configuration management tool (such as Puppet or Chef) that can recreate Pidgin's current hosting environment.
More info: We run a lot of services off of two servers. The services have been configured manually as needed. This is a time-consuming process and it would be very inconvenient to rebuild everything. A correct solution would be able to recreate all needed services automatically on a clean server. A correct solution would work well regardless of the Linux distribution which is used.
Bonus:
- Switch web server from lighttpd to nginx
- Ensure all data is backed up (mailing list archives, home directories, source repositories, anything else important that isn't captured in the configuration management config).
List of services:
- Web site for www.pidgin.im
- Trac for developers.pidgin.im
- Web site and MediaWiki? for imfreedom.org
- Mercurial version control for hg.pidgin.im
- Mailing lists for Pidgin and IM Freedom
- Mailing list archives for Pidgin and IM Freedom
- Automated generation of localization stats at https://developer.pidgin.im/l10n/
- Automated generation of API documentation at https://developer.pidgin.im/doxygen/
- DNS for pidgin.im and imfreedom.org
- Email for pidgin.im and imfreedom.org
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:
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
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.
Miscellaneous, less-refined, small ideas
- $1 for every 5 lines of code removed. Must remove at least 100 lines of code. Removal must not cause things to break. The intent is to reduce code duplication, so changes must make the code work better, or be easier to read, or make things cleaner, or eliminate confusion.
- a multi-user selector and associated request field types. I'd wanted to work on one, but when I attempt to mess with UI the result is almost always an atrocity. Something similar to a file selector, where it's got a simple "normal" display with a more complex pop-up. It would be useful for inviting multiple buddies to a chat, and sametime could use it for the announcement feature. API should permit filtering by account (or just some arbitrary filter function?) and possibly permit entering users that aren't in the blist.
- Generate Doxygen docs for our protocol plugins in a nice, organized way. $25.
- $1 per memleak fix, regardless of size
Background: Checks are expensive (say, $15ish) for Europeans to cash, overseas wire transfers carry fees (similar, maybe a bit more), cash isn't safe. Discussion on making micropayments like this feasible. We can send checks within the US for free, so that's not a problem.
hbons: What about a gift certificate for a big international online store (amazon or something)?
elb Good suggestion. We could even make this an option; users could choose from an Amazon gift certificate or a check. There are probably several retailers we can look at for this. In the US, credit card-style "gift certificates" (which can be used anywhere that takes, e.g., Visa or American Express or whatever service backs the card) are quite affordable. I do understand that in some European locales, using a proper credit card is also a problem. In that case, though, we're back to the postage & time problem unless they can be ordered online; also, I'm not sure about denomination options.
In Europe, wire transfer could be used instead. Euro-denominated wire transfers within the EEA are treated as domestic within the Eurozone and many banks (at least in Germany) are doing domestic wire transfers for free. (NB: some countries in Europe are not part of the Eurozone although they have unilaterally adopted the Euro; some others are not part of the EEA but use the Euro bilaterally) -- chemistrydioxide
- Generate SWIG bindings for usage from plugin loaders - eventually replace current Perl and Tcl? loaders. $100
deryni: I think swig generates ugly, overly complicated code. In working on my lua loader I used swig to parse the gaim source into xml, then grabbed from the xml the information I needed about all the functions, classes, enums, etc. and then used lua itself to massage that information into boilerplate code for each function. I'd sooner see a script written to automatically generate the result of the swig->xml->simple_info_format which could then be used by loader authors to make their boilerplate (or at least be a reference of what should and shouldn't be bound).
- A Symbian (J2ME? S40? Any mobile will be great ..) client using libpurple. I get asked this really surprisingly frequently
- Replace GtkIMHtml with a better HTML widget. $100
- Privacy Rewrite Rewrite our privacy UI and API so that we correctly and intuitively handle the privacy settings for each protocol. $100
- GObjectification Convert structs in Pidgin to GObjects. $10 per major struct
- Support for Microsoft LCS Our SIP/SIMPLE plugin is currently not able to connect to Microsoft's Live Communication Server. We have code for autheticating with NTLM, but it doesn't work correctly. $25
- Rewrite the log API to be non-blocking
- Plugin Types - Remove the artificial distinction between protocol, loader, and "regular" plugins. $100
rekkanoryo - Some work toward this will happen in GObjectification
- Improve ICQ support - The current implementation of ICQ support in our OSCAR code has some deficiencies, including issues with status messages, nearly non-existant privacy support, buddy list issues, some file transfer issues, buddy icons, etc.
