fidzu : GNOME

It's been a long time since I last posted anything here, huh.

Well, a few hours ago I was preparing the release notes for the next release of GNOME Calendar. It is yet to be reviewed, but this is how it reads at the time I write this blog post:

This is a remarkable release for us, as it is one of the biggest releases in the history of the project, and we're excited to share a slightly longer update on it.

The first thing many users will notice is how GNOME Calendar will feel snappier now. During the past six months, a lot of work was put in optimizing GNOME Calendar from the inside out. This includes a major change in how it handles events internally, vastly reducing the amount of data transferred between GNOME Calendar and other components of the desktop, and applying many different tricks and strategies to make it render faster. Really, this is probably the most optimized the project has ever been.

Another front in which GNOME Calendar has been consistently improving is accessibility and keyboard navigation. During this development cycle, another big batch of improvements on these fronts were merged. You can now navigate between events and days in the Month view using only your keyboard. Notification bubbles are properly read out loud (thanks also to Orca developers for accommodating our use case!). The Week view is now properly styled when the high-contrast setting is enabled.

[…]

On the non-technical side, in the past few months the project received contributions from many new contributors, as well as long time contributors. Our issue tracker continues to be in excellent shape, well triaged, and properly labeled. Our three latest releases were the biggest releases in the history of the project. Thank you all very much for using, developing, documenting, translating, testing, and fixing GNOME Calendar!

This release of Calendar has lots to talk about. It is, as mentioned, the biggest release in the history of the project. Not in numbers of line added, or patch count, but certainly in terms of contributor involvement, code reviews, code quality, and features. We're not just a bunch of bored university students pushing unreviewed patches non-stop to the main branch anymore!

For the next few weeks, I'll be writing more focused blog posts about the work I've done in Calendar this cycle. I've focused mostly on performance and reorganizing the internals of the application to be more resilient. It's not glorious work, but I do love working on optimization problems!

GNOME Calendar will complete 15 years in a few months from now. The project is one of the few lucky projects in GNOME - and, I'd argue, in the free software scene in general - that has such a thriving community of contributors. It's one of the few GNOME core apps that survived the great purge. It's a super rare example of a GNOME app with a product manager.

It is also the project that brought me in in GNOME, so pardon me if I get a little emotional when I see the project thriving as it is, and think back of all the good friends that came and went, the hard lessons from maintaining it over over a third of my life, and the prospects for the future.

GNOME Calendar is entirely developed and maintained by volunteers. We have never received any kind of funding, be it corporate, from grants, or other forms of patronage. This gives us freedom from these kinds of influences (mostly to complain about how so many big companies fail to meet the calendaring standards that they themselves helped create), but the reality is that it is really damn hard to pitch for funds for a calendaring application.

Please consider donating to GNOME, or to the individual contributors of your choice. It makes a difference. All the difference.

10 Sep 2026 12:09am GMT

I'm looking at something entirely unrelated, but tripped over some search results that made me realise that a lot of people still think getting errors like ACPI Warning: SystemIO range 0x0000000000001828-0x000000000000182F conflicts with OpRegion 0x0000000000001800-0x000000000000187F indicate a firmware bug. This is generally untrue. We need to dive a little into what ACPI is to clarify why.

The Advanced Configuration and Power Interface¹ specification defines a whole bunch of stuff, but what's interesting to us here is the hardware abstraction it performs. While PCs are nominally a well-defined platform that's really not true at the hardware level once you get beyond a certain level of complexity. When you suspend a system you want to power down the hardware in the correct order, for instance, and knowing what that order is requires you to know details about the specific motherboard design. The approach taken in the embedded world is to just bake that knowledge into the OS in some form, which is how we end up with Devicetree. ACPI takes an alternative approach - rather than provide that information as data that has to be consumed by OS drivers, it distributes it as code.

The ACPI Source Language, or ASL, is a simple language that gets compiled into a bytecode that's then interpreted by the OS at runtime. One of the features of this language is the ability to define "Operation Regions", effectively structure definitions that describe access to underlying hardware. Let's imagine a simple device with two exposed registers. The first is an index register - it describes which internal register we want to access. The second is a data register, where reading it gives us the value of the internal register whose address is currently in the index register, and writing to it modifies that register. An example operation region declaration would look something like

1
2
3
4
5
6

