GNOME Project ideas for Google Summer of Code 2023

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

• Overlay plane unredirection of client buffers in GNOME Shell
• Make GNOME platform demos for Workbench
• Add Acrostic Puzzles to GNOME Crosswords
• Implement backlog search in Polari IRC client
• OpenQA testing for desktop search
• Rewrite Bustle to Rust & GTK 4
• Flatpak synching between machines
• Create a New "System" panel in GNOME Settings
• Integrate GNOME Network Displays features into GNOME Settings
• Click here to propose a new project idea

Overlay plane unredirection of client buffers in GNOME Shell

Implement support in mutter (and its scene graph and compositing library Clutter) for unredirecting client buffers into DRM overlay planes. This involves calculating what elements of the scene graph are candidates for unredirection, without relying on anything other than the scene graph state itself, as well as plumbing the act of unredirecting via the relevant kernel mode setting API, as well as evaluating eventually using libraries such as libliftoff.

Related GitLab issues: GNOME/mutter#61

Requirements

• Computer graphics and scene graph knowledge
• Excellent C skills
• KMS/DRM experience

Communication

Matrix: #gnome-shell:gnome.org

Mentor(s): Jonas Ådahl, Carlos Garnacho

Project length: 350h

More information

Make GNOME platform demos for Workbench

Workbench is an application with a focus on teaching and experimenting with GNOME technologies.

One of Workbench feature, the Library, is a collection of platform demos and examples. It currently has a limited number of entries, and I (the maintainer) have not had much time to work on adding more compared to working on the core of Workbench. The project is about adding entries covering large parts of the GNOME platform. Scope can be refined depending on the interests and availability of the intern. Some examples:

• Cover GTK4 widgets with their most commonly used signals/properties
• Cover libadwaita widgets with their most commonly used signals/properties
• Cover GNOME HIG patterns
• Cover most common GLib/Gio APIs
• Cover libportal APIs

It is possible that some demos require minor contributions to related projects such as Workbench itself or Blueprint.

How it benefits GNOME?

• Showcase GNOME platform capabilities
• Alternative format to lengthy/heavy tutorials and API references
• Quick and ready to use snippets for GNOME developers

Requirements

⚠️ This is not a Web project - this projects is suited for JavaScript developers but is about GNOME technologies

