Contents

  1. Students Information
  2. Mentors Information
      1. Adding an idea
      2. When students approach you
  3. Accepted Ideas
  4. Untriaged Ideas
  5. More Ideas

Students Information

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 find a mentor and define your GSoC project idea.

Mentors Information

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.

Adding an idea

  • Read mentor's guidelines and follow the steps to become a mentor .

  • Discuss your idea with designers in #gnome-design to get their input and plan collaboration.

  • Make sure your idea consists of manageable and relevant tasks that the student can merge in the main module throughout the internship period.

  • Do not list multiple ideas in 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. Try to summarise it and explain it clear enough for someone that might not know the GNOME platform.

  • List your idea on this page even if you already have a strong applicant applying to it.
  • Put [Many strong applicants] next to your idea if you have already too many strong applicants.

When students approach you

  • Be clear with students 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 are redirecting students from your idea, please add [Many strong 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 and add your idea to the bottom of the Untriaged Ideas section below: 

 '''Project name: idea title''' (mentor: MentorName linking to your wiki.gnome.org personal info page)
 * ''Brief explanation'': Explain briefly the idea, including the benefits for GNOME.
 * ''Requirements'': what should the student know already?
 * ''Communication'': what communication channels do you use for mentoring?
 * Note: one or multiple notes, links, whatever further information

Accepted Ideas

  • Rygel DLNA suite: Implement synchronized playback (e.g. multi-room audio) (mentor: JensGeorg, co-mentor: tbd)

  • Brief explanation: Implement the UPnP/DLNA synchronized playback feature in Rygel

  • Requirements: Vala, C, ideally an understanding of GStreamer and a grip of reading and understanding specifications

  • Communication: phako in #gupnp on irc.gnome.org

  • Note: Bug with a couple of links is at https://gitlab.gnome.org/GNOME/rygel/issues/94


  • Geoclue: Port service code to Rust language (mentor: ZeeshanAli, co-mentor: tbd)

  • Brief explanation: Port of service to Rust, will bring safety and other benefits, without compromising on efficiency.

  • Requirements: Familiarity with Rust. Familiarity with C as well, would be a big advantage but not required.

  • Communication: zeenix in #gnome-maps or #gnome-hackers on irc.gnome.org

  • Note: More details: https://gitlab.freedesktop.org/geoclue/geoclue/issues/103


  • Fractal: Improve Room Details (mentor: DanielGarcia, co-mentors: team)

  • Brief explanation: Work on improving the Room Details view, adding missing features such as media history, join addresses, notification settings, visibility settings, and moderator tools.

  • Requirements: Familiarity with Rust and GTK

  • Communication: #fractal-gtk:matrix.org on Matrix is used for communication by the team of about 5 regular code contributors. New contributors are expected to be available here.

  • Note: More details in https://gitlab.gnome.org/GNOME/fractal/issues/449


  • Fractal: Add Devices & Security dialog (mentor: DanielGarcia, co-mentors: team)

  • Brief explanation: Add a new dialog to manage the user's devices with a connection. The dialog would be similar to the "Security & Privacy" section in the Riot settings.

  • Requirements: Familiarity with Rust and GTK

  • Communication: #fractal-gtk:matrix.org on Matrix is used for communication by the team of about 5 regular code contributors. New contributors are expected to be available here.


  • Fractal: Add Read Receipts and improve Message View (mentor: DanielGarcia, co-mentors: team)

  • Brief explanation: Work on adding Riot-style read receipts and other UI improvements to the Message View, such as better mentions and replies.

  • Requirements: Familiarity with Rust and GTK

  • Communication: #fractal-gtk:matrix.org on Matrix is used for communication by the team of about 5 regular code contributors. New contributors are expected to be available here.


  • Fractal: Implement Discover View (mentor: tbd, co-mentor: team)

  • Brief explanation: Work on adding a new Discover view, which includes the Room Directory and a new GNOME newcomer experience.

  • Requirements: Familiarity with Rust and GTK

  • Communication: #fractal-gtk:matrix.org on Matrix is used for communication by the team of about 5 regular code contributors. New contributors are expected to be available here.


  • Fractal: Make API calls async (mentor: JulianSparber, co-mentor: team)

  • Brief explanation: Work on porting our Matrix API calls to tokio, in order to make them asynchronous and improve performance.

  • Requirements: Familiarity with Rust and GTK

  • Communication: #fractal-gtk:matrix.org on Matrix is used for communication by the team of about 5 regular code contributors. New contributors are expected to be available here.


  • Fractal: UI refactor (mentor: JulianSparber, co-mentor: team)

  • Brief explanation: We plan to add a new backend to Fractal, therefore the UI needs a lot of refactor to interact with the backend(doesn't exist yet)

  • Requirements: Familiarity with Rust and GTK

  • Communication: #fractal-gtk:matrix.org on Matrix is used for communication by the team of about 5 regular code contributors. New contributors are expected to be available here.


  • Boxes: Improve express-installations by adding support for tree-based installations (mentor: FabianoFidencio, co-mentor: FelipeBorges)

  • Brief explanation: Currently GNOME Boxes is able to do either express-installations on a downloaded ISO or to download an ISO and offer the option to express-install it. What we're aiming for with the project is to add support for express-installations using the OSes' network trees from where we can get the kernel and initrd and then perform the express installation using those (instead of downloading a whole ISO). The project will consist on work done both in the Boxes' UI and on its internals and, most likely, also on libosinfo.

  • Requirements: Vala, C

  • Communication: fidencio and feborges in #boxes on irc.gnome.org

  • Note: This project requires UI changes and must be in sync with the designers' goals.

  • Yet another note: Those are a few examples of trees we can use to get the kernel and initrd to perform the express-installations: http://fedora.uib.no/fedora/linux/releases/29/Server/x86_64/os/, http://archive.ubuntu.com/ubuntu/dists/cosmic/main/installer-i386


  • Infrastructure: Automate accounts creations process (mentor: AndreaVeri)

  • Brief explanation: Create a Django based form to request an account making sure the account naming policy and other guidelines are taken into account, automatically mail the module maintainers to receive approval. If confirmed generate a ticket on RT with the original request, approval and one line for creating the actual account via the IPA cli or API

  • Requirements: Python, Django

  • Communication: averi in #sysadmin on irc.gnome.org


  • Membership Committee: Automate Foundation membership applications process (mentor: AndreaVeri)

  • Brief explanation: Improve (or eventually re-think) the form at https://www.gnome.org/foundation/membership/apply, automate reaching out to applicant's contacts, make sure they're existing Foundation Members, store their responses on the associated RT ticket for the Committee to start reviewing

  • Requirements: Python, PHP

  • Communication: averi in #sysadmin on irc.gnome.org


  • Polari: Preview links (mentor: FlorianMuellner)

  • Brief explanation: People often share links during conversations. Previewing them as inline thumbnails would make switches to the web browser unnecessary in many cases.

  • Requirements: JavaScript, GLib, GTK+

  • Communication: fmuellner in #polari on irc.gnome.org

  • Note: Mockup available


  • Games: Support multiple snapshots (mentor: AlexanderMikhaylenko)

  • Brief explanation: Allow to take, manage and restore snapshots anytime for supported games, with a nice UI, based on the already present snapshot technology.

  • Requirements: Familiarity with Vala and GTK

  • Communication: exalm in #gnome-games:matrix.org on Matrix or #gnome-games on irc.gnome.org


  • GTK: Rework the GTK website (mentor: EmmanueleBassi)

  • Brief explanation: The GTK website hasn't been updated in a long time, and with the GTK4 release looming large in the future, we want to provide a better experience for potential GTK developers.

  • Requirements: GTK, web development, web design

  • Communication: ebassi in #gtk on irc.gnome.org


  • GTK: Improve the GTK test suite (mentor: EmmanueleBassi)

  • Brief explanation: Work on GTK's test suite. Increase in coverage, reliability, and ease of update.

  • Requirements: GTK, GLib's test API, C, GitLab's CI

  • Communication: ebassi in #gtk on irc.gnome.org


  • GVfs: Improve Google Drive support (mentor: OndrejHoly)

  • Brief explanation: Add support for move and copy operations within the Google Drive filesystem and possibly other improvements.

  • Requirements: Familiarity with C and ideally an understanding of GLib/GIO and libgdata.

  • Communication: oholy in #nautilus on irc.gnome.org

  • Note: https://gitlab.gnome.org/GNOME/gvfs/issues/8


  • GVfs: Implement generic test suite (mentor: OndrejHoly)

  • Brief explanation: GVfs has just a few tests specific for concrete backends. The idea is to implement a set of generic tests which can be used to test any backend and make them part of GitLab CI.

  • Requirements: Familiarity with C and ideally an understanding of GLib/GIO and GitLab CI.

  • Communication: oholy in #nautilus on irc.gnome.org


  • Battery Bench: Bring battery testing back to the future (mentor: ChristianKellner, co-mentor: BenjaminBerg)

  • Brief explanation: Improvements, port to Wayland and new benchmarks, tests.

  • Requirements: C, GObject (and GTK+) is a plus, some understanding of power would be awesome.

  • Communication: gicmo and benzea on #gnome-hackers on irc.gnome.org


  • Migration Assistant: Getting started and background research (mentor: ChristianKellner, co-mentor: N.N.)

  • Brief explanation: Migration of data and settings from one computer to another (like from an old one to a new one). There is a design, but no code. The idea would be to start with migrating simple data, flatpak Apps (data and settings) and also doing research how non-simple data/settings (general settings, dot-files, etc.pp.) should be treated.

  • Requirements: GTK and a preferably a high-level language with good GTK bindings (rust, Vala, Python, C or C++ could work, maybe JS if we find a right co-mentor)

  • Communication: gicmo on #gnome-hackers on irc.gnome.org


  • tracker-miners: Allow indexing on demand (mentor: CarlosGarnacho)

  • Brief explanation: Make it possible for applications to request for portions of the FS to be indexed.

  • Requirements: C, GObject and DBus knowledge is a plus, notions of flatpak.

  • Communication: garnacho in #tracker on irc.gnome.org


  • GStreamer: Convert plugins from C to Rust (mentor: Sebastian Dröge)

  • Brief explanation: GStreamer has started implementing new plugins in Rust, in an effort to improve safety and maintainability. There are a few plugins already ported that would have to be brought to feature-equivalence with the corresponding ones in C. In addition, new plugins around already existing Rust crates for codecs and file formats could be written, or other existing C plugins be ported to Rust.

  • This would include enough potential tasks for more than one student.

  • Requirements: familiarity with or strong interest in learning Rust, if possible some knowledge about GStreamer

  • Communication: slomo on #rust on irc.gnome.org


  • Gtk-rs: Add subclassing support to GIO/GTK Rust bindings (mentor: Sebastian Dröge)

  • glib-rs recently gained the capability to subclass GObjects directly from Rust code, and the required API for this was added to the GStreamer bindings too. However the GIO/GTK bindings are lacking this API currently and it would have to be added too to allow subclassing of specific types like gio::Application or gtk::Widget. This could be partially done manually and partially by extending the existing code generator and updating an older branch that was started for doing this.

  • Requirements: familiarity with or strong interest in learning Rust, familiarity with GObject and to some degree GIO/GTK

  • Communication: slomo on #rust on irc.gnome.org


  • Gtk-rs: Add GTK4 Rust bindings (mentor: JordanPetridis co-mentor: Sebastian Dröge)

  • GTK4 is going to be released soon and now would be a good time to start GTK4 Rust bindings to see if all we need is available. These would be based on the existing GTK3 bindings as a starting point, and then adjusted for all the new API changes. As part of this, bindings for the graphene library will also have to be written and possibly other bindings improved too. In addition, the gtk-rs examples repository would have to be ported to these new GTK4 bindings.

  • Requirements: familiarity with or strong interest in learning Rust, some familiarity GTK

  • Communication: alatiera or slomo on #rust on irc.gnome.org


  • Gitg: Side by side diff view (mentor: AlbertoFanjul)

  • Brief explanation: At this time, there's only a unified diff to show changes in gitg. Split view (original and modified file side by side) is a handy representation of a change, and allow too to show merges as three way diffs, modernizing the whole changes view in gitg.

  • Requirements: Vala, GLib, GTK

  • Communication: albfan in #gitg on irc.gnome.org

  • split view MR


  • Gitg: Implement rewrite history operations (mentor: AlbertoFanjul)

  • Brief explanation: Gitg allow people to deal with git repos visually. Implement rewrite history operations (like rebase and pull), is a must to allow a complete experience on git through gitg.

  • Requirements: Vala, GLib, GTK

  • Communication: albfan in #gitg on irc.gnome.org

  • rebase issue


  • Nautilus: Implement libcloudproviders for Dropbox client (mentor: CarlosSoriano)

  • Brief explanation: Implement integration of libcloudproviders for Nautilus for the Dropbox client, which uses a Nautilus-only plugin.

  • Requirements: familiarity with GLib and D-Bus

  • Communication: csoriano in #nautilus on irc.gnome.org



  • Music: Implement importing/syncing music (mentor: JeanFelder)

  • Brief explanation: Implement Music syncing with devices and importing from (remote) locations.

    • Use GIO to track interesting mounts
    • Control indexing of locations with Tracker
    • Import or sync music, using GStreamer pipelines as necessary to convert music

  • Requirements: Python

  • Communication: ptitjano in #gnome-music on irc.gnome.org

  • Notes:

    • Discussions around the idea in GitLab

    • A similar project was implemented in Photos



  • BuildStream: Replace/improve gnome-continuous (mentor: buildstream maintainers / GNOME release team)

  • Brief explanation: gnome-continuous is an amazing technology that has sever us well for long time (build.gnome.org). But It's showing its age and its getting difficult to maintain, apart that some of the features are currently broken, like the generation of images. Also is a pain to keep other set of metadata different from what GNOME release team uses (gnome-build-meta). I think we can develop something with gitlab-ci and gnome-build-meta to have a single point for that metadata

  • Requirements: yocto, ostree, buildstream, gitlab-ci, and general devops experience will help

  • Communication: jjardon on #release-team on irc.gnome.org

Untriaged Ideas

  • Usage: Add GPU panel (mentor: carpediem, co-mentor: To be decided)

  • Brief explanation: Develop a GPU panel to display information about available video hardware, processes utilizing the resource, available memory status etc.

  • Requirements: C, Vala, little knowledge about GPU hardware and APIs would be nice but not mandatory.

  • Communication: carpediem in #gnome-hackers, #newcomers, #usage on irc.gnome.org

  • Notes: https://gitlab.gnome.org/GNOME/gnome-usage/issues/16 is a good starting point for discussions. Depending on the proposals, timelines and slot availability etc., the idea may be drawn out into separate projects or have multiple students.

  • Proof of Concept: Survey for available APIs, existing open-source implementations and/or proprietary offerings, potential mockups for the panel

  • Bonus: Provide information relevant for training deep neural networks, machine learning and cryptocurrency mining. Depending on availability of data, this can include power draw of GPU, temperature, locked video memory, number of (CUDA?) cores in active use by a process, determining when and how memory is overflowing, storing stack trace in case of overflow etc. Also consider the use case for systems with multiple GPUs, external GPUs and how to display that information. Feel free to consider any other out-of-the-box use cases and potential applications.


  • BuildStream: Add BuildStream plugin to gnome-builder (mentor: buildstream maintainers)

  • Brief explanation: gnome-builder is the default GNOME IDE. I think integration with buildstream will give it interesting capabilities like sandboxed builds, reproducibility, using of a external cache to store artifacts ... etc

  • Requirements: GTK+, gnome-builder code base, buildstream, python

  • Communication: jjardon on #buildstream on irc.gnome.org


More Ideas

The following GTK projects are taking part in GSoC individually, feel free to check out their list of ideas: Inkscape, Pitivi, Synfig.


Past ideas: 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006, 2005.

CategoryGsoc

Outreach/SummerOfCode/2019/Ideas (last edited 2019-03-26 16:58:14 by MattiasBengtsson)