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 consist of manageable and relevant tasks that the student can land 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 [No longer taking 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 [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 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
Nautilus: Improve search (mentor: CarlosGarnacho, co-mentor: CarlosSoriano)
Brief explanation: We improved search quite a lot in the last releases, we implemented a new UI with filters and make the search performance better. However it still needs the last step to be the best file manager search. The task will involve:
- Expose more features of Tracker into Nautilus. For example FTS (Full Text Search).
- Improve the search made from gnome-shell. We currently don't have a way to stop the search when the user stop searching on gnome-shell, and nautilus keeps going. The task will be to do the Nautilus side of this.
Add what's missing in https://github.com/gnome-design-team/gnome-mockups/blob/master/nautilus/nautilus-next/search-filters-wires.png , that means to expose other file formats filters. Discussion with the design team will be part of it.
- Improve search performance, debuggability and testing. Make sure that we do the best possible to show the most important results to the user.
- Improve the type-ahead use case to make sure those users are covered for most of the part that type-ahead was useful for.
- Make patches for tracker if something is missing.
- Create code for fixing bugs in the search of Nautilus. Tasks in here can be found searching on Bugzilla about the search of Nautilus. We will decide together which ones are the most important for the project.
Requirements: C. GObject and Tracker are a plus.
Communication: IRC as garnacho (CarlosGarnacho) or csoriano (CarlosSoriano) on #nautilus at irc.gnome.org.
Note: You can read where the code of search starts from.
Nautilus: Rework thread management of operations (mentor: CarlosSoriano)
Brief explanation: Currently we are not using a thread pool or GObject for operations, making it difficult to interacting with other parts of nautilus through signals and allowing the operations to overflow the computer spawning threads. With the rework of the operations to a single thread pool and with GTask operations of Nautilus will benefit performing better, avoiding races and not locking up the computer.
Requirements: C, GObject and GLib file operations, including GTask.
Communication: Mainly IRC as csoriano on #nautilus at irc.gnome.org
Note: You can read the current code of operations management
Nautilus: Modernize backend and improve developer experience (mentor: CarlosSoriano)
Brief explanation: Nautilus is an app with long history, that reflects in what tools are used for the code itself and the backend. The idea of this project is to modernise those tools to improve the maintainability and the general quality of code of Nautilus. These tasks include porting from old libraries inside nautilus to known external libraries, improve performance of some widgets, critical strategic bugs, etc. This project will benefit greatly the maintainability and developer experience of Nautilus to ensure a good future for it.Specifically the TODO list is:
- Port to gtk4
- Port from eel
- Finish the separation of the desktop part of Nautilus
- Convert code UI to .ui files
- Reorganize folder structure of Nautilus
- Some of the tasks marked as milestone 3.24 and 3.22 in Bugzilla (TBD which ones are relevant to the project).
Requirements: C. GLib is a big plus.
Communication: Mainly IRC as csoriano on #nautilus at irc.gnome.org
Pitivi: Color correction interface with color wheels (mentors: Alexandru "aleb" Băluț, Thibault "thiblahute" Saunier)
Brief explanation: Currently, the UI for configuring an effect applied to a clip is generated dynamically. Having a custom UI for some effects would improve the end user experience a lot. The first goal would be to add a custom UI mechanism for effects. Building on that, the second goal would be to have a custom UI for the color correction effect, which is extremely important for a video editing application.
Requirements: Python. Minimal experience contributing to Pitivi.
Communication: The Pitivi community has many members who are knowledgeable about the project, just join the #pitivi channel on Freenode and ask your question!
Note: Relevant task: T2372. For details see GSoC with Pitivi.
Pitivi: Slow-motion video (mentors: Alexandru "aleb" Băluț, Thibault "thiblahute" Saunier)
Brief explanation: Currently it’s possible to change a clip’s speed in GES, Pitivi's backend, but the keyframes applied to the clip are not updated accordingly. The first goal would be to complete the GES implementation. The second goal would be to allow specifying a clip’s speed using a very simple UI and make sure it’s displayed correctly in the timeline.
Requirements: C, Python. Minimal experience contributing to Pitivi. Experience with GStreamer would be a big plus.
Communication: The Pitivi community has many members who are knowledgeable about the project, just join the #pitivi channel on Freenode and ask your question!
Note: Relevant task: T2344. For details see GSoC with Pitivi.
Pitivi: Scaled proxies (mentors: Alexandru "aleb" Băluț, Thibault "thiblahute" Saunier)
Brief explanation: Currently it’s possible to generate and use high-quality proxies (AKA optimized-media) in Pitivi. These are intended to be used instead of the original material when editing and also when rendering the final media file. While editing, the user should be able to work with low-quality scaled proxies, mainly for performance reasons. The first goal would be to allow the user to specify an encoding profile for the low-quality proxies. The second goal would be to allow generating the low-quality proxies and using them in the project while editing.
Requirements: Python. Minimal experience contributing to Pitivi.
Communication: The Pitivi community has many members who are knowledgeable about the project, just join the #pitivi channel on Freenode and ask your question!
Note: Relevant task: T2455. For details see GSoC with Pitivi.
Pitivi: Plugins (mentors: Alexandru "aleb" Băluț, Thibault "thiblahute" Saunier)
Brief explanation: This is an exploratory project. Since Pitivi is in Python, it will be relatively easy for anybody to write a plugin which changes how it works, or extends its functionality. The first goal would be to investigate what options there are for having plugins which extend Pitivi’s functionality and document them, detailing how the plugins can be discovered and installed. The second goal would be to implement Pitivi’s plugins framework and document it for plugin writers. A stretch goal would be to setup a semi-automated process for generating and publishing Pitivi’s API so it can be used by plugin writers.
Requirements: Python. Minimal experience contributing to Pitivi. Experience with another Python app using plugins would be a big plus.
Communication: The Pitivi community has many members who are knowledgeable about the project, just join the #pitivi channel on Freenode and ask your question!
Note: Relevant task: T3193. For details see GSoC with Pitivi.
Pitivi: Integrate the welcome dialog into the main window (mentors: Alexandru "aleb" Băluț, Thibault "thiblahute" Saunier)
Brief explanation: Currently when Pitivi starts it shows a Welcome dialog which lists the recent projects. The first goal would be to integrate this dialog into the main window, similar with how Builder does it. This will provide a nicer user experience since there is more space for displaying the projects. The second goal would be to generate and display thumbnails for the projects shown at the start.
Requirements: Python. Minimal experience contributing to Pitivi.
Communication: The Pitivi community has many members who are knowledgeable about the project, just join the #pitivi channel on Freenode and ask your question!
Note: Relevant task: T3015. For details see GSoC with Pitivi.
Pitivi: UI for the Ken Burns effect (mentors: Alexandru "aleb" Băluț, Thibault "thiblahute" Saunier)
Brief explanation: The Ken Burns effect is a type of panning and zooming effect used in video production from still imagery. Currently it's possible to keyframe the x, y, width, height properties of clips in GES, Pitivi's backend. The first goal would be to expose this functionality through Pitivi's GTK+ UI, as simple as possible. The second goal would be to make it useful by allowing interacting with the viewer to specify the clip's position at different points in time.
Requirements: Python. Minimal experience contributing to Pitivi.
Communication: The Pitivi community has many members who are knowledgeable about the project, just join the #pitivi channel on Freenode and ask your question!
Note: Relevant task: T7340. For details see GSoC with Pitivi.
Games: Gamepads and Keyboard Configuration (mentor: AdrienPlazas)
Brief explanation: Add a way to graphically and easily set a gamepad or a keyboard up to use in games. Stretch goals could be offering the user to share their gamepad mappings with us and to compare the standard gamepad to the emulated one. These changes could:
- allow us to support any or most gamepads and to improve our gamepad bindings database;
- allow the user to set its keyboard as desired;
- allow the user to understand how his gamepad maps to the emulated gamepad.
Requirements: Vala. Knowledge of GObject, GTK+, GtkBuilder or SVG would be a big plus.
Communication: Mainly IRC as Kekun on #gnome-games at irc.gnome.org
Note: Design page. Some resources regarding SVG layouts: layouts from libwacom, old GTK+ based implementation.
Games: Advanced Video Display (mentor: AdrienPlazas)
Brief explanation: Create a new Libretro core display rendering the video in a hardware accelerated way and allowing us to apply advanced effects to the video, like simulating CRT TVs.
Requirements: Vala, OpenGL. Knowledge of GLSL would be a big plus.
Communication: Mainly IRC as Kekun on #gnome-games at irc.gnome.org
Games: Control the Application with Gamepads (mentor: AdrienPlazas)
Brief explanation: Allow to control the application with the same input you will you to control you game: the gamepad. This implies thinking how to control the UI in a very different way, adapted to such input devices.
Requirements: Vala.
Communication: Mainly IRC as Kekun on #gnome-games at irc.gnome.org
- Note: Long discussions with the designer team are to be expected.
Games: Make the Nintendo DS a First Class Citizen (mentor: AdrienPlazas)
Brief explanation: The Nintendo DS has two screens, one of them being a touchscreen. To make it work really well we need to take into account all its specificities:
- having multiple screen configurations: both screens, focusing on one screen…;
- adding touch support;
- allowing to rotate the screens for games expecting you to rotate the console;
- allowing to close the lid of the console (some games require you to do so to solve enigmas);
- map the touch screen to an analog stick.
Requirements: Vala. Knowledge of GObject and GTK+ would be a plus.
Communication: Mainly IRC as Kekun on #gnome-games at irc.gnome.org
Calendar: Add support to recurrent events (mentor: GeorgesNeto)
Brief explanation: GNOME Calendar lacks support to recurrency, which is a much needed and requested feature. This project encompasses three major tasks: (i) add support to recurrency in GcalEvent, (ii) add the necessary widgets to GcalEditDialog and (iii) add a rudimentary support for tests (optional).
Requirements: C. GLib & Gtk+ are a big plus.
Communication: IRC as feaneron on #gnome-calendar at irc.gnome.org, plus weekly meetings
Calendar: Navigation sidebar (mentor: GeorgesNeto)
Brief explanation: GNOME Calendar's designers expressed interest in experimenting with a new sidebar-based layout. The sidebar would improve the browsing experience and the ability to recognize events. This project encompasses the following tasks: (i) create mockups for different versions of the sidebar, (ii) validate them with the designers and (iii) prototype the mockups. Testing the prototypes will be optional but highly desired, although it may be a separate project.
Requirements: C. GLib & Gtk+ and Design knowledge are a big advantage.
Communication: IRC as feaneron on #gnome-calendar at irc.gnome.org, plus weekly meetings
To Do: Todoist integration (mentor: GeorgesNeto)
Brief explanation: GNOME To Do supports custom backends, but currently no external service is integrated yet. This project is about integrating the Todoist service in GNOME To Do through the following steps: (i) add GtdTodoistProvider implementing the GtdProvider interface, (ii) add support for different accounts using GNOME Online Accounts and (iii) general bugfixing.
Requirements: C. GLib & Gtk+ are a big plus.
Communication: IRC as feaneron on #gnome-todo at irc.gnome.org, plus weekly meetings
Logs: Search improvements (mentor: DavidKing and JonathanKang)
Brief explanation: GNOME Logs is a systemd journal viewer for GNOME, and during GSoC 2016 saw several improvements to search. This project is concerned with building upon the improvements and providing a faster and more consistent search experience, such as by completing the GNOME Shell search provider, and collapsing multiple log entries into one. Several bugs in the search model code will need to be fixed, and a complete test suite to validate the new search model features would also be useful.
Requirements: C experience. Knowledge of systemd, GLib and GTK+ an advantage.
Communication: IRC in #gnome-hackers on irc.gnome.org preferred, email or other methods also possible
Evolution: Port Evolution to gpgme (mentor: TobiasMueller and Tong Hui)
Brief explanation: Evolution has its own gpg abstraction instead of using the official gpg library, gpgme. This causes trouble in certain situations like we saw with the switch from gpg1 to gpg2. This project is about porting Evolution to gpgme to get rid of its own process babysitting code. You will be (i) analysing the gpg functionality desired by Evolution, (ii) writing prototypes, (iii) provide detailed information in case things go wrong.
Requirements: C. Gtk+ is an advantage.
Communication: IRC as muelli on #safety, plus weekly meetings via voice chat.
Keysign: Alternative Key transports [No longer taking applicants] (mentor: TobiasMueller and AndreiMacavei)
Brief explanation: Currently, GNOME Keysign transfers keys via a wireless network. This requirement can be challenging in certain situations where the network does not allow clients to connect to each other. The idea now is to use, e.g. Bluetooth or Magic Wormhole to transfer a key. This project encompasses the following tasks: (i) implement a bluetooth and wormhole sender and receiver, (ii) ensure that the data has not been tampered with, and (iii) provide enough details in error cases so that the user can recover from them.
Requirements: Python. Gtk+ is an advantage.
Communication: IRC as muelli on #safety, plus weekly meetings via voice chat.
[No longer taking applicants]Mutter Wayland without X11 (mentor: CarlosGarnacho and JonasAdahl)
Brief explanation: Eventually mutter (and gnome-shell) using Wayland should not require an Xwayland X11 server instance to run, and Xwayland stopping should not bring the compositor down with it. This project aims to take the first steps towards this goal by adapting mutter to manage to run without Xwayland while also being able to survive Xwayland crashing or restarting.
Requirements: C. Wayland, X11, GLib & Mutter experience are big advantages.
Communication: IRC as garnacho or jadahl on #gnome-shell at irc.gnome.org and gnome-shell mailing list.
Builder: Code Search (mentor: ChristianHergert)
Brief explanation: Objective of this project is to improve code navigation and global search in Builder. An indexer has to be implemented which will create 'Code Search Index'. And using that index, 'Jump to Definition' and 'Global Search' of symbols has to be implemented. Three tasks in this project are: implementing indexer in Builder which will create Code Search Index of projects. Implementing Jump to definition, where definition can be in any file in the project. Implementing Global Search, using which any symbol in the project can be searched.
Requirements: GLib/GObject/Gtk and C. Experience with Clang a plus.
Communication: IRC as hergertme on irc.gnome.org, plus email
Builder: Word Completion (mentor: ChristianHergert)
Brief explanation: The word completion engine in Builder needs to be improved to support sorting words by their relative distance from the insertion cursor. This will allow for quickly autocopmleting words based on their relative use in a function. As storing words from all open files can take a considerable amount of memory, it is expected the student researches novel techniques to balance search performance and memory overhead.
Requirements: GLib/GObject and C. Experience with search algorithms a plus.
Communication: IRC as hergertme on irc.gnome.org, plus email
[No longer taking applicants] Gaming mouse configuration application (mentor: PeterHutterer)
Brief explanation: libratbag is a library to provide generic access to configurable gaming mice and comes with a DBus server (ratbagd). What it lacks is a userfriendly GUI. This project proposes designing and implementing that GUI to make it possible to configure gaming mice from a GNOME desktop. Some work on the plumbing layer may be necessary.
Requirements: C or Python for the GUI, Gtk+, C for any plumbing work required. Knowledge of DBus is an advantage.
Communication: IRC as whot on irc.gnome.org, plus weekly meetings
[No longer taking applicants] Disks: Resize and fix filesystems (mentor: OndrejHoly, co-mentor: Vratislav Podzimek)
Brief explanation: Disks has only seen minor development recently and needs support for resizing and fixing filesystems in order to fully replace GParted which runs only as root and not under Wayland. A good part, but not all, for this is already covered in libblockdev which UDisks started to link to, and support for it has to be worked out as D-Bus API (other projects using UDisks might also benefit). The UI for these features in Disks should enable unexperienced users to safely accomplish their task.
Requirements: C. GObject, GTK, D-Bus, filesystems are a plus.
Communication: oholy at #nautilus in irc.gnome.org
- Note: has an applicant
Untriaged Ideas
GDK-Pixbuf improvements (mentor: BastienNocera)
Benefits: make GDK-Pixbuf better/smaller, to ease the long-term goal of moving away from it
- This is a 2-part project:
- ICO/BMP code sharing: Both uncompressed ICO and BMP use the same DIB format, though the headers are different. There's quite a few pieces of code that could be shared. Patches to share structures between both would be a good first patch contribution, which we now require for GSoC at least. This would be useful to become familiar with the pixbuf loaders.
- Use giflib to load GIF files: Again, the gif loader is kind of hard to read and maintain and giflib seems to be well maintained. It would start with a new loader, which we could force load and check that it can pass all the test cases we have for the home-made GIF loader, and then use it to fix the additional bugs.