• Linux operating system, prefarably with GNOME (use Fedora if you're not sure)
• JavaScript, CSS
• Git
• Enthusiasm for design/UI/UX
• Interest in the GNOME platform/technologies
• Good communication skills

Workbench supports Vala too – translating JavaScript examples to Vala can be part of the project if there is interest.

We will be accepting multiple candidates

Communication

Matrix: #workbench:gnome.org

Mentor(s): Sonny Piers, Andy Holmes, Tobias Bernard

Project length: adjustable

More information

Add Acrostic Puzzles to GNOME Crosswords

GNOME Crosswords is a game that lets you play crossword and other grid-style puzzles. Acrostics are a fun type of puzzle that combines Crosswords with general puzzle solving (see description on wikipedia). We would like to add support for acrostic puzzles to this game.

This project would start by extending a library called libipuz. This library loads and saves puzzles from the free ipuz file format. They would add support to load Acrostics from disk. Testing support will also be added.

Once the files are loading, they would add support to the game itself through widget work. They'd have to write two custom widgets. First, they would write an answer widget that contains a sub grid and links styles with the main grid. Then they'd modify the clue row widget for acrostics to support the different types of clues.

As a final step, a separate widget will be written to add a custom layout for acrostics. Given that acrostics behave differently than crosswords, we want to lay them out differently. This can be done either by extending the existing custom widget, or them writing their own.

Requirements

• Knowledge of C is required. Most of the code being touched will be in C
• Experience with GObject / GTK / json is preferred, but not necessary for this project
• Enjoying solving puzzles is a bonus, but not required!

Communication

Chat (Matrix or WhatsApp) and email are preferred. Video call is available, but not regularly.

Matrix: @jblandford:matrix.org

Mentor(s): Jonathan Blandford, Federico Mena Quintero

Project length:

This could be either a Short or Long. The full time is required to finish the feature, but there is a reasonable off-ramp half-way through for partial support.

More information

Implement backlog search frontend in Polari IRC client

Polari The Polari IRC client currently has limited capabilities to access to logs of old conversations. This project aims to finish the port of its logging infrastructure from Telepathy Logger to Tracker, in order to improve Polari search capabilities from there. Search in old conversations is a valued tool in free software IM channels, this is expected to enhance productivity when using IRC.

Requirements

• Knowledge about GTK and JavaScript will be required.
• Ground knowledge about RDF and SPARQL is accessory, but welcome.

Communication

The #polari IRC channel at irc.gnome.org

Mentor(s): Carlos Garnacho, Florian Müllner

Project length: 175h

More information

OpenQA testing for desktop search

OpenQA is a testing tool, we are trialling OpenQA to do end-to-end testing of GNOME OS.

Currently there are no tests for desktop search, this is blocked on having some well-defined example content to search through.

There are three steps to make this happen, you could propose to do the first only, or the first two, or all three.

1 - Collect realistic examples of user content, and set up a CI process to build a disk image with a realistic home directory.

Requirements for this task can be found here: GNOME/openqa-tests#8 (comment 1664309)

As a guide, this may be around 80 hours of work.

2 - Update OpenQA tests to mount the disk image from (1) at /home/testuser

This requires basic knowledge of QEMU. There is probably a test in the https://github.com/os-autoinst/os-autoinst-distri-opensuse/ repo that shows how to do this. This may be 20-40 hours work, depending on experience with QEMU and OpenQA

3 - Create initial set of tests for desktop search

The idea of OpenQA testing is to have a small set of tests which cover a lot of functionality. The goal would be to find 2 or 3 search queries, which are able to exercise many difficult codepaths within the search infrastructure. We might produce many tests and select the most useful 3 from those.

This might be completed to a minimal within 20 hours but ideally more time would be spent to ensure code coverage is as high as possible. (Note that actually measuring coverage may be too difficult, we might have to estimate based on reading code).

Requirements

• Knowledge of scripting languages, e.g. Python (for step 1) and Perl (for step 3).
• Basic knowledge of managing virtual machines and disk images with QEMU (for step 1 and 2).

Communication

TBD

Mentor(s): Sam Thursfield, Jordan Petridis

Project length: 175h (extensible to Long (~350 hours) if preferred.)

More information

Flatpak synching between machines

Currently, it’s rather bothersome to sync the Flatpak packages installed on multiple systems: One either has to manually keep them in sync or use the CLI to get a list of installed Flatpaks.

As such, it would be useful to have an application that can do this for users. The go-to approach would be a D-Bus daemon that automatically (either on changes or periodically) creates a list of installed Flatpaks and pushes it to a service like GitHub Gists. If a new version is detected (which comes from a different system), the daemon would fetch it and adjust the local installation accordingly.

Additionally, there should be a GUI application that can interface with the daemon for setup and configuration. A CLI application for usage independent of the DE and manual syncing would be a plus.

Requirements

Since the project should be useable on Silverblue, it’d be good if the binary can run on it by default. Since Silverblue doesn’t have GJS nor Python installed by default, Rust seems like a good choice now that we have zbus.

• Familiarity with Rust & DBus

Communication

Matrix

Mentor(s): Rasmus Thomsen

Project length: 175 hours

More information

Rewrite Bustle to Rust & GTK 4

Bustle is a graphical D-Bus message analyser and profiler.

Bustle draws sequence diagrams of D-Bus activity, showing signal emissions, method calls and their corresponding returns, with timestamps for each individual event and the duration of each method call. This can help you check for unwanted D-Bus traffic, and pinpoint why your D-Bus-based application isn't performing as well as you like. It also provides statistics like signal frequencies and average method call times.

Currently, Bustle is written in Haskell & GTK 3. Haskell bindings are not very nice to use, not that many contributors to the bindings themselves and no one is capable of updating the application on the wide GNOME community. Especially when it comes to generating a working Flatpak manifest.

The idea is to rewrite it in Rust & GTK 4 using zbus for the dbus part.

Requirements

• Familiarity with Rust & DBus

Communication

Matrix

Mentor(s): Bilal Elmoussaoui , Maximiliano, Will Thompson

Project length: 350 hours

More information

Integrate GNOME Network Displays features into GNOME Settings

GNOME Settings (aka gnome-control-center) is GNOME's main interface for configuration of various aspects of your desktop.

GNOME Network Displays is a standalone application for casting your display's content onto another remote display in the network.

The goal of this project would be to reuse the work in gnome-network-displays to be able to manage remote displays in the GNOME Settings Display panel. Allowing users to select the remote display from the list where they already can find local displays/monitors. This work will involve iterating with the GNOME design team and discussing the UX of the functionality.

Requirements

• Experience with C/GObject and GTK
• Familiarity with networking protocols

Communication

Matrix: #control-center:gnome.org

Mentor(s): Felipe Borges, Claudio Wunder, and others

Project length: 175h

More information

Create a New "System" panel in GNOME Settings

GNOME Settings (aka gnome-control-center) is GNOME's main interface for configuration of various aspects of your desktop.

We have an ongoing issue with there being too many top level settings panels (see #1090). One way to help with this would be to move Region & Language, Date & Time, Users, and About into a new System panel (mockups).

Previously we had the "details" panel, which served a similar function. We removed that after people seemed to get confused by it, though now I wonder whether it was as much an issue with the "details" name as much as anything else. Other platforms have a "system" section, so I think people are used to this concept. Also, we've tested the system panel design with users, and it has performed well (see Teams/Design/usability#10).

The implementation should take inspiration on the recent redesign of the Accessibility panel. For this reason, a good way to organize the codebase is:

• Move the panel sources into a new panel/system/ folder
• Convert each CcPanel object into a new widget that could be used as a page for the system panel (likely AdwPreferencesPage)
• Implement the CcSystemPanel class implementing the pagination from the designs (likely an AdwLeaflet with rows that when clicked will open each page).
• Identify duplicated code between the panels that can be reused/refactored
• Customize each page to account for differences between panels and page (for example, widgets that a panel would place in the headerbar now could be placed elsewhere, etc...)
• Address design review (GNOME designers will suggest modifications. You should plan and expect design iteractions that change the original design from the mockups).

Requirements

• Strong GTK and C (GLib/GObject introspection) skills
• Knowledge of the Linux desktop stack internals (systemd, dbus)

Communication

Matrix: #control-center:gnome.org

Mentor(s): Felipe Borges, Georges Basile Stavracas Neto

Project length: 350h

More information