Update on what happened across the GNOME project in the week from August 28 to September 4.

GNOME Foundation

marimaj reports

We’ve held an AUA on Reddit with GNOME’s new Board members last Saturday. Sri Ramkrishna — President, Jonathan Blandford — Vice-President, Maria Majadas — Chair, and Adrian Vovk — Vice-Secretary, answered all the proposed questions from the participants. You can read them in:

https://www.reddit.com/r/gnome/comments/1vz7pja/meet_the_board/

Thank you for joining us!

GNOME Fellowship

Peter Eisenmann says

I posted about all the cool things I got up to in August as part of the GNOME Fellowship, read about it here :) https://blogs.gnome.org/p3732/fellowship-report-august-2026-rivendell/

Sophie (she/her) says

New month, new GNOME Fellowship report. You can read about my contributions in my August 2026 blog post .

GNOME Core Apps and Libraries

Files ↗

Providing a simple and integrated way of managing your files and browsing your file system.

Peter Eisenmann reports

Files, aka nautilus, received some great changes in the 51 cycle, here is a selection of my favorites:

• AdwTabOverview is used in narrow mode
• Slightly smoother navigation by delayed clearing
• Show count badge when while dragging multiple files
• Open locations from other apps in new tabs
• Add an empty document menu entry in case of empty templates directory
• Selection handling improvements:
  • Correctly restore focus and selection if a file gets removed
  • Don’t unselect when right clicking the view’s background
  • Don’t override manual selection with file operation results
• Correctly raise the window when other apps call “Open location”
• Type-to-search support in app chooser dialog
• Accessibility enhancement, e.g. for filename entry feedback
• More tests (📈 44%)

PS: Ctrl+E is a not-yet-documented shortcut to focus the file chooser filename entry

Peter’s work is funded by the GNOME Fellowship program. You can support the fellowship program via a donation .

GNOME Circle Apps and Libraries

Alexander Vanhee announces

In Bazaar, we are dropping the dialog you sometimes see when installing an app that makes you pick a specific source, in favor of just putting the non-primary sources somewhere on the app’s page. This should make the most common case of just installing the normal version of the app faster and avoid confusion for new users who don’t know what option to install.

Third Party Projects

Lanséria reports

Hey people, this week I’ve finally published the new version of PedantiK, 1.6.0, that includes new language packs!

PedantiK is a game where you need to find the hidden Wikipedia page by guessing words one by one. The new version include a new English language pack, allowing you to play in English or French by installing what language you want!

PedantiK is available through Flathub

Shell Extensions

Christian W reports

It’s sci-fi week for Gnome. This week cwittenberg published two purely-for-fun sci-fi extensions:

Matrix turns your desktop into the familiar falling digital rain from The Matrix, while still keeping your normal desktop usable underneath it.

Starfield takes things a little further into space, adding a Star Trek: The Next Generation-inspired starfield that makes it look like your desktop is flying through the stars.

Both extensions preserve your existing wallpaper and renders the effects efficiently on the GPU using a shader, consuming hardly any CPU.

Neither extension will make you more productive. They may, however, make staring at your desktop considerably more entertaining.

Extension app: search for “Matrix code” Matrix: https://extensions.gnome.org/extension/10708/matrix-code-rain/ Source: https://github.com/cwittenberg/matrix-rain

Extension app: search for “starfield” from @cwittenberg Starfield: https://extensions.gnome.org/extension/10743/starfield/ Source: https://github.com/cwittenberg/starfield

Tomáš Gažovič reports

RSS Feed GNOME Shell extension has a new release (version 9.0).

Adding your feeds no longer means typing them in one by one: you can import the whole list at once from an OPML file, the same format you can export from pretty much any other reader. Export works too, so moving your feeds somewhere else is no problem.

Accessibility also improved: the panel menu is now fully keyboard operable, and the view scrolls along to keep the focused item visible.

Under the hood, the extension now checks whether a feed changed before downloading it, so refreshes are lighter on the network. Feed data also lives in a JSON store instead of GSettings, which handles larger feed lists better.

Supports GNOME 46 to 51.

Get it on EGO | Source on GitHub

Miscellaneous

Sophie (she/her) announces

We are in the process of introducing a new decision-making process into the GNOME project. The specification of the RFC process is available as a merge request on GitLab . The discussion is happening on the respective Discourse thread . I am now announcing the start of the final comment period for the adoption of this RFC process. We are deviating from the proposal’s 14-day period for this occasion and instead will consider concerns raised up until October 4th at 23:59 UTC. All active GNOME Foundation members remain invited to contribute to the discussion.

That’s all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