OperationRegion(OPR1, SystemIO, 0x400, 0x2)
Field(OPR1, ByteAcc, NoLock, Preserve)
{
  INDX, 8
  DATA, 8
}

This defines an operation region called "OPR1" at IO port 0x400, 2 bytes long. Inside it are two 8-bit fields, INDX and DATA. These are to be accessed one at a time, do not need the ACPI interpreter to take a global lock when accessing them, and if a subset of the register is modified then the other values should be preserved (irrelevant in this case since the fields are only a byte wide). Now any references to INDX or DATA in this scope will trigger accesses to those registers. So, a method to read the value of register 0x03 would look something like:

1
2
3
4

Method (RD03) {
  INDX = 0x3
  Return (DATA)
}

ie, set INDX to 3, and then read the value of DATA and return it. But! What if another ACPI method is running at the same time? Let's say we have one that writes to register 0x05:

1
2
3
4

Method (WR05, 1) {
  INDX = 0x05
  DATA = Arg1
}

What happens if RD03 executes while we're part-way through WR05? INDX might get reset to 0x03, and now WR05 will modify register 0x03 instead of 0x05. Oh no! But we can avoid this - we declare a mutex (Mutex (MUTX, 0x00)), and update our methods to be something like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Method (RD03) {
  Acquire (MUTX, 0xFFFF)
  INDX = 0x3
  Local0 = DATA
  Release (MUTX)
  Return (Local0)
}

Method (WR05, 1) {
  Acquire (MUTX, 0xFFFF)
  INDX = 0x05
  DATA = Arg1
  Release (MUTX)
}

