Contents
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
Fractal: Multi account support (mentor: DanielGarcia, co-mentors: team)
Brief explanation: Fractal currently supports only one account, if you want to be connected at the same time with different accounts the user has to launch several instances. You will implement multi account support in the client so users can have more than one account connected at the same time with a user friendly interface. You will need to work with GNOME's design team to come up with the interface. To add multi account support first of all we should work on the backend code to make it more client independent, then we can work on the interface.
Requirements: Familiarity with Rust and GTK
Communication: #fractal-gtk:matrix.org on Matrix is used for communication by the team. New contributors are expected to be available here.
Evolution Data Server: EteSync sync module (mentor: MilanCrha and TomHacohen)
Brief explanation: EteSync is a secure, end-to-end encrypted and FLOSS sync solution for your contacts, calendars and tasks. There are are clients for Android, iOS, the desktop (Cal/CardDAV bridge) and the web, and a Thunderbird plugin is in the works. You will implement an EDS module that will enable GNOME/Evolution users to easily end-to-end encrypt and sync their contacts, calendars and tasks.
Requirements: Be able to code in either Rust, C, or C++.
Communication: mostly IRC (#evolution @ irc.gimp.org) and email.
Note: MilanCrha is one of the developers of Evolution Data Server, and TomHacohen is one of the developers of EteSync. They will be mentoring together.
Note: EteSync's sources: https://github.com/etesync (clients and server).
Games: Add Collections (mentor: AlexanderMikhaylenko)
Brief explanation: Make Games automatically generate collections and let the user create their own ones. You will work on the backend and also with the GNOME design team to create a new user interface.
Requirements: Familiarity with Vala and GTK. SQL would be a plus.
Communication: Alexander Mikhaylenko in #gnome-games:gnome.org
Games: Add UI for importing and managing firmware (mentor: AlexanderMikhaylenko)
Brief explanation: Allow to manage firmware in preferences, add automatic drag-n-drop install. You will work with the GNOME design team to create a new user friendly interface.
Requirements: Familiarity with Vala and GTK.
Communication: Alexander Mikhaylenko in #gnome-games:gnome.org
Note: See issue #145.
GTK/libhandy: Adaptive Grid/Form Widget (mentor: Adrien Plazas)
Brief explanation: libhandy is a library full of adaptive GTK widgets, helping applications to be usable at any window and screen size. Application windows with large grids of information or forms often cannot be made small enough to work on phones. The goal is to write a generic grid widget to help them rearrange the information to work well at different sizes.
Requirements: Being comfortable developing with GTK+ in C
Communication: #libhandy:talk.puri.sm on Matrix (Fractal is a good client)
Sound Recorder: Redesign the app to make it adaptive (mentor: Bilal Elmoussaoui, Felipe Borges)
Brief explanation: Sound Recorder's main window UI has not been updated to follow the latest design patterns. The project is about redesigning the UI to make it fit in smaller screen sizes as well. You will work with GNOME's design team to implement the changes.
Requirements: Familiarity with GTK
Communication: https://chat.gnome.org/channel/sound-recorder
GNOME Shell: Notification Popover Redesign (mentor: Florian Muellner)
Brief explanation: Revamp of the Shell notifications popover. This includes making actions being available in the popover, adding app grouping, and various other visual and layout issues.
Requirements: Familiarity with Javascript
Communication: #gnome-design and #gnome-shell on IRC/Matrix
Music: Support remote sources (mentor: JeanFelder)
Brief explanation: Music is not able to display songs or albums from a remote source (DLNA, DAAP, etc.). The project consists of integrating the content of the remote sources in the main views (Album, Song, and Artist views). Then, the search view needs to be redesigned to integrate search results from online sources (such as jamendo).
Requirements: Familiarity with Python and C
Communication: ptitjano in #gnome-music on irc.gnome.org
Geoclue: Port service code to Rust language (mentor: ZeeshanAli)
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-hackers:matrix.org or #_gimpnet_#gnome-maps:gnome.org on Matrix, or email.
Note: More details: https://gitlab.freedesktop.org/geoclue/geoclue/issues/103
Nautilus: redesign Preferences dialog (mentor: António Fernandes)
Brief explanation: The Nautilus preferences are looking a bit old and crufty, and in need of a redesign. The same goes for some of the dialogs (e.g. file/folder properties). This project would update the design of these dialogs to new adaptive design patterns (e.g. listboxes). As a side benefit, this redesign would enable these dialogs to work on narrower screens (i.e. mobile).
Requirements: Familiarity with GTK
Communication: antoniof on #nautilus (irc.gnome.org)
Network Displays: Implement further streaming protocols (mentor: BenjaminBerg, ?)
Brief explanation: Network Displays is an application that supports Miracast revision 1 to driver wireless displays. There are further popular devices that allow streaming in this way like the Chromecast or Apple AirPlay. The task would be to implement protocol support for one or more of these protocols and possibly improve the existing pipelines. https://github.com/benzea/gnome-network-displays/issues/18
Requirements: Familiarity with GStreamer; availability of device(s) for testing purposes
Communication: ?
gitg: Polish files plugin (mentor: AlbertoFanjul, co-mentors: team)
Brief explanation: gitg is able to show the files involved in each commit, but navigation through them is not smooth and easy to use. You will work with the design team to prepare and execute a usability test to identify which changes are needed. You will then implement the solution with the aim of merging it into the app for the next release.
Requirements: Vala, C, GTK+ and libgit2.
Communication: #gitg:matrix.org on Matrix is used for communication by the team. New contributors are expected to be available here.
gitg: Differences between two non-consecutive commits (mentor: AlbertoFanjul, co-mentors: team)
Brief explanation: As a git history reviewer, gitg lacks a comparison between non-consecutive commits. That would be really useful and will expand the tool usage. You will need to expand the libgit2 exposed API to implement this feature.
Requirements: Familiarity with Vala, GTK+ and libgit2.
Communication: #gitg:matrix.org on Matrix is used for communication by the team. New contributors are expected to be available here.
GNOME.org: Evaluation of requirements, content, design and components for the refresh of the website. (mentor: ClaudioSantoro, co-mentors: Engagement Team, co-mentors: NeilMcGovern, Caroline Henriksen)
Brief explanation: The GNOME.org website needs a redesign (refresh) both in design terms and look-and-feel (UI) terms. This project is about the technical and content-wise evaluation for a possible refresh of the GNOME.org website. This project would include the assessment of the current state of GNOME.org by its content and then a full evaluation of design-wise and content-wise changes.
Goals: Our goals within this GSoC project are the assessment of current GNOME.org followed by an evaluation of a future GNOME.org website. Including also a development of a UI library (Framework) made of UI components (Colours, Grid, Buttons, Containers, etc) that would be used as building bricks (Foundation) for the next GNOME.org website.
Requirements: Good communication skills, observational skills and writing skills are a plus. Experience with SCSS/Sass, ES6 (JavaScript/EcmaScript) is also welcome. Having experience with Node.js, Static-Page-Generators like Jekyll and other web development tools are also a big plus.
Communication: The announcements will be made on Discourse. Our internal communication will be done through our Rocket.Chat (https://chat.gnome.org) on the channel #outreach. GitLab will be used for planning, issues discussion and development. We may also use additional video-conference tools and/or communicate also through e-mails.
Fonts (Lettercase): enhance the UI and featureset (mentors: FelipeBorges, Bilal Elmoussaoui)
Brief explanation: Lettercase is a brand new app with few font management features. This project would make the app much more useful by adding missing features and making the UI more elaborate and useful. See https://wiki.gnome.org/Design/Apps/Fonts
Requirements: Familiarity with GTK and Rust
Communication: issues are tracked on Gitlab project, communication can happen in the #gnome-design IRC channel or #design on chat.gnome.org
Librsvg: Revamp the text engine (mentor: FedericoMenaQuintero)
Brief explanation: Librsvg supports only a few features of the SVG Text specification. It requires extra features, like proper bidirectional support for right-to-left text, and fine typographical control.
Requirements: Rust for programming language; some familiarity with Unicode concepts and text layout. Familiarity with Cairo and Harfbuzz would help a lot. Preference will be given to people who can write a right-to-left human language, or a language that requires complex shaping.
Communication: #rust on irc.gnome.org (look for federico there), or mail to mailto:federico@gnome.org, or chat.gnome.org
Notes:
Epiphany: Improve Dialogs (mentor: MichaelCatanzaro and JanMichaelBrummer) [Many strong applicants]
Brief explanation: this project consists of making design improvements to the preferences dialog, history dialog, and bookmarks popover.
Requirements: experience with GObject and GTK
Communication: IRC, Matrix
Builder : Redesign project-wide search (mentor: Umang Jain, co-mentor:team)
Brief explanation: The "Find in Files" feature in Builder works, but the UI and workflow is not great at the moment (https://gitlab.gnome.org/GNOME/gnome-builder/issues/941). The project is to work with the design team on coming up with a new workflow/layout, and implementing it in Builder.
Requirements: Familiarity with GTK
Communication: #gnome-builder
Geary: Implement Message List Redesign (mentor: ?)
Brief explanation: Implement a shiny new design for the message list (https://gitlab.gnome.org/GNOME/geary/issues/414). Depending on how much time this takes, some other areas of Geary could also be redesigned (e.g. the conversation list https://gitlab.gnome.org/GNOME/geary/issues/391 or conversation actions https://gitlab.gnome.org/GNOME/geary/issues/413)
Requirements: Familiarity with GTK
Communication: ?
developer.gnome.org: Revamp the HIG and GNOME Developer Docs (possible mentors: Allan Day and/or Emmanuele Bassi)
Brief explanation: Redesign and revamp the HIG and GNOME Developer Docs website by bringing the documentation of GNOME hosted projects at a single place, put in place a static site generator and revamp its UI. Features such a Progressive Web App, Dark Mode, and printable PDFs can also be added as a bonus.
Requirements: Familiarity with Static Site generators, basic Frontend Web Development, HTML, CSS/SASS, JS, Gitlab REST API, Gitlab CI/CD
Communication: IRC/Matrix
More Ideas
The following GTK projects are taking part in GSoC individually, feel free to check out their list of ideas:
Past ideas: 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006, 2005.