GNOME Project Ideas for Google Summer of Code 2022
Welcome to the GNOME project ideas for GSoC 2022! In this page we list ideas that could be used for GSoC proposals.
Visit our Contributor Guidance page for information on how to apply to GSoC.
Important notes:
- Use this template for your GSoC application (preferably).
- Most of our mentors prefer to communicate over the GNOME communication channels.
- Project ideas could be long (350 hours) or short (175 hours), check the GSoC change announcement for more information on the program changes.
- Check the GSoC rules for eligibility and other information.
- Contributors (students/interns) can find more information about the GNOME participation in GSoC at our wiki page.
- More project ideas are being proposed and reviewed in our gitlab repository before getting listed in this page.
Health: reworking the sync options for Health
Mentor(s): Rasmus Thomsen (@Cogitri, @Cogitri on Gitlab, email: oss@cogitri.dev , matrix: @cogitri:cogitri.dev)
Source code: World / Health · GitLab
Description: Health is a health tracking app. That means it helps the user visualise and understand their health indicators better: It can show the user if they’re active enough, how their weight has developed and more.
However, this data has to be collected somehow. As of now, most users have to manually enter data. This is error prone and tedious. To fix this, the aim of this project is to improve synchronisation with 3rd party services such as Google Health (and possibly Nextcloud Health, Apple Health and the PineTime companion apps). This way activities, steps, weights and so on can be synchronised between Health and 3rd apps that interact with different devices such as smart watches.
Requirements: Health is written in Rust, as such a basic understanding of Rust (e.g. by going through the Rust Book) is a necessity. This project will be done with SCRUM as development tactic. As such, it’s a good idea to read the SCRUM Guide beforehand.
Project length: This project can go either way (175h or 350h). If we only target reworking Health’s database and sync code it’s probably a short project. It’d be nice if we could also try to integrate Health with companion apps that work with devices like the PineTime to sync steps without a 3rd party service.
More information: Health GSoC - reworking the sync options for Health (#1) · Issues · Teams / Internship / Project Ideas · GitLab
Faces of GNOME - Continuing the Development of the Platform
Mentor(s): @cwunder @kristiprogri @Chenriksen
Source code: Teams / Engagement / Websites / Faces of GNOME · GitLab
Description: The Faces of GNOME is a Foundation-led initiative with the intent of championing our contributors and recognising their continuous and previous efforts towards the GNOME project. Faces aim to be a historical platform where you’re able to see the faces behind the GNOME project. From current contributors to past contributors. Faces intend to be a place where Contributors have their own profile, serving as a directory of the current and past Contributors of the Project.
Faces features also different pages where the community is able to see numerous aspects of the people behind the GNOME project. For example, who are the current Maintainers of each Application, Who are the Board of Directors, the Foundation Members, past GSoC and Outreachy mentors/students and more.
Requirements: For GSoC, we’re looking for someone that has previous experience with Web Development. As being a student, we don’t expect much and what matters the most are people eager to learn. Whilst the platform is currently built upon specific technologies such as JavaScript, Jekyll and CSS, we don’t expect the student to be advanced or have experiences with those technologies. Of course, knowing these technologies or having previous experiences with them, might facilitate and ease the development process of the Platform.
Project length: 350h (long)
More information: Faces of GNOME - Continuing the Development of the Platform (#2) · Issues · Teams / Internship / Project Ideas · GitLab The preferred platforms are our Engagement Matrix channels. DM’s and other chatting platforms for occasional/informal conversation, such as asking for advice is also allowed.
GNOME Websites Framework - Part 2
Mentor(s): @cwunder @kristiprogri @Chenriksen
Source code: Teams / Engagement / Websites / GNOME HIG CSS Library · GitLab
Description: The GNOME Websites Framework is an attempt to create a CSS Library that conforms with GNOME’s HIG and Design principles, that allows in an easy way to create new Websites for the GNOME Project and for the GNOME Foundation that both respect and follow the very same Design principles that compose the GNOME project. The main goal of this project is to allow uniformity and conformity across our GNOME Websites.
Currently, many Websites have different designs (some outdated, and some completely non-fitting). The idea here is that with this Framework we can work on existing Websites and adapt them to the current standards. The Framework would also allow new websites to be quickly built upon.
Requirements: This project requires CSS knowledge mostly. For this project, we’d be accepting students willing to learn and dive deep more into CSS and Web Design. If you’re a student that loves Design, Documentation and/or Open Source that’d be great!
Project length: 350h (long)
Communication: The preferred platforms are our Engagement Matrix channels. DM’s and other chatting platforms for occasional/informal conversation, such as asking for advice is also allowed.
More information: GNOME Websites Framework - Part 2 (#5) · Issues · Teams / Internship / Project Ideas · GitLab
Overlay plane unredirection of client buffers in GNOME Shell
Mentor(s):
- @jadahl, jadahl@gmail.com>, IRC: jadahl
- @carlosg, carlosg@gnome.org, IRC: garnacho
Source code: GNOME / mutter · GitLab
Description: 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
Project length: 350h (long)
Communication: The #gnome-shell IRC/Matrix channel.
More information: Overlay plane unredirection of client buffers in GNOME Shell (#10) · Issues · Teams / Internship / Project Ideas · GitLab
Extend the feature set of Rust GObject introspection code generator
Mentor(s): Bilal Elmoussaoui @bilelmoussaoui:gnome.org on Matrix
Source code: GitHub - gtk-rs/gir: Tool to generate rust bindings and user API for glib-based libraries
Description: If you always wanted to learn more about GObject Introspection and you are familiar with Rust this project might be the perfect match for you!
The Rust bindings of GLib based libraries makes uses of gir to automatically generate the bindings along with their documentations from the .gir files. Lately, the Rust bindings saw a huge growth in number of users along with a growing community of contributors.
This project proposal aims to get some of the nice to have features on the Rust code generator. Below you will find a list of issues I picked from the issues tracker that would be a good fit for the duration of this project.
Requirements: Previous Knowledge of Rust and C preferable.
Project length: 175h (short).
More information: https://gnome.element.io/#/room/#rust:gnome.org
Implement backlog search in Polari IRC client
Mentor(s):
- @fmuellner (fmuellner@gnome.org), IRC: fmuellner
- @carlosg (carlosg@gnome.org), IRC: garnacho
Source code: GNOME / polari · GitLab and GNOME / TinySPARQL · GitLab
Description: 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, a ground knowledge about RDF and SPARQL is accessory, but welcome.
Project length: Can be either:
- 175h: Goal is porting existing functionality to a Tracker database, update and modernize code
- 350h: Goal is implementing a fully featured search UI
More information: Implement backlog search in Polari IRC client (#12) · Issues · Teams / Internship / Project Ideas · GitLab the #polari IRC channel at irc.gnome.org, and Discourse
Pitivi: Port UI to GTK4
Mentor(s): aleb cfoch thiblahute yatinmaan
Source code: GNOME / pitivi · GitLab
Description: The scope is the entire Pitivi UI. Pitivi is using the GTK widget toolkit version 3. You can follow the official guide for migrating from GTK 3 to GTK 4.
Requirements: Python. At least a small code-wise contribution to Pitivi so you know what you’re getting into.
Project length: Long
Communication: https://app.element.io/#/room/#pitivi:matrix.org, video call
More information: Pitivi: Port UI to GTK4 (#16) · Issues · Teams / Internship / Project Ideas · GitLab
Pitivi: Integrate video downloader
Mentor(s): aleb cfoch thiblahute yatinmaan
Source code: GNOME / pitivi · GitLab
Description: The project scope is Pitivi’s media library. The media library panel allows managing the assets imported into the project. In the spirit of creating video mash-ups or simply for integrating a relevant clip from a video hosting website, we can extend the media library with a Download function. The user can simply enter a URL which we pass to an external download manager. The downloaded file is then automatically imported into the project so it can be used right away.
Requirements: Python. At least a small code-wise contribution to Pitivi so you know what you’re getting into.
Project length: Long
Communication: https://app.element.io/#/room/#pitivi:matrix.org, video call
More information: Pitivi: Integrate video downloader (#17) · Issues · Teams / Internship / Project Ideas · GitLab
Pitivi: Timeline improvements
Mentor(s): aleb cfoch thiblahute yatinmaan
Source code: GNOME / pitivi · GitLab
Description: The project scope is Pitivi’s timeline. The timeline is essential for arranging clips in a video project and to synchronize video and audio moments. Get in touch with us to prepare a mix of timeline enhancements and bug-fixes.
Requirements: Python. At least a small code-wise contribution to Pitivi so you know what you’re getting into.
Project length: Long
Communication: https://app.element.io/#/room/#pitivi:matrix.org, video call
More information: Pitivi: Timeline improvements (#15) · Issues · Teams / Internship / Project Ideas · GitLab
Pitivi: Render improvements
Mentor(s): aleb cfoch thiblahute yatinmaan
Source code: GNOME / pitivi · GitLab
Description: The project’s scope is Pitivi’s render dialog. Currently exporting a video project requires selecting a video encoder. First idea is to expose in the UI which video encoders support hardware-accelerated (GPU) encoding. Second idea is to expose GStreamer’s smart rendering functionality. With some limitations, smart rendering allows exporting the input video as is, offering blazing fast exports with no quality loss.
Requirements: Python. At least a small code-wise contribution to Pitivi so you know what you’re getting into.
Project length: Long
Communication: https://app.element.io/#/room/#pitivi:matrix.org, video call
More information: Pitivi: Render improvements (#14) · Issues · Teams / Internship / Project Ideas · GitLab
Fractal-next: Add room moderation
Mentor(s): @jsparber
Source code: World / fractal · GitLab
Description: This project consists of identifying tools and features needed to moderated chat rooms(e.g. setting power levels) and implement it in Fractal-next. You will need touch the matrix-rust-sdk and Fractal-next itself.
Requirements: Basic knowledge with Rust and GTK4 is required. You should also have contributed to Fractal-next or other GNOME projects. Knowledge about the Matrix specs is a plus.
Project length: 350 hours (long)
More information: Fractal-next: Add room moderation (#22) · Issues · Teams / Internship / Project Ideas · GitLab
Fractal-next: Media history viewer
Mentor(s): @jsparber
Source code: World / fractal · GitLab
Description: This project consists of adding a media history viewer to Fractal-next. Currently we have a media viewer but we would like to have a more complete viewer for the history of send media similar to other IM clients. You will need touch the matrix-rust-sdk and Fractal-next itself.
Requirements: Basic knowledge with Rust and GTK4 is required. You should also have contributed to Fractal-next or other GNOME projects.
Project length: 350 hours (long)
More information: https://gitlab.gnome.org/Teams/Engagement/gsoc-2022/-/issues/21
Fractal-next: Implement and design tests
Mentor(s): @jsparber
Source code: World / fractal · GitLab
Description: Fractal-next currently doesn’t have any tests. It would be great to add unit and UI tests via gtk-test that can be run on the CI. This requires also mocking a matrix homeserver. This will keep the app more stable with out manual testing. You will need touch the matrix-rust-sdk and Fractal-next itself.
Requirements: Basic knowledge with Rust and GTK4 is required. You should also have contributed to Fractal-next or other GNOME projects.
Project length: 350 hours (long)
More information: Fractal-next: Implement and design tests (#20) · Issues · Teams / Internship / Project Ideas · GitLab
Fractal-next: Add network traffic inspector
Mentor(s): @jsparber
Source code: World / fractal · GitLab
Description: Fractal-next sends many HTTP requests. For development and debugging it will be useful to inspect the traffic. The added inspector should work similar to web browsers integrated network inspectors. You will need touch the matrix-rust-sdk and Fractal-next itself.
Requirements: Basic knowledge with Rust and GTK4 is required. You should also have contributed to Fractal-next or other GNOME projects.
Project length: 175 hours (short)
More information: Fractal-next: Add network traffic inspector (#19) · Issues · Teams / Internship / Project Ideas · GitLab
Add Chromecast support to Gnome-Network-Displays
Mentor(s): (possibly) Benjamin Berg (benzea, bberg)
Source code: GNOME / gnome-network-displays · GitLab
Description: Gnome-Network-Displays currently works off the Miracast protocol. There is another major and popular network display protocol that is not supported: chromecast. It will be a major benefit to users.
Requirements: Python and GNOME/GTK experience.
Project length: TBD
More information: Add Chromecast support to Gnome-Network-Displays (#8) · Issues · Teams / Internship / Project Ideas · GitLab
Enlarge code testing coverage in GNOME Files
Mentor(s): AntĂłnio Fernandes @antoniof
Source code: GNOME / Files · GitLab
Description: The file browser is expected to be a reliable application which people can use safely to manage their own data and keep open without affecting other tasks.
The GNOME Files application is one such file browser, originating from the nautilus project. It’s a live project, under constant development (maintenance, modernization, enhancement, bugfixing) for over 2 decades. It’s also an extenside codebase and original authors of many portions of it are no longer active participants. This creates a challenge to developers who, while fixing one thing can inadvertly break something else in unexpected ways on unpredictable components. The answer to this challenge are unit tests and integration tests.
Thanks to GNOME’s adoption of GitLab, Continuous Integration has become a norm. GNOME Files has pipelines which test every merge request builds and passes a the tests. The existing tests already cover some critical components, but this coverage is far from complete.
The goal of this project is improving the coverage of code testing, by advancing through the roadmap in GNOME/nautilus#224 . This makes it a sequel to a previous GSoC project which has covered the first steps of that roadmap.
Requirements: Good knowledge of C. Basic knowledge of GObject. Basic knowledge of glib testing framework
Project length: Can be either “Short (~175 hours)” or “Long ~350 hours”. The number of tasks to pick from the roadmap is a function of project length.
More information: Enlarge code testing coverage in GNOME Files (#23) · Issues · Teams / Internship / Project Ideas · GitLab
Matrix: #nautilus:gnome.org
Revamp “New Document” submenu in GNOME Files
Mentor(s): AntĂłnio Fernandes @antoniof
Source code: GNOME / Files · GitLab
Description: The scope of the ideal is GNOME/nautilus#2205
The context is that the New Document creation feature has long standing discoverability and usability issues, along with old and new bugs. Porting the application to GTK 4 has brought further regressions that need to be addressed.
The goal of this project is to design and implement a UI for this feature.
The GNOME project will benefit from addressing all these issues at once with a new design.
Development will happen on the GNOME/nautilus project, mostly in the NautilusFilesView class. It’s going to include creating a new composite GTK widget template to be factored out from that class. It may also include reporting and/or fixing GTK bugs found along the way.
This is a UI front end project. It can and should use the NautilusFile abstraction, such that direct no direct filesystem I/O is needed. UI design is expected to be refined during the project, likely including a few prototype iterations, always requesting review and advice from #gnome-design team.
Requirements: Good knowledge of C. Basic knowledge of GObject and GTK 4. Ability to work as part of a team with different sets of expertise. Basic notions of usability. Acknowledgement of the importance of good user experience design.
Project length: Short (~175 hours)
More information: Short project idea - Revamp "New Document" submenu in GNOME Files (#24) · Issues · Teams / Internship / Project Ideas · GitLab
Matrix: #nautilus:gnome.org
Add PWA manifest support to GNOME Web
Mentor(s): Phaedrus Leeds @mwleeds
Source code: GNOME / Epiphany · GitLab
Description: GNOME Web (aka Epiphany) is GNOME’s web browser. Adding PWA (Progressive Web Apps) manifest support to GNOME Web will improve the experience of managing webapps and also allow for webapps integration with GNOME Software. See also the Web Application Manifest spec.
Project length: Short (~175 hours)
More information: Improve core apps integration with xdg-desktop-portals (#7) · Issues · Teams / Internship / Project Ideas · GitLab
Add support for the latest GIR attributes and gi-docgen formatting to Valadoc
Mentor(s): Looking for mentors!
Source code: https://valadoc.org/
Description: 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.
Project length: TBD
More information: Add support for the latest GIR attributes and gi-docgen formatting to Valadoc (#13) · Issues · Teams / Internship / Project Ideas · GitLab
Matrix: #vala:gnome.org
IRC: irc://irc.gnome.org/vala
More ideas to be added to this page soon!