Each method takes a lock (waiting up to 0xffff milliseconds and then erroring out if it doesn't), and performs the access. There's now no chance of a race. Phew!

Now suppose someone writes a Linux driver for this piece of hardware. It accesses the hardware directly, with no knowledge of ACPI. What stops the driver from racing against one of the ACPI access methods? Nothing at all. Oh no! Again! This isn't hypothetical, by the way - here's a relatively harmless example, but back in the day we did trip over cases where temperature monitoring chips would be accessed by the firmware and Linux simultaneously and as a result you might end up thinking you're reading a temperature when you're actually reading a status flag, resulting in an impossibly high temperature and an immediate thermal shutdown.

In this case, the kernel saves you from this (potentially hardware damaging) outcome by printing a message like ACPI Warning: SystemIO range 0x0000000000000400-0x000000000000401 conflicts with OpRegion 0x0000000000000400-0x0000000000000401 (OPR1), telling you that the kernel has detected that a driver is attempting to allocate IO ports 0x400-0x401, but that there's an ACPI operation region called OPR1 that is claiming the same addresses. The kernel isn't in a position to know what type of access the firmware might perform in that region, so assumes that it might be dangerous and blocks the driver from loading.

But all is not lost! The kernel also prints some helpful advice, ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver. And ACPI tables will often actually have a definition that looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

Device (HDW1)
{
  Name (_HID, "VEND0001")
  OperationRegion(OPR1, SystemIO, 0x400, 0x2)
  Field(OPR1, ByteAcc, NoLock, Preserve)
  {
    INDX, 8
    DATA, 8
  }
  Mutex (MUTX, 0)
  Method (RD03) {
    Acquire (MUTX, 0xFFFF)
    INDX = 0x3
    Local0 = DATA
    Release (MUTX)
    Return (Local0)
  }

  Method (WR05, 1) {
    Acquire (MUTX, 0xFFFF)
    INDX = 0x05
    DATA = Arg1
    Release (MUTX)
  }
}

which defines an ACPI device and associated methods. The _HID field defines the device type, and a Linux driver can be written that will be automatically loaded if a device with type VEND0001 is seen. That driver can then call ACPI methods associated with the device and access the resources in a way that matches the firmware's expectations.

(Interested in writing such a driver? I wrote a guide back in 2009)

The firmware did absolutely nothing wrong here², but trying to load the native ddriver will generate an error and the internet will tell you that PC firmware developers are incompetent³ and you should pass a kernel argument that overrides this behaviour and it never did them any harm, and it probably won't do you any harm either but it might and you might never know why your system occasionally wedges or catches fire.

09 Sep 2026 6:15pm GMT

Hello again! A few weeks ago, I wrote about the work I've been doing this summer adding Debug Adapter Protocol (DAP) support to GJS as part of Google Summer of Code (GSoC) 2026. If you haven't read that post, start there for the background on what GJS and DAP are and why this matters.

As my GSoC is wrapping up, I wanted to share you an update on what I've done, what I've learnt, and what I'm planning for the future.

Instead of a lengthy report, I actually want to walk you through debugging a real GJS application using the DAP support I've added to GJS.

By the end of this post, you'll know how to launch a GJS app in Zed, set breakpoints (including on exceptions), step through code, inspect variables and more, all from inside your editor.

Setting Up

The code I've implemented is currently in a Merge Request being reviewed, so to you use it, you will need to clone and build GJS from source (until GNOME 52).

Cloning and Building GJS from source

You can build GJS from source by following the Hacking guide, but here's a shorter version of it

# 1. Clone GJS
git clone https://gitlab.gnome.org/GNOME/gjs.git
cd gjs

# 2. Checkout my branch
git checkout wip/vixalien/dap

# 3. Setup meson
meson setup _build

# 4. Build GJS
ninja -C _build

# 5. Verify
meson devenv -C _build gjs-console ../script.js

This will be required before GNOME 52.

Please note the path where you cloned GJS (e.g. ~/Projects/gjs). We will need it later.

Editor setup

You will also need to download and install the Zed editor. The currently supported editors for GJS DAP are Zed and VS Code. We will use the Zed editor since it's more validated to work with the GJS DAP support currently.

You will also need to install the GJS Debugger Extension for Zed, which is currently pending review to be included in the Zed extension store.

But you can build it locally, by cloning my Extension. To install within Zed, Press Ctrl+Shift+X, then click "Install Dev Extension". A file picker will open, so navigate to the directory where you cloned the extension and select it.

This will require a Rust toolchain to be installed, so the extension can be built.

Let me know if you want to debug GJS apps from other editors (not just Zed).

Navigating Around

To make this concrete, I'm going to walk through debugging an standard example application.

1. Setting up the application

The application we are going to debug is a simple Calculator, as found in the GJS Examples

Create a simple file called calc.js in a new project directory and save the contents of the Calculator app above into it.

Then open the project in Zed as you normally would.

2. Opening the Project in the Debugger

To open the project in the Debugger, you can use the F4 key to start debugging.

A dialog will then pop up asking for the Debugger configuration.

1. Select the Launch tab to launch a new debugger instance.
2. Select GJS as the debugger.
3. Type calc.js as the program to debug.
4. Disable "Stop On Entry" so that the debugger doesn't stop at the first line of the script.
5. Press Ctrl+Enter or select "Edit in debug.json" to open the configuration file.

This will create a new configuration file at .zed/debug.json in the project directory, we will use this file to configure the debugger and make sure our debugger settings are saved across sessions.

That file will look like this:

// Project-local debug tasks
//
// For more documentation on how to configure debug tasks,
// see: https://zed.dev/docs/debugger
[
  {
    "adapter": "gjs",
    "label": "calc.js (gjs)",
    "args": [],
    "cwd": "/home/alien/Projects/calc",
    "program": "calc.js",
    "stopOnEntry": false,
  },
]

We will need to make a small modification to it to point it to the GJS we just compiled (otherwise it will use the default GJS from our system, which doesn't have the unmerged DAP changes).

This is needed before GNOME 52 is released (which means gjs will be able to do this natively).

We will do it by adding a gjsPath field to the configuration in this format:

...
     "program": "calc.js",
     "stopOnEntry": false,
+    "gjsPath": "flatpak-spawn --host meson devenv -C ~/Projects/gjs  --workdir . gjs-console",
   },
 ]

Where ~/Projects/gjs is the path to the GJS repository you cloned.

After making this change, press F5 again, and now you will see an option called calc.js (gjs) in the dialog's "Debug" tab.

Click that configuration, and this will launch the debug configuration we just saved.

Now you have a running GJS debugger session!

3. Navigating the Debugger

At the bottom of the window, you will see a debug toolbar with various sections, panes and controls.

Fret not! The debugger toolbar is simple to understand, as I will explain here below.

The debugger toolbar is made up of controls at the top, then 3 horizontal panes.

1. The controls bar

This is where you have different buttons to control the state of the program. In order, we have the Pause/Resume button, Step Over (or Next) button, Step In, Step Out, then the Restart and Quit buttons.

2. The frames pane

This pane shows the currently active stack frames (or call stacks).

This frame has another tab that shows the various set breakpoints.

3. The console pane

