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.

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

GNOME Foundation

marimaj reports

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

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

Thank you for joining us!

GNOME Fellowship

Peter Eisenmann says

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

Sophie (she/her) says

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

GNOME Core Apps and Libraries

Files ↗

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

Peter Eisenmann reports

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

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

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

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

GNOME Circle Apps and Libraries

Alexander Vanhee announces

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

Third Party Projects

Lanséria reports

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

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

PedantiK is available through Flathub

Shell Extensions

Christian W reports

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

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

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

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

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

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

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

Tomáš Gažovič reports

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

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

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

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

Supports GNOME 46 to 51.

Get it on EGO | Source on GitHub

Miscellaneous

Sophie (she/her) announces

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

That’s all for this week!

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

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

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

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

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

Tales of a Dicey API

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

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

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

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

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

Other Work

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

Glycin

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

Loupe

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

Other Projects

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

Outlook

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

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

Support the GNOME Project

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

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

Nautilus

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

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

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

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

Sushi

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

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

gnome-autoar

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

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

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

Roadmap

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

Support the GNOME Project

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

AI Summary

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

Important note: All statements in this blog are fictional.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Screenshot of the Fingerprint Authentication dialog

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

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

Screenshot of a fingerprint enrollment

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