We are in the process of introducing a new decision-making process into the GNOME project. The specification of the RFC process is available as a merge request on GitLab . The discussion is happening on the respective Discourse thread . I am now announcing the start of the final comment period for the adoption of this RFC process. We are deviating from the proposal’s 14-day period for this occasion and instead will consider concerns raised up until October 4th at 23:59 UTC. All active GNOME Foundation members remain invited to contribute to the discussion.

The proposal of this RFC process is part of a broader initiative to improve the governance and coordination within the GNOME project. You can learn about other initiatives in Emmanuele Bassi’s latest Some more governance talk, and his older Governance in GNOME blog post.

The GNOME Foundation is supporting contributors with its fellowship program . You can help expand the fellowship program with a donation .

The previous month concluded with releasing the beta versions for GNOME 51. So this month, it was about time to get the bugs fixed in the beta releases.

Tales of a Dicey API

To give you a peek into my work, I’ll walk you through debugging an annoying issue. This problem had been floating around for a while during the GNOME 51 cycle. GNOME Shell was failing to load some of the app icons in the app grid. While I was pretty sure that the issue wasn’t the fault of libglycin, I finally decided to track down the problem myself. Luckily, running a nested GNOME Shell is pretty simple and well documented . Tracking down the key symptom was a question of systematic search. As it turned out, glycin was blocked as soon as it reached any asynchronous Gio.File operation. But why? Dumping the tracebacks of all the GNOME Shell threads via gdb gave an insight into Shell’s state: There were a lot of threads named pool-<n> , blocked on waiting for Gly.Loader.load to make progress. That’s exactly how Gio.Task names threads in its thread pool.

Hence, we had two important observations: Operations like Gio.File.open_async were not making progress. At the same time, there were a lot of threads on the Gio.Task thread pool that were stuck on calling Gly.Loader.load . Knowing more about GIO’s internals, this would immediately reveal the issue. Knowledge that I was lacking. I read GIO’s async documentation yet again, but I still couldn’t make sense of this behavior. Luckily, Sergey Bugaev and Sebastian Dröge immediately connected the dots: GIO’s async operations on Gio.File rely on the Gio.Task thread pool internally. However, the creation of new threads in the pool is heavily throttled . With that context, the issue became clear: GNOME Shell was trying to spawn as many threads as there are app icons via Gio.Task.run_in_thread , each thread waiting for a Gly.Loader.load call to return. For Gly.Loader.load to load the app icon from the disk, Gio.File.open_async would need a thread on the thread pool. However, as soon as the throttling allows the creation of a new thread, GNOME Shell would spawn yet another thread to load another app icon.

As far as I know, this interaction of the user-facing APIs like Gio.Task.run_in_thread and GIO’s async internals is not documented anywhere. Generally, just spawning as many threads on the task pool as possible is quite a fragile design decision, as it is hard to reason about and ensure that this is not starving other important operations from obtaining a thread on the thread pool. These are issues well known to some people. One suggestion has been to just remove or reduce the throttling of thread creation. However, designs like the one in GNOME Shell show that API consumers rely on the throttling, since otherwise, Shell might spawn in the order of hundreds of threads in one moment. There are also unsolved issues with memory management that go back to 2018. I think it is time to act on the conclusion that many people already had: This GIO feature is fundamentally broken. I have now proposed to deprecate the API.

After understanding the issue, something else clicked for me: I had seen issues with Nautilus mysteriously being stuck on file copy operations for a while. Now, that made sense: Nautilus was blocking the Gio.Task thread pool with loading thumbnails, running into the same issue as Shell. But not only were thumbnails not loaded, other Gio.File operations were blocked as well. While I previously thought about just fixing GNOME Shell by properly using libglycin’s async API directly, it now became obvious that far too many apps might rely on being able to occupy the complete thread pool. Hence, libglycin’s sync API would need a workaround for at least this cycle until the issues could be addressed properly in the API users. Glycin now tracks the information of something being a sync API call and then uses GLib’s sync APIs internally.

Hopefully, we can port our apps to using proper async APIs for GNOME 52.

Other Work

Of course, I worked on lots of other things this month. Here is a short overview.

Glycin

• • Fixed broken colors after editing a rare kind of JPEG where colors are encoded as RGB instead of YCbCr.
  • Allowed editing JPEGs with dimensions larger than 16,384 × 16,384 pixels. This was previously prevented due to accidentally using zune-jpeg’s default options in editing.
  • Added some missing API documentation.
  • Worked around a memory leak in gtk-rs’s gio::spawn_blocking . This issue has been fixed in a new gtk-rs release by now.
  • Finally merged the pixel density support in gdk-pixbuf’s libglycin shim.

Loupe