This pane shows the console output of the program and allows you to potentially execute commands (not yet supported in the GJS debugger).

It has a different tab that shows the different scopes. Here, you can expand a scope to see variables inside that scope.

4. The terminal pane

Last, but not least, the terminal pane shows regular terminal output from the running program. This is also not currently implemented in the GJS debugger.

Debugging

Now that you can navigate around the debugger, let's get to debugging!

1. Using the debugger statement.

The debugger statement is a built-in statement in JavaScript that pauses execution and allows you to inspect the current state of the program at the time it pauses.

You can add a debugger statement to calc.js at the end of the file to test it out.

Then click F5 again to start debugging. This will launch the debugger and pause execution at the debugger statement.

Note: Ignore the "the debugger statement is not allowed" message for now, but remember to remove it before building/shipping your application.

The highlighted line is where the debugger paused execution.

2. Inspecting Variables

With the debugger now paused, you can inspect the variables in the current scope.

Click on a scope's name to expand the variables under it.

You can click on one of the objects to inspect its properties, for example, in the module scope, click on Gtk to see all the widgets available in the GTK library.

Inspecting all types of variables is implemented and you can inspect numbers, booleans, strings, symbols, functions, classes and most other types of objects.

3. Adding breakpoints

Adding the debugger statement is not the only way you can stop execution, you can also quite easily add breakpoints by clicking on the line number you want to pause at in the editor.

For example, let's add a breakpoint on the first line of the pressedEquals function.

Then we can stop and restart the debugger. In the running program, type a simple equation like 1+1, then click =.

The debugger panel will now show that you're paused, and allow you to view the stack frames as well as the scopes.

With this approach, you can debug applications and pause execution at any point to inspect the state of the program.

Also note that the breakpoints tab is now updated to show the breakpoint we just set.

Note: The main Calculator window might now appear as Frozen (e.g. with a "« gjs-console » is not responding" message). Don't worry, this is because the program is paused in the debugger.

Note2: You can set/remove breakpoints anytime the app is running or before it starts.

4. Stepping through the code

With the application now paused, we can progressively move execution line-by-line by stepping through the code.

To "Step Over" (execute the current line and move to the next one), press the "Step Over" button in the debugger toolbar.

<video src="/images/posts/gjs-dap-report/equals-stepping.webm" loop muted autoplay controls></video>

You can also click the "Step Into" button to step into a function call (or just step over).

Here's an example where I've added a breakpoint on Line 40 (first line of pressedOperator button) and stepping into the updateDisplay function call.

<video src="/images/posts/gjs-dap-report/step-into.webm" loop muted autoplay controls></video>

Stepping back is currently not implemented.

5. Breaking on Exceptions

Another way to pause execution is to set to break on exceptions. The GJS debugger supports breaking on breakpoints that would either be caught (i.e. in a try {} catch {} block) or not caught (i.e. unhandled exceptions).

You can set these options by going to the Breakpoints tab and then clicking either the "Uncaught Exceptions" or "Caught Exceptions" button (or both).

VS Code Extension

I've also worked on a VS Code extension, which enables debugging GJS applications inside of VS Code, however it reamins highly experimental and many features are not working yet.

This is because I focused on the Zed extension and it's the one I used during development extensively, so the VS Code extension is not as well tested as the Zed one, but I am also planning to improve it and submit it to the VS Code extensions marketplace in-time for the GNOME 52 release!

You can find instructions to use the VS Code extension in it's repo. Here is an example of it debugging an application:

<video src="/images/posts/gjs-dap-report/vscode.webm" loop muted autoplay controls></video>

Challenges

While working on this project, I had a few challenges:

Firstly, I really had trouble working well because of the remote nature of GSoC, and sometimes collaborating with my mentor would get off-tracked because I tended towards working alone instead of realising my mentor was available to help me. For future participants, I would advise you to realise that your mentor is available to help you, instead of feeling like you should be 100% independent. In my experience, a mentor will usually point you to the right solution, or even help you understand topics you might otherwise get blocked on for too long.

Code-wise, the most challenging part was getting the message parsing (i.e. sending DAP messages and receiving them through stdio) to work. I tried many approaches on my own (see point 1 above) but at the end it got resolved when I decided to ask my mentor for help.

