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 [http://pidgin.im/cgi-bin/mailman/listinfo/devel devel mailing list]. == Information About Projects By Year == [wiki:SummerOfCode2012 Information about some Summer of Code 2012 projects] [[BR]][wiki:SummerOfCode2011 Summer of Code 2011 (no participation)] [[BR]][wiki:SummerOfCode2010 Information about some Summer of Code 2010 projects] [[BR]][wiki:SummerOfCode2009 Information about some Summer of Code 2009 projects] [[BR]][wiki:SummerOfCode2008 Information about some Summer of Code 2008 projects] [[BR]][wiki:SummerOfCode2007 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: {{{ #!comment == 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. }}} == 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: [http://i.imgur.com/XczYG.png like a current one] [http://i.imgur.com/dTFtV.png better one]. {{{ #!comment == Automated usage statistics collection == It would be useful if Pidgin included functionality to automatically collect various statistics from users and aggregate these statistics into a viewable form on the Pidgin website. This would be useful in determining which features are popular and which are not, and could allow us to remove unused features and preferences. Google Chrome and possibly Adium could be used as references for how to implement this. Some requirements: * The information must be anonymous, and not include usernames or passwords. * Users must be able to opt-out. It's not clear whether reporting would be enable or disabled by default. * Information must be easily viewable (so this project includes the client-side changes as well as possibly a server... but definitely investigate whether an existing solution could be used before creating a new one). It's not clear whether it would be public or private. * Could also include automated crash reporting. }}} == 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. {{{ #!comment == Telepathy prpl == Currently, people wanting to use [http://telepathy.freedesktop.org Telepathy] have to switch from Pidgin to some other IM client (such as [http://live.gnome.org/Empathy 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 [wiki:Telepathy] SoC project, which there wasn't time to start on. Grab [wiki:resiak 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) [http://www.nat.org/dashboard/ Dashboard] project – maybe some ideas from there could be adopted? —[wiki: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. * [wiki:rekkanoryo]: Plugins should become gobjects and prpl's should be implementations of a !PurpleProtocolIface (or similarly named interface) as a mandatory requirement of gobjectification. * [wiki: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 [wiki:GSoC2010/DetachableLibpurple detachable session project] to ~~resuscitate~~ improve and eventually get to a usable state. == 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. {{{ #!comment == 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 daemon, and a method for the clients to connect to that server, and access and display the buddy list, conversations, and chats. Existing ongoing conversations' history should be visible in Pidgin or Finch when they connect to this daemon. }}} == 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 [wiki:ThirdPartyPlugins 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: * [http://adiumxtras.com/ adiumxtras.com] * [http://addons.instantbird.org/ addons.instantbird.org], [https://addons.mozilla.org/ addons.mozilla.org] * [http://software.opensuse.org/package/pidgin software.opensuse.org] == 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 [http://pidgin.im/pipermail/devel/2013-April/011268.html 1] and [http://pidgin.im/pipermail/devel/2013-April/011274.html 2] for more info. * Clean up/Finish work * Support for Jingle File Transfer: see http://hg.pidgin.im/dev/malu/xmpp_jingle_ft/ * Better Facebook and Gmail support * Triaging [https://developer.pidgin.im/query?status=new&status=pending&component=XMPP 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 [https://developer.pidgin.im/wiki/GSoC2012/Android Android libpurple port], to let mobile client act standalone