• • Fixed some issues with the new dialogs asking to save unsaved changes when editing.
  • Fixed a race condition when showing an edited image. This is still not completely behaving as intended and will need some more work during the GNOME 52 cycle.

Other Projects

• • Cleaned up the code for cargo-lock-analyzer . Also added an overview of Rust dependencies with security issues in our stack. This is still pretty experimental, and I’m thinking about how we can integrate this into a larger security tracking system for our dependencies.
  • Updated some apps to resolve open security issues. However, none of them seem to have any practical relevance for us.
  • Brought the proposal for an RFC process to the next step. It is now a merge request , following the RFC logic. Incorporated some of the feedback.

Outlook

This month was a bit slower than the previous month, since I worked some additional hours in July. Due to my disabilities , my contract is about the equivalent of a 1/3-position. I am very thankful that the Foundation has accommodated that. So my progress might be a bit slower in general.

For GNOME 52, there are exciting things ahead: Inkscape has ported their handling of raster graphics to libglycin. However, they still need CMYK and PNG interlacing support in libglycin to land the changes. This is something I will work on soon. For Loupe, there is an open merge request for saving images in different formats, which I’m looking forward to being completed.

Support the GNOME Project

The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please consider donating .

The second month of the Fellowship is already over, let’s see what I got up to this month

Nautilus

I started implementing Tobias’ redesigned “Open With” mockup . The foundations to make the changes are done, as are most of the UI changes. Here is a preview:

Due to technical limitations the design will need adjustments. Nautilus only can retrieve information about one recently used application per file type, but the mockup intended to have the displayed apps sorted by recency (and then limited to only showing 5 of them). Nautilus could start tracking app usage itself, but it probably would make more sense to have it in the App Chooser Portal . Unfortunately the portal currently does not support opening more than one file. For now I will implement a compromise of the mockup in nautilus and in parallel work on a proposal to extended the portal API to also cover opening multiple files.

While working on the app chooser I also found some fixes an improvements for it that still made it into the 51 release. Additionallyation per file type, but the mockup intended to have the displayed apps sorted by recency (and then limited to only showing 5). Nautilus could start tracking app usage itself, but it probably would make more sense to have it in the App Chooser Portal . Unfortunately the portal currently does not support opening more than one file , I fixed memory trimming when closing a window , removed mispositioned menu entries and made navigating feel slightly smoother .

I also investigated an obscure bug with the location entry and figured nautilus could be a lot more efficient when getting completions. Instead of checking the contents of the typed path for each entered letter, it’s enough to only do that whenever the typed directory changed. (So far only some cleanups for that are ready.)

Sushi

I continued polishing sushi for the 51 release, which will be the first major overhaul it has received since its initial release 15 years ago. Tau Gärtli and I ping-ponged many MRs between one another, which can be seen by the extensive release notes for 51.rc . Some of the changes I made this month:

• Add a plugin example with support for shortcuts and UI files
• Forward Trash and Rename shortcuts to nautilus
• Add play/pause shortcut for audio and video files
• Hide titlebar on fullscreen
• Various leak plugging, bug fixes and cleanups, including obsoleting some outdated mime type lists

gnome-autoar

gnome-autoar is a convenience library that is built around libarchive and provides nautilus’ archive capabilities. It also offered some archive-related widgets, which made it depend on GTK3, and therefore by extension made nautilus depend on GTK3. The only known consumer, Evolution, had already inlined those widgets, so they were ripe for removal.

I fixed and modernized the CI, fixed-up and landed Emmanuele Bassi’s MR to remove the GTK3 widgets, landed a combination of MRs by Iñigo Martínez and Corey Berla for modern docs and added the release service CI pipeline to create a new release, which was accepted into the 51 cycle via a freeze exception .

With that, nautilus shouldn’t have any direct GTK3 dependencies left, only the recommended usage of xdg-user-dirs-gtk which I will tackle in the 52 release cycle.

Roadmap

As this month was at the end of the release cycle, I focused a bit more on things that could still make it to the next release. I still made some progress on the open-with rework though.

Support the GNOME Project

The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please consider donating .

AI Summary

Still trying to locate the XDG creature, the group heads to the archive, where they meet Autoar. The old gnome mage has fallen prey to the curse of Groaning Time Konundrum, but clear instructions on how to lift the curse are already prepared, along with others on how to improve the archive in general. Thankful for having their curse lifted, Autoar prophesizes that the group will achieve great things in the next sun cycle and points them to instructions for creating portals. Together they enjoy some of the freshest sushi rations they had in the last 15 years.

Important note: All statements in this blog are fictional.

Once again, GNOME is considering participating in the Outreachy internship program. Outreachy provides internships to people subject to systemic bias and impacted by under-representation in the tech industry where they live.

