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.
To discuss ideas, please join the respective Communication channel listed bellow.
2. Potential Project Ideas
Design tooling: port to gtk 4 (mentor: BilalElmoussaoui, co-mentors: team)
Brief explanation: The design tooling consists of a small set of applications that boosts the design team and developers productivity. App Icon Preview, Symbolic Preview & Icon Library shares more or less a common base code for parsing SVG files, rendering icons and other stuff. The project will consist of porting App Icon Preview (to be determined) to GTK 4 while moving parts of it's code to a common library that will be shared between the there utilities.
Requirements: Basics of writing Rust & software development in general. Gtk or gobject experience.
Communication: Matrix: @bilelmoussaoui:gnome.org
tracker: File creation times (mentors: @sthursfield and/or @carlosg. Support (but not mentorship) from @antoniof and @oholy)
Brief explanation: File creation time was historically not tracked on UNIX file systems and it's not part of the POSIX specification. Other OSes do track this, and modern Linux can provide files creation times in most cases. Nautilus can now sort by creation time. This project is about adding creation time support to the Tracker Miner FS indexer, and to allow searching by creation time in Nautilus.
Requirements: C programming with GLib. Basic knowledge of Linux filesystems.
Communication: #tracker (and #tracker:gnome.org) for coordination. #gtk (and #gtk:gnome.org) for GLib development, and #nautilus (and #nautilus:gnome.org) also relevant.
tracker: Improve custom ontology support (mentors: Carlos Garnacho and/or Sam Thursfield)
Brief explanation: Tracker SPARQL 3.0 allows apps to store and publish data using custom database schemas a.k.a ontologies. A few apps use this already, including Nautilus and Health, but there are open bugs that make developing a custom ontology more painful than it should be. The scope of this project can vary depending on the skill and interests of the participant..
Requirements: C programming with GLib. Debugging with GDB. Writing unit tests.
Communication: #tracker on IRC
Redesigning Health's MainView (mentors: Cogitri)
Brief explanation: Health (a GNOME Circle application) currently has three view modes (step count, weight measurements and recent activities) where users can see historical data points and today. However, most of the time users only really care about what they archived recently and not about historical data reaching back for multiple weeks or longer. As such, Health could do with a new view that gives users a nice overview about how they're currently doing (as in their current step streak, today's step count, etc.).
Requirements: At least basic knowledge of the Rust. Good understanding of GTK(4) since this is mainly UI focused. Either experience with gtk-rs or good understanding of both Rust and GTK so learning gtk-rs won't be too hard.
Communication: Matrix: @cogitri:cogitri.dev
Animation API for libadwaita (mentors: @exalm)
Brief explanation: When building applications, most major commercial toolkits have some kind of animation framework. GNOME apps follow a design-driven programming approach, and the whole GNOME ecosystem is based upon the concept of semantic animation. Semantic animation, a term coined by the GNOME designer Tobias Bernard is already a reality in GNOME Shell. Allowing the app ecosystem to access it in an easy way is the logical next step regarding providing the best possible UX. This project aims at providing the GNOME ecosystem with one animation framework of its own, via a high-level API exposed in the libadwaita library, and a collection of carefully designed presets.
Requirements: Basic programming experience, C knowledge is a plus. Advanced maths knowledge. Physics knowledge, as some animation require to be physics-driven. Design experience, as the framework will need a good set of carefully preset values.
Communication: #libhandy:gnome.org room and more generaly on Matrix.
libsecret: extend file backend to use TPM2 derived encryption keys (mentors: @dueno and @ansasaki)
Brief explanation: libsecret is a library that allows applications to store/retrieve user secrets (typically passwords). While it usually works as a client against a separate D-Bus service, it can also use a local file as database. Currently, the file database uses an encryption key derived from user's login password. That is not ideal because the entire security relies on the login password and is not able to cope with alternative login methods, such as fingerprint readers. The situation could be improved if the key is protected by hardware, such as TPM2 on consumer notebooks. As TPM2 has a mechanism to securely import/export private keys in a wrapped form (i.e. encrypted), the libsecret implementation merely needs to record the wrapped key as an opaque key handle along with the encrypted database upon writing, and upon reading it can ask TPM2 to decrypt the session key from the key handle. The TPM2 Software Stack provides the necessary functions for that.
Requirements: C language basics would be preferred.
Communication: chat (#seahorse or #keyring on IRC/Matrix).
Fractal: feature parity between fractal-next and fractal (mentors: @jsparber)
Brief explanation: Fractal is a Matrix client using the GNOME technologies. Last year, the GSoC intern re-architectured it so the backend is in a much cleaner state. There is currently a re-write of the UI part of Fractal being carried on. This project is codenamed Fractal-next. See https://gitlab.gnome.org/GNOME/fractal#fractal-next-initiative
Requirements: Knowledge of the Rust language. Gtk4. gtk-rs, Having contributed to Fractal or Fractal-next is mandatory.
Communication: #fractal:gnome.org
Fractal: Multi account support (mentors: @danigm)
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: Knowledge of the Rust language. Gtk4. gtk-rs, Having contributed to Fractal or Fractal-next is mandatory.
Communication: #fractal:gnome.org
Faces of GNOME / People of GNOME (mentors: @cwunder and @Chenriksen)
Brief explanation: Faces of GNOME has the purpose to serve as an archive of all the current and past collaborators (starting from when this project is launched) to the GNOME Project. It also has the intention to create simple profile pages where contributors might add custom information, blog links/pages, and much more.
Communication: Matrix/IRC
GNOME.org UI Part 2 (mentors: @cwunder and @Chenriksen)
Brief explanation: This project would take from where we stopped on GSoC 2020, and continue the goals of the project. Aiming a code-complete version of all the basic UI element (button, div/containers, paragraphs, inputs, text, font, etc) and UI components (header, footer, tables, lists, sections, etc).
Communication: Matrix/IRC
Shell: update screenshot and screen recorder (mentor: verdre, co-mentors: team)
Brief explanation: gnome-shell allows taking screenshots and has a built-in screen recorder, it can take screenshots and record screencasts of an area, a window or the whole monitor. Right now, screenshots can be taken using the gnome-screenshot utility or by pressing certain key combinations, recording screencasts only works by pressing a key combination. Remembering all those combinations is hard, especially when not using them often, also it turned out a lot of people are not even aware features like the screen recorder exist. The plan for this project is to unify both the screenshot and the screen recorder functionality within a single UI that's part of gnome-shell. This will make it easy to select an area or a window to screenshot/to record, especially on devices like tablets or phones where no keyboard and mouse are available. You'll work together with our design team, implementing design mockups and iterating on the changes to make for a great user experience.
Requirements: Basic experience writing JavaScript and CSS, preferrably GObject experience, some design knowledge and ideas
Communication: Matrix/IRC #gnome-shell:gnome.org
Shell: implementing layout manager in Rust (mentor: Jordan Petridis (alatiera), co-mentors: verdre, team)
Brief explanation: gnome-shell uses the scenegraph library Clutter to draw and layout it's UI. Layout with Clutter has historically been done by setting fixed positions and sizes for every element of the UI, while the modern way is to make use of the size negotiation techniques Clutter supports like layout managers and constraints. gnome-shell has been transitioning to make use of the latter a lot more with GNOME 40, which allowed for much more maintainable code and easier development. The downside of those changes is that the way gnome-shell is implemented makes it necessary to transition from a C into a JS environment every time that layout negotiation happens, which incurs a certain overhead. This project is trying to explore the idea of implementing specific code like layout managers in Rust, while leaving the largest parts of the UI in JS, reducing the amount of marshalling done and crossings of C and the JS FFI.
Requirements: Knowledge of GObject and GLib Experience programming in Rust, preferrably with Rust-GObject libraries
Communication: Matrix/IRC #gnome-shell:gnome.org
Implement active resource management in GNOME 4 (mentors: @bberg and @fmuellner)
Brief explanation: In this project, we want to introduce resource management for applications in GNOME. On the technical level, this means dynamically modifying the properties of the running systemd units. Internally however, we will need to properly track various pieces of information in order to be able to make policy decisions.
Requirements: Languages: C, JavaScript. Some understanding of DBus, systemd and cgroups is useful. Background reading: https://lwn.net/Articles/829567/
Communication: IRC/Matrix: #gnome-hackers:gnome.org
Past ideas: 2020, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006, 2005.