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:
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.
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!
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.
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.
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.
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.
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.
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:
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.
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).
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.
Some time ago I visited a used book fair and came across this awesome piece of 80s scifi-asthetic.
This book is a collection of short stories by the Polish author Stanisław Lem originally published in 1964. Its English title is The Cyberiad. One story, about Trurl's electronic troubadour, turned out to be surprisingly topical.
Spoilers for the whole story follow
The inventor Trurl (revealed in other stories to be a robot) wants to create a machine that can generate poetry. He begins by obtaining several hundred tonnes of books to use as training data.
Trurl gets to work constructing the electric poetry machine. In the process they have to create massive data storage containers that stretch further out than one can see using binoculars. This is considered a necessary evil to get this great invention going.
The machine will not work as expected. As a last resort Trurl rips out all logic circuits and replaces them with "narsistors". Then things start working.
Trurl invites his friend Klapaucius over to test the new machine. They give it all sorts of weird and wacky instructions like "create a pastoral love poem that also contains mathematics and cybernetics". Basically they do a whole bunch of prompt engineering. They talk and behave exactly like people of 2021-2023 did when LLMs first appeared.
Eventually the machine causes uproar among poets and there are protests demanding it to shut down. These go nowhere in part because the media secretly love the machine. They are using it to create their own content for pennies and thus don't want to see it come to harm. As all of this is going on various people develop symptoms quite similar to modern day AI psychosis.
Things eventually crash when Trurl gets the machine's electrical bill, which turns out to be astronomical. He needs to get rid of the machine and manage to dump it on a visiting dignitary who takes it to his home planet where causes a supernova explosion. Trurl deems that to be sufficiently far away to not be his problem any more.
The difference between fact and fiction
In the story all the problems are caused by the fact that the machine's output is vastly higher quality than anything humans can create. Even the great Stanisław Lem could not predict that in reality the output would turn out to be mediocre garbage and still lead to all the same problems.
Even though the story specifies that the machine is given some "basic instructions" first, nobody tries to do a prompt injection attack on it. That would only appear almost 30 years later in 1993's Paranoia novel Title Deleted for Security Reasons. An earlier example may well exist somewhere, it almost always does.
The GNOME 51 Flathub SDK is now based on the Freedesktop SDK v26.08. The GNOME Beta SDK is available from Flathub Beta as org.gnome.Sdk/x86_64/51beta and GNOME Nightly as org.gnome.Sdk/x86_64/master.
You might need to update the sdk-extension and append-path in your Flatpak manifests to newer versions like LLVM 22, and install newer versions of the extensions on your local system like org.freedesktop.Sdk.Extension.rust-stable//26.08beta.
Hello everyone! I’ve been working on GPU reset recovery in Mutter through the summer, under the mentorship of Jonas Ådahl, Robert Mader, and Carlos Garnacho.
Previously, a GPU reset would take the whole session down, crashing or freezing it. That’s no longer the case: Mutter now detects a reset and recovers automatically, restoring windows, background, cursors, and text, all in an instant. The work isn’t fully done: GNOME Shell doesn’t recover completely yet, and real hardware testing has been trickier than expected, but the implementation is up as an upstream MR for review, and I’ll keep working on it after GSoC.
Full details, demos, and some of the more entertaining debugging stories are in my wrap-up post.
This is modest release, which contains some quality of life improvements:
Generic annotations for Async.
Path separator (/) support for Gio.File objects, similar to pathlib.Path.
Updates to tutorials and examples.
Behind the scenes, this release includes an update to the marshalling code. Now it’s easier to clean up after a call is dispatched from Python to C or visa versa.
Lastly, the ability to find libraries automatically on Windows has landed in this release. Before, you had to call os.add_dll_directory() for each directory which contains DLLs you want to use. Now, a default directory are added, relative to where PyGObject is installed.
Libglycin 2.2.beta.1 has been released. This release brings two important workarounds. The first avoids triggering a memory leak in gtk-rs that has been fixed upstream but where a gtk-rs bugfix release isn’t available yet. The second workaround avoids using the async Gio.File API in libglycin’s sync API. The Gio.File internals rely on at least one thread being available in the Gio.Task thread pool. However, it is currently commonpractice to starve the complete Gio.Task thread pool via Gio.Task.run_in_thread() when using sync APIs. Therefore, libglycin now internally uses Gio.File’s sync API for executing blocking functions like Gly.Loader.load().
Sophie’s work is funded by the GNOME Fellowship program. You can support the fellowship program via a donation.
Together with Modal, I’m happy to announce that the Sovereign Tech Agency is investing nearly €510k into Flatpak development. The focus is on closing gaps in Flatpak’s sandboxing story: new portals for audio, networking, VPNs, and spell checking, plus infrastructure work on entitlements and intents.
I’ll be leading the technical side alongside Adrian, with organizational support from Kateryna and Cade. We’ve brought on a great team and the project will ramp up over the coming months through the end of 2027.
Test Center is a new native app to manage experimental versions of apps (flatpak) and system components (systemd sysext, only available on GNOME OS), similar to Apple’s Test Flight. The initial version we just released supports installing and managing both types of experiments, but we have a lot more planned including a built-in feedback workflow, updates, expiration dates, and an integrated “first-run” dialog for experimental apps.
After the initial release, our next focus for Test Center is adding “studies”, i.e. developer-curated experiments with a custom name, icon, testing instructions, etc. This requires metadata that is not part of the merge request itself, which means more complexity in the developer workflow. To get your input on this we’re having another community call on Thursday, September 10 at 13:00 UTC.
Graphs is now available in the GNOME nightly repo. You can get the latest build straight from the main branch by adding the GNOME Nightly repo using flatpak remote-add --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepo, after that you can just install Graphs like you’d usually do.
The current nightly includes some enhancements, such as a further optimized codebase and a much improved math parser. But also the handling of very large data files. Instead of crashing or locking up the application, Graphs now uses a LOD-based approach and downsamples large datasets visually to a maximum of 5000 datapoints, still drawing over one datapoint per pixel even at 4K resolutions. This behaviour can be turned off for each item for the sake of scientific accuracy.
Another major feature that already has landed in the nightly build is the implementation of fills. This enables you to add visually pleasing fills above, beneath or between curves, or use a fill area to e.g. show error margins. Fills can be coupled to any number, equation or even to another item in Graphs.
I’ve also been experimenting a bit with implementing free variables, as well as the introduction of support for date-time datapoints. But there’s no set ETA for that as yet, and both features need some rethinking so edge-cases are dealt with more cleanly. Such features will hit the nightly first though. Note that the nightly version is always in active development, and is purely meant for testing purposes. You can expect things to break from time to time, and project data might get corrupted. Do not use the nightly for mission-critical work.
For those of you looking for a modern mail suite dedicated to GNOME, here is Stamp.
Over the last two years I’ve been working on Stamp as a modern replacement for Evolution’s user interface, suitable for both private and business accounts. It is based on the Evolution Data Server backend, combining its proven reliability with a modern Adwaita interface.
Besides standard mail features, Stamp also supports a number of Microsoft 365 features such as Internal/External identifiers and Categories, which are quite common in enterprise environments. Thanks to its Adwaita-based design, it also works well on mobile devices.
Mail and Contacts are already integrated, and Calendar support is available in a pending merge request based on GNOME Calendar as a library. Future versions will make these components pluggable, allowing Stamp to be shipped as a standalone mail client or as a complete personal information suite.
Newelle, AI assistant for Gnome, has received a new major update, which brings a lot of UI refinements, improved agentic capabilities and other interesting features.
Highlights
(I have written personally with my keyboard every single character of this description. Emojis are indicative of what is each feature, stop complaining under each post)
🖥 Improved terminal tool, Newelle can now manage persistent Terminal sessions and interact with TUIs
💫 Mode switching: users can now create custom “modes” that quickly change prompts, tools and skills (ex. Planning mode)
📲 Added a curated catalog of MCP servers that can be used to connect your applications to Newelle
🌐 Added citations, the LLM can now state the source of an information
➕ You can now add LLM providers directly from the UI (OpenAI/Ollama/Anthropic compatible)
🚀 Improved text generation animation
🔻 Added “Compact Mode” for tool calls and input bar
🧩 You can now download and explore new extensions and skills directly in Newelle
✏️ Added a Skill editor to create and edit Newelle Skills directly from Newelle
RustConn 0.21.0 is out - connection manager for SSH, RDP, VNC, SPICE, Telnet, Web and Zero Trust (GTK4/libadwaita).
New features: portable encrypted credential store you can sync through a cloud folder, with tools to copy stored passwords between any two backends and to change the passphrase; a jump host that can be set once on a group or for the whole application and is inherited by SSH, SFTP, RDP, VNC and SPICE, with a per-connection Direct override; window sizing for the external RDP client; an option to reveal the session toolbar on hover or on click only; connection names in split panes; a flat accent Shell button in the header bar instead of the oversized pill; Georgian translation, so 17 languages now.
Fixes: the sidebar context menu opened and vanished within a frame on GNOME Wayland, and did not open at all when there was no room below the pointer; the terminal started at 24x80 in Flatpak instead of its real size; telnet, ssh and serial processes stayed alive after quitting, and quitting from the tray tore nothing down at all; a jump host set on a group or globally was stored and shown as inherited, then dropped at connect time; the Secrets page could stay empty and a KeePass operation could freeze the window with no way out, so every credential-path subprocess now has a deadline; SPICE asked to install virt-viewer on machines that already had it; Simplified Chinese had never loaded in any package; minimizing to tray silently killed port forwards, recordings and external viewers; nine dependency advisories are gone along with the GTK3 binding stack that the macOS tray was pulling in.
Thanks to everyone who uses RustConn, reports bugs, contributes or supports the project. If you’d like to support development - the repo has a Sponsor link.
Whisp is a minimalist, folder-less note-taking application built for speed and simplicity. Designed around a fluid, gesture-driven interface, it features powerful text-expansion capabilities to help you capture and organize your thoughts without the friction of a traditional file system.
This week, we released Whisp v1.4.1, bringing several productivity enhancements and UI polish to the app:
Instant Export: You can now instantly export your current note to a file directly from the main menu.
Native Markdown Lists: Creating lists is faster than ever—typing - or * followed by a space now automatically formats the line as a list item.
Smarter OCR: The Smart Paste image-to-text engine now correctly preserves hard indentation and paragraph structures from the original images.
GNOME HIG Polish: We replaced the old update popup with a sleek, non-intrusive update banner, and fixed a responsive layout bug that caused the Preferences dialog to clip on narrow screens.
Bouncer 50.2.0 has been released! This release brings closer alignment with the GNOME Human Interface Guidelines, including the ability to undo changing a network’s firewall zone or forgetting a network, more consistent controls, and clearer empty states. Bouncer also handles more edge cases and error conditions, with improved feedback and recovery options when saved networks or firewall information cannot be loaded. Spanish translations have been added, and Occitan and Danish translations have been updated. The new release is available on Flathub.
The Calendar Reminders extension has been released! It replaces the Evolution reminder notifications with ones that fit GNOME Calendar better, which allows you to join virtual meetings straight from the notification itself, open the GNOME Calendar app to the event, or snooze the notification.
ChromaLeon v2.2.0 has been released with new styling options and a significant restructuring of the theming logic for GNOME Shell.
ChromaLeon is an extension I created that can change the accent colors of GNOME Shell and applications based on the wallpaper’s colors, as well as apply tinted styles, generate a dynamic icon pack, and more.
The focus of the v2.x.x updates was to resolve structural issues and simplify maintenance, thereby extending the extension’s lifespan and improving contrast standards relative to the GNOME interface.
Key improvements in this version include:
New style application logic: ChromaLeon now applies Shell styles as a theme rather than an overlay stylesheet. This resolves any conflicts with other extensions.
Simplified maintenance: All styles are now based on a copy of the default GNOME Shell theme. This makes it easier to track changes in new GNOME Shell versions, preventing conflicts or missing styles.
Improved contrast: ChromaLeon previously had methods to adjust contrast for very light colors, but issues remained with very dark colors. ChromaLeon now also adjusts very dark wallpaper colors to ensure optimal contrast with the dark theme.
New fully light style: This option applies a light style to the entire Shell, unlike the default GNOME light theme, which keeps the overview and app grid dark.
Better contrast in the light theme: The light theme now offers improved contrast for interface elements compared to the default GNOME light theme for the Shell.
Additionally, many bugs reported in the repository or identified by me have been fixed, resulting in greater stability during use.
I would also like to give a special thanks to the developer of the Luminus extension. The “fully light” style was based on it.
Aurora Shell is making its first appearance in TWIG 🎉. It is a modular extension for GNOME Shell 50 with a configurable dock, Clipboard History, Capture Tools for screenshot annotation and local OCR, Tray Icons, Meeting Clock, Weather Clock, and privacy helpers. Each module is optional and managed from the same preferences window.
Version 50.12 is mostly about the dock. It can now sit on the bottom, left, or right edge of the screen. Users can set a maximum icon size from 16 to 64 pixels and turn on live window previews with window actions. Window Previews is off by default and can be enabled under Dock & Panel → Dock.
Outside the dock, Meeting Clock now extracts conference links from redirect and tracking URLs and requests another banner when an active alert fires again. Tray Icons now loads icons supplied as absolute SNI paths.
Google Summer of Code 2026 has come to a close, so here’s where things stand with GPU reset recovery in Mutter. If you’re catching up, the short version is in my intro post: a GPU reset invalidates the EGL context and wipes all GPU memory, and until now Mutter had no way to come back from that. My project is a recovery mechanism so a reset doesn’t take the whole session down. Here is what things look like now:
Mutter graphics recovery demo
In the video: After a period of normal operation, a reset is triggered. Mutter recovers successfully and is back to normal operation instantly. Everything is restored, from the background to windows and cursors. Then a loop is executed to trigger a reset every second while various activities are performed within the session. Through it all, Mutter remains unfazed and the session responsive.
The display stayed blank until the creation of a new framebuffer was manually forced (I triggered it with a window maximize keyboard shortcut in that demo).
The desktop background came back with garbled/wrong textures.
Both of those are now fixed, along with a lot more that wasn’t even in scope for that post yet.
A Well-Defined Recovery Order
My previous update touched on this problem: recovery involves a lot of GPU-associated state scattered across Cogl, Clutter and Meta, and a lot of it depends on being torn down and rebuilt in a specific order. The font renderer needs the stage unrealized first; the stage needs stage views rebuilt before it can be realized again; and so on. The earlier approach made use of a single signal on ClutterBackend, and relied on G_CONNECT_AFTER and GLib’s signal connect order for ordering, which worked but was fragile and implicit. That’s now been replaced with a dedicated ClutterGraphicsRecoveryContext type encapsulating all the core recovery logic, and whose signals are emitted in a fixed, well-documented sequence:
Graphics recovery signals
Anything in the compositor that owns GPU-associated state now hooks into one of these instead of guessing at ordering. Only recreate-context can actually fail; if it does, recovery aborts there and recovery-failed is emitted instead of continuing on to recreate graphics resources.
What Else Recovers Now
Framebuffer and background: The display now comes back on its own, no manual nudge required, and the pause is virtually unnoticeable. There is no blackout, at least from the compositor’s point of view. To the user, however, monitors driven by a GPU that resets may briefly go dark. The desktop background restores correctly and immediately: when a background image is set, loading it from disk can take a moment, so a plain colour is shown in the meantime. One caveat worth flagging for anyone testing this: background image loading was recently moved out of Mutter in !4980. That means reloading the image and reuploading its texture after a reset is no longer something Mutter can do on its own; it now falls on downstream consumers (like Shell) to handle it.
Window and surface content: Wayland surfaces restore to their last rendered frame right after recovery, instead of going blank until the next commit. When a client commits a new buffer in the narrow window between when a reset occurs and when it finishes, and the buffer attach fails because the context is already lost, the surface gets a dummy texture so nothing crashes, and the real content replaces it when we re-attach the buffer during restoration.
Cursors: Both Xcursor-based cursors and Wayland client cursors restore their textures on reset.
Actor effects: All ClutterOffscreenEffects (blur, desaturate, deform, shader, etc) recreate their GPU-side pipelines and textures on reset instead of quietly holding onto invalid ones.
Stream sources: Screencast and remote-desktop pipewire streams stop and restart cleanly around a reset, recreating the necessary GPU-side resources instead of ending up in a broken state.
Overlays:MetaOverlays (used for things like cursor sprite compositing) recreate their pipeline and texture too.
Along the way, a decent amount of the codebase moved from static and class-level CoglPipelines to named pipelines owned by the CoglContext, specifically so they’d get recreated automatically instead of leaking or going stale across a reset.
Tales From The War Front
The context that died too soon and then never died
Historically, objects didn’t take references to CoglContext; they simply held bare pointers to it. The reason was that there was only a single context for an entire session, which got destroyed at exit after all the objects associated with it had been destroyed.
Since the context is now recreated during recovery, this introduced a whole new problem: some objects now outlived their associated CoglContext, resulting in use-after-frees and segfaults. Specifically, some objects can not be destroyed until they’re replaced by new ones (after we have recreated the context) because they hold on to crucial states which get destroyed by lower levels of the stack as soon as they become inactive. There’s also the case of garbage collection, e.g in Shell, where the garbage collector may keep objects alive after we’ve destroyed their associated context.
To solve this, every object holding a pointer to CoglContext now takes a reference, and the context is explicitly disposed of and marked as defunct during recovery. The use of a defunct context is restricted so associated objects don’t make use of invalid data and silently corrupt memory. The context is finalized when the last reference to it is dropped. Also, with this change, we can more easily spot objects that needed to be restored after a reset.
With this in place, defunct CoglContext objects were, for a while, never finalized after a recovery cycle; they’d plateau at a fixed refcount and stick around. Tracking it down took multiple long GDB sessions. The actual root cause, once Jonas helped dig further, turned out to be leaked CoglPipelines and pipeline cache entries. The stencil and current pipelines weren’t being unrefed by the context, which in turn kept the default pipeline (their parent) alive too. There was also a cyclic dependency in CoglPipelineCache that only surfaced as a use-after-free once those pipelines were finally unrefed. Two separate bugs stacked on top of each other, and the second one was hidden by the first.
The popup that broke hell loose
During recovery, the whole actor tree is unrealized and re-realized, which started by unmapping everything from the stage down. With a popup open when reset occurs, this crashed at an internal invariant check. A thousand steps (in GDB) later… It turned out a ClutterInputOnlyActor, owned by the popup’s ClutterGrab, was getting destroyed mid-unmap. A grab doesn’t hold its own reference to an actor it owns. So when the actor got unmapped, the grab was detached, which in turn disposed of the actor, removing it from the tree. So, the unmap loop lost track of the next sibling and left the rest of the tree mapped.
The apparent fix was to have ClutterGrab take a proper reference to the actor it owns and pre-fetch the next sibling before unmapping so the loop doesn’t depend on an actor that might disappear underneath it. It worked, in the sense that the crash went away, but it turned out that removing a grab actor during recovery broke other things further down the line in ways that were harder to pin down. The real problem wasn’t how the unmap loop handled a disappearing actor; it was unmapping the actor tree at all as part of recovery.
The actual fix was to stop unmapping the stage during recovery entirely. Two new private methods, _clutter_actor_realize_mapped() and _clutter_actor_unrealize_mapped(), unrealize and realize the actor tree recursively while leaving everything mapped, with a flag on ClutterActorPrivate carving out an explicit exception to the established unmap-before-unrealize / realize-before-map invariant. Recovery now uses these directly without unmapping and mapping the stage, so the popup, its grab actor, and everything else stay exactly where they were.
The time-travelling touch
For a while, single resets were sometimes turning into two or three in a row, with no clear pattern. The reset trigger mechanism (used for testing without messing with real hardware) works by touching a file that llvmpipe watches for a changed mtime. That file lived in a virtiofs-mounted directory shared between my main machine and the test VM, and the mtime it ended up with was consistently a bit ahead of the VM’s and even my main machine’s clock at the time of touching the file, sometimes enough that by the time one recovery finished, the file still looked “new” and triggered another reset. Not a bug in the recovery logic at all or the manual reset implementation, just a quirk of the shared filesystem layer. Moving the trigger file to the VM’s own local filesystem made it go away.
Here’s a sample from one of my debug sessions (timestamps are the giveaway):
$ date -Ins && touch ~/llvmpipe_reset && date -Ins
2026-07-31T15:53:34,157134442+01:00
2026-07-31T15:53:34,160985080+01:00
$ stat ~/llvmpipe_reset
...
Modify: 2026-07-31 15:53:34.255579148 +0100
...
The recovery mechanism itself is solid: Mutter survives GPU resets, the session stays alive and responsive, and the visible state (background, windows, cursors, text) is restored correctly, automatically and instantly. There are still a couple of edge cases I’m chasing down, mostly around rapid resets, but nothing that looks architecturally hard, just more debugging.
The implementation has now been submitted upstream for review. By the way, that MR is a clean recommit of the whole branch. The real development history, which can be found at my fork, was a lot messier: a lot of iteration, backtracking, and reordering as the design of the recovery cycle itself evolved. Once the approach stabilised, it made more sense to rebuild the commit history cleanly from the current state than to untangle months of exploratory commits.
Real hardware testing has also been trickier than expected. On the AMD GPU I tested with, the default reset method used by the kernel driver (MODE2) turns out not to invalidate EGL contexts, which means it can’t exercise the code path this project implements. The other reset modes either weren’t supported by the driver or failed outright. So testing thus far has mostly stayed in the VM, using the llvmpipe reset simulation Robert implemented before GSoC started.
Honest Note On Scope
Going by the goals set out at the start, this isn’t finished. A few things from the original plan are still ahead:
GNOME Shell doesn’t fully recover yet: After a reset, Shell recovers successfully, but not completely. On-screen framebuffers, windows, cursors and text are restored. However, the Shell UI (the chrome, overview, widgets, effects, and icons) and desktop background image are not restored. Here’s a recording showing the current state of the UI:
GNOME Shell UI recovery state Note: This was recorded with a modified branch; with the unmodified branch (at the time of this writing), Shell currently crashes, as expected.
The llvmpipe reset simulation is not yet wired into tests or CI.
Real hardware testing is still an open problem, for the reasons stated above.
I’ll keep working on these after GSoC.
What’s Next
Chase down the remaining edge cases
Get GNOME Shell recovering reliably; a few known to-do items include:
Clear the background cache and reload the image (will restore the desktop background)
Clear the texture cache (should restore icons)
Clear the theme node cache (should restore widgets and effects)
Add test coverage using the llvmpipe reset simulation, and get it into CI
Find a real hardware reset setup that actually exercises context invalidation
Push the MR through upstream review
Reflection (A Personal Note)
I still remember opening gsoc.gnome.org on that fateful day “just to see what GNOME’s doing this year” and scrolling down just to see this project, and I was immediately drawn to it. I had known graphics was the path I wanted to take, and this project checked so many boxes. At the same time, I couldn’t deny how daunting it seemed. Yes, I have done some graphics work in the past (my GSoC project last year, in Uni and personally), but nothing of this scale. Anyway, I decided to take up the challenge; after all, why do it if it isn’t challenging?
Here are two notable challenges I faced, from which I also learned a lot:
The sheer mass of the codebase: Man, Mutter is huge !! Coupled with the fact that my project cut across every layer and almost every aspect of it. I wasn’t building a compositor, but I had to understand how a lot of it worked. This wasn’t the kind of project that dealt with a single subsystem.
Debugging, debugging and debugging: Logs are good and have their place, but also their limits. This project required using the debugger a lot. I’ve become so much more comfortable with sifting through logs and stack frames, and stepping through thousands of lines of code.
And here are three notable lessons I learned (more of):
There’s always a simpler solution to any problem (thanks, Jonas).
Keep digging, never give up: Some of the “bugs” I encountered just kept on giving. Some were like playing whack-a-mole, others like the hydra. Life is all about resilience.
Community matters more: It’s good to get the job done, but the people we meet along the way are more important.
Throughout the course of this project, I got to do things I never imagined I would (at least, not this soon), like chatting on a kernel dev IRC . I could go on forever, but let’s call it a wrap here for now.
Thanks
A huge thank you to my mentors, Jonas Ådahl, Robert Mader, and Carlos Garnacho, for believing in me and for the guidance and hands-on help throughout. Thanks to Google and the GNOME Foundation for this awesome opportunity. Finally, thanks to the entire GNOME community and everyone who followed along this summer, asked questions, or gave feedback. GSoC has ended, but this isn’t done yet, and neither am I – more soon!
The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please 
!! Coupled with the fact that my project cut across every layer and almost every aspect of it. I wasn’t building a compositor, but I had to understand how a lot of it worked. This wasn’t the kind of project that dealt with a single subsystem.
. I could go on forever, but let’s call it a wrap here for now.