Contents
1. 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.
2. 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.
2.0.1. 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 [Many strong applicants] next to your idea if you have already too many strong applicants.
2.0.2. 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 ----
3. Accepted Ideas
ExampleApplication: Improve Example Application (mentor: FelipeBorges, co-mentor: CarlosSoriano)
Brief explanation: A brief description of the implementation details required to complete the project.
Requirements: Programming language X, library Y, framework Z.
Communication: csoriano and feborges in #gnome-hackers at irc.gnome.org.
- Note: Some example.
To Do: Remember The Milk® integration (mentor: GeorgesNeto)
Brief explanation: We want to integrate GNOME To Do with the online personal task management service Remember The Milk®.
Requirements: C, GLib, GObject and GTK+ are the requirements.
Communication: feaneron in #gnome-todo at irc.gnome.org or Matrix.
GJS: Promises for Asynchronous Operations (mentor: PhilipChimento)
Brief explanation: We want to make it so that asynchronous operations in GJS use Promises and async/await as is expected in modern Javascript, instead of the "Pyramid of Doom" of nested callbacks. This requires work in gobject-introspection but will unlock this feature for both JS and Rust.
Requirements: C, Python, Javascript. Knowledge of GObject a plus. I don't know Rust but if you wanted to get this working in GObject Rust bindings I would also try to help.
Communication: ptomato in #gnome-hackers at irc.gnome.org or Matrix.
Note: Background is at 623635
GJS: Reference example application (co-mentor: PhilipChimento, co-mentor: tbd)
Brief explanation: An app that exhibits modern Javascript usage and leverages our platform including Builder for development, Flatpak for packaging, Flathub for distribution, accompanied by documentation on how to achieve all of this.
Requirements: Javascript, document formatting language such as Markdown
Communication: ptomato in #gnome-hackers on irc.gnome.org or Matrix
Rygel DLNA suite: Implement synchronized playback (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 irg.gnome.org
Note: Bug with a couple of links is at 757681
GNOME LaTeX: make the application ready for GTK+ 4 and improve auto-completion (mentor: SébastienWilmet)
Brief explanation: no longer use deprecated GTK+ APIs and improve some features (e.g. LaTeX command completion). Benefits for GNOME: having a well-maintained LaTeX editor for GNOME.
Requirements: the student needs to already have experience with LaTeX, C and ideally GLib/GTK+ too.
Communication: swilmet in #gnome-latex on irc.gnome.org or the mailing list of the project.
Note: GNOME LaTeX also contains Vala code, so be prepared to learn that language if not already done. During the GSoC you will also probably need to contribute to underlying libraries, especially Amtk/Tepl, to have re-usable code.
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: Kekun in #gnome-games on 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: Kekun in #gnome-games 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.
Requirements: C, GObject (and GTK+) is a plus, some understanding of power would be awesome.
Communication: gicmo on #gnome-hackers on irc.gnome.org
Pitivi: Slow-motion video (mentor: ThibaultSaunier)
Brief explanation: The implementation of this feature in GES, Pitivi's backend, is very basic. The first goal would be to complete it, to support keyframes. The second goal would be to update Pitivi's UI to allow specifying a clip’s speed in a simple way.
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: 632. Read more about what we offer and what we are looking for.
Pitivi: Scaled proxies (mentor: ThibaultSaunier)
Brief explanation: Currently it’s possible to generate and use high-quality proxies (AKA optimized-media) in Pitivi. These can 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 instead, 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: 743. Read more about what we offer and what we are looking for.
Brief explanation: This is composed of two main tasks. Currently when Pitivi starts, a Welcome dialog which lists the recent projects appears. This dialog should be integrated into the main window, similar with how the GNOME Builder does it. This will provide a nicer user experience since there is more space for displaying the projects. If we manage to find a good idea about how to generate thumbnails for the projects shown at the start, this would be useful. The second task would be to allow easy resizing of the viewer.
Requirements: Python, eye for detail. 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 tasks: 1302, 1816. Read more about what we offer and what we are looking for.
Pitivi: Effects improvements (mentor: Mathieu Duponchelle)
Brief explanation: The main task would be to improve the Effects discovery experience, and find a way to make easily accessible a set of whitelisted effects, as well as the effects used often by the user. Depending on what ideas we explore and how much this takes, a potential second task is related to the effects UI consistency. Currently the UI for configuring an effect applied to a clip is generated automatically, except for a few effects. Quite a few effects allow specifying a color and the UI is far from optimal. These should all use the same polished widget for selecting or specifying a color.
Requirements: Python, eye for detail. 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: 2146 966. Read more about what we offer and what we are looking for.
Brief explanation: The main task would be to improve the Render experience. The Render dialog has options the users should not need to care about. This will be an exploratory task, in close contact with the GNOME Designers team. In addition, the experience when using the encoders settings dialog can be improved for important encoders.
Requirements: Python, eye for detail. 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: Read more about what we offer and what we are looking for.
Pitivi: Render queue (mentor: Mathieu Duponchelle)
Brief explanation: Currently when starting a render, the edit functionality is blocked until the render is done. The main task would be to render in the background. The second task would be to have a render queue.
Requirements: 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: Read more about what we offer and what we are looking for.
Pitivi: Render only a portion of the timeline (mentor: AlexBăluț)
Brief explanation: The user should be able to specify an interval on the timeline, and be able to render only that.
Requirements: 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: 1006. Read more about what we offer and what we are looking for.
Books: Improve the epub support in gnome-books (mentor: DanielGarcia)
Brief explanation: There's a basic epub support in gnome-books and this can be improved with a set of changes.
Proposed Tasks:
- Ability to change styles: We can improve the epub support being able to change the book styles to change the background and text color, text flow, how images are shown, etc.
- Two pages mode: The libgepub provides a simple widget with paginate support but in wide screens we want to show two pages at the same time, like a book and improve reading experience.
- Fixes in page management and navigation: Currently there's a *chapter* navigation and a *page* view, but that can be improved in several ways, we can add the number of pages in the book (that depends on the window side, but it can be calculated), the reading estimated time.
- List of chapter for navigation: We can add the list of chapter to the menu to make the navigation easier
- Bookmarks: We can add a way to store bookmarks and a list of bookmarks to navigate in a book back and forward
Requirements: Javascript and C programming and some knowledge of css and styles. Gobject knowledge is a plus because this work requires some work inlibgepub.
Communication: All the communication should go in the #documents channel in the GNOME IRC
Fractal: Fractal UI redesign and new dialogs (mentor: DanielGarcia)
Brief explanation: Fractal is a really new app and currently have a simple interface. Some parts have been redesigned to make it easier to use and beautiful, but there's more task to do to have a great interface.
Proposed Tasks:
User settings dialog: There's now way to change your Matrix.org user settings in Fractal, this is a main functionality to have in the client, so we should provide a dialog to change username, avatar, email and all personal data. There's a bug with design for this: https://gitlab.gnome.org/danigm/fractal/issues/21
- Redesign the room directory: Currently there's a basic room search that shows a list for result, but it's ugly, that should be redesigned.
- Show user details in the user popover
- Improve the room details dialog showing more information
- Redesign the messages history: There's a work in progress design for the messages history redesign, there's more gtk design work to be done there.
Requirements: Rust programming languange and Gtk+.
Communication: All the communication should go in the Fractal room in Matrix.org, #fractal-gtk, https://matrix.to/#/#fractal-gtk:matrix.org
Fractal: Support for all kind of messages (mentor: DanielGarcia)
Brief explanation: Fractal currently supports text messages, and images and attachments have a basic support, we're open them with xdg-open. It could be great to support all kind of messages: m.emote, m.notice and m.location and provide an integrated way to show m.image, m.file, m.video and m.audio.
Requirements: Rust programming languange, Gtk+ knowledge is a plus.
Communication: All the communication should go in the Fractal room in Matrix.org
Nautilus: Implement test, profile and debug framework (mentor: CarlosSoriano)
Brief explanation: Nautilus is mostly lacking in test, profiling and debug capabilities. This project would be to ensure we have proper tests, a good code coverage, and a good framework for debugging and profiling together with our GitLab CI.
Requirements: C, gcov, perf, and other profiling and testing tools.
Communication: csoriano in #nautilus on irc.gnome.org
Notes: Discussions around the idea in GitLab
Logs: Responsive updates (mentor: DavidKing and JonathanKang)
Brief explanation: Logs currently does not update the view when new log messages are added to the journal. Fixing this should also make it easier to fix several other bugs, such as showing notifications when certain other messages appear in the journal, as well as improving search filters.
Requirements: some C, GTK+ knowledge
Communication: amigadave and jkang on #gnome-hackers on irc.gnome.org
Note: several relevant bugs, including https://bugzilla.gnome.org/show_bug.cgi?id=753471
Five or more: Modernization (mentor: RobertRoth)
Benefits: Five or more is looking pretty old and needs a revamp both on the interface and in the sources.
Requirements: Experience with C, Vala, and GObject programming; previous contributions to GNOME (games or application); and experience designing a significant programming project
Communication: evfool[m] on #gnome-hackers on irc.gnome.org
Note: Before coding begins, we'll work with a designer to come up with a modern design for this game. The code is old and organized into a couple of files, so your first task will be to rewrite the application in Vala. This will be difficult for new programmers to do well, so this project is better suited to more experienced students. As you go, you'll take special care to do a separation between the game model and the view for the UI to be less dependent on the model and to be able to easily update/rewrite later on. Lastly you will make use of the gnome games support library for keeping track of high-scores instead of a custom potentially buggy scores tracking.
Fleet Commander: Fleet Commander Integration with Active Directory using GPOs (mentors: OliverGutierrez, co-mentor: FabianoFidencio)
Brief explanation: Fleet Commander is a system to manage GNOME in large deployments to ease management of desktop configuration in environments with many users with multiple needs. Integrating Fleet Commander with Active Directory would allow GNOME to seamlessly coexists within Microsoft Windows deployments in large institutions like universities, government and big companies, easing the migration towards a Free Software setup.
Requirements: Decent knowledge of Python programming. Familiarity with LDAP, Windows environmens (Samba/CIFS shares) is a big plus.
- Note: The goal is to write a Python module integrated with the Fleet Commander internal API that allows it to communicate with Active Directory to access users, groups and other resources, and to publish the desktop configuration
Fleet Commander: Fleet Commander: Logging the history of changes done on a Desktop Profile (mentors: FabianoFidencio, co-mentor: OliverGutierrez)
Brief explanation: Fleet Commander is a system to manage GNOME in large deployments to ease management of desktop configuration in environments with many users with multiple needs.Having a way to check the history of changes done on Desktop Profiles would help sys-admins to better audit the Profiles which are going to be deployed.
Requirements: Decent knowledge of Python programming. Familiarity with LDAP or FreeIPA is a big plus
Communicaton: #fleet-commander and #freeipa, both at freenode.org
Note: The goal is to write a Python plugin for FreeIPA (thus, Stanislav Láznička would be the contact person on FreeIPA side), which would help sys-admins to audit changes done in a Desktop Profile. Also, interaction with Cockpit and Fleet Commander team would be needed in order to have those changes presented to the admins in the Fleet Commander Cockpit's plugin.
To Do: Make Todoist and Todo.txt integration shine (mentor: GeorgesNeto)
Brief explanation: GNOME To Do already has beta-quality Todoist integration, and alpha-quality Todo.txt integration. This project is making these data providers production-quality. This is essentially a bugfix and feature parity project. This project encompasses the following features and fixes:
- Todoist: network monitoring; automatic synchonization; move authentication out of GNOME Online Accounts;
- Todo.txt: reimplement subtask support; add support for comments; asynchronously update the file; document GNOME To Do's Todo.txt format;
Requirements: C, GLib, GObject and GTK+ are the requirements.
Communication: feaneron in #gnome-todo at irc.gnome.org or Matrix.
Boxes: Import & export of VMs (mentors: FelipeBorges)
Benefits: While Boxes allows for import of virtual machine disk images, it's not the best method to import a VM. We really need a proper method to export and import VMs and the industry standard seems to be OVF format. We've been meaning to implement that for many years now but just never got around to getting it done.
Requirements: Decent knowledge/experience of C. Vala and XML skills would be a definite plus.
Note: Most of the work is going to be implementation of a C library that transforms libvirt domains into OVA files and viceversa. Once this library works on a basic level, the next task would be to make it work in Boxes .
Evolution: Port Evolution to gpgme (mentor: TobiasMueller)
Brief explanation: Evolution has its own gpg abstraction instead of using the official gpg library, gpgme. In order to make it easier to implement a more modern cryptographic email experience like Autocrypt porting Evolution to gpgme will probably help.
Benefits: GNOME will benefit from using a contemporary gpg library by having a smaller and less fragile code base.
Requirements: Student needs to demonstrate strong knowledge of C and GNOME development. Some knowledge of gpgme is required. Gtk+ is an advantage.
Communication: IRC as muelli on #safety, plus weekly meetings via voice chat.
Games: Add Collections/Developer View (mentor: AbhinavSingh)
Brief explanation: Improve how we show games to the user.
- Allow the user to view games segregated by platform and developer.
- Show game metadata (e.g. description, rating, etc.) provided by Grilo to the user.
- Allow the user to save statistics such as playtime, finish status, etc.
Requirements: Vala, Gtk+, Grilo.
Communication: theawless in #gnome-games on irc.gnome.org
[Many strong applicants] Nautilus: Port to gtk4 (mentor: CarlosSoriano)
Brief explanation: With gtk4 around the corner we should port Nautilus to it for all the benefits it brings.
Requirements: C, gtk.
Communication: csoriano in #nautilus on irc.gnome.org
Notes: Discussions and expanded explanation for this task in GitLab
Music: Full stack MusicBrainz integration (mentor: MarinusSchraal)
Brief explanation: Make MusicBrainz and related services a first-class citizen in Music.
Retrieve and update tags from MusicBrainz based on AcoustId in Grilo (ties into this past gsoc)
Retrieve cover art from the coverart archive based on MusicBrainz ID
Implement ListenBrainz support in Music through GOA (if time permits)
Requirements: Python, C, SPARQL, lua.
Communication: foser (Marinus Schraal) in #gnome-music on irc.gnome.org
Notes: This would require changes and challenging those changes in several modules: Music, Tracker, Grilo and GNOME Online Accounts
Music: Implement importing/syncing music (mentor: MarinusSchraal)
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: foser (Marinus Schraal) in #gnome-music on irc.gnome.org
Notes:
GNOME Keysign: Bridge desktop app to the Web (mentor: TobiasMueller, co-mentor: LudovicoDeNittis)
Brief explanation: GNOME Keysign currently uses the laptop's screen and camera to display and scan a QR code. That is inconvenient for people who either do not have a webcam or chose to disable it. Also holding two laptops is front of each other is more awkward than with phones. This project is about implement a secure way of bonding the user's browser running on their phone with GNOME Keysign running on the laptop which in turn has access to the OpenPGP keys. The candidate needs to investigate how to securely connect a Web browser with an application on the desktop and how make them interact securely with low latency.
Benefits: GNOME Keysign is a modern helper for an old problem. By bridging it to the Web, we make the user-base much bigger and help to strengthen the Web of Trust. The ideal result of this project is a method and implementation of using remote APIs on the user's phone which will can benefit other GNOME apps (think: remote control your playlist, take snapshots for cheese from your phone, ...).
Requirements: Experience with Python and Web APIs
Communication: muelli in #safety on irc.gnome.org; weekly voice chats, e.g. via mumble
Meson: Improve refactoring tools (mentor: JussiPakkanen)
Brief explanation: IRefactoring tools are important productivity enhancements in modern software development. For a build system these include tasks such as programmatically adding new source files to build targets. Meson currently has some groundwork for providing these tools but they don't exist in a form that end users could use. The goal of this project is to expose this functionality properly and then add refactorings. A basic set would consist of adding and removing sources in a target, creating a new target from scratch and deleting a target. Stretch goals could include any of a number of more complicated refactorings such as moving targets between directories and making the existing tools more aware of the entire project (such as not deleting a target that is being used somewhere else).
Benefits: By providing basic refactoring tools directly in Meson we make it easy for any editor or IDE to provide refactoring functionality.
Requirements: Python. Knowledge of parsers and other refactoring tools is beneficial.
Communication: jpakkane in #mesonbuild on irc.freedesktop.org
Gnome-class: Continue development of the Rust code generator (mentor: FedericoMenaQuintero)
Brief explanation: Gnome-class is a Rust procedural macro that will let people write GObject implementations in Rust without writing boilerplate by hand. It is in early development; please look at the list of issues for ideas of what you can work on.
Requirements: You should have written a GObject class in C in the past. You should be able to write Rust at an intermediate level - if you can "fight the borrow checker" mostly successfully, you'll be fine. You don't need to have written procedural macros; you can learn here, but of course it helps if you have.
Communication: I prefer conversations on the Gitlab issues, IRC (federico in #rust on irc.gnome.org), and email.
4. Untriaged Ideas
Boxes: Restore oVirt support (mentor: FelipeBorges)
Brief explanation: Boxes used to allow importing and managing oVirt brokers. But this feature hasn't being supported lately, causing it to break after oVirt evolved its API. Now we want to bring back oVirt broker integration. Including additional features, such as creation of VMs from templates.
Requirements: Vala, C, experience with virtualization technologies (oVirt, libvirt, KVM, QEMU, SPICE...)
Communication: feborges in #boxes on irg.gnome.org
Notes: Discussions around the idea in GitLab
Librsvg: Port to Rust (mentor: FedericoMenaQuintero)
Brief explanation: Librsvg is GNOME's library to render SVG images. We are porting it from C to Rust while keeping the API/ABI intact. There are many remaining tasks in the porting effort.
Requirements: You should be able to write Rust at an intermediate level - if you can "fight the borrow checker" mostly successfully, you'll be fine. You should be able to read C code. You should not need to write new C code; maybe just refactor a few things to make them easier to port to Rust.
Communication: I prefer conversations on the Gitlab issues, IRC (federico in #rust on irc.gnome.org), and email.
Dino: Message search (mentor: fiaxh)
Brief explanation: Dino is a modern Jabber/XMPP chat client for the desktop. This project should add a user interface to quickly and intuitively search through locally stored messages with the possibility to view the context of a result.
Requirements: Vala, GTK+.
Communication: XMPP multi user chat: gsoc@dino.im.
Dino: Audio/Video Communication via Jingle (mentor: MarvinW (larma))
Brief explanation: Dino is a modern Jabber/XMPP chat client for the desktop. The XMPP protocol includes a signaling system to set-up peer-to-peer connections, dubbed Jingle. One usecase for Jingle is to start an audio and/or video dual-link session. This project idea is about adding support for setting up such communication sessions as well as adding a basic user interface to do so. This project provides a lot of room for extensions like screen-sharing or encryption.
Requirements: Vala, GTK+, ideally an understanding of GStreamer and ICE protocol.
Communication: XMPP multi user chat: gsoc@dino.im.