The issue was complex because we needed to have access to the standard input as a stream so we can parse the protocol's Content-Length: {nBytes}\r\n headers, then read the corresponding number of bytes exactly. My first instinct was to use Gio.DataInputStream directly, but it didn't because it wasn't possible to load Gio/GLib imports in the main realm. The solution was to create a few functions (openInputStream, readLine and readBytes) on the C++ side since it can use the Gio/GLib APIs, then expose them to the JS code that implements the DAP communication (and linking with Firefox/Spidermonkey's Debugger API).

Another challenge I had was when implementing the VS Code extension. In the beginning, I wrote a Zed extension that would expose GJS' DAP capabilities to the Zed Editor. When working on a similar extension for VS Code, I got stuck a bit because VS Code doesn't have a native way to easily show the communications happening between the DAP client (in this case VS Code) and the DAP server (GJS), while Zed had an easy way to show them. This effectively hid a bug where Zed was sending/requesting an extra /r/n in the DAP requests & responses, while VS Code was not (they both implemented the standard differently). In the end, I created a wrapper script that would also log all the communications between the client and the server differently so I can diagnose that bug and fix it.

A recommendation I would give to future GSoC participants is to also track time and progress well. When working on the project, I didn't regularly check my proposal and the different activities and their timelines, so I ended up moving/reprioritising tasks towards the end of the program, which could have been avoided if I always checked the timeline to make sure I'm still on track and adjusting early.

Further Steps

There are some remaining tasks that could be done to make the GJS debugger better, and here's some of them.

1. Bring the VS Code extension to feature parity as the Zed extension (see above).
2. Add support for debugging GJS applications in GNOME Builder: Currently blocked by GNOME Builder itself lacking DAP support
3. Add support for evaluating expressions in the debugger when paused.
4. Correctly stop/kill the script when the debug session ends.
5. Enabling source map support, which will make debugging compiled GJS (and TypeScript!) applications (like GNOME Weather, GNOME Sound Recorder) easier.
6. Testing and ensuring the debugger works well on macOS and Windows (I only tested on Linux).
7. Redirect console.log and other output to the debug console.
8. Allow attaching to already running GJS applications (potentially by implementing a SIGUSR1 handler and communicating via unix socket).
9. Allow pausing the program that's being debugged (at any point).
10. Implement setting or modifying variables in the debugger.
11. Give information about the current exception when we hit an exception breakpoint (needs the VS Code extension).
12. Maybe implement watching source code and live-reload of the code while debugging.
13. Implement more DAP capabilities (e.g. function breakpoints, conditional breakpoints) to improve the debugging experience even more (including correct presentationHint)
14. Show the scopes in a better way (e.g. merge the global and GjsGlobal scopes, potentially merge the class body scopes, etc...)
15. Maybe support debugging the GNOME Shell??
16. Maybe implement GJS debugging (and provide instructions) for other DAP clients like Emacs, Vim, etc. (see full list of tools implementing DAP here)
17. Maybe add documentation for debugging a GJS application while developing with meson (will need to add a run_target).

Let me know if there's more support you may want, or if you'd like to work on any of these.

Improving WASM Support

As part of the GSoC project, during the initial community bonding period, I also worked on improving WASM support in GJS. The MR essentially connects WASM's event loop to the GLib main loop set up by GJS.

Conclusion

I would like to thank Google Summer of Code for selecting me to work on this project, which I hope will improve the experience of writing, debugging and improve GJS applications.

I'd also like to thank the GNOME Project for hosting GJS, which is an important part of the GNOME ecosystem.

Finally, I'd like to thank my mentor Philip Chimento so much for his important skills, guidance, and support while I was working on this project.

You can reach out in the GNOME JavaScript room in Matrix: #javascript:gnome.org for any questions or feedback.

07 Sep 2026 12:00am GMT

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!

04 Sep 2026 7:31pm GMT

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.

04 Sep 2026 6:20pm GMT

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.

04 Sep 2026 5:53pm GMT

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. Additionally, 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.

Title Image by BUNT, near 44°52'57.8″N 13°48'24.2″E

04 Sep 2026 3:59pm GMT

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.

01 Sep 2026 12:59pm GMT

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.

31 Aug 2026 7:21pm GMT

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.

31 Aug 2026 12:00pm GMT

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.

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.

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!

31 Aug 2026 9:57am GMT

• 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.

30 Aug 2026 9:00pm GMT

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.

30 Aug 2026 5:55pm GMT

Update on what happened across the GNOME project from August 14 to August 28.

