General Info
Students, please read information about our application requirements and advice for students in addition to reviewing the ideas on this page. This list is not exclusive, and there are other ways you can define your GSoC project idea. Also, please be sure to contribute some code for the module you are applying to work on before or during the application process.
Mentors, the ideas do not have to be only about modules that are in a GNOME suite. If it's a project on GNOME-related software that can benefit the GNOME community, it's also good to list it here.
When adding a project idea, please try to follow those guidelines:
Discuss your idea with designers in #gnome-design to get their input and plan collaboration, especially if your idea is related to one of the core GNOME modules. If you are not sure who to speak to, start with AllanDay .
Consider ideas that consist of manageable and relevant tasks that the student can land in the main module throughout the internship period. See the information for mentors for more on preferred idea types.
- If you're interested in mentoring the idea, put your name. If not, then just leave it blank.
- Do not list multiple ideas with only one item. Use multiple items instead.
- Briefly explain why this would be great for GNOME.
- Do not write lots of text to explain your idea. If this is going to be long, maybe it's worth creating a page for it?
- Make sure students who do not know much about all GNOME modules can understand the proposed idea.
When students approach you about the idea you listed:
- Be clear with them about whether it is suitable for new contributors or for their experience level.
- Be prepared to give them a simple bug to fix or task to complete for your module and help them along with the setup and questions about the code. Encourage them to continue on fixing more bugs or writing code for the idea they are planning to apply for.
- If you already have a strong student applying to work on the idea, redirect other students to find other ideas to propose instead or in addition to your idea.
- If you already have as many strong students applying to work on the ideas you plan to mentor as you can handle, redirect other students to find other ideas and mentors.
- If you are redirecting students from your idea, please add [No longer taking applicants] to its title in the list below.
Don't hesitate to reach out to the GNOME GSoC admins if you need help redirecting students.
Please use this format:
. '''idea title''' (mentor: MentorName linking to you live.gnome.org personal info page) * ''Benefits'': describe the benefits of your idea * ''Requirements'': what should the student know already? * Note: one or multiple notes, links, whatever further information ----
Confirmed Ideas
[No longer taking applicants] Music: Add support for advanced search and remote sources (mentor: VadimRutkovsky)
Benefits: Music will get access to remote music sources. Search will be more complex and precise
Requirements: Python, GIO, GTK+
Notes: grilo plugins should be used to connect to remote sources. Integration with ownCloud via WebDAV and media (MTP players and CD) are nice enhancements
[No longer taking applicants] Photos: Browse DLNA media servers (mentor: DebarshiRay)
Benefits: There are lots of gadgets around us that are DLNA media servers (or DMSes) - smartphones, tablets, laptops, etc.. It is quite common to access them from other devices, such as TVs. This would enable users to browse DMSes from their GNOME computer.
Requirements: C, GLib, GTK+
Note: You do not need any fancy gizmos to get started. You can turn your GNOME computer into a DMS using Rygel. You will need to write a miner using dleyna-server and possibly Grilo, and then use it from Photos. You can use the existing code for Google Drive, SkyDrive, Flickr and Facebook as examples.
[No longer taking applicants] Photos: Browse PicasaWeb content (mentor: DebarshiRay)
Benefits: Increases the range of cloud services supported by GNOME.
Requirements: C, GData, GLib, GTK+
Note: You will need to write a miner using libgdata to fetch the metadata from the server and then use it from Photos. The existing Google Drive code would help you get started. There is support for SkyDrive, Flickr and Facebook. So you have plenty of examples to learn from.
[No longer taking applicants] Weather: integration with geocode-glib and geoclue (mentor: GiovanniCampagna)
Benefits: will expand the range of cities available in gnome-weather (and all libgweather using apps, including gnome-initial-setup and gnome-clocks) and will reduce the dependency on the static database
Requirements: C and JS. Familiarity with web APIs is a nice touch on top.
Note: the basic idea would be to take the existing text entry with completion and make sure it can list cities outside the database. The next step would be to have geolocation integration (so that the closest city is automatically picked).
Shell: make progress on Initiatives/EveryDetailMatters (mentors: AllanDay, GiovanniCampagna, JasperStPierre)
Benefits: we show users that we care about bugs, we refine and polish the user experience
Requirements: JS (and C, but not much); experience with the Shell (eg. through extensions) and with a jhbuild environment is welcome
Notes: This is about minor features and bugs, so you'll need to pick many to come up with a good GSoC proposal
[No longer taking applicants] Documents: Write an eBooks application based on Documents (mentor: CosimoCecchi)
Benefits: GNOME users will be able to read, search and manage their eBooks collection.
Requirements: Knowledge of Javascript is required. Familiarity with C, GTK, DBus and GNOME development in general will definitely be an advantage.
Notes: This bug report has some background on the application. The project would probably share a lot of code with Documents (e.g. by living in the same git tree).
[No longer taking applicants] Evolution: Complete instrospection support for EDS (mentor: FabianoFidencio)
Benefits: With introspection working we can improve our tests (that can be written in another languages than C) and make the calendar backend usable for another projects again.
Requirements: C, GObject, GLib
Notes: This project consists basically in write a libical wrapper, using GObject, to replace the libical's APIs that are being used directly in EDS calendar backend. Introspection works properly for Addressbook backend. More info can be found here
Evolution: Standalone app for editing server-side Sieve filters (mentor: MatthewBarnes)
Benefits: Support server side filters in evolution, what could be done using this standalone app as a useful starting point.
Requirements: C, GTK+, GLib
Notes: More info can be found here
Evolution: Notmuch as indexer and search language (mentor: FabianoFidencio, MatthewBarnes, MilanCrha)
Benefits: A real gain for usability once the user will be able to search something in a gazillions of mail and get the results really fast.
Requirements: C, GTK+, GLib, D-Bus
Notes: AlbertoRuiz started a proof of concept that can be found here. More info can be found here
Evolution: Implement a simple PKCS#11 module using evolution's addressbook as a backend (mentor: DavidWoodhouse)
Benefits: Allow users to send encrypted email to contacts with X509 certificate
Requirements: C, GTK+, GLib
Notes: A small discussion about this idea/issue was started here. More info can be found here
Boxes: Express installation of Debian, Ubuntu and OpenSUSE and make it perfect! (mentor: ZeeshanAli)
Benefits: Express installation is one of the coolest features of Boxes. Would be nice to at least support it for all major Linux distributions. Also Boxes, as a (virtual) machine manager is expected to be super stable and reliable so secondary goal of this project would be fix as many of the open bugs as possible.
Requirements: C, Glib and XML. Experience of Vala and XSL would be big pluses.
Notes: The primary goal of the project will involve work on libosinfo as well.
Boxes: Add snapshotting and/or cloning of virtual machines (mentor: ChristopheFergeau)
Benefits: Snapshotting would allow to 'tag' interesting points in a box lifetime, and easily go back to these if something goes wrong afterwards. Cloning makes it possible to easily and quickly create a separate and nearly identical box from an existing one.
Requirements: Vala, C, Glib.
Notes: Some work will probably be needed in libvirt-glib.
Projects/GnomeContinuous: Improve GnomeContinuous (mentor: ColinWalters)
Benefits: All people committing projects to GNOME benefit from Continuous
Requirements: C, JavaScript
Notes: Improve the web UI, testing framework, the underlying Projects/OSTree tool, etc. See this bug for example.
Automated tests for applications in GnomeContinuous (mentor:VadimRutkovsky, VitezslavHumpa and VladimirBenes)
Benefits: detect bugs early, improve overall quality of applications
Requirements: Knowledge of Python and Dogtail, minimal knowledge of Makefiles
- Note: Several projects have started using dogtail scripts for tests, this idea will help new projects to adopt tests, improve them and make use of CI in GNOME
[No longer taking applicants] Maps: Foursquare and Facebook integration (mentor: ZeeshanAli)
Benefits: User will be able to checkin to places and see last known checkin location of their friends.
Requirements: Knowledge of Javascript and C are required. Familiarity with GTK, DBus and GNOME development in general will definitely be an advantage.
- Note: This will likely involve work in GNOME Online Accounts (GOA) and not just Maps.
[No longer taking applicants] Maps: Routing: Add support for via points (mentor: MattiasBengtsson & PeterKarich)
Benefits: The user will be able to search for routes via many points (A → B → C not just A → B).
Requirements: Knowledge of JavaScript and Java are required. Familiarity with efficient Java development, algorithms, GTK and GNOME development in general will definitely be an advantage.
Note: This will involve working on both GraphHopper and Maps. GraphHopper needs better via points support and Maps need a good UI exposing the new functionality.
[No longer taking applicants] Maps: Routing: Add support for alternative routes (mentor: MattiasBengtsson & PeterKarich)
Benefits: The user will be able to choose between route suggestions when searching for a route.
Requirements: Knowledge of JavaScript and Java are required. Familiarity with efficient Java development, algorithms, GTK and GNOME development in general will definitely be an advantage.
Note: This will involve working on both GraphHopper and Maps. GraphHopper needs support for alterative routes and Maps need a good UI exposing the new functionality.
[No longer taking applicants] Improve calculation back-end of Calculator for dynamic length calculations (mentor: ArthPatel)
Benefits: Drop the "9 digit limit", improve calculation precision and fix all bugs related to large calculations.
Requirements: Basic knowledge of Vala.
Note: Current implementation of calculation back-end works with fixed length Numbers. Dynamic length Numbers can be implemented by using get/set methods in Vala. All arithmetic algorithms needs to be tweaked to work with dynamic length Numbers. Or, an alternate method is to utilize the GMP (or derived) libraries and construct an intermediate wrapper for Calculator.
- To know more about the idea or to discuss it, or drop me an e-mail.
Geysigning (mentor: TobiasMueller)
Benefits: GNOME would provide a comprehensive tool to sign OpenPGP keys and effectively obsolete Keysigning Parties
Requirements: Some Python, ideally some GTK+ and other (desktop) technologies (think DBus, avahi)
- Note: Right now, signing OpenPGP keys is a tedious process. It requires the signing party to download the key, verify its integrity, verify the information on the key being correct and finally redistribute the signed public key. Each of these steps are considered to be crucial and protocols for so called Keysigning Parties have been developed to help this process. Automated systems (CABot, caff) were built and abandoned because they are either to cumbersome to set up or hard to use. Other OpenPGP shells such as Seahorse or KGPG do not cater the need for signing keys in an automated fashion. It is thus hard for new people to start using OpenPGP. The idea is thus to provide the user with a simplistic set of tools which integrate seamlessly into the desktop, that allow to perform all the necessary steps to successfully sign a key. Target platform will be the GNOME desktop and thus GNOME and Linux technologies, such as GTK+, Avahi or DBus, will be used.
Banshee: Revamp MTP sync and add Bluetooth sync support (mentor: AndresAragoneses)
Benefits: Our device-synchronization story is getting a bit rusty, because latest Android versions default to MTP mode and don't allow MassStorage mode, and our MTP add-in has never been very mature. On top of that, having the possibility of syncing in a wireless way would just be awesome.
Requirements: confident working with both managed (C#, F#) and unmanaged (C) worlds. DBUS experience very desirable. You will probably learn a bit of GObject-Introspection along the way, but previous experience is not required.
- Note: I added both MTP and Bluetooth under the same GSoC task, because maybe a student can concentrate in one for the first term, and in the other for the second. But depending on the difficulty of each task, we may well plan later to discard one of them if we find the other to be a bigger (or more unimportant) task. (Our mileage may vary)
Banshee: Integrate with Rygel (mentor: AndresAragoneses)
Benefits: Banshee can already connect to UPnP servers as a client (thanks to Mono.UPnP), but with this idea it would start being able to serve files as a server, plus benefit from the maturity/polish/maintenance of Rygel.
Requirements: confident working with both managed (C#) and unmanaged (Vala) worlds, some experience working with GObject, and ideally some experience working with gobject-introspection
Note: To achieve this, this task is highly dependant on improving the bindinator, a new approach to make .NET bindings benefit from gobject-introspection rather than just plain API parsing from source code (GAPI).
Banshee: Integrate with AcoustID (mentor: AndresAragoneses)
Benefits: Banshee already has a MetadataFixer plugin which lets you improve the metadata/tags of your tracks collection greatly, but to achieve mass fixage (i.e. to curate your grandpa's crappy MP3 collection), we should need fingerprinting technology. AcoustID fills this gap by being one of the best opensource fingerprinting algorithms out there, which integrates very well with GStreamer (they also provide free APIs which integrate very well with MusicBrainz too). Thanks to this, we would get rid once and for all, of all these "Track 01" kind of tags which many music collections have, improve CoverArt guess/retreival, provide the best track-duplication detection, etc.
Requirements: confident working with REST API querying, some experience with C# or F#, and ideally GObject/GStreamer experience
Note: This task is somehow dependant on improving the GStreamerSharp binding via the bindinator, a new approach to make .NET bindings benefit from gobject-introspection rather than just plain API parsing from source code (GAPI), as we would need to improve the GStreamerSharp binding to use AcoustID in the best and most performant way.
Banshee: Integrate with Cydin (mentor: AndresAragoneses)
Benefits: Most bugfixes and new features implemented in Banshee are done in managed code in plugins. Recently a plugin contributor asked where to put the binaries of his plugin to at least increase awareness (and therefore user base) about its existence, and the best answer we could give to him is to host his source code on git and hope for distributions to package it. Shouldn't there be a better way? Well, we could do what other Mono/.NET programs already do for cross-platform functionality (i.e. MonoDevelop): addin(plugin) management via Cydin.
Requirements: basic C# (or similar language) skills, and be very aware of how a plugin/module architecture/paradigm works (dynamic module loading/unloading; ideally with experience on MonoAddins), basic ASP.NET experience will help too
Note: we could try this out first with the addins hosted in Banshee-Community-Extensions, and see how well it works to then decide if apply it to the rest of the official plugins
Banshee: Improve REST API Services integration (mentor: AndresAragoneses)
Benefits: Banshee already benefits from some free REST APIs such as MusicBrainz. Last year a student developed 2 plugins to make use of others that are freely-available which offer interesting features to the player: 1) SongKick 2) FanArt.TV APIs. However, we don't consider this addins production ready as they lack important features which could be developed in this GSoC: caching (so as to avoid unnecessary traffic towards the free APIs, this is a requirement to meet their ToS), geolocation (very useful in the case of SongKick), and better visualization for the FanArt grid (currently, the grid doesn't allow variable height for each row, which makes the experience less than ideal). These features could fill up an entire GSoC.
Requirements: basic C#, basic REST, basic gtk+/gtk#
- Note: even though these APIs are for non-commerical usage, we should license our code with an opensource license (open source is always commercial-friendly) and hope no one violates this restriction with our API key
EasyTAG: Add Musicbrainz metadata search support (mentor: DavidKing)
Benefits: Musicbrainz has more structured and accurate data than the current CDDB support, and provides an API (libmusicbrainz) for consuming data from the web service. The existing CDDB code is complex and fragile. Replacing the CDDB backend and UI with a Musicbrainz search would provide a better search experience and more complete metadata
Requirements: C, GIO, GTK+
Notes: libmusicbrainz will be used for querying the XML web service.
[No longer taking applicants]Getting Things Gnome!: Polish the backends experience (mentor: NimitShah)
Benefits: With backends for Gtasks and Todoist, GTG users will be able to get indirect support for their smartphones
Requirements: Python, Gtk+
Notes: Fix RTM backend, add new Gtasks and Todoist backends. You can have a look at the idea page to get a better understanding.
[No longer taking applicants]Getting Things Gnome!: Recurring tasks support (mentor: NimitShah)
Benefits: Will allow users to add repetitive tasks in one go. Will be more productive and is a much awaited feature for the product.
Requirements: Python, Gtk+
Notes: You can go through the idea page to get a fair understanding.
[No longer taking applicants] Four-in-a-row Four-in-a-row AI (mentors: MichaelCatanzaro)
Benefits: GNOME's Connect Four game is wickedly difficult, which makes the game unenjoyable. We need a new artificial intelligence that will provide three reasonable difficulty levels, without making unrealistic moves.
Requirements: Competency both C and Vala (or a similar language: C# or Java)
Notes: If you're new to AI, that's fine: this is a simple adversarial search, so you'll only need to learn minimax (aka maximin). Some research into Connect Four might be required. This won't take very long to complete, so this could be one component of a GNOME Games internship proposal and a good way to get started, but not the entire project.
[No longer taking applicants] Iagno Iagno Modernization (mentors: MichaelCatanzaro and AllanDay)
Benefits: GNOME's Reversi/Othello game is looking a bit old. A modernized design will provide a better user experience.
Requirements: Some experience with Vala (or a similar language: C# or Java)
Notes: Mock-up designs exist on GitHub. You'll also have time to help with one or more other games.
[No longer taking applicants] Mines GNOME Mines Modernization (mentors: MichaelCatanzaro and AllanDay)
Benefits: GNOME's Minesweeper game is looking a bit old. A modernized design will provide a better user experience.
Requirements: Some experience with Vala (or a similar language: C# or Java)
Notes: Mock-up designs exist on GitHub. You'll also have time to help with one or more other games.
[No longer taking applicants] Quadrapassel Quadrapassel Modernization (mentors: MichaelCatanzaro and AllanDay)
Benefits: GNOME's Tetris-like game is looking a bit old. A modernized design will provide a better user experience.
Requirements: Some experience with Vala (or a similar language: C# or Java)
Notes: Mock-up designs exist on GitHub. You'll also have time to help with one or more other games.
[No longer taking applicants] Sudoku Sudoku Modernization (mentors: MichaelCatanzaro and AllanDay)
Benefits: GNOME's Sudoku game has too many complicated features, and it doesn't follow modern GNOME design principles. We're halfway through rewriting it, but it's not nearly ready for release. Help finish the rewrite, modernizing and simplifying the game.
Requirements: Some previous experience with GTK+ and GLib; good competency in Vala (or a similar language: C# or Java)
Notes: Mock-up designs exist on GitHub.
Evince Finish the bookshelf view for recently opened documents and other improvements (mentors: José Aliste and Germán Poo-Caamaño)
Benefits: make easier to open recently viewed documents in Evince
Requirements: Knowledge of C, familiarity with Gtk
Notes: The view is similar to the Grid View available in Documents, however the use case is different. In Documents the use see what she have available in her collection of documents, but Evince shows only the recently viewed documents. If the document is no longer available, it should provide some indication to the user. The current implementation has the bulk done (check current status and patches, but it needs polishing before getting integrated in Evince. This should be part of several bugs to fix. See the GNOME Love bugs for Evince. More details about the different ideas (varying in complexity and fun) can be found in Apps/Evince/SocIdeas2013
Evince Tile rendering and other improvements (mentors: José Aliste and Germán Poo-Caamaño)
Benefits: Makes possible unlimited levels of zoom in Evince, and other applications that depends on it like GNOME Documents
Requirements: Knowledge of C, familiarity with Gtk
Notes: The current approach for zooming is inefficient in the use of memory. By using tiles for rendering documents, Evince should be have unlimited zoom levels without major memory footprint. See the bug report Tile rendering. This should be part of several bugs to fix. See the GNOME Love bugs for Evince. More details about the different ideas (varying in complexity and fun) can be found in Apps/Evince/SocIdeas2013
Evince Post-it Notes-like annotations improvements (mentor: Germán Poo-Caamaño)
Benefits: make easier handling post-it notes like annotations in Evince
Requirements: Knowledge of C, familiarity with Gtk
Notes: You will create a custom widget for annotations that is not subclass of GtkWindow, so it could be embedded inside the document view without losing the focus, moving according the view moves, etc. See Bug 700292]. This should be part of several related bugs to fix, such as, moving the annotation, changing and remembering its size and position, improve the sidebar view for annotations. See the Annotation bugs in Evince.
Evince Add text markup annotation support and other types of annotations (mentor: Germán Poo-Caamaño)
Benefits: Improve support for PDF annotations in Evince. Other applications that uses Evince libraries will be as well.
Requirements: Knowledge of C and basic knowledge of C++, familiarity with Gtk (Basic understanding of the PDF Specification is a plus)
Notes: Text markup annotations in Evince include highlight, strike out, underline and squiggly. This task will consist into enable these annotations with its respective UI interaction in Evince. The support has been added recently in Poppler (the library used by Evince to render PDF documents), which includes a working demo of these and other annotations, that can be used to get an idea on how to implement them in Evince. This should be part of adding other types of annotations (like lines, circles, squares and so on). More details about the different ideas (varying in complexity and fun) can be found in Apps/Evince/SocIdeas2013
Pybliographer Finish the port of to GTK+3 and other improvements (mentor: Germán Poo-Caamaño)
Benefits: Improve the user experience of managing references according to GNOME 3
Requirements: Knowledge of Python, familiarity with Gtk. (knowledge of unit tests is a plus)
Notes: The UI porting is mostly done, but it is necessary to add unit tests to check regressions before making them final. Once the porting is done, it will require to make the application follow the UI guidelines for GNOME 3 applications. Other improvements involve making the UI simpler, integration via dbus with other editors or word processors like Gedit or LibreOffice (to add references in documents). See related bugs.
Evince/Poppler Add support for new types of annotations and other improvements (mentor: Germán Poo-Caamaño)
Benefits: Improve support for PDF annotations in Poppler-glib, the library for render PDF used by Evince and other applications.
Requirements: Knowledge of C and C++, familiarity with Glib and Gtk (Basic understanding of the PDF Specification is a plus)
Notes: Recently new annotations has been added in Poppler-glib, which should serve as a template for adding missing annotations in Poppler-glib and then in Evince. New annotations include freehand (ink), caret, among others. This task will include also improving the support for already existing annotations (like resizing annotations like lines, squares, circles), and adding their corresponding demos. This proposal must be submitted to Evince project.
NoFlo GNOME components (mentor: HenriBergius or LionelLandwerlin)
Benefits: provide a flow-based development environment for GNOME, allowing people to visually build GNOME applications and automate their desktop environment. See a blog post describing the concept.
Requirements: Knowledge of JavaScript or CoffeeScript, some familiarity with the GNOME development stack and APIs
Note: NoFlo has been ported to run on Gjs. Having more components available for it would enable visual GNOME development. Components are written in CoffeeScript or JavaScript, and would essentially just wrap the appropriate GNOME APIs
Pitivi: various projects (mentor: Thibault "thiblahute" Saunier, Mathieu Duponchelle, Jeff "kiddo" Fortin...)
Benefits: bring video editing and filmmaking within the reach of everybody
Requirements: knowledge of Python, ideally for graphical user interface canvases and multimedia-intensive applications. Previous knowledge of GLib and GStreamer are a plus.
For the list of ideas, detailed requirements, benefits and instructions, see http://wiki.pitivi.org/wiki/Google_Summer_of_Code
Untriaged Ideas