Contents

  1. General Info
  2. Confirmed Ideas
  3. Untriaged Ideas
  4. Ideas from previous years

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.
  • 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.

  • 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] Several improvements to Evince (mentor: JoseAliste)

  • Benefits: Improve the support for PDF Documents in GNOME (like better support for PDF annotations or better zooming capabilities). Improvements to the View part of Evince would also benefit GNOME-Documents app.

  • Requirements: Basic Knowledge of C (and C++), familiarity with Gtk (Basic understanding of the PDF Specification would be a plus)

  • Notes:

  • [No longer taking applicants] Add a bookshelf view for recently opened documents to Apps/Evince (mentor: JoseAliste)

  • Benefits: make easier to open recently viewed documents in Evince

  • Requirements: Basic Knowledge of C, familiarity with Gtk

  • Notes:
    • The view should be 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 should show only the recently viewed documents. If the document is no longer available, it should provide some indication to the user. The current implementation is in a menu, which is short and confusing when there is more than one file with the same name.

    • This should be only one 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.

  • Porting color management in GNOME to Wayland (mentor: RichardHughes)

  • Benefits: With GNOME moving to wayland we need to port our color managed stack away from Xorg.

  • Requirements: Good understanding of C, experience with jhbuild and Fedora 19

  • Notes: At the moment GNOME sets the Xorg video gamma tags at startup in the color plugin in gnome-settings-daemon. The plugin also sets the main system display profile as an X atom called _ICC_PROFILE on the root window for clients such as GIMP to read. Neither of these things will work with wayland. What we need to happen is:
    • We set the profile calibration state (the 'vcgt' gamma ramps) using some functionality in weston/wayland
    • We provide a way for applications to easily get the display profile so that the subsurface can be converted from either an embedded space or sRGB to the monitor space.
  • I'm expecting this to involve a bit of hacking wayland, quite a bit of hacking gnome-settings-daemon and lots of hacking color managed applications like GIMP and EOG.
  • About me: I'm a color-management geek who maintains all the existing color stuff in the free software stack (colord, gnome-color-manager, color control-panel and color settings-daemon plugin). I'm happy to mentor one or more students to do the different tasks.

  • [No longer taking applicants] Gnome Tweak Tool UI Refresh (mentor: JohnStowers)

  • Benefits: The tweak-tool UI looks dated compared to the new UI style of Gnome3 apps.

  • Requirements: PyGObject

  • Note: There are mockups here and here

  • [No longer taking applicants] Add Musicbrainz support to EasyTAG (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, GTK+

  • Notes: libmusicbrainz will be used for querying the XML web service.

  • [No longer taking applicants] Archive integration (mentor: CosimoCecchi)

  • Benefits: Improve the user experience in GNOME when reading and writing archive files

  • Requirements: Basic knowledge of C. Previous knowledge of GLib and GTK are a plus.

  • Note: see notes on Archives for an analysis of the status quo and some possible approaches to improve it

  • Boxes: Ability to save and load virtual machine boxes (mentors: ZeeshanAli, ChristopheFergeau)

  • Benefits: Users be able to save their VM boxes (along with their states) to an on-disk file and then be able to load the VM from it (possibly on another machine). This will go a long way towards enabling downloadable ready-made VMs (an optional part of this project that will give extra points to student).

  • Requirements: C, familiarity with Vala, Gtk+ and GNOME technologies/libraries in general would be a big plus.

  • Note: This work will involve understanding how libvirt's 'saving' and 'migration' feature works, how to use those to implement the needed features in Boxes and then making it all happen. Will definitely involve libvirt-glib (glib bindings for libvirt) and Boxes hacking but might also involve some libvirt hacking.

  • Boxes: Fill the gap with Vinagre (mentors: ZeeshanAli, ChristopheFergeau)

  • Benefits: GNOME3 can offer a single modern application to connect to remote desktop in various ways. Implement the following missing features available in Vinagre: RDP, reverse-vnc, avahi & SSH tunnel.

  • Requirements: C, familiarity with Vala, Gtk+ and GNOME technologies/libraries in general would be a big plus.

  • Note: This project will give you a chance to look at various technologies. We expect regular deliveries since there is existing code and each feature is relatively small.

  • [No longer taking applicants] Complete redesign of GNOME Shell's app picker (mentor: FlorianMuellner)

  • While the application view has evolved in 3.6 and 3.8, it still does not match the design mockups:

    • Applications should be paginated rather than scrolled - this will work better with the new folders, and will help with spatial memory. See this mockup for one idea of how it could look

    • Make the transition gorgeous - the currently used fade does not compare favorably to the original mockup

    • Expose folder editing to users - it is still unclear whether editing should be available in the overview itself or via an application like in this mockup, so close collaboration with the design team is expected

  • Benefits: A more usable and functional application picker

  • Requirements: Basic knowledge of Javascript/C. Previous knowledge of the GNOME platform (GLib, Gio, Clutter) is a plus.

  • Improve GNOME Shell's workflow in multi-monitor scenarios (mentor: JasperStPierre)

  • Fix bugs and implement the designs in Boston2012/Multimonitor.

  • Benefits: Make GNOME make work better in multiple monitor scenarios.

  • Requirements: Basic knowledge of Javascript/C. Previous experience with window management and X is a plus.

  • [No longer taking applicants] Implement a new avatar picker dialog that will pull from online sources (mentor: JasperStPierre)

  • Implement a new avatar picker UI that will be used in gnome-control-center, gnome-initial-setup, and empathy that can automatically pull from online accounts sources and services like Gravatar.

  • Benefits: Simplify the setup and personalization experience.

  • Requirements: Basic knowledge of C. Previous knowledge of the GNOME platform (GLib, Gio, GTK+) is a plus.

  • [No longer taking applicants] Implement design for Transfers application (mentor: EmmanueleBassi)

  • Implement the core service for submitting transfers, including its RPC API; iterate with the design team over the UI for displaying and controlling the current transfers, as well as the history of past transfers; integrate with the Privacy control panel.

  • Benefits: track transfers of content and files; centralize all long running download/transfer operations into a single UI

  • Requirements: Knowledge of JavaScript and C; previous knowledge of core GNOME platform libraries (especially GTK+ and DBus) is a plus.

  • Improve gnome-clocks world view (pictures, geolocation) (mentor: PaoloBorelli)

  • Benefits: implement the next design steps for the clocks application

  • Requirements: Basic knowledge of Vala

  • Notes:
    • Implement integration with geolocation
    • Implement support for custom city images as specified by the original design

  • Implement Caret and Focus Tracking for GNOME Shell (primary mentor: JosephS; additional support: JoanmarieDiggs, AlejandroPiñeiro, RuiMatos)

  • Benefits: Interested clients, a chief one being GNOME Shell's magnifier, will be notified of these events and can respond appropriately (e.g. ensure the focused object and caret remain on-screen).

  • Requirements: JavaScript (required). Knowledge of AT-SPI2, especially the handling of accessibility events, will also be needed to successfully complete this project. While it is not expected that GSoC applicants will already have knowledge of AT-SPI2 or accessibility, they are encouraged to acquire basic familiarity at their earliest convenience. Tips provided below.

  • Notes:

    • For more information about the project, please see its "features" page.

    • For more information about accessibility events and objects as a consumer/client application, you will likely find Accerciser a good place to begin.

    • For a functional/end-user understanding of the problem to be solved, enable GNOME Shell's magnifier, select a moderate degree of magnification (e.g. 4X-6X), and then perform a familiar task such as entering a bug in Bugzilla using only the keyboard to navigate to the page and fill out the fields.

    • Having attempted the above, should you have any questions, please ask us in #a11y. :)

  • Benefits: Have a new Application ready for GNOME 3.10 which complies with the design patterns of GNOME.

  • Requirments: Basic knowledge of Javascript/C. Previous knowledge of the GNOME platform (GLib, Gio, Clutter) is a plus.

  • Tracker miner for online Music accounts to be used with GNOME Music (mentor: SeifLotfy)

  • Benefits: Allow GNOME Music to explore Music on online storages like (ownCloud and Google Music) just like GNOME Documents does.

  • Requirments: Basic knowledge of Javascript/C. Previous knowledge of the GNOME platform (Tracker) is a plus.

  • Benefits: a fully functional git UI to be used standalone or to be reused in the GNOME IDE

  • Requirements: Basic knowledge of Vala and C, familiarity git and libgit2

  • Integrate Shotwell with Widely-Used Free RAW Photo Processing Tools (mentor: LucasBeeler)

  • Benefits: Shotwell and F-Spot have done a lot to advance the state of digital photography on the GNOME desktop, but using free tools exclusively remains difficult for pro-level photographers because of a lack of integration between tools for photo organization (i.e. Shotwell) and tools for developing camera RAW images into JPEGs (i.e. ufraw). In proprietary desktop environments like Windows and MacOS, these features are usually integrated into a single appliction like Adobe Lightroom or Apple Aperture. We'd like to solve this problem "the UNIX way" by providing integration between Shotwell and Widely-Used RAW processing tools.

  • Requirements: Intermediate knowledge of Vala or another modern, object-oriented language (e.g., Java, C#), previous knowledge of the GNOME platform, familiarity with pro-level digital photography.

  • Proxy editing in GES for Pitivi (mentor: Thibault "thiblahute" Saunier) - other ideas/projects also available

  • Benefits: Allow users of video editing software to dynamically swap clips in their project, to use low-definition versions for fast playback during editing and high-definition versions for rendering.

  • Requirements: knowledge of C. Previous knowledge of GLib and GStreamer are a plus.

  • Note: see https://bugzilla.gnome.org/show_bug.cgi?id=609136 for some details.

  • Presentation page for Rygel (mentor: JensGeorg)

  • Benefits: Easy status queries (and perhaps configuration changes) of our beloved UPnP-AV server through a web browser.

  • Requirements: Basic knowledge of Vala and HTML (perhaps C). Knowledge of the HTTP protocol and libsoup could be helpful.

  • Note: see https://bugzilla.gnome.org/show_bug.cgi?id=688859 for some details.

  • [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.

    • To know more about the idea or to discuss it, poke me (PioneerAxon) on IRC, or drop me an e-mail.

  • [No longer taking applicants] Implement support for custom functions in Calculator (mentor: ArthPatel)

  • Benefits: Usability for students and professionals by being able to define functions, and use them later to reduce usage overhead.

  • Requirements: Basic knowledge of Vala and some knowledge of parsers could be helpful.

  • Note: This can be achieved by implementing a FunctionManager class, which will load and store user defined functions and a little tweaking in parser (for being able to recognise the new grammar).

    • To know more about the idea or to discuss it, poke me (PioneerAxon) on IRC, or drop me an e-mail.

  • 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#, 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: Integrate with more REST API Services (mentor: AndresAragoneses)

  • Benefits: Banshee already benefits from some free REST APIs such as MusicBrainz. We could make use of others that are freely-available which would offer interesting features to the player, for example: 1) a SongKick plugin, which will let you know when your favorite artists (guessed from the ratings you apply to your music) would play near the place you live (or other places configured by you); 2) as well as having a CoverArt grid that lets you categorize your music per Album, it would be great to gain this eye-candyness advantage to the Artist categorization, thanks to the FanArt.TV APIs (further-explained in this bugzilla comment).

  • 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

  • GCompris is an educational software for children 2 to 10 (mentor: BrunoCoudoin).

  • It maintains its own list of ideas but other ideas will be evaluated as well.

  • Since some of these ideas are too small for a summer of code, you should get in touch with the GCompris developers to group a few ideas together and devise a realistic schedule.

  • Add test suite to Grilo (mentor: JuanSuarez)

  • Benefits: increase quality of code and prevent regressions on Grilo

  • Requirements: Knowledge about C and unit testing.

  • [No longer taking applicants] Add Lua support for Grilo plugins (mentor: JuanSuarez)

  • Benefits: allow developers to write plugins in Lua language

  • Requirements: Knowledge about C, Lua and Grilo.

Untriaged Ideas

  • Distributable Gtk+ and PyGObject (and dependencies) builds for Windows (mentor: JohnStowers, DieterVerfaillie, Tarnyko and probably others)

  • Benefits: To include continuous windows builds of the GNOME stack task

  • Requirements: PyGObject, MinGW and MSVC experience.

  • Note: Prior art here and here

  • Port GTranslator to Vala (mentor: nicolassatragno)

  • Benefits: give new life to a powerful and complete translation tool for GNOME translators.

  • Requirements: Vala/GTK, some gettext knowlegde and Python (optional, for plugins).

  • Note: the project is currently under minimal maintainance, but there's an important interest in bringing it back. Rewriting it in Vala would certainly boost the community support.

    • Be careful not to duplicate efforts with Virtaal though.

  • Redo charts for Baobab disk usage analyzer (mentor: PaoloBorelli)

  • Benefits: make the charts beautiful

  • Requirements: Basic knowledge of Vala and C, familiarity with Gtk and Clutter

  • Notes:

Ideas from previous years

CategoryGsoc

Outreach/SummerOfCode/2013/Ideas (last edited 2014-01-28 02:31:34 by MarinaZ)