Outreachy internships are funded by the participating communities. While the GNOME Foundation has not yet finalized the budget for this cohort, having a strong list of proposed projects and available mentors helps the Board decide how many slots to fund.

Project ideas will be selected based on available funding and their relevance to the overall goals of the GNOME project. Project selection will be handled by Matthias Clasen, Allan Day, and Sri Ramkrishna.

If you are a GNOME developer/maintainer available for mentoring between December 2026 and March 2027, please submit a project proposal at gitlab.gnome.org/Teams/internship/project-ideas as soon as possible (by September 11).

If you have any questions, you can contact the Internship Committee on Matrix or ask on Discourse .

It’s hard to evaluate the security of open source projects when security bug reports remain private forever. Users deserve to see security bug reports, so please remember to unset issue report confidentiality when you’re done handling an issue. There are very few good reasons to keep an issue report confidential forever. If you’re not planning to disclose the issue report within the next few months, it should probably already already be public.

For GNOME, I disclose issues whenever a merge request has been created or a fix lands in the git repo, or 30 days after the issue was reported , whichever comes first. Your project might prefer to wait until the fix is released before disclosing, especially if you fear that a vulnerability might actually be exploited during the window between the fix and release. Whatever you choose, please don’t forget about it and leave the issue report confidential forever. That’s not fair to your project’s users. Even if not many people will take the time to look, users should at least have a chance to see reported issues.

I realized that deleting local copies of files early and often is better than keeping them forever.

I'm the kind of person who will work on something, share their work, and then just let the file I had linger around indefinitely. You never know, it's better to have a local copy, it can save the day. Or you keep it at hand when you're offline. And do I really need a reason to keep a copy of the file I was working on anyway? Hoarding files and keeping them forever is tempting.

The one thing I've overlook in the past is context. When I produce or get a file, I do so in a specific context. But if I want to do some cleanup later I will certainly have lost that context, or have fragments of it. I won’t know if I can delete it safely or not, so I will keep it forever. The longer a file has been around, the more difficult it becomes to delete it.

The best thing I can do in a work context is to make it not a me-problem. Whenever I get or produce a file, I make sure there is a copy of it in a company shared drive, and I delete it from my machine as soon as possible.

Throwing it over the fence is bad behavior of course, so I make sure it’s stored somewhere with as much context as possible for people who need to use it. My machine stays decluttered, and if it’s stolen I "just" lose hardware, I have a safe copy of my work data, and there is little to leak on my (encrypted) disk.

Note: this is true for documents because all versioning systems are terrible. This is not true for code thanks to git and the like.

For a while now, the fingerprint management UI in GNOME Settings (gnome-control-center) has felt outdated. While it worked, the layout and enrollment flow hadn’t kept up with the rest of GNOME’s modern interface updates.

I am happy that during the GNOME 51 development cycle we managed to address that. Allan Day, Marco Trevisan, and myself worked on modernizing the interface . There’s still more work to do in the UI and in fprintd, but what we will ship in 51 is already a great step forward.

Historically, the fingerprint dialog in User Settings was stuck on a GTK3-style design. Even after being ported to GTK4, conceptually it remained unchanged. Beyond looking out of place alongside Libadwaita-based settings panels, it suffered from responsiveness and accessibility issues that made it difficult for some users to enroll their prints.

Screenshot of the Fingerprint Authentication dialog

The new fingerprint management dialog uses a standard boxed list displaying your enrolled fingers. From here, each enrolled finger can be removed individually.

Clicking the “Add Fingerprint” button starts the finger enrollment process. First, you choose one of the unused finger options to enroll. From there, an assistant guides you through the scanning process. As you place your finger on the reader, the UI detects the touch and provides feedback on whether it was read correctly. You continue touching the reader until enough samples have been collected (the exact number depends on your reader’s driver). Once the progress bar fills, your finger is ready for authentication.

Screenshot of a fingerprint enrollment

This is only one of the improvements that GNOME 51 is bringing. As with everything in GNOME, we will continue gathering user feedback and making iterations over time. There are already more fingerprint features in the pipeline, such as renaming enrolled fingers and verifying individual prints. Stay tuned!

• Up earlyish, still a painful back - there is a thought that I should actually do the exercises from the physio - so tried that.
• On to the Carlisle Congregational Church with Joel Schofield - great talk on Psalm 131, enjoyed catching up with some smart cookies afterwards - learned how satellites shed heat, how heat-pipes work, government project management and much more.
• Out for a Diner brunch with T&B, bid a sad 'bye to H&M. at Logan, swapped the car for a less odiferous & maggot infested machine - nice.