GNOME Core Apps and Libraries

Sophie (she/her) announces

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.

Mutter ↗

A Wayland display server and X11 window manager and compositor library.

Toluwaleke announces

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.

Python Bindings (PyGObject) ↗

Python language bindings for GNOME platform libraries.

Arjan announces

Today I release PyGObject 3.58.0.

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.

PyGObject can be found on PyPI and the GNOME download server.

GNOME Fellowship

Glycin ↗

Sandboxed and extendable image loading and editing.

Sophie (she/her) announces

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 common practice 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.

Sovereign Tech Agency

swick reports

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.

Read the full announcement on the Modal blog.

Prototype Fund

verdre reports

I'm happy to announce that Test Center is available on Flathub now 🧪️✨️

https://flathub.org/en/apps/cx.modal.TestCenter

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.

If you want to give the app a spin, here's a fun merge request to try, adding interactive screenshot UI to Epiphany: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/2129

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.

See the full agenda and sign up here: https://pad.gnome.org/K1MftsinR2-uruO\_4KWnLQ

GNOME Circle Apps and Libraries

Brage Fuglseth reports

Last week Bazaar was accepted into GNOME Circle.

Bazaar is a new app store for GNOME with a focus on discovering and installing apps and add-ons from Flatpak remotes, particularly Flathub.

Congratulations!

Tuba ↗

Browse the Fediverse.

Evangelos "GeopJr" Paterakis 🏳️‍⚧️🏳️‍🌈 says

Tuba v0.11 is now available, with many new features and bug fixes!

✨ Highlights:

• Tuba moved to Codeberg!
• Full Mastodon quotes support
• Collections
• Hashtag Lists
• UnifiedPush
• Android builds
• Better custom emoji picker
• Improved media viewer
• More compact narrow layout
• Custom thumbnail support for media
• Font-size slider
• Regularly update stats in threads and check for new replies
• Support for Mastodon's new profile tabs settings
• Formal AI policy
• Much much much more!

Read more and see all the changes in action on the (very) informative changelog!

Graphs ↗

Plot and manipulate data

Sjoerd Stendahl reports

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.

Third Party Projects

Jan-Michael Brummer says

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.

Got your interest? Check it out: https://gitlab.gnome.org/jbrummer/stamp or download it via GNOME Nightly

Francesco Caracciolo says

Newelle 1.5.0 released!

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

Full changelog: https://github.com/qwersyk/Newelle/releases/tag/1.5.0

Download: https://flathub.org/en/apps/io.github.qwersyk.Newelle

Anton Isaiev says

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.

https://github.com/totoshko88/RustConn https://flathub.org/apps/io.github.totoshko88.RustConn https://snapcraft.io/rustconn/

Tanay Bhomia reports

Whisp v1.4.1 - Exporting and Better OCR

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.

Links Download - https://flathub.org/en/apps/io.github.tanaybhomia.Whisp Website - https://tanaybhomia.github.io/Whisp/ Source Code - https://github.com/tanaybhomia/Whisp Donate - https://tanaybhomia.github.io/Whisp/donate.html

Bouncer ↗

Bouncer is an application to help you choose the correct firewall zone for wireless connections.

justinrdonnelly says

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.

Shell Extensions

Just Perfection announces

The extension port guide for GNOME Shell 51 is ready, and we are now accepting 51 packages on EGO.

If you need any help with your extension you can ask us on GNOME Extensions Matrix Channel.

Daniel Elia says

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.

You can get the extension from EGO here!

🇧🇷️ Fabito02 says

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.

Leandro Rodrigues says

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.

Aurora Shell 50.12 is available on EGO. Read the full announcement or visit the GitHub release.

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!

28 Aug 2026 8:12pm GMT

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:

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.

Where We Left Off

In my last progress update, the compositor survived a reset, but with two open gaps:

• 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:

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
...

And the corresponding recovery logs:

Clutter-Message: 15:53:34.164: [RECOVERY]: Graphics reset detected
Clutter-Message: 15:53:34.251: [RECOVERY]: Graphics recovery successful
Clutter-Message: 15:53:34.251: [RECOVERY]: Graphics reset detected
Clutter-Message: 15:53:34.321: [RECOVERY]: Graphics recovery successful

Where Things Stand

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:

• 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!

28 Aug 2026 4:50am GMT

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.

Read the full announcement on the Modal blog.

27 Aug 2026 10:30pm GMT