GNOME Project ideas for Google Summer of Code 2024
For general information on how to get involved with our project and participate in Google Summer of Code with GNOME visit gsoc.gnome.org
This is the list of project ideas that the GNOME community is interested in mentoring. GSoC interns can also propose their very own project ideas. If you are interested in proposing a project idea, please file an issue in our Internship Project Ideas repository.
GSoC contributors proposing something original must engage with the community strongly before or during the application period to get feedback and guidance to improve the proposal.
Project list
Libipuz is a C library that loads puzzle files and used by Crosswords as the underlying data structure. It is written in C. Since it is used primarily to parse files from disk, rewriting it in Rust adds additional safety while (hopefully) improving the maintainability of this library.
Requirements
Rust and C Language support required Knowledge of glib is a plus
Communication
Matrix (video call and email are secondary comms)
FlatSync is a GSoC 2023 project to synchronise Flatpak installations across machines. During GSoC 2023 FlatSync was bootstrapped and already has basic synchronisation functionality. However, there are still some missing pieces:
- Currently FlatSync stubbornly tries to synchronise all Flatpaks. This doesn't make sense in all cases, e.g. if you only want NVidia drivers to be installed on your desktop machine but not your laptop (which only has an internal GPU). Instead, we should add a way to exclude some flatpaks/do machine specific overrides.
- The error handling is still pretty basic and users aren't notified about failed synchs.
- The UI is currently very basic, only allowing users to enter their GitHub-Token. During GSoC 2024, the following things should be added:
- An initial setup, which guides the user how to add an initial/additional machine
- A UI to exclude certain flatpaks (see above)
Having these capabilities would make FlatSync viable for GNOME users, making Flatpaks a lot nicer to use for GNOME users with multiple computers.
Requirements
Since Flatsync is written in Rust and uses GTK-rs, these should be looked into in advanced before working on the project:
Communication
Matrix: #flatsync:gnome.org
Valadoc is the API documentation generator for the Vala programming language. First it is needed to make the Vala API generator and Vala compiler support the latest GObject-Introspection attributes to for example marking a method as getter or setter of a property and emit them (issue). This will also benefit other users of Vala libraries, like language bindings. Then in Valadoc would be support implemented for displaying these attributes and information properly.
Other not directly involved but connected things to work on would be to add support to Valadoc for understanding the formatting of gi-docgen API references (issue) and modernizing the style of the outputted documentation pages bit (issue).
Requirements
Experience in programming with the Vala language is recommended. Other helpful topics are how compilers work and knowledge in the GObject type system.
Communication
Matrix: #vala:gnome.org
IRC: irc://irc.gnome.org/vala
Currently, Bustle's diagram has a few design problems. This includes, but not limited to:
- Unreadable arrows on concurrent method calls between two services;
- Time is not represented well, i.e., longer method calls are not really represented by a longer gap between rows; and
- RTL is not supported well.
The goal of the project is to, therefore, prototype a new design, possibly an overhaul, that solves the aforementioned problems, weigh its pros and cons, and implement it into the application. The old and new diagram view can coexist by creating a view switcher.
The project would benefit the community as it would improve Bustle's functionality and usability in debugging DBus applications.
See also World/bustle#4 (comment 1795458)
Requirements
Familiarity with Rust, GTK, and DBus, Experience with Git and creating MRs/PRs
Communication
Matrix: #bustle:gnome.org
Implement a web IDE in Tracker SPARQL, as described in GNOME/tracker#421.
Development is mostly HTML + JavaScript to implement the IDE. Some fixes and improvements in the underlying C + GObject code is also involved.
Benefit for community: improved developer experience for app developers that use libtracker-sparql. This includes apps that do desktop search in GNOME.
Requirements
- HTML and JavaScript are required
- Some knowledge of databases is required, understanding RDF + SPARQL is a bonus
- Programming in C with GObject is also a bonus
- Ideal for someone who likes to create user interfaces and developer tooling
Communication
Matrix: #tracker:gnome.org
This project is about porting remaining Workbench demos from JavaScript to Vala. At the time of this writing, 40 demos needs porting to Vala.
We expect there might be time left that will be used for one of these:
- Make new Workbench demos
- Improve tooling related to demos
- Improve Workbench Library
Components:
https://github.com/workbenchdev/demos and https://github.com/workbenchdev/Workbench
Requirements
- Great attention to details (it's important for the ports to be correct and close to the original)
- Vala
- Using Git and contributing via PRs/MRs
Communication
Matrix: #workbench:gnome.org
Workbench grew from a simple GTK XML previewer to a multi-language code sandbox.
Some of the early technical decisions do not make sense anymore, and we can improve Workbench as well as extend the ecosystem by reworking some of the internals.
- Add an out-of-process previewer for JavaScript, similar to Python
- Remove the inline previewer for JavaScript
- Stop listening on stdout for console
- Write a previewer as an introspectable library
- Replace the previewers with the unified library
If time permits, we will investigate using the previewer for a GNOME Builder extension.
https://github.com/workbenchdev/Workbench
Requirements
- JavaScript
- familiarity with C
- GObject / GTK / ...
- Using Git and contributing via PRs/MRs
Communication
Matrix: #workbench:gnome.org
The goal of the project is to make Papers useful on devices like phones and tablets. It is unfortunately one of the few (soon to be) Core Apps which does not properly fit in a phone form factor or with not good enough touch support. The project includes two parts, out of which the second could be optional:
- The compulsory one is changing the UI to use a more adaptive design according to latest mockups, the main skills required are widgetry knowledge.
- The optional part is doing changes at the core of one of the application's libraries to consider touch support. The said library has many years of life, and some of its components are outdated and in need of refactoring. So the ability to understand other people's code and dig into git history should greatly help.
Component: Papers
Requirements
The Papers codebase compromises of 2 libraries written in C, and a frontend written in C that is being ported to Rust. Knowledge of those two programming languages is a must.
Papers is also a big application with more than 20 years of history. Good experience with git, and some navigating big and old codebases might also be considered a requisite.
Communication
Matrix: #papers:gnome.org