Gnome Planet - Latest News

Bombarded by the deception and lies of the AI industry I chose to sample boy Amodei for the ironic outrage about Chinese companies stealing their dataset. Thus the tune title. Usually I barely manage to finish up my weekly beats track on a Sunday night. This week I've somehow had some extra time to sink into polishing an actual full track on the Dirtywave M8. Built around the bassline where I've mimicked the approach used on the Analog 4 of fading in a modulated filter and volume pulse over time using slight different tools (the M8 has 4 LFOs and ability to modulate a modulator).

Update on what happened across the GNOME project in the week from September 11 to September 18. This week we released GNOME 51! This new major release of GNOME is full of exciting changes, including visual signatures in Papers, Maps offline usage, Files refinements, Calendar usability improvements, many accessibility enhancements, and much more! See the GNOME 51 release notes and developer notes for more information. Readers who have been following this site will already be aware of some of the new features. If you’d like to follow the development of GNOME 52 (Spring 2027), keep an eye on this page - we’ll be posting exciting news every week! GNOME Core Apps and Libraries Libadwaita ↗ Building blocks for modern GNOME apps using GTK4. Alice (she/her) 🏳️‍⚧️🏳️‍🌈 reports A few days late, but I published an overview of the new features in libadwaita 1.10. Internships Felipe Borges says We just concluded another successful season of Google Summer of Code with GNOME! In case you missed it, here’s where you can find all the details about the projects and work done by our interns https://feborg.es/wrapping-up-gsoc-2026-with-gnome GNOME OS ↗ The GNOME operating system, development and testing platform Ada Magicat announces We now have documentation, on a website! We wrote new guides, updated old ones and consolidated most information about GNOME OS and gnome-build-meta in one place. We now automatically publish a small book with up-to-date documentation on installing and using GNOME OS as well as how to contribute to GNOME OS and the GNOME flatpak runtimes This is the result of many items of work over the last few months. And we’re not done yet! We have a few more items that need validating and updating. Ada Magicat reports Users with little RAM, rejoice! GNOME OS should now stay fast and responsive even if you’re using a lot of RAM. This is because we now use zswap, a Linux kernel feature that intelligently compresses infrequently used memory contents and writes them to a swap file. For the few users that had issues with applications being killed due to their system running out of memory, this change should help a lot. Thanks to Jonas, Sebastian and Valentin for working on this. You can try it out on the latest GNOME OS nightly. Miscellaneous albfan reports Hi, some gitg contributor write this https://medium.com/@divyanshurajput709/one-micro-commit-at-a-time-my-gnome-journey-and-oosc-4-0-9b36236c4066 Third Party Projects Deimos Hall says Metamorphosis is an app to edit metadata. This week it received a new app icon by Hylke Bons and an update that improves the user experience with four categories to let users discover what to edit in an easier way. But it’s an ongoing work. If you find the tool useful, I need you. Please help me to drive the decisions for the future of the app, I want it be able to edit metadata of any kind of popular file formats as well as general date & time system metadata. My goal is a tool that covers: Geotagging and Metadata Editor An app to change the modification date / timestamps of one or more files on the filesystem JExifToolGUI replacement Is coded by hand (no AI) Download it on Flathub. Daniel Elia announces Convey, a GTK4 email client, has finally launched on Flathub! It’s a fork of Geary with Microsoft 365 support, GTK4, as well as a bunch of bugfixes and UX improvements, notably fixing scroll issues on the conversation list, more predictable keyboard navigation and improved legibility in dark mode. We’re now on version 50.1, with 50.2 on the horizon. Graph accounts now persist their folders so they load offline, folder keyboard navigation is predictable, Escape deselects conversations (with autoselect off in Trash and Junk), and dark mode rendering and context menu positioning in the message body are fixed. Install it from Flathub, and check out the GitLab repo! Alain announces Planify 4.20.0 — Nextcloud Deck, CalDAV reminders, productivity goals, and more Planify, a task manager with Todoist, Nextcloud and CalDAV support, released 4.20.0 — one of its biggest updates yet. Highlights: Nextcloud Deck integration — boards, stacks and cards sync two-way, with labels, drag and drop across boards, and archiving. CalDAV reminder sync — reminders now sync bidirectionally with Nextcloud, Radicale, Tasks.org and Thunderbird via standard VALARM. Productivity goals — set daily and weekly targets, track them with a mini progress widget, and review an 8-week activity heatmap. GNOME Online Accounts detection — existing Nextcloud/CalDAV accounts are detected and can be imported without retyping the server URL. Quality-of-life — completed tasks in Today, sort and filter across All Tasks, keyboard project navigation, locale-aware dates, better PDF export, and automatic backup retention. Read the full release notes here. Tanay Bhomia announces Whisp v1.5.0 - Custom keyboard Shortcuts and Gnome Search Integration This Week I released Whisp 1.5.0 Which includes two main things Integration with the gnome search - Now you can search through your entire notes without even opening the app by using the native gnome search Custom Keyboard Shortcuts - This is one of the most requested feature on the repo and I wanted to develop it for a long time so finally it is here. Adding a Keyboard Shortcut for exporting notes - This shouldve been added in the last release but somehow I missed it Links: Flathub: https://flathub.org/apps/io.github.tanaybhomia.Whisp GitHub Repository: https://github.com/tanaybhomia/Whisp Project Website: https://tanaybhomia.github.io/Whisp Support & Donation: https://tanaybhomia.github.io/Whisp/donate.html Personal Website: https://tanaybhomia.github.io Now that we have this app thing out of the way. I wanted to share something ( I wanted this to be a good news and share with you guys that I landed a job but) I sat for an interview for KPMG which I went till the last round of but then got rejected for. I lost motivation for anything actually I really wanted to land this job. But eh. I hope I get a job real soon. Thank you for your support Anton Isaiev reports RustConn 0.22.0 is out - connection manager for SSH, RDP, VNC, SPICE, Telnet, Serial, Kubernetes, Web and Zero Trust (GTK4/libadwaita). New features: import your existing setup from mRemoteNG, PuTTY and KiTTY, and export RDP connections to standard .rdp files. A one-click private browser tunnelled through any SSH host (embedded or an external Chromium), and a Web connection that can browse through a bastion the same way. Interactive ASK variables that prompt for a value at connect time, plus built-in date, time and environment placeholders in any ${…} field. Terminal colours can now follow the desktop light/dark setting and repaint live when it flips. A monitoring mode that fires on a real shell event - the command finished, with its exit code - and marks the tab until you look at it. Automatic answers to sudo, su and doas prompts on SSH sessions; an output filter that pipes a session through ChromaTerm, ccze or pv before it is shown; FIDO2 passkey redirection for RDP; a searchable connection list in the cluster editor; and an editable login timeout. Security: SSH passwords are now handed to OpenSSH itself instead of being typed into the terminal, which closes a whole family of “wrong prompt gets the password” bugs; session recordings and logs were storing secrets and were world-readable, both fixed; a debug log could contain an RDP account password in clear; an RDP server could write files outside the folder you picked or make the client allocate gigabytes; and dangerous VNC viewer arguments could be smuggled in from an imported connection. Every secret-backend subprocess now has a deadline, and a password the selected backend refused is no longer redirected somewhere the connect path never reads. Fixes: a jump host set on a group or globally was stored and shown as inherited, then dropped at connect for SSH, RDP, VNC and SPICE; SPICE and RDP asked for the password every time instead of using the stored one, and failed on Flatpak and macOS; embedded RDP now verifies the server certificate on first use like SSH does for host keys; the embedded web browser lost its login on every restart; RDP clipboard file transfer never actually worked; Bitwarden auto-unlock did nothing in any language but English; a KeePass group password was saved but never loaded back; embedded RDP could be killed by a Windows 11 keepalive; and a pile of macOS paths that assumed Linux now find the real .app clients and runtime directories. 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/ Gir.Core ↗ Gir.Core is a project which aims to provide C# bindings for different GObject based libraries. Marcel Tiede announces GirCore 0.9.0-preview.1 got released. It features a new API to match GExceptions with errors and supports nullable return values from instance factories. Shell Extensions Romain says Night Theme Switcher, the GNOME Shell extension that automatically toggles the desktop to dark mode at night, has been updated for GNOME 51. It includes a redesigned preferences window that visually previews the day and night appearances and makes setting multiple commands easier, and adds the long requested features of accent color switching and manual location setting. You can install it from the Extensions website, and the [source code is available on GitLab](https://gitlab.com/rmnvgr/nightthemeswitcher-gnome-shell-extension. 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!

I like to run my Linux as an operating system, so I usually resort to toolbox for packages and development. However flatpak-builder is distributed as a flatpak itself, so here's how you can go about building flatpaks yourself for when GNOME Nighlies are not enough. On GNOME OS, some developer tools like git and toolbox are in the base image. Installing flatpak-builder flatpak-builder isn't part of base OS though. It is distributed on Flathub as org.flatpak.Builder. Install it like any other Flatpak: flatpak install flathub org.flatpak.Builder Building and Installing Locally Here's how I build Shaper, an icon designer for GNOME symbolics. flatpak run --command=flatpak-builder \ org.flatpak.Builder --user --install \ --force-clean build-dir org.gnome.design.Shaper.json And that's it! Developer extension There are some extra tools for development available for GNOME OS. You get them by enabling the developer system extension: sudo updatectl enable devel --now So instead of installing the flatpak, you get flatpak-builder as a utility.

[Originally written in Czech] At the very beginning of the last year, Jiří Eischmann wrote a post on his blog about the status of the Czech translation at GNOME, tl;dr: the translation was slowly dying. I would really love to say that it is resolved, but that would be oversimplified. What changed? During this year we decided to restructure our team and to restore the translation’s former scope and quality. Since spring, I’ve taken on the coordinator role in our Czech translation team—this release is under my lead. Fortunately I have Daniel Rusek beside me, who makes sure nothing goes unnoticed and who proposes further direction of our team, and I am very lucky to work with him. I am happy to announce that our Czech translation is slowly forming to a pretty nice form, maybe soon as it was before. The first action I have done as coordinator was updating our manual for translators—I made sure it was easy to comprehend without a need for bigger changes from the previous one. I thought it would attract new contributors, which happened in summer right before the release was available to translate. The core is almost fully translated to Czech, only sysprof is not. There is now also a new translation of foundry. Does it mean GNOME 51 is fully Czech? Unfortunately no. While using GNOME you can still find untranslated strings from the modules that GNOME depends on, like NetworkManager, which is used for VPN connections—but we are still responsible for translating some of them. We also translated a few apps from GNOME Circle, some websites, and some of the modules from freedesktop.org. Even though we had small updates of user documentation, it’s largely stagnating. But…thanks to Petr Kovář’s awesome work help.gnome.org is now translatable and even translated to Czech language. (You can find whole overview of translated modules on Damned Lies.) During this cycle we got new members to our team, half of whom have already translated at least one module. I am very optimistic, and I believe these are not one-off translations but the beginning of long-term collaboration. Daniel Rusek remains reviewing, and I am joining him with doing so too. That doesn’t mean that the translation is somehow resolved. You have to care about translations as if it were your garden, just having seeds does not imply a harvest, you need to take care of your plants first. We are still just a small group of people who gave up their leisure time and a few hours of sleep for the others. It’s not easy, and we possibly cannot translate for the eternity, that’s why we take your help seriously, we are more thankful for it than maybe you imagine. Thank y’all. Don’t let us down We are grateful for every help with translating. If you want to make GNOME closer to Czech users, we are willing to teach you and navigate through translation. All needed information is listed on our page, or you can directly reach me via Matrix.

It’s been about 4 months since my last GNOME Foundation update. Time flies. I’m sorry that it’s been so long. I will try to do more regular posts again in the future, but perhaps not at the same tempo as before. While I would love to post every other week, it’s hard to sustain. With that said, let’s jump in. Given the time since my last post, I’m going to focus on the bigger and more recent news items that have happened at the GNOME Foundation. New board, new officers The Foundation’s board elections happen every year, and this year’s election completed in July. The election resulted in a number of changes to the board: Sri Ramkrishna, Jonathan Blandford and Adrian Vovk joined the board as new/returning directors Deepa Venkatraman, our treasurer, secured a new two year term Robert McQueen, Federico Mena Quintero and myself all ceased to be directors (Rob failed to be re-elected, Federico didn’t run, I withdrew part-way through the process) The election was a difficult one for me personally, and left me reconsidering my involvement in the Foundation. This was not because I lacked motivation or commitment, but because the situation around the election had become untenable for me personally. However, I’ve spent a good deal of time since I withdrew my candidacy thinking about my role at the Foundation, and I’ve concluded that I care about this organisation and the progress we’ve made, and I want to see that work through. Conversations I’ve recently had with members of the community have also given me confidence that we can move forward together. In short: I’m happy to be sticking around. The new board held its annual meeting in August, which is when officers and committees are appointed for the next 12 months. The Board decided to put me into position as Interim Executive Director, with Sri Ramkrishna taking my place as President. This is a good move from my perspective: it recognises that I’ve been doing a lot of the day to day management work (which I will continue to do), and gives the Board more ability to hold me accountable. Sri stepping into the role of President means that he will be my backup. Other officer changes include Jonathan coming in as Second Vice-President, Cassidy moving from Vice-Secretary to Secretary, and Adrian stepping up as Vice-Secretary. Our other officers remain in post, with Maria as chair, Deepa as Treasurer, and Arun as Vice-President. Huge thanks to everyone who volunteered for these positions! In terms of committees, the Executive Committee had a minor reshuffle, with Jonathan, Adrian, and Sri joining, and Julian and Rob departing. The new members of the exec are already taking on work, which is great, and I’m hopeful for the newly reconstructed committee. The Finance Committee had some slight membership changes, with Rob leaving and Sri joining. Finance and Operations Director Last April we opened the search for a new paid team member, to join us as our Finance and Operations Director. There are a number of goals for this new position: to enhance the finance and accounting expertise that we have internally, to lead the development of our internal systems and budgets, to ensure the sustainability of finance and compliance tasks, to manage our fiscally sponsored projects, and more generally take ownership of the business side of the organisation. We had a huge number of applicants apply for the position, and had some extremely high quality candidates to choose from. After going through several rounds of interviews we selected Dawn Matlak for the role, who we are extremely excited about joining us. Those of you who have read my previous posts might remember Dawn’s name: she initially started working with us as a consultant last year, in order to help us prepare for our first formal audit, which happened in March this year. As part of this work she helped us to transform many of our internal systems and processes. We’re thrilled that she is joining the Foundation on an ongoing basis, and are confident that our internal operations will continue to improve under her stewardship. Dawn is already doing a small number of hours for us each week, which she will continue to do until she properly starts in the role in November. Many thanks to Arun and Deepa who helped enormously with the hiring process. FY27 Budget The Foundation’s financial year runs from 1 October to 30 September, and each financial year requires a new budget, both for planning and as the basis of reporting and spending authorisation. We have all therefore been working hard on the new budget that will come into effect on 1 October. The new budget has been in the works for a while, and has been a major focus for the board over the past few months. Thankfully we got the initial budget approval done last week at the board’s regular September meeting. We’ll follow-up with a more detailed post about the budget as soon as we’re able, so the community can have some insight into how we’re managing our finances. Events With GUADEC 2026 wrapped up, Kristi has turned her attention to the next event in our schedule: GNOME.Asia 2026. This is being held in Terengganu, Malaysia, from 31 October to 2 November. There’s a great venue lined up, and Kristi is busy working on the details with a fantastic local team. Aside from GNOME.Asia, the other recent focus has been GUADEC 2027. We have a couple of options for locations right now, and are in the process of confirming details before we commit to one of them for next year. We’ll share updates as soon as we have more details confirmed. Fundraising The end of the calendar year is an important time for non-profit fundraising, and we are currently busy planning our campaign for the end of 2026. I’ll be posting more about this soon, in particular in relation to the budget, but for now I will say that this campaign is going to be critical for our ability to grow and support the GNOME project. Other As ever, many other things have been happening at the Foundation, and there’s too much to go into detail about here. Work on GNOME’s infrastructure and Flathub continues, our back office operation continues with finances and other routine paperwork, and the board continues to discuss our long-term plans. That’s it for now. Many thanks for reading, and feel free to leave questions in the comments.

Back in April I wrote an informal history of the BuildStream project: Status update: 23rd April 2026. Things escalated and somehow I ended doing a podcast interview with Rich Bowen of the Apache Software Foundation recently, on the Apache PlusOne podcast:Apache BuildStream — with Sam Thursfield – YouTubeFame at last! I didn’t get much time to prepare for this so excuse any clunky explanations or inaccuracies. My main aim was to place BuildStream and Freedesktop SDK in context for an audience who don’t live and breathe operating system integration tools. I’m interested in your thoughts on how successful that was. Comments are enabled on the YouTube video so you can also fact-check us there as needed.

Not a lot of things have landed this cycle, but there's still a bit to list, so let's do that. Android support As part of his effort to port GTK to Android, Florian also ported libadwaita demo. The builds are available from CI and the GTK 4 Android page. He also implemented a settings backend, meaning that libadwaita apps now support system dark mode and accent color on Android (not high contrast or document/monospace fonts though). Ministream AdwAboutDialog can be populated from an AppStream metainfo file, via libappstream. While useful, it also causes problems on other platforms, such as Windows (libappstream can't be built using msvc) or Android, due to its dependencies. Since we only use a small part of appstream (for example, we don't need composing or anything related to networking), he reimplemented the subset libadwaita uses as ministream. It only depends on GLib and it should build fine with msvc, so it should make building libadwaita outside of Linux easier. CSS class bindings A fairly common pattern is having property that toggles a style class - e.g. for use with breakpoints. Currently implementing it is a bit annoying, so Jamie Murphy added API for automating it - adw_bind_property_to_css_class(). It's modeled after g_object_bind_property() and works much the same way, incl. allowing bidirectional bindings. A variant with mapping functions is also available, allowing to bind properties of arbitrary types and not just booleans. Sidebar additions AdwSidebar and AdwViewSwitcherSidebar have received a number of additions. Sidebar prefix and suffix First, both sidebar widgets now support having prefix and suffix widgets. This can be used for things like adding an account switcher, a prominent title, or a help button at the bottom. While it's not used a lot in GNOME apps at the moment (the only app I'm aware of is a development version of Crosswords), it's a common pattern on other platforms, so it's good to have API for this. Section suffix Next, sections can have suffixes in their headers, similar to AdwPreferencesGroup. This can be used to put a spinner or a button in the sidebar sections, similar to what Polari has. Item prefix Finally, sidebar items can have prefix widgets. They can be used instead of the icon or together with it, in that case it will be displayed before it. This can be used to display avatars, checkboxes and so on. Icon changes Last cycle I announced the new icon work. Unfortunately, it's still not ready, but a few smaller things have landed. First, larger icon sizes now use smaller weight, so new icons in AdwStatusPage and in images with the icon-size (but not pixel-size!) property set to LARGEwill look thinner. Second, AdwSpinner now also follows icon weight and will look consistent with icons. Apps that use spinners at large sizes outside of AdwStatusPage may have to adjust the weight manually using the -gtk-icon-weight CSS property. Other changes AdwShortcutLabel now uses proper labels for keys like ⌘ or ⌥ on macOS, as well as more natural ordering for modifiers everywhere. GtkDropDown can now be used with the .flat style class, and automatically becomes flat in toolbars (which can be undone with the .raised style class, same as for other buttons) AdwAboutDialog now has the :other-apps-title property, allowing to override the title of the "Other Apps" section. Overall, not a lot has happened. Even this blog post is late, for the first time. Part of the reason is various health issues, both physical and mental, another part is the state of the world at large and software industry in particular. It's hard to focus at the best of times, let alone when everything is falling apart. I've been working on a personal project as a means of escapism, but it does mean libadwaita is getting less attention. Thanks to the GNOME Foundation for their support and thanks to all the contributors who made this release possible.

I’ve been working for a while as a contractor as part of the Sovereign Tech Fund (STF) initiative for Flatpak, organized by Modal and Para-Real Ltd. There is a nice write up about the project, giving an overview of the investment and the collaborative effort. Intents My involvement has been focused on the Intents, which is an abstract system for apps to declare their offered services. Applications can announce which Intents they support using the Implements key from the Desktop Entry specification, and the default selection mechanism is solved by the intent-apps specification. For example, one could develop a Thumbnailer Intent, which would be then supported by implementing a specific DBus interface (e.g. “org.freedesktop.Thumbnailer1”). That would allow for apps and system components to have a standardized, flatpak friendly way to discover thumbnailers, and use their functionality in the sandboxed world, increasing security. Another use case would be an URI Handler Intent, that would among others let users specify which applications they would like to be opened when clicking a particular link. The overall idea has been going for quite a while, and there are some very good sources to read up on the Intents in general, including Andy Holmes’ “Best Intentions” blog post and Sebastian Wick’s follow up. Terminal Intent Last year the intent-apps specification allowing for default selection of Intents was accepted, and the next step is to start implementing them. One that caught interest is the Terminal Intent. Currently, there is no standardized, sandbox friendly way for the system to discover terminal emulators, and use their functionality. It’s not associated with either a mime-type or an URI scheme, which is one of the reasons why changing the default terminal has been challenging for a long time now. This changes with the proposed spec, that allows applications to implement the “org.freedesktop.Terminal1” Intent, and therefore advertise to the system and other interested users that it’s a terminal emulator, capable of executing commands via a specific D-Bus interface. In GNOME, it will unlock many things we’ve wanted for quite a while, among others: changing the default terminal in Settings, adjusting the behaviour when launching apps meant for terminal, and opening directories from the file manager. Settings There’s an early implementation in GNOME Settings for the terminal Intent, that exposes an option to change the default terminal emulator across the system. Applications that are meant to be executed in a terminal window, which is indicated by a “Terminal=true” line in their desktop file, would then launch in the previously selected terminal. Apart from the spec being accepted itself, for the functionality to work correctly, there needs to be support for the intent in GLib, which is being worked on, as well as in the terminal emulators themselves, with both Console and Ptyxis having work in progress implementations. Settings with an option to choose the default terminal Below I’ve provided screen recordings of Shell launching Vim in a terminal emulator chosen in Settings, as well as a custom terminal application. https://blogs.gnome.org/ignapk/files/2026/09/termapps-default-terminal.webm https://blogs.gnome.org/ignapk/files/2026/09/custom-termapps-default-terminal.webm Files Another cool use case would be opening directories from the file manager in the terminal, adhering to the selected default in Settings. The integration would also cover other terminal related functionality, such as running the scripts as programs in the terminal. There’s a work in progress implementation in GNOME Files. Here’s another pair of screen recordings, showing Files opening directories and running a custom script in a terminal emulator chosen in Settings. https://blogs.gnome.org/ignapk/files/2026/09/nautilus-default-terminal.webm https://blogs.gnome.org/ignapk/files/2026/09/nautilus-run-as-program-default-terminal.webm Testing As usual, I’ve prepared a custom GNOME OS image that can be used to test the functionality, which I’ve also used to make various screenshots and recordings in this blog post. You’ll need to install it (in GNOME Boxes for example), which takes a simple click and does not require a reboot (magic!). To be able to switch between different default terminals, you’ll want to download the custom build of Ptyxis as well, and install it with a command “flatpak install ptyxis-terminal-intent.flatpak”. Then you can get some applications meant for terminal such as Vim directly in Software, which is preconfigured to get them from Flathub. Next Currently, the major blocker for the work is getting the Terminal Intent specification accepted upstream, which needs to be merged before the rest of the ecosystem can fully embrace it. There needs to be consensus from other desktops such as KDE, after which the focus would become the GLib integration, following support from individual applications. And in the future, work on other Intents can begin, unlocking many more possibilities. I’d like to thank Modal and Para-Real Ltd. for the ability to work on this, as well as Sovereign Tech Agency for sponsoring the work. I also really appreciate the help from the technical leads Sebastian Wick and Adrian Vovk who are always there to answer questions, the organization of the work by Kateryna Omeltschenko who knows how to brighten up a meeting, and Cade Diehm, who’s bravely fighting with the bureaucracy for us. Until the next update!

With GNOME 51 out the door, it's wallpaper reveal season again. This time around it's evolution, not revolution — the set sticks to its geometric roots. The default is really just a stylistic touch up of the 50 hexagons. The subtle rim highlight received a spotlight and now shines extra bright. I do keep hoping landscape nature photos eventually join the lineup, but capturing the same scenery under different conditions so the light and dark variants actually make sense is trickier than it sounds. That one's still on the wishlist. As usual, plenty of concepts didn't make the cut. For every wallpaper that ships, there's a good pile of experiments that never got past the "that's kinda neat" stage. One thing we keep struggling with is performance in the Appearance panel. The images now include an embedded small thumbnail, so hopefully a faster way to build the initial cache of thumbnails is on the horizon. We've also started embedding attribution and license straight into the images themselves, so the credits travel with the file instead of living only in the repo. And with Loupe displaying the metadata nicely, you get to see it conveniently.

Guadec happened. It was a extremely well organized event, with plenty of good talk, people that I was longing to see again, and new faces to put a name on. My experience was however very much soured by interactions with other people within the community, against myself and other members of the community. To the point that I had to take the time to relieve the distress it has caused me, hence the time it took me to write this down. The mobile shell initiative The development for a “mobile” GNOME Shell started somewhere around 2022, and at least the supporting parts of it passed as a project sponsored by the first and only round of GNOME projects sponsored by Germany’s Sovereign Tech Fund, as “Increase Range and Quality of Hardware Support”, this was acknowledged in the final STF report. Making GNOME Shell behave natively on a new form factor is a massive undertaking, and the planning was not sufficient. The first, most glaring mistake was to drive this project from the start with minimal involvement from the existing project maintainers. No consultation happened at any point in planning, not just to ensure the goals were in scope, but also to ensure the project is stewarded towards a point that everyone can walk away with a sense of completion. The second biggest mistake was in planning for upstreaming, instead the work piled up on a branch in a personal repository. To be fair, the supporting bits got merged over time, and there’s got to be some breathing room for new initiatives. But sooner or later there’s the harsh reality that the work has to be divided into tractable pieces and pushed in a structured manner through the review process, in order to end up with the work merged upstream. The Mutter low level pieces were merged over the course of 1 year after the STF project, divided in 3 (1 2 3) merge requests, and some of the corresponding GNOME Shell changes to make use of this (no longer) new infrastructure were merged as well. But meanwhile the mobile-shell branch kept piling on, north of 300 patches, with substantial changes to code (diff is +120437 -7156, by my accounting) and UI. The original author did not make attempts to upstream the changes, and the few efforts from other participants to upstream bits of it or as a whole did not last long, unfortunately. The work is nowadays sitting on its separate repository, using a separate issue tracker. The mobile BoF at Guadec This jagged interaction between the people acting as maintainers and the people driving the mobile-shell initiative lead to difficulties in making this work upstreamed in a timely fashion, much to everyone’s disappointment. In this situation, we arrive to this year’s Guadec. There is of course an interest in upstreaming the changes, from Mutter+Shell core developers and maintainers included, so we attend this BoF. What happened there could be best described as a maintainer shaming session, specifically towards Jonas Adahl, Florian Müllner and myself, for “discriminating/demotivating newcomers”, “wanting to steal the spotlight”, “stalling things on purpose”, … essentially choosing slander as a way to put the blame on us for not having merged the work as-is. Even though this attack was driven by a few closely related to the initiative, it happened in front of 20+ people. This was not ok Even though I understand the frustration behind, I find the tactics used on us inexcusable. Look, the community guidelines at conduct.gnome.org are a bar to meet for everyone, towards everyone. And the guiding principle of them all is pretty simple, we all row the boat roughly in the same direction. Once the basic principles of respect are lost between us, the boat does sink. The main asset that keeps Free Software moving forward is not the code, but the people. Jonas, Florian and myself are lucky to be paid by our employer to work upstream on GNOME, but I can say for myself (and perhaps the three of us) that I work at Red Hat because I work on GNOME, rather than the other way around. We go well beyond our duties, in ways our employer does not care in the slightest if we do, and in ways it consumes our free time as well. We have looked to nurture the community, mentoring in GSoC and Outreachy more times than it’s worth counting. The accusations of discrimination fall entirely flat. We so far had no trouble in collaborating with the main developer behind the mobile shell work either, there’s 226 merge requests merged from him in GNOME Shell and 151 in Mutter attesting that. This strain on relationships is not baggage free. I don’t see myself working with the individuals that drove this attack pretty much anymore with any productive outcomes, and I will avoid that to the extent of my capabilities. There is an unbelievably long road to undo the damage they’ve done. How to improve from here The mobile fork is currently sitting in a separate repository, based on a now old release, and contains a number of back-and-forths, FIXMEs, WIPs, and code that has been either already done (albeit differently) or entirely refurbished upstream. A rebase that is mindful to all these and brings the branch to a plausible up-to-date state is likely to take days to weeks. At this point, it could make more sense to identify the possible topics to split into multiple (many) merge requests, and cherry-pick the patches individually. After these merge requests are done, they should go through review, and the style/architectural differences between the original author and the maintainers’ mindset be settled. Changes could be merged incrementally, advancing towards the common end goal. It looks like I just described the software review process in a nutshell, and I very much did! But I feel it is important to point out that nothing of this has happened yet with these patches in a proper or substantial way. In a shred of constructivism during the Mobile BoF, Markus Göllnitz offered himself to do this on behalf of the original author. I am looking forward for these steps to happen, and will collaborate with Markus on it. I deep down hope that this blog post also serves as a cautionary tale about how wanting to rock the boat instead of rowing together may stall initiatives, and eventually poison relationships.

Andreas Gabriel Berbescu has reported several root privilege escalation vulnerabilities in various NetworkManager VPN plugins. If the VPN plugin is installed, then an unprivileged user can escalate to root by loading a malicious VPN configuration file: (CVE-2026-91837) network-manager-iodine: Option confusion reaches iodine’s pre-drop root shell (CVE-2026-91838) network-manager-sstp profile data reaches root pppd pty shell (CVE-2026-91839) NetworkManager-fortisslvpn credential newline injection permits local root code execution (CVE-2026-91840) NetworkManager-vpnc: Top-level VPN username newline injection reaches a root password helper (CVE-2026-91841) NetworkManager-vpnc: Incomplete fix of CVE-2018-10900 While most obviously bad for multi-user systems, root privilege escalation is also a serious defense in depth problem for single user systems. You are vulnerable if you have the VPN plugin installed; it does not matter whether you actually use it or not. These are not vulnerabilities in NetworkManager itself. The VPN plugins are each separate projects, with their own separate maintainers, hosted by GNOME rather than by freedesktop.org. The status of each project is a little different: The NetworkManager-vpnc and Network-Manager-fortisslvpn git repos have both been archived. Contributions are no longer accepted, and you should uninstall them immediately. NetworkManager-vpnc users should migrate to NetworkManager-libreswan, and NetworkManager-fortisslvpn users should migrate to NetworkManager-openconnect. network-manager-sstp is currently unmaintained, but it is not obsolete. If you are interested in SSTP, this project needs a new maintainer. network-manager-iodine is maintained, and the maintainer has created a merge request to resolve this issue. For more information on NetworkManager VPN plugins, see Josephine’s VPN plugin overview and announcement.

In July, I shared an update about my new role as AI Alignment Community Architect at Red Hat, focused on Fedora. This post clarifies what that role entails, why "AI alignment" is more than a technical term, and how I plan to support the Fedora community in leveraging LLM-gen-AI. I organized this blog post into three sections: Reclaiming AI Alignment: The meaning behind the term. Model builder engagement: Why do we need bidirectional feedback loops? My work in Fedora: Upcoming priorities this quarter and the path forward. Note I use the term “LLM-gen-AI” throughout this article aligned to the Software Freedom Conservancy’s recommendations. This is in support of addressing this technology in community-first terms. Reclaiming AI Alignment: The meaning behind a term As I defined my new role, I carefully considered the title. The Fedora community sentiment toward LLM-gen-AI is deeply divided: some rally against it, while others push for rapid adoption without wider community consensus. I needed a title that signaled a neutral, balanced approach. My mandate at Red Hat is to support upstream projects in adopting AI, focused primarily on Fedora. Working in the “AI” space at Red Hat is fascinating because I am exposed to diverse ways that customers use and deploy innovative open source technology. Additionally, Red Hat provides real value by supporting customers in their “hybrid AI” journeys. Many of my Red Hat colleagues consistently push for more Free Software and open source answers for customers and enterprises building infrastructure to support AI inference, local models, and more. Red Hat has a responsibility to innovate when new technology opportunities emerge that its customers are acting upon. With this in mind, I am more convinced that LLM-gen-AI is something that open source maintainers and contributors can leverage for real workloads. There are opportunities to solve real problems and routine maintenance tasks for complex projects. LLM-gen-AI used right can support maintainers in automating boring, cyclical work so they can focus more on the exciting work of innovation and focused engineering efforts within their projects. Or even going outside and spending time offline. However, I distinguish "AI alignment" from "AI adoption." "AI adoption" communicates a pre-defined, non-negotiable stance where the goal is simply to increase usage. "AI alignment," by contrast, communicates that LLM-gen-AI use exists on a spectrum. My intent in Fedora is not to insist, but to negotiate and compromise. I want to align how our community uses these tools with our existing values, norms, and culture. CHAOSS AI Alignment Working Group & model builders My approach to "AI alignment" is influenced by the CHAOSS Project. I co-chair the CHAOSS AI Alignment Working Group with Emma Irwin and Coraline Ada Ehmke. Recently, Emma, Adrian Edwards, and I presented at FOSSY 2026 on this topic in greater detail. This experience frames my definition of "alignment" as I move forward in my new role. Traditionally, "AI alignment" is a term used by model builders to describe processes where communities have little influence. As LLM-gen-AI grows in widespread use, the power gap between those model builders and the communities they impact will widen. This creates an unsustainable dynamic in the safety and well-being of our communities with these new tools. We need more than just "AI adoption". We need bidirectional feedback loops. Free Software communities deserve a seat at the table. This is not just for iterating on model development, but for defining how we integrate LLM-gen-AI tools sustainably and responsibly. To achieve this, we (i.e., open source community citizens) need a stronger value proposition for engagement with model builders. Whether commercial or altruistic, we must persuade model builders that a community-driven approach is a critical advantage. If we refuse to engage, we risk Free Software values and culture being shut out of conversations entirely. So, I believe it is better to be an advisor than a bystander. Advising is its own form of open source contribution. Therefore, I lend my support toward the wider notion that "AI alignment" fosters two-way conversations that ensure model builders actually listen to the communities their work impacts. My work in Fedora: What I hope to work on next September 2026 is my first full month in this role. While there is still much to define, a few priorities have emerged. Here is where I will be focusing my initial energy: Migrating "This Week in Fedora": Aurélien Bompard (@abompard) created a useful tool for AI-curated, human-reviewed weekly summaries. Currently, it lives on a personal fedorapeople.org space. I am beginning to work with Aurélien to migrate this to a weekly WordPress article on the Fedora Community Blog, since we first began talking about this in July. I am already submitting pull requests to support this transition. Launching LLM-gen-AI Agent Skills: Together with the AI/ML SIG, we are building the Fedora Agent Skills Library. These define best practices for using LLM-gen-AI agents to automate routine maintenance. My immediate task is community architecture: setting up the repository for contributions and improving documentation so these skills are accessible and scalable. AI/ML SIG Documentation: As the Fedora Docs Team works to identify "team captains" for specific topics, I am volunteering to lead AI/ML SIG documentation. This involves importing or deprecating content in the Quick Docs site and migrating extensive Wiki documentation to the Fedora Docs site, creating a central, discoverable home for all things LLM-gen-AI in Fedora. An update to the Fedora AI-Assisted Contributions Policy?: Honestly, I am not sure about this one yet. But it seems apparent to me that eleven months after the Fedora Council first introduced the Fedora AI-Assisted Contributions Policy, it is time for an update. Nearly a full year of lived experience has happened within the framework of this lightweight policy. Furthermore, a coalition of Fedora contributors agree that an update is needed, but there is not a single, shared view of what those updates should be. It will take more community input and feedback to shape the next iteration to that policy. I anticipate facilitating inclusive future community conversations about what those changes should be. I am both excited and nervous to work with fellow Fedorans on these initiatives. I know there are strongly-held opinions on both sides of the LLM-gen-AI debate. (An understatement!) I accepted this role because I believe participation is more constructive than standing on the sidelines. My goal is to navigate this work in alignment with Fedora’s Four Foundations: Freedom, Friends, Features, First. Until next time! Since March 2026, I invested a lot of time into migrating my blog to a new publishing system and improving the website user interface. However, now that my site is fully functioning on a technical level, it is refreshing to begin writing content again here. There is more to come from me in this space. Expect new content about my work in Fedora and the LLM-gen-AI space, and other open source and personal items too.

¡Hola! 36 hours of travel, multiple buses that didn't want me, one unexpectedly early morning, a trip to Porto, a lot of GNOME, and an unreasonable amount of coffee. That's GUADEC 2026 for me. For more details, read on! Usually, I churn these out in about a week after the conference, but this time it took a bit longer due to extreme workload, another conference just after GUADEC, and the travel chaos. Let's start :) Unlike last year, I went easy on myself and didn't delve into giving a talk each day of the conference. My main talk on Open Forms BoF on GNOME Foundation Internships - Unrecorded 😅 The main talk was on Day 1 of the conference, which was quite exhausting, not due to the talk but because I had to wake up on time. I had the pleasure of sharing my journey developing open forms and why it exists. Attending GUADEC was much easier this year. If you haven't been following my blogs, then last year was quite a rollercoaster with travel and visa issues. You can read last year's rant at https://aryank.in/posts/2025-09-06-guadec-2025-experience/ , but now I finally have a 2-year visa, so no more pain for some time :D Anyway, let's proceed with the blog :D The touchdown Due to a lack of flights to A Coruña, I had to take connecting flights through other cities to reach my destination (as I believe most did as well). All in all, it was about 36 hours of travel to reach A Coruña. From Bareilly to Delhi, then to Qatar, then to Barcelona, and finally to A Coruña. Phew, if it wasn't the excitement of attending GUADEC, I might have surrendered midway. In Qatar, I found two of my good friends waiting for their connecting flights as well. Turns out, we had the same layover and connecting flights onwards. Seeing the struggles Aaditya went through for previous additions of GUADEC in securing his visa, I was insanely happy that he succeeded this time! Having the company of Aaditya and Sailesh, we made a quick exit at Barcelona to visit La Sagrada Familia before catching our connecting flight to A Coruña. It was a super short visit, and we couldn't even go inside the basilica. Nevertheless, seeing it from the outside was still breathtaking. Can you say you travelled to Spain and didn't see La Sagrada Familia? The pre-conference party I was looking forward to attending it, but the long journey, combined with the exhaustion from travel, made it quite challenging to muster the energy for the party. Also, my hotel was way too far from the venue, making it even more inconvenient to attend. Not to mention, I was famished, and any longer without food and I would have turned into a hangry mess. So unfortunately, I had to skip the pre-conference party and head straight to find some food. But but but, even though the hotel was far, it was at the perfect spot possible. Close to the attractions, the market, the beach, everything. Thanks, Canonical! The first day of the conference My first day is always a shocker. And my journey with the bus in the EU has always given me pain at least once, haha. When I boarded, just like last year, I was again denied entry, as on the UDC line you can't tap your bank card, which wasn't the case with the airport bus, and the only bills I had were 100 EUR (Thanks to my chosen forex service :( ). Thankfully, a student paid for my bus fare even without asking (kindness is still alive, people). As soon as I boarded, I downloaded the A Coruña public transport app so that I could pay myself for future rides. This actually portrays how poor my planning was this year. Every year, I spend at least a month knowing everything about the city, this year, I hardly spent a day, didn't even check what to visit :) Lesson learned for next time! Kudos to the GUADEC team, as the website clearly mentioned the public transport and other logistics, which I overlooked. After reaching the venue, I spent 10 minutes wondering where the conference was. The map link on the website was for the university, but not the exact building. Eventually, I found another attendee who guided me to the right location. Upon entering, I met Anisa, Kristi, Asmit, Deepesha and so many more familiar faces. I had a fun time asking everyone to guess my name to figure out who actually cares :) Joking on that part, I'm terrible with names and faces myself, but it's always fun to make things awkward lol. We started with the conference welcome session, where, of course, I didn't hear any of it properly, being too busy catching up with everyone around. I then had to quickly rush for Aaditya's session. Which was full of energy and insights, as always. GNOME Nepal has been doing amazing! Following his session was mine! Again, the first talk I hadn't prepared at least 100 times. But I believe it was one of my finest yet! Lesson learned again, too much preparation sometimes makes the talk boring, uncertainty makes it lively and engaging. Following which, was Sailesh's session, which was equally engaging and informative. The day went on with multitudes of sessions and amazing talks as GUADEC usually does. Then, Felipe asked me, if I'd like to join him for the community update at the end of the first day, and of course I said yes. From being an intern in 2022 to now being a part of the Internship committee and presenting at the community update, it has been an incredible journey. The growth, learning, and experiences I've had along the way are truly priceless. If you want to watch - the community update The second day of the conference While staying at the conference, we rarely get the time for sightseeing, so I did what my brain can not fathom... I woke up early :) And that was so worth it, went on a super early morning trip to the Tower of Hercules. Thankfully, I did a bit of searching on the bus and learned that you can go to the top, and so I did! And no pictures, no stories or whatever I say can justify the visual bliss I received. I just fell in love with A Coruña right there. But I had a conference waiting for me, so on we go. The highlight talks for me were "When Porting Isn't Enough: Rewriting a Python GTK2 Application for GTK4", "GNOME Internationalization: accessibility for all over the world!" and "Session Save/Restore" The one that particularly piqued my interest was the Internationalisation talk. It was fascinating to see how GNOME is making efforts to ensure accessibility and usability for people all over the world, and how what phrases we think are simple or sufficient in our context can be completely different in other languages and cultures. Always insightful and eye-opening! Then, just before the lightning talks, we had "The Future of Boxes" session by Felipe. Having discussed it with him in the past, and having had the pleasure of being one of the people who got to test it before the official release (and annoy Felipe with nitpicks), it was fascinating to see the improvements and new features being showcased. Boxes looks really promising with the new features and improvements, and I can't wait for the stable release. Then we had the intern lightning talks, where several interns shared their projects and experiences. It was inspiring to see the fresh perspectives and innovative ideas brought forward by the new members of the community. The third day of the conference As you can guess by now, it was great as well! The highlights? Those were the super longggggg AGM, but also the engaging discussions and the sense of community that made it all worthwhile. Followed by State of the Shell, a must-watch ALWAYS! And we ended the day with a great conference dinner. Instead of taking the bus to the dinner venue, I walked. This is something I learned at last year's GUADEC: if you really want to experience the city and its atmosphere, walking is the best way to do it. You find monuments not listed anywhere, hidden gems in the streets, and get a true feel of the local life. The food was amazing, the company was great, and the atmosphere was just perfect. The highlight? Drinking Queimada. The traditional Galician drink was both fun to watch being made and delicious to taste. The funniest bit was seeing people who have experience with alcohol still being afraid just from the extremely potent smell. It felt like I could get intoxicated just via that aroma alone. But the taste? It was pretty amazing! Although I was offered another glass, I had to refuse. Remember, kids (me being one too) drink responsibly! I thought that this was it, that's the end of the day, but it wasn't. Me, Felipe, Alan, Tobias, Jakub Steiner, and a few others decided to walk to Maria Pita Square to watch football. Now, I was an imposter there, as I had no clue what was going on in the match. But the vibe is what made it fun! We then had a good discussion on Indian currency notes, where I handed Felipe some to take back home. I never thought my own country’s currency could spark such interest and conversation among international friends. For me, they are pretty boring hehe. The BoFs Being a GNOME GSoC'22 Intern, and now a part of the GNOME Internship Committee, I had my third and final talk (kind of), the GNOME Internship Committee Meetup, where we discussed the future of the program, the challenges we face, and how we can improve it. As it was Sunday, the bus service was heavily disrupted, a bus denied me again, citing that they won't drop me in the city, only at the airport. So, I had to walk to the venue, my legs gave out after it, and I was partially drowning in sweat by the time I reached (not a great sight). But I had to be there! Thanks to a pizza party earlier that day, sessions were delayed, and I could relax somewhat before the discussions began. I was continuously on chat with Felipe, ranting about the bus situation and my struggle to reach the venue on time. Thanks, Felipe, for organising it and inviting me to be a part of it. It was great to see the progress we have made and the plans we have for the future. The same day, we also made plans to watch the World Cup Final at Maria Pita Square. Due to bad network and an insanely packed area, we couldn't find each other, but man, what a time to organise GUADEC. Even though I was again an imposter there, I was there more for the vibe. When the match went into overtime with the score still being 0-0, I left for my hotel, as I had no clue who could win, and a city with disappointed fans packed in one area is not something I would vibe with :) But I'm so gladddd that Spain won! I was in my room when my college friend Shreyash motivated me to go out again and not waste it, so I did. And I have to say, that was soooo gooodddddd, all the crazy fans, the vibe, the sounds, people using horns to play songs and rhythms. IT WAS BLISS IN NOISE. The Final BoF Day After attending the BoFs, as per Emmanuel's recommendation, I went and visited the Aquarium, making sure to go at the time when they offer food to the Seals. Thank you, Emmanuel, for the inspiration, as otherwise, an aquarium would have been pretty down the list. Watching the Arctic shore, the spectacular underground water tank and a real warship I spotted in the Arctic would make it forever memorable (the Aquarium was on the shore, so you could see the ocean). The Porto tour As this year the day trip was self-organised, I took a detour and went to Porto. It was a short trip at best, and quite draining for my wallet, but totally worth it for the experience and the memories made. I absolutely loved and hated their topography. The steep hills and narrow streets made each spot a marvel to click pictures, explore and absorb, but navigating those same hills made my legs ache and my stamina tested. Coffee Conference I am going to call GUADEC the "Coffee Conference" because of all the amazing coffee experiences I get there. Last year, after discussions with Federico, I learned a lot and bought a Bialetti Moka Pot. And, it was such an amazing investment. Not only that, I asked him jokingly to bring me beans from his area next year. This year, Federico actually brought me some beans, and it was such a treat. The aroma, the taste, everything was just perfect. It felt like a little piece of Mexico had come to my home. Just like last year, this year's splurge was a grinder. Federico recommended multiple times that grinding at home is a completely different experience. So, I went ahead and bought one. Although it was a heavy splurge, it was totally worth it for the experience and the quality of coffee it produces. I used to get pre-ground, as there isn't any grinding facility nearby, and as they were in bean form, that was sufficient reason for me to finally drop the hammer. Meeting people At last, I met many new people and got to learn a lot. Made new friends, got to meet people I look up to and many more. And I really missed Aarti and Sri :( I wish they both were there. The Return During return, I again got to meet Sailesh, Aaditya and Federico :D I wanted to bring some good white wine to India, as Spain had some really nice one, so I took Federico's help in picking one from Duty Free, and I'm gald I did, got to learn so much about picking the right one, and it was all so much. Btw, it tasted awesome, so thanks again :) Another special thing that happened was that just a day after I landed back in India, I had my college graduation. I got to regroup with my old friends, receive my degree, and, well... clicked a lot of pictures :P But this was one of those moments that will keep it memorable for me. The End When I attended GNOME Asia Summit as a GSoC intern in 2022, I never imagined I'd return a few years later as part of the Internship Committee and present at the community update. Looking back, that's probably what I'll remember most about GUADEC 2026, not any particular session, but how much this community has changed my life. Thanks to all the people for making the event so great. I would also like to thank Ubuntu CDA for sponsoring the trip :) I hope I used it to the fullest and made the most of it. :D

I've been doing weeklybeats 2026 almost entirely on the Dirtywave M8 -- often on a Sunday night, in bed, on an actual hw. This was before Tim went and elevated a hardware abstraction layer into a proper iOS App (which I still very much recommend). This particular tune though, "Innit", is an oddity for me: it lives on the Analog Four, a box I got from a friend ages ago for an absolutely irresistible price. It mostly collected dust. I'd make a few tunes here and there but never really dug into the stuff that makes it unique. Other than having individual channels ready for effects pedals and exposing the Elektron sequencer via CV for your eurorack addiction (stuff that I for sure will never use). I've been putting off learning about the performance macros forever, and I hate myself for it. Luckily the amazing Ivar Tryti revealed his mastery on Youtube which helped a lot. The concept is simple: you bundle up to five track parameters onto a single macro knob. Ten of them live on the performance page making is far less stressful of a navigation when performing. There's a setup cost, you need to precisely tune the parameter interactions, but once that's locked in, live performance becomes a far less stressful affair. You can also live map any or all of these ten mappings onto a single encoder for otherwise physically impossible twistings. This is easily remappable during the performance. I'm still a noob at this, but the point is the same as always: there's real joy in performing and building up energy for the drop in real time -- way more satisfying than preprogramming the whole sequence.

It’s been another fantastic year for Google Summer of Code with GNOME! This year, six contributors worked on a range of interesting projects across our ecosystem. Our contributors have been blogging about their progress on Planet GNOME throughout the summer. In case you missed their updates, here is a breakdown of what they have worked on: Adding a recovery mechanism for GPU resets in Mutter by Toluwaleke Ogundipe Adding debug adapter protocol (DAP) support to GJS by Angelo Verlain Shema Playing vocab-style puzzles in GNOME Crosswords by Laureen Caliman Rewriting the Pitivi timeline ruler in GTK4/Rust by Michael Calabrese Implementing app uninstallation in the GNOME Shell app grid by Ramayanapu Jagath Porting Gitg to GTK4 by Shivam Our interns also presented their work during GUADEC. You can watch their lightning talks on YouTube. This would not have been possible without the support of our community mentors. A huge thank you to Jonathan Blandford, Federico Mena Quintero, Alex Băluț, Yatin, Adrian Vovk, Jonas Ådahl, Robert Mader, Carlos Garnacho, and Philip Chimento. Mentoring takes a lot of time and energy, and it plays a vital role in onboarding new contributors to our community. If you are a GNOME developer and interested in mentoring a project next year, you can already start working on your project ideas and submit them at gitlab.gnome.org/Teams/internship/project-ideas. If you are a newcomer interested in starting your journey toward becoming a GNOME contributor, check out gsoc.gnome.org and stay tuned to Planet GNOME and our social media channels for updates on the 2027 program!  

Google Summer of Code 2026: Native App Uninstallation in GNOME Shell This summer, I spent my Google Summer of Code working on something I’ve wanted to see for a while, making it possible to uninstall apps right from the GNOME Shell app grid. Before this, if you wanted to remove an app, you had to open up GNOME Software, hunt it down, and delete it from there. My goal was to completely remove that friction. By connecting GNOME Shell and GNOME Software behind the scenes using D-Bus, I made it so users can securely delete apps with just a couple of clicks right from the desktop GitLab Links to Code GNOME Shell: App Grid Uninstallation Frontend This Merge Request covers all the frontend work I did in GNOME Shell. The brain behind it all is a new class called AppStoreIntegrationManager. Think of it as both a state tracker and our bridge to GNOME Software. When it boots up, it connects to GNOME Software asynchronously over D-Bus using the org.gnome.Shell.AppStoreIntegration interface. To keep the app grid feeling snappy, I didn’t want to query the app store every single time a user right-clicks an icon. Instead, the manager grabs the dictionary of uninstallable apps and caches it in memory. To make sure this cache is always accurate, it listens for installed-changed signals from Shell.AppSystem and quietly updates itself in the background. Because the data is cached, the UI just has to react to it. When you open the context menu, it checks if the app is in our cache; if it is, the “Uninstall” button appears. This is a great way to prevent users from accidentally trying to delete core system apps. Once a user clicks uninstall, the frontend checks if the app supports purging user data. If it does, a confirmation dialog pops up with a checkbox to wipe those files. After confirming, the app goes into a tracking Set (_uninstallingApps). This immediately tells GNOME Shell to remove the app icon from the grid right away, giving the user instant visual feedback that the app is gone. Finally, if the background job finishes successfully, it happens silently without spamming the user with notifications. However, if the uninstallation fails for any reason, a system notification pops up to let the user know what went wrong. GNOME Software: App Store Integration Backend This Merge Request focuses on the backend GNOME Software. It’s essentially the engine that listens to GNOME Shell and handles the actual uninstallation and data purging. To make this work, I built a custom GObject called GsAppStoreIntegrationBackend. This object exposes the necessary D-Bus methods and acts as a safe router, directing GNOME Shell’s queries straight into the GsPluginLoader. When the Shell asks for the list of uninstallable apps via the GetUninstallableApps method, we can’t afford to make it wait while we search the entire software catalog. Instead, the backend fires off a GsAppQuery using gs_plugin_job_list_apps_new to quickly grab only the installed apps. I also built in a strict safety net: if an application is tagged with the GS_APP_QUIRK_COMPULSORY quirk, we automatically strip it out of the response. That way, GNOME Shell never even gets the chance to offer a “Delete” button for critical OS components like Settings. I also spent a lot of time on secure data deletion, which is super important for sandboxed apps like Flatpaks. To pull this off, I extended the core plugin architecture by introducing a new flag, GS_PLUGIN_UNINSTALL_APPS_FLAGS_PURGE_DATA, to the GsPluginUninstallAppsFlags enumeration. Now, if a user checks that ‘wipe data’ box on the desktop, the backend attaches this flag to the uninstall job. I modified the Flatpak plugin (gs-plugin-flatpak.c) to intercept it. Once the standard uninstall finishes successfully, the plugin spots the flag and calls gs_utils_rmtree() to safely and recursively scrub the isolated app data right out of ~/.var/app/<app-id>. GUADEC 2026 Presentation Honestly, one of the absolute highlights of my summer wasn’t even the code, it was getting to share this project with the wider GNOME community at GUADEC 2026! I had a blast giving a talk about how this feature actually works under the hood. I walked through the technical hurdles of bridging GNOME Shell with GNOME Software. You can check out my presentation here What’s Next? This project might be wrapping up, but my time with GNOME is just getting started. My immediate goal is to finish up the its and bits and get it merged. Once that’s done, I’m already looking at my next feature to add, implementing drag-and-drop uninstallation into the app grid A huge thank you goes out to my mentor, Adrian. His patience and guidance meant everything to me this summer. He didn’t just review my code; he took the time to help me really understand the bigger architectural picture. Because of him, I’ve grown so much as a developer. I loved how he would take the time to explain the deep history of Linux architecture to me, like how default applications and URL schemes eventually paved the way for XDG Intents. Combined with all the practical debugging techniques he showed me, he really helped me level up this summer. It’s been an amazing ride, and I’m so excited to continue my journey with GNOME and the open source world!

Update on what happened across the GNOME project in the week from September 4 to September 11. Felix announces Hey everyone, there won’t be a new issue of TWIG from me today… for a good reason! I’m happy to announce that Brage Fuglseth is now officially part of the TWIG team. Going forward, we’ll be alternating weeks, taking turns publishing TWIG. Today’s issue will be handled for the first time by Brage! TWIG has been running successfully for 265 weeks now, and I’m thrilled to have an additional editor on board. With that, the future of TWIG is looking brighter and more sustainable than ever, welcome aboard, Brage! GNOME Core Apps and Libraries Mutter ↗ A Wayland display server and X11 window manager and compositor library. Yves Auxier reports Mutter has landed support for custom pointer input acceleration profiles in time for the GNOME 51 release in this merge request! For more details, you can check the custom-accel-config GSetting key on your system under org.gnome.desktop.peripherals.{device_type} and change your pointer acceleration profile to custom, and your desktop will use a user-defined pointer acceleration curve; the change was made in this merge request. There are a couple other changes which you can also see in the NEWS file in the mutter git repository. Calendar ↗ A simple calendar application. Hari Rana | TheEvilSkeleton (any/all) 🇮🇳 🏳️‍⚧️ reports GNOME Calendar has received tons of improvements in the past few months: The event editor dialog has been cleaned up and reworked to allow focusing and selecting text on read-only events, as opposed to the current version which simply disabled everything. The rework introduced a couple of bugs that would have warranted to revert all of them, but Niklas Wimmer has heroically saved the rework by fixing the remaining issues: !792, and !798 The codebase has received a nice cleanup that removed 1500 lines of code and fixed a bug. Addresses can now be opened in GNOME Maps (or other maps app) from the event popover, thanks to Alistair Francis. The week view now adapts to high contrast Calendar now supports Microslop Teams links. Keyboard navigation in the month view has received a nice upgrade: it is now possible to focus the event widget in front of its cell using Shift+Tab (see screen recording) Georges has made some crazy rework and optimization on how events are being retrieved and displayed, making the experience significantly smoother: !742, !757, and !761 Empty notes in the event editor dialog will now display “Notes” as a placeholder, thanks to Zelda Ahmed. Third Party Projects Jogger ↗ Fitness tracker baarkerlounger reports Jogger fitness tracker had a big new release this week. New features include importing FIT workouts from Garmin devices, setting and tracking progress towards weekly monthly or yearly goals, tracking gear like shoes or bikes, auto-pausing workouts, grade adjusted pace metrics and a new 3D-flyover map view. There are also big improvements to the statistics pages with better charts and a new “personal bests” tab and calendar/streak view. Thanks to everyone that has helped translate Jogger on weblate or has raised issues on codeberg. Gitte ↗ A simple Git GUI for GNOME Christian reports Gitte, a simple Git client for GNOME built with GTK4, libadwaita and Relm4, just got its 0.10.0 release! 🎉 The headline feature this time is side-by-side diffs: you can now compare the old and new versions next to each other, with separate settings for the working copy and history views. If you need more context, Ctrl+Shift+E toggles between showing the whole file and just the changed context. Git LFS and submodules are supported now as well. You can set up LFS, manage tracked patterns, inspect its status and start tracking files straight from the working copy. Submodules can now be added, updated, synced, configured, deinitialised and removed from within Gitte. A few more things can now be managed per repository: you can add, rename, delete and fetch individual remotes, and delete remote branches together with their tracking configuration if you want. Commit and tag signing can be configured too, including the signing format and key, and the revamped signing-status dialog helps you figure out what needs fixing when the configuration isn’t quite right. There are some handy new shortcuts and actions: F4 opens the current repository in a terminal, and Ctrl+G / Ctrl+Shift+G take you to the next or previous search result. You can add several selected files or patterns to .gitignore at once, choose whether a new branch should be checked out immediately, and optionally have Gitte open the repository in the current working directory when started without a path. On the UI side, you can now choose a light or dark appearance or keep following the system setting (the old standard). Commit information now sit directly beside the graph lanes, working-copy filters make it clearer when they are active and offer reset actions, and most context-menu actions now work with multiple selections. Commit messages and stash details can be selected and copied, code and diffs use the system’s monospace font, and sidebar and list pane widths stay put when resizing the window. Performance also got some attention in this release. Repository startup and commit-graph loading are much faster, especially with lots of remotes and remote branches, as are staging, unstaging and discarding all changes. Working-tree status and safety checks before rewriting history are faster too, particularly with large untracked directories. Diffs outside the visible area are rendered lazily, and large diffs initially show the first 500 lines until you choose “Show All”. And of course there is the usual pile of fixes: staging selected lines now works across multiple hunks, diffs refresh correctly when hunk headers change, and “Edit Commit” now lets you actually modify the commit instead of just stopping the rebase at it. Rebases also resume correctly after commands that pause the operation. Context menus open at the right size, and macOS got fixes for window controls in collapsed-sidebar mode and for finding Git, GPG and Git LFS installed outside the default application environment. Under the hood, many Git write operations have moved from libgit2 to the Git CLI for more consistent behaviour, the Flatpak package got smaller by stripping the bundled Git binary, and test coverage has grown. There are also updated Basque, Cornish, Finnish, Slovenian and Ukrainian translations, plus fresh dependencies. Get it on Flathub, for macOS or have a look at the Code. Rat Cornu says ratic music player had a small release this week for music sorting in the application. The main features of it are the ability to sort musics by their path on your system, the fact that musics in groups (albums, artists and playlists) can be sorted as well, and a “natural” sort has been added for albums. You can check the v0.4.1 directly on flathub, on the repo, or even come discuss with us on our matrix room! Thanks again for all the people that contribute to the localization on weblate. Nathan Perlman says Rewaita received a small update this week, mainly just adding features users have requested in the past. This is what has been done in v1.1.7: Firstly, you can edit existing themes to make them your own! This has been requested since 2025, and I finally got around to adding it. You can also create new themes from images, similar to pywal. Some miscellaneous theming fixes and polish improvements where needed. I hope you all enjoy this release! You can get Rewaita on Flathub or the AUR if you don’t have it, and want to give it a try. 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!

It has been quite a long time since my last post with release news for GVfs. I haven’t had much time for upstream development recently. Furthermore, I was out for health reasons for almost the entire last year, so development has been mostly focused on bug fixes. Still, there are some changes in GVfs 1.62 and 1.60 worth mentioning. Auto-unmount of inactive backends The biggest addition is the auto-unmount feature (!330), which fixes a very old feature request (#31). This feature introduces a mechanism where certain backend can be automatically unmounted after a defined period of inactivity. This was enabled for the most of auto-mounted locations (i.e., admin, computer, http, network, recent, trash). This solves a long-standing issue where auto-mounted locations couldn’t be easily unmounted via the file manager, causing their daemons to run until the end of the session and needlessly waste system resources. Security fixes The current influx of CVEs hasn’t missed GVfs. The highlight of the 1.62 release is a fix for a local privilege escalation issue (CVE-2026-88924), which I describe in more detail in a separate post. Aside from that, several other lower severity CVEs were addressed (CVE-2026-28295, CVE-2026-28296, CVE-2026-84267, CVE-2026-84268, CVE-2026-84269, and CVE-2026-84270). Also other potential security vulnerabilities that didn’t receive specific CVE assignments were patched across these releases. Deprecating backends I am also continuing to clean up the codebase. As part of this effort, the legacy burn backend and several deprecated APIs have been completely removed. Additionally, the afp and archive backends were marked as deprecated and will be removed in future releases. The google backend has also been disabled and marked as deprecated, however, there is an ongoing effort to restore this functionality, but it did not make it into this release cycle though. I would like to thank all the GVfs contributors who helped keep the project moving forward, especially while I was away. Let me know in the comments if you have any thoughts on the recent changes!

A security vulnerability (#875) in the gvfsd-admin daemon that allows local privilege escalation was recently discovered and is tracked as CVE-2026-88924. What is the issue? The problem relates to how the daemon creates a private D-Bus socket. Previously, the socket was created with root privileges, and then a chown() call was used to change its ownership to the invoking user. Because this happened inside a user-controlled directory, a local attacker could exploit a race condition by quickly replacing the newly created socket with a symlink pointing to a root-owned file (e.g., /etc/pam.d/su). This would grant the attacker ownership of that critical file, leading to a local root privilege escalation. Who is affected? To exploit this vulnerability, an attacker needs local code execution within an active graphical session and must belong to a privileged desktop group (like wheel or sudo). The gvfsd-admin backend must also be installed. Unfortunately, these conditions are met by default on many standard desktop installations. What to do? The fix is already merged (!352). The issue was resolved by using setfsuid() to set the correct filesystem UID before the socket creation. New versions 1.62.0, 1.60.3, and 1.58.5 containing this fix have just been released. I strongly recommend all users and distribution maintainers to update as soon as possible. Finally, I would like to thank the security researcher lain for discovering the vulnerability and providing a very detailed report!

Breakfast, kindly taken to the venue by Arnaud in his car. Good to catch up with a number of people and get the latest state of affairs. Gave a talk about the FLOSS Office space past and present no doubt omitting lots of great projects I didn't notice yet (or remember). Trying to stress that commercial reality sadly beats technical excellence in lots of contexts, no doubt the recording will be published at some stage too:

Two weeks ago, I released AppStream 1.2.0. This release contains a lot of great changes, but one of the most important ones concerns how media are being handled, and AppStream’s default image export format. AppStream is a Freedesktop metadata standard to describe software components. That can be anything from system services over fonts to console and graphical applications. AppStream metadata is supposed to give users enough information to decide whether they want to install a piece of software, to represent that piece of software, and to give the operating system enough information to decide whether a software component should be installed automatically and (to some extent) what capabilities and relations it has, to provide the user with sensible options. Especially for the first two goals, and especially for GUI applications, AppStream supports icons and screenshots, which are used to showcase applications. Today, AppStream is used by all kinds of services, from Linux distributions over firmware updates to Flatpak and desktops directly. AppStream’s original design however comes from the perspective of Linux distributions in 2011, where you may want to browse the software catalog offline, without delay, and without pinging an external server (which could be a privacy concern). Therefore, a common way to deploy an AppStream-enabled software repository is to ship all icons of all applications in the repository to the user as part of the repository metadata download. AppStream does support remote icon downloads nowadays, and for a while I thought that this would become the default eventually. However, especially in today’s world, having a bandwidth-saving, instantly responsive, privacy-protecting application browsing experience seems more important that ever. PNG images are great! The only format that AppStream supports for icons and screenshots (which are downloaded on-demand from your distributor’s CDN) has always been exclusively PNG. PNG images are perfect for icons, because they compress well (especially for common icon shapes), are fast and simple to load, and can be loaded anywhere, by any toolkit or webbrowser. They also ensure we deliver faithful screenshot images, even though we may have scaled or re-rendered them. Still though, PNG images are less great for screenshots, as they are not very efficient, which puts strain on any CDN that has to deliver them, as well as on people’s internet connections when browsing screenshots. Having smaller thumbnails alleviates that problem a little, but does not fully solve it. But even for icons, PNG could be improved upon: In many cases, icons are re-downloaded with the repository metadata again and again, so having a large icon tarball adds up to the data transferred during metadata refreshes. AppStream also now supports large 128x128px icons, which nobody in 2012 expected we would need, adding even more data that will be re-downloaded. Saving some space here translates directly to lower bandwidth costs as well as faster downloads for users. To improve PNG file sizes, the AppStream Compose library, which handles all image processing and metadata catalog composition, was running optipng on all generated PNG images. That does create smaller PNG images, but they were still relatively large compared to other image formats. For a long time though, there was no alternative to PNG images for icons: There was no lossless image compression format that could give us the same quality as PNG images and that was also widely supported. JPEG-XL vs PNG in AppStream Since 2021 we have JPEG-XL (JXL), which offers a true lossless mode with often better compression than PNG. The issue was that JPEG-XL wasn’t widely supported. Then, in 2025, the PDF Association selected JPEG-XL as the preferred image format for HDR images in PDFs, and now we are finally getting browser support and more ubiquitous availability of the format (you can try it right now in Firefox!). For screenshots, using JXL’s lossy mode, it has obvious and extreme size advantages over PNG, so supporting JXL or WebP for screenshot images was an obvious choice. If JXL would support the lossless case very well as well though, we could serve many use cases with the same exported image format, which is very attractive to me. So, the obvious next question was whether it was worth the pain of switching the icon format, so I did some measurements on real icons. For that I used the AppStream component icon pool that Debian Unstable ships, which is almost 5000 application icons of various sizes, and converted them to PNG: Icon sizeIconsPNG totalJXL totalPool savedPNG avgJXL avgMedian savedMean saved Worst BestLarger as JXL 48×48 1544 3.7 MiB 3.0 MiB 17.8%2.4 KiB2.0 KiB 17.9% 16.7%-118.7%60.0% 206 64×64 2018 7.0 MiB 5.8 MiB 17.8%3.6 KiB2.9 KiB 18.0% 15.8%-112.7%70.0% 279 128×128 1411 11.2 MiB 8.7 MiB 22.0%8.1 KiB6.3 KiB 20.1% 17.5% -89.7%61.0% 209 TOTAL 4973 21.9 MiB 17.5 MiB 19.9%4.5 KiB3.6 KiB 18.6% 16.6%-118.7%70.0% 694 PNG images saved with libpng at effort=4, compression=9, then optimized using optipng -o2, JXL images encoded using vips jxlsave lossless=1 effort=7 strip=1 via VIPS/libjxl. As the table shows, using lossless JXL images over size-optimized PNG images (using optipng’s default settings) provides a roughly 20% gain. This does not look like much, until you consider how often these files are downloaded: A 20% file size reduction may only save 1-2 MiB of disk space, but if they are downloaded over and over again by many clients, it will save a lot of bandwidth. Interesting JXL encoding findings As a sidequest, I was curious why some images were larger than their PNG counterparts when encoded with JXL, and what the ones that were significantly smaller were. In short, the biggest size reductions for JXL existed on images that were already small as PNG, and contained large, flat color surfaces with hard edges and simple shapes. They were not very interesting, and much of JXL’s wins come from accumulating smaller gains across all files, which compound the bigger icons get (especially at 128x128px, where JXL truly shines). The events were JXL loses to PNG are more interesting: For example, it does quite poorly with pixel-art images that have a lot of repeating patterns. Those are encoded well by PNG, but less efficiently by JXL. Take for example Vonsh: Icon of Vonsh, an SDL-based snake game, which PNG compresses better than JXL My guess is that while PNG can exploit the repeating pixel patterns for compression, JXL’s predicts surrounding pixels from its neighbours, which fails too often and makes it pay almost full entropy per pixel. In this single rare case, the PNG is at 5.4 KiB, while the JXL is almost 8 KiB in size. Other cases I looked at were arguably buggy input data, where color channels were hidden under the alpha channel of the input image. PNG could probably again exploit repeats, while we were forcing JXL to encode pixels that were invisible in the final image. This is arguably a problem with the original input data. Currently, AppStream does not make any changes to icons at all, but in future we might add a filter that removes invisible colors from images to solve this pathological case (it was only two icons out of 5000 though, so it is not a high priority). The third case I found where JXL loses to PNG were icons with checkerboard-like patterns: Icon of x3270, an IBM 3270 Terminal Emulator For those, PNG can likely again exploit the repeating patterns, while a checkerboard layout is pretty bad for left/top predictors like JXL’s. However, in this case the size difference (and loss for JXL) is only 450 bytes, so even though JXL loses to PNG, it does so not by much. JXL in AppStream Given these findings, JPEG-XL is the default image format starting with AppStream 1.2.0. AppStream Compose will encode all images losslessly as JXL, while screenshots are encoded in lossy mode at Q=90 effort=7. Since the optipng step does not happen for JXL images, this comes at no speed penalty and is even a bit faster on modern x86_64 CPUs (where libjxl can use SIMD). PNG is still available, and Compose can be told to switch between the two formats. Upsides of JXL in AppStream right now If you use JXL in Compose or the recent release of appstream-generator, you will get much smaller images and, for screenshots, will benefit from other JPEG-XL features such as progressive decoding, providing a far nicer user experience. libAppStream has supported JXL icons since version 1.1.3, so your clients will need that version or a newer one, and all software centers will have to support loading JXL images (which all of them do, provided the right plugins are installed). Downsides of switching to JXL too quickly JXL is a very new format, so web browsers might not yet display it if you are serving webpages. Your clients may also have bugs in processing JXL images, as the format is still “new”. For example, switching on JXL in Debian sent KDE Discover into an infinite loop on startup while trying to load the icons (an issue which has been fixed, but clients will need that patch first before JXL is switched on). This currently makes JXL enablement only possible when you know that your clients can support it. This is the case for me in Debian Unstable and Debian 14, which are using JXL images for a few weeks now, but not for any older releases. Platforms like Flatpak have it even harder, because they do know even less about their clients. So, even though it has big advantages, you may want to hold off on using JXL right away, and force PNG by setting the ImageFormat key to png in appstream-generator‘s configuration, or passing --image-format=png to appstreamcli compose. It is also worth mentioning that JPEG-XL is much, much slower on systems that do not have SIMD instructions or for which the libjxl/jxl-rs library does not have them (such as apparently riscv64 right now). If this is a concern, you might not want to switch to JXL right away. Media pipeline improvements Besides the JXL default change, AppStream 1.2.0 also comes with a complete overhaul of its media processing pipeline. While libappstream, AppStream’s main library, does not do any media processing and comes with very minimal dependencies to be embedded in client applications and used on servers, the same can not be said about libappstream-compose, AppStream’s library to build metadata generating applications (the server-side part, usually). The compose library has to render fonts into font specimen cards, inspect translation files, render SVG images, decode all kinds of raster images, inspect video files, etc. Especially the fonts, and the fact that fonts can appear in SVG images, has caused issues in the past, as libappstream-compose is a heavily threaded library and most font libraries can only work from a single thread. This forced the library to essentially go into single-thread mode anytime anything that could touch a font was being processed. AppStream also originally was created for a “safe world” where applications were vetted by the distributors before their metadata was processed. This is increasingly not the case, so it made sense to put at least a few guardrails on the most complex part of the pipeline: The media processing. As part of the change, media processing was split out into a separate worker process. This solved two problems at once: Font handling was isolated in a single-threaded binary – if we wanted to handle fonts in parallel, we could simply spawn more workers. And, being in a separate process, the media processing could now be sandboxed. As part of the multiprocess changes, Compose also switched from using GdkPixbuf to VIPS for image processing. The latter allows for much more fine-grained control over the image output and encoding, and comes with a lot of well-maintained filters and operations, which made it possible to eliminate a fair chunk of AppStream’s hand-rolled image processing operations. As part of this transition, we unfortunately lost the ability to read XPM images, which dropped about 20-30 applications from the pool at Debian. But in the name of security, this is a sensible choice, especially since most XPM icons were very small and low-resolution, and applications using them could benefit from adding a high-quality PNG icon anyway. With VIPS, we also now restrict the amount of image formats we can load to a sensible set, so extremely niche or unexpected formats will be outright rejected (this includes sane-but-unusual formats for screenshots and icons, such as TIFF images). The Compose library, with all of these changes, will now just request high-level operations (e.g. “render a font card for this font to a JXL image”) from the worker, and provide it with input data in sealed memfds and output locations as FDs as well. On Linux systems, the worker will use Landlock if available, to block all write access to the filesystem, deny device access and deny TCP and UDP as well. The sandbox can certainly be tightened a fair bit in future, but this was a good and safe start to gain some experience with it without having things break too easily, given the many places Compose is used in (also, Landlock’s API is surprisingly nice to use, so it was easier than I thought to add in this early version). With all of these changes, the libappstream-compose library is now also officially marked API-stable, so you should be able to rely on it in future to build new things (its API has barely changed in the past, and now with the new media API and defaults change in place, it was time to declare it stable). I want to see / try this! Currently, the easiest way to have a look at the new data is to check out Debian Unstable. If you have a JXL-enabled browser, you can also see the icons in AppStream Generator’s HTML pages for Debian Sid. If you are using appstream-generator for your distribution, you will also get much more pleasant statistics and HTML pages, as well as fully deterministic media output and a whole bunch of security updates, so, update to its recent 1.0 release. Please keep in mind that if you switch to JXL, the client tools receiving the image data have to support it. Support varies depending on the Linux distribution, so, test it first and switch the default back to PNG in case you encounter any issues. What’s next? With so many features and changes landed, the next changes in AppStream will focus on improving what already exists and fixing any issues (there will be more blogposts about the other features 1.2.x delivers!). Testing with the entire Debian archive as data source makes me fairly confident though that there will not be many problems. In the longer term, tightening the media processing sandbox will also be something we might want to do, e.g. by hiding parts of the filesystem tree or filtering syscalls. For JPEG-XL, one obvious question is “Will you add support for it to the Freedesktop icon-theme specification as supported format alongside PNG, SVG(Z), and XPM?”. For on-disk icon repositories, JXL’s space-savings are less compelling, and it being HDR-capable is also not necessarily a killer feature (PNG can go a long way!). However, JPEG-XL’s ability to immediately decode larger images at reduced resolution without resampling could legitimately be very powerful here, as applications could ship a single large image and quickly decode it at 1/2, 1/4 or 1/8 the size for different purposes in their UI. JPEG-XL also supports spot-color extra channels, which applications could use as masks to recolor raster icons at render time. This could be incredibly nice to color symbolic icons on-the-fly without any SVG and CSS. JXL also provides richer metadata, which might be neat for (license/author) documentation. So, the answer here is: Maybe it makes sense to allow another format, but this will have to be discussed first, as it would force JXL into every toolkit and desktop, which is a much bigger ask than supporting it only in AppStream. As always, let me know what you think and please report any issues or bugs directly against AppStream or AppStream Generator if you encounter problems that are with the tools, and not with a project’s metadata.

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.

We’re happy to announce the release of GIMP 3.2.6! This stable release contains several months worth of patches, bug fixes, security updates, and more from new and longtime contributors. Special thanks to Bruno Lopes, who has taken charge of backporting fixes from our development branch to the 3.2 stable branch. General Highlights and UX Improvements New Rotation Stylus Dynamics Input OS and Platform Specific Improvements New macOS Package Security updates For Plug-in/Script Authors and Builders GIMP SDK Around GIMP GIMP 3.2 Help Manual Updates Historical News GEGL and babl Release Stats Downloading GIMP 3.2.6 What’s Next This news posts provides an overview of the changes since GIMP 3.2.4. For a more detailed review, check out the NEWS changelog. “Don’t squash bugs… free them!”, by Aryeom, CC BY-SA 4.0 (a poetic approach to debugging), 2019 General Highlights and UX Improvements¶ A number of the fixes we first mentioned in our last development update were backported to GIMP 3.2.6. Cheesequake has added code so you can use Cut on a layer group. This will allow you to cut the same section of all layers in the group, provided they are rasterized and not locked. Jehan made further improvements to this code. The Sample Merged option for the Color Picker tool should now include any filters applied to a single layer when selecting colors. This was originally ignored due to an older optimization used for single layer images. Balooii made many improvements to boost performance when loading a large number of fonts. While some lag remains and will likely require us to update to GTK4, the initial GIMP start-up, typing in the text tool, and closing font lists should be much faster! Ondřej Míchal and Jehan have begun making changes to GIMP’s codebase to support an eventual GTK4 port. This includes swapping out the deprecated gtk_widget_show () functions with gtk_widget_set_visible (), replacing direct access to GdkEvent types with getter functions, replacing GDK_WA_CURSOR flags for explicit gdk_window_set_cursor () calls, and more. Even though we are not yet planning a GTK4 port, it doesn’t hurt to start preparing for it! New contributor Ryan McDonald and Idriss Fekir have fixed an issue where the end of a line might be hidden on the left/right side when the text layout is set to “fixed”. When loading older XCFs, the problem will still be visible, but any changes to the text layer will update it to the correct view. Kaushik B. has fixed an issue with the Heal Tool where you might get dark smudges if you move outside the bounds of a layer that’s smaller than the image canvas. New contributor Manu Cornet and Jehan fixed a crash that could happen in certain circumstances when pressing keys too quickly after releasing the spacebar when panning. Brandon Henderson reduced the sensitivity of the pan gestures when using the touchpad on macOS. This should make it easier to make fine-grain adjustments while editing an image on that platform! Richard Gitschlag has adjusted the Text Tool so that you can still select the text to edit even if it has a layer mask that partially covers it. Jacob Boerema resolved a bug in our metadata code that prevented GIMP from loading the Licensor metadata for an image. Alx Sa added a maximum width of tooltips, preventing options with long descriptions from filling the entire screen. Rodrigo Lledó Milanca updated our information on the ART Camera RAW plug-ins. Several bugs related to rasterized vector layers have been resolved. Thanks to BobsDaughter, teapot, and Richard Gitschlag for their testing and feedback! New Rotation Stylus Dynamics Input¶ Jehan recently implemented a new dynamic input for painting - Rotation (also known as Barrel Rotation). This feature is prominently used in the original Wacom Art Pen and newer Wacom Art Pen 2 pens, and allows GIMP to react to how you have rotated the brush in your hand as you draw. You can adjust this value for custom brushes in the Dynamics editor. The MyPaint Brush tool is integrated with this feature as well, so it will automatically pass the rotation on as you paint if your stylus supports it. OS and Platform Specific Improvements¶ GIMP uses GTK3, a cross-platform library for GUIs, to display its windows, widgets, and more. While it does a very good job of this, GIMP requires a lot of very complex interactions, and sometimes this can expose bugs that are only visible on certain platforms. Bruno Lopes has been hard at work making a staggering number of platform-specific improvements to make GIMP work better. These include (but are not limited to): Using “Server-side Decorations” for dialogs on KDE instead of GNOME-style “Client-side Decorations”. (In other words, the buttons appear at the bottom of the dialog instead of the header bar). Secondary “pop-up” windows such as the resource selection and metadata editor dialogs should now appear in front of the first dialogue on Windows and macOS. The System theme now uses your system’s defined accent colors on Windows and macOS. Many improvements to proper focus setting on Windows and macOS. Improvements to multi-window mode operations on Windows and macOS. More system theme leaks caught on KDE Breeze system themes. This should help with graphical glitches in the UI. We now depend on winflexbison on Windows for building the Image Map plugin. This fixes an issue where Windows users couldn’t reopen their image maps, even when created with GIMP. Send to Email now works on MS Windows too using MAPI (works with Thunderbird and Outlook Classic). Windows users can now use “Open With” on multiple files on start, without creating multiple instances of GIMP. This is consistent with how Linux and other platforms operate. Because these improvements are wide-ranging, it is possible that we missed some interactions during testing that could cause a regression. If you notice any problems in GIMP 3.2.6, please let us know! New macOS Package¶ Starting with GIMP 3.2.6, the .dmg package is now created at the same time as the Linux and Windows packages. This has not been possible for many years! We used to create binaries for macOS on a separate GitLab repository, which was mirrored to another repository on GitHub, which was connected to a proprietary CI service (CircleCI) which then was connected to a MacStadium runner. All of that with dozens and dozens of additional patches, scripts etc! As you can see, this was extremely complicated, but it was the only way to ship macOS binaries back then. Thanks to your donations, we were able to sponsor a MacBook Pro M5 for Bruno Lopes, who has been working since December 19, 2025 to fix that situation. As a result, GIMP can now be easily built on macOS with both MacPorts and Homebrew packages. The macOS version of GIMP is now much more integrated with system-specific features, similar to the Linux and Windows version. A few examples: Titlebars on macOS now follow the dark/light mode settings of the current theme. Scrollbars now follow the macOS preference for whether they should be always visible or not. The more standard ~/Library/Caches/ location is used for storing caches of GIMP resources, fixing a bug of brushes directory not being created on macOS. GIMP’s number input buttons now respond to Cmd on macOS, like they do to Ctrl on other platforms. Some standard Mac shortcuts like, Ctrl + F2, Cmd + Shift + //Cmd + Ctrl + Space and Cmd + ` work as well. Meta and Hyper modifiers now work. Incorrect offsets when drag-n-dropping colors and layers/channels/paths have been fixed. Filters now accept negative values regardless of your system language settings. Plug-ins are treated as children of the main GIMP application, so they do not appear in the dock anymore. GIMP custom cursors are now properly set for all tools (previously, they were being overwritten by the macOS arrow). “GIMP”, “Windows” and “Help” menus now match the standard macOS menus with proper localization. Dialogs that shouldn’t be minimized (such as the search actions dialog shown with /) no longer show a minimize button on macOS. Remote files can be opened thanks to using the native macOS API, since GIO does not support HTTPS on this platform. Dashboard Backtraces are now supported using libunwind from libSystem. In the process of implementing all these improvements, the separate macOS “developer package” was dropped. It was created due to the limitations of the previous macOS build infrastructure and became unnecessary now that it is way easier to build GIMP on macOS. Plug-in and script developers should use the new GIMP SDK instead, or build GIMP directly. Again, this is a brand new package. So, if you notice any problems in GIMP 3.2.6, please let us know! Security updates¶ GIMP has added support for importing many different file formats over the years. In recent years, security detection tools have improved and found more and more potential exploits in open source software. Jacob Boerema and Alx Sa have been busy testing and patching these. For reference, the following Common Vulnerabilities and Exposures (CVE) have been patched in this release: CVE-2026-18301, CVE-2026-18304, CVE-2026-18302, CVE-2026-18303, CVE-2026-18305, CVE-2026-18306, CVE-2026-18307, CVE-2026-18308, CVE-2026-18309, CVE-2026-62438, CVE-2026-62439, ZDI-CAN-29400, CVE-2026-59087, CVE-2026-59088, CVE-2026-59089, CVE-2026-66757, CVE-2026-59090, CVE-2026-59091, CVE-2026-66758, CVE-2026-66759, CVE-2026-78465, CVE-2026-78475, CVE-2026-79902, CVE-2026-80101, CVE-2026-82324, CVE-2026-82328, CVE-2026-82330, CVE-2026-82343 We want to thank Jace, Brent Hull, Tristan Madani, Florent Saudel, bb1abu, Yukihiro Nakamura, Securin Disclose, and Zero Day Initiative for their security reports and suggestions. We also want to thank Michael Catanzaro for his help in organzing these reports and requesting CVEs for them. For Plug-in/Script Authors and Builders¶ Our GdkPixbuf dependency minimum version has been updated to 2.32.0 due to an issue with Glycin printing a bunch of unnecessary messages on start-up related to a deprecated to-pixdata function. PDB commands now only show error/warning messages when run in interactive mode. For non-interactive modes, you won’t see anything printed in the console on PDB function failure. Instead, you can check the return values of the function and provide any messages you want to users. Jehan improved our method for checking if a plug-in has been updated since the last time you opened GIMP. Now we check creation time (ctime) instead of just modified time (mtime) since it might be always 0 on certain packages like flatpak. This should mean that changes you make during development are more likely to be loaded if you’re testing on flatpak. Kamil Burda fixed documentation for integer and double types in the Procedure Browser. Pranav P corrected a build issue that caused a freeze on s390x systems. GIMP SDK¶ You can now build C plug-ins and GEGL filters from all the official packages we distribute by using the gimptool commandline tool. That is because we now ship all required headers and libraries for compiling (in total, less than 20MB). Before now, this was possible only on flatpak and Snap. So, Bruno Lopes extended it to the AppImage, Windows and macOS packages. We call this new feature the “GIMP SDK”. Take a look at the build instructions if you are interested. Around GIMP¶ GIMP 3.2 Help Manual Updates¶ Jacob Boerema, maintainer of the GIMP help manual repo, has released an updated version that contains all the changes brought in GIMP 3.2. It is available online, or you can download it if you want to keep a local copy. Historical News¶ Balooii has been working to restored older news posts that have been lost to the ages. You can now see almost all news posts from 2004 to 2008 on the main site now - just navigate back to that point in time in the archive. GEGL and babl¶ GIMP 3.2.6 also shares a release with new versions of GEGL and babl by maintainer Øyvind Kolås! babl 0.1.128 includes several fixes for building on macOS, initial WebAssembly support, and better checks at runtime for avx512 - all by Bruno Lopes. GEGL 0.4.72 updates its OpenCL support to version 3.0. Ondřej Míchal worked on important stability fixes for the OpenCL code (though such code path is still disabled by default in GIMP). Jacob Boerema made several fixes to the RGBE file format import and export functions. Aruius made the GeglColor comparison functions public, for future use in better comparing comparing colors in GIMP and other software. Tal Regev added support for building GEGL using only MSVC, and Bruno Lopes added support for WebAssembly as well. Luigino Camastra added more security checks to prevent potential overflows. More details can be found in the GEGL NEWS document! Release Stats¶ Since GIMP 3.2.4, in the main GIMP repository: 179 reports were closed as FIXED. 104 merge requests were merged. 871 commits were pushed. 21 translations were updated: Belarusian, Brazilian Portuguese, Chinese (China), Dutch, Georgian, German, Hebrew, Hungarian, Kazakh, Lithuanian, Norwegian Bokmål, Norwegian Nynorsk, Slovenian, Swedish, Serbian, Slovak, Spanish, Thai, Turkish, Ukrainian, Vietnamese. 58 people contributed changes or fixes to GIMP 3.2.6 codebase (order is determined by number of commits; some people are in several groups): 22 developers to core code: Bruno Lopes, Alx Sa, Jehan, Ondřej Míchal, balooii balooii, Richard Gitschlag, Michael Natterer, programmer-ceds, Ahmed E. Yassin, Andreas Vukman, Estecka, Idriss Fekir, Jacob Boerema, Manu Cornet, Petr Vorel, Ryan McDonald, balooii, cheesequake, kaushik_B, screem02, v4vansh, woot000. 14 developers to plug-ins or modules: Alx Sa, Bruno Lopes, Ondřej Míchal, Jacob Boerema, Jehan, Dimitriy Ryazantcev, lloyd konneker, balooii balooii, Frank Teklote, Harsh Verma, Michal Vašut, Mike Gorse, Richard Allen, Rodhos. 23 translators: Dick Groskamp, luming zh, Martin, Yuri Chornoivan, Ekaterine Papava, Rodrigo Lledó, Aefgh Threenine, Anders Jonsson, Kolbjørn Stuestøl, Baurzhan Muftakhidinov, Emin Tufan Çetin, Aurimas Aurimas Černius, Jose Riha, Марко Костић, Rafael Coelho Costa, Trần Ngọc Quân, Vasil Pupkin, Balázs Úr, Carsten Drewes, Juliano de Souza Camargo, Kjartan Maraas, Sabri Ünal, Yaron Shahrabani. 3 theme designers: Bruno Lopes, Alx Sa, Ondřej Míchal. 9 build, packaging or CI contributors: Bruno Lopes, Jehan, Jacob Boerema, Petr Vorel, Harsh Verma, Lukas Oberhuber, Ondřej Míchal, balooii balooii, lloyd konneker. 3 contributors on other types of resources: Jehan, Bruno Lopes, Aryeom. The gimp-data submodule had 16 commits by 7 contributors: Bruno Lopes, Jehan, Alx Sa, Anders Jonsson, Denis Rangelov, Lukas Oberhuber, balooii balooii. 4 image creators: Bruno Lopes, Jehan, Anders Jonsson, Lukas Oberhuber. 1 icon designers: Denis Rangelov. 1 cursor designers: balooii balooii. Contributions on other repositories in the GIMPverse (order is determined by number of commits): Our UX tracker had 3 reports closed as FIXED. babl 0.1.128 is made of 70 commits by 3 contributors: Bruno Lopes, Øyvind Kolås, Jehan. GEGL 0.4.72 is made of 234 commits by 28 contributors: Bruno Lopes, Ondřej Míchal, Øyvind Kolås, luming zh, Jacob Boerema, Jehan, Kolbjørn Stuestøl, Tal Regev, WarisMaqbool, Aefgh Threenine, Anders Jonsson, Martin, Yuri Chornoivan, Baurzhan Muftakhidinov, Dick Groskamp, Ekaterine Papava, Sabri Ünal, aruius, Alan Mortensen, Asier Saratsua Garmendia, Chao-Hsiung Liao, DiGro, Marco Ciampa, Rodrigo Lledó, Saikeo Kavhanxay, Thomas Manni, YOSHIDA Shigeto, Марко Костић. ctx had 150 commits since 3.2.4 release by 3 contributors: Øyvind Kolås, Bruno Lopes, Tal Regev. The gimp-test-images (unit testing repository) repository had 5 commits by 1 contributors: Jacob Boerema. The flatpak release had 35 commits by 3 contributors: Bruno Lopes, Erick555, Jehan. Our main website (what you are reading right now) had 182 commits by 7 contributors: Bruno Lopes, Jehan, Alx Sa, balooii balooii, balooii, Liam Quin, Allan Day. Our developer website had 110 commits by 5 contributors: Bruno Lopes, Jehan, Alx Sa, aruius, Ondřej Míchal. Our 3.0 documentation had 276 commits by 20 contributors: Jacob Boerema, Dick Groskamp, DiGro, Kolbjørn Stuestøl, Marco Ciampa, Anders Jonsson, Yuri Chornoivan, Марко Костић, Richard Gitschlag, Alx Sa, Baurzhan Muftakhidinov, Christian Kirbach, Mateusz Jastrząb, YOSHIDA Shigeto, Andre Klapper, Balázs Úr, Chas Belov, Kristjan ESPERANTO, Rodrigo Lledó, Víttor Paulo Vieira da Costa. Let’s not forget to thank all the people who help us triaging in Gitlab, report bugs and discuss possible improvements with us. Our community is deeply thankful as well to the internet warriors who manage our various discussion channels or social network accounts such as Ville Pätsi, Liam Quin, Michael Schumacher and Sevenix! *Note: considering the number of parts in GIMP and around, and how we get statistics through git scripting, errors may slip inside these stats. Feel free to tell us if we missed or m Downloading GIMP 3.2.6¶ You will find all our official builds on GIMP official website (gimp.org): Linux AppImages for x86 and ARM (64-bit) Linux Flatpaks for x86 and ARM (64-bit) Linux Snaps for x86 and ARM (64-bit) Universal Windows installer for x86 and ARM (64-bit) Microsoft Store for x86 and ARM (64-bit) macOS DMG packages for Intel/x86 and Apple/ARM hardware (64-bit) Other packages made by third-parties are obviously expected to follow (Linux or *BSD distributions’ packages, etc). What’s Next¶ Work these days has mainly and already shifted to the development series which will eventually lead to GIMP 3.4 versions. For anyone who missed it, the Development Update, August 2026 news is interesting on this aspect. In the meantime, we will obviously still continue backporting bug fixes on the 3.2 series, of which GIMP 3.2.6 is a part of. This new version should widely improve stability, and in particular it looks like macOS users should particularly appreciate it (thank Bruno for that)! We are also extremely thankful to the new skilled contributors the project has been getting. Don’t forget that, as long as you don’t use genAI in your toolset, everyone is very welcome to participate! 🤗 Don’t forget you can donate and personally fund GIMP developers, as a way to give back and accelerate the development of GIMP. Community commitment helps the project to grow stronger!

Fitful sleeping action on the plane, found our luggage, had a good experience with the parking-elsewhere service. Drove home via some breakfast at a Greggs. Lunch, packed, turned around to travel to Italy for LibOCon. Plugged away at slides left and right, code analysis, and more. Arrived rather late, caught up with some folk, worked until much too late at night on slides.

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 Interface1 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 here2, but trying to load the native driver will generate an error and the internet will tell you that PC firmware developers are incompetent3 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. The ACPI spec used to live at acpi.info, but sadly that seems to have vanished some time after UEFI took over stewardship of the spec ↩︎ You might argue that the firmware should simply not do anything at runtime because it is not the firmware’s job to do that, and I do understand that and you can certainly boot with acpi=off if you want to and no ACPI code will be executed at runtime. Let me know how that goes. ↩︎ I’m not going to present an opinion on that here, merely say that this provides no supporting evidence for that assertion ↩︎

Up early, call with Naomi, then Damien. Showered, packed, lunch with Thomas, bid a very fond farewell to the excellent American Meeks' hospitality. Drove into Boston, visited the Library, admired the Singer Sergant murals, and other bits. Checked out some rattan Elephants, ice-cream at "JP Licks", babes did some sketching in the park. Off the the airport, struggled to return the car at the check-in desk. Then discovered UK Air traffic mahyem had stopped our plane outbound, we'd been bumped by a day - hmm, how do I get to LibOCon. Said I wanted a refund, and would book a new flight to make the connection - and BA re-booked us all onto an equivalent AA flight - wow! nice work BA.

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. Select the Launch tab to launch a new debugger instance. Select GJS as the debugger. Type calc.js as the program to debug. Disable "Stop On Entry" so that the debugger doesn't stop at the first line of the script. 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. Bring the VS Code extension to feature parity as the Zed extension (see above). Add support for debugging GJS applications in GNOME Builder: Currently blocked by GNOME Builder itself lacking DAP support Add support for evaluating expressions in the debugger when paused. Correctly stop/kill the script when the debug session ends. Enabling source map support, which will make debugging compiled GJS (and TypeScript!) applications (like GNOME Weather, GNOME Sound Recorder) easier. Testing and ensuring the debugger works well on macOS and Windows (I only tested on Linux). Redirect console.log and other output to the debug console. Allow attaching to already running GJS applications (potentially by implementing a SIGUSR1 handler and communicating via unix socket). Allow pausing the program that's being debugged (at any point). Implement setting or modifying variables in the debugger. Give information about the current exception when we hit an exception breakpoint (needs the VS Code extension). Maybe implement watching source code and live-reload of the code while debugging. Implement more DAP capabilities (e.g. function breakpoints, conditional breakpoints) to improve the debugging experience even more (including correct presentationHint) Show the scopes in a better way (e.g. merge the global and GjsGlobal scopes, potentially merge the class body scopes, etc...) Maybe support debugging the GNOME Shell?? Maybe implement GJS debugging (and provide instructions) for other DAP clients like Emacs, Vim, etc. (see full list of tools implementing DAP here) 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. 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

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!

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

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!

Google Summer of Code 2026 has come to a close, so here’s where things stand with GPU reset recovery in Mutter. If you’re catching up, the short version is in my intro post: a GPU reset invalidates the EGL context and wipes all GPU memory, and until now Mutter had no way to come back from that. My project is a recovery mechanism so a reset doesn’t take the whole session down. Here is what things look like now: Mutter graphics recovery demo In the video: After a period of normal operation, a reset is triggered. Mutter recovers successfully and is back to normal operation instantly. Everything is restored, from the background to windows and cursors. Then a loop is executed to trigger a reset every second while various activities are performed within the session. Through it all, Mutter remains unfazed and the session responsive. 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: Graphics recovery signals Anything in the compositor that owns GPU-associated state now hooks into one of these instead of guessing at ordering. Only recreate-context can actually fail; if it does, recovery aborts there and recovery-failed is emitted instead of continuing on to recreate graphics resources. What Else Recovers Now Framebuffer and background: The display now comes back on its own, no manual nudge required, and the pause is virtually unnoticeable. There is no blackout, at least from the compositor’s point of view. To the user, however, monitors driven by a GPU that resets may briefly go dark. The desktop background restores correctly and immediately: when a background image is set, loading it from disk can take a moment, so a plain colour is shown in the meantime. One caveat worth flagging for anyone testing this: background image loading was recently moved out of Mutter in !4980. That means reloading the image and reuploading its texture after a reset is no longer something Mutter can do on its own; it now falls on downstream consumers (like Shell) to handle it. Window and surface content: Wayland surfaces restore to their last rendered frame right after recovery, instead of going blank until the next commit. When a client commits a new buffer in the narrow window between when a reset occurs and when it finishes, and the buffer attach fails because the context is already lost, the surface gets a dummy texture so nothing crashes, and the real content replaces it when we re-attach the buffer during restoration. Cursors: Both Xcursor-based cursors and Wayland client cursors restore their textures on reset. Actor effects: All ClutterOffscreenEffects (blur, desaturate, deform, shader, etc) recreate their GPU-side pipelines and textures on reset instead of quietly holding onto invalid ones. Stream sources: Screencast and remote-desktop pipewire streams stop and restart cleanly around a reset, recreating the necessary GPU-side resources instead of ending up in a broken state. Overlays: MetaOverlays (used for things like cursor sprite compositing) recreate their pipeline and texture too. Along the way, a decent amount of the codebase moved from static and class-level CoglPipelines to named pipelines owned by the CoglContext, specifically so they’d get recreated automatically instead of leaking or going stale across a reset. Tales From The War Front The context that died too soon and then never died Historically, objects didn’t take references to CoglContext; they simply held bare pointers to it. The reason was that there was only a single context for an entire session, which got destroyed at exit after all the objects associated with it had been destroyed. Since the context is now recreated during recovery, this introduced a whole new problem: some objects now outlived their associated CoglContext, resulting in use-after-frees and segfaults. Specifically, some objects can not be destroyed until they’re replaced by new ones (after we have recreated the context) because they hold on to crucial states which get destroyed by lower levels of the stack as soon as they become inactive. There’s also the case of garbage collection, e.g in Shell, where the garbage collector may keep objects alive after we’ve destroyed their associated context. To solve this, every object holding a pointer to CoglContext now takes a reference, and the context is explicitly disposed of and marked as defunct during recovery. The use of a defunct context is restricted so associated objects don’t make use of invalid data and silently corrupt memory. The context is finalized when the last reference to it is dropped. Also, with this change, we can more easily spot objects that needed to be restored after a reset. With this in place, defunct CoglContext objects were, for a while, never finalized after a recovery cycle; they’d plateau at a fixed refcount and stick around. Tracking it down took multiple long GDB sessions. The actual root cause, once Jonas helped dig further, turned out to be leaked CoglPipelines and pipeline cache entries. The stencil and current pipelines weren’t being unrefed by the context, which in turn kept the default pipeline (their parent) alive too. There was also a cyclic dependency in CoglPipelineCache that only surfaced as a use-after-free once those pipelines were finally unrefed. Two separate bugs stacked on top of each other, and the second one was hidden by the first. The popup that broke hell loose During recovery, the whole actor tree is unrealized and re-realized, which started by unmapping everything from the stage down. With a popup open when reset occurs, this crashed at an internal invariant check. A thousand steps (in GDB) later… It turned out a ClutterInputOnlyActor, owned by the popup’s ClutterGrab, was getting destroyed mid-unmap. A grab doesn’t hold its own reference to an actor it owns. So when the actor got unmapped, the grab was detached, which in turn disposed of the actor, removing it from the tree. So, the unmap loop lost track of the next sibling and left the rest of the tree mapped. The apparent fix was to have ClutterGrab take a proper reference to the actor it owns and pre-fetch the next sibling before unmapping so the loop doesn’t depend on an actor that might disappear underneath it. It worked, in the sense that the crash went away, but it turned out that removing a grab actor during recovery broke other things further down the line in ways that were harder to pin down. The real problem wasn’t how the unmap loop handled a disappearing actor; it was unmapping the actor tree at all as part of recovery. The actual fix was to stop unmapping the stage during recovery entirely. Two new private methods, _clutter_actor_realize_mapped() and _clutter_actor_unrealize_mapped(), unrealize and realize the actor tree recursively while leaving everything mapped, with a flag on ClutterActorPrivate carving out an explicit exception to the established unmap-before-unrealize / realize-before-map invariant. Recovery now uses these directly without unmapping and mapping the stage, so the popup, its grab actor, and everything else stay exactly where they were. The time-travelling touch For a while, single resets were sometimes turning into two or three in a row, with no clear pattern. The reset trigger mechanism (used for testing without messing with real hardware) works by touching a file that llvmpipe watches for a changed mtime. That file lived in a virtiofs-mounted directory shared between my main machine and the test VM, and the mtime it ended up with was consistently a bit ahead of the VM’s and even my main machine’s clock at the time of touching the file, sometimes enough that by the time one recovery finished, the file still looked “new” and triggered another reset. Not a bug in the recovery logic at all or the manual reset implementation, just a quirk of the shared filesystem layer. Moving the trigger file to the VM’s own local filesystem made it go away. Here’s a sample from one of my debug sessions (timestamps are the giveaway): $ date -Ins && touch ~/llvmpipe_reset && date -Ins 2026-07-31T15:53:34,157134442+01:00 2026-07-31T15:53:34,160985080+01:00 $ stat ~/llvmpipe_reset ... Modify: 2026-07-31 15:53:34.255579148 +0100 ... 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: GNOME Shell UI recovery stateNote: This was recorded with a modified branch; with the unmodified branch (at the time of this writing), Shell currently crashes, as expected. The llvmpipe reset simulation is not yet wired into tests or CI. Real hardware testing is still an open problem, for the reasons stated above. I’ll keep working on these after GSoC. What’s Next Chase down the remaining edge cases Get GNOME Shell recovering reliably; a few known to-do items include: Clear the background cache and reload the image (will restore the desktop background) Clear the texture cache (should restore icons) Clear the theme node cache (should restore widgets and effects) Add test coverage using the llvmpipe reset simulation, and get it into CI Find a real hardware reset setup that actually exercises context invalidation Push the MR through upstream review Reflection (A Personal Note) I still remember opening gsoc.gnome.org on that fateful day “just to see what GNOME’s doing this year” and scrolling down just to see this project, and I was immediately drawn to it. I had known graphics was the path I wanted to take, and this project checked so many boxes. At the same time, I couldn’t deny how daunting it seemed. Yes, I have done some graphics work in the past (my GSoC project last year, in Uni and personally), but nothing of this scale. Anyway, I decided to take up the challenge; after all, why do it if it isn’t challenging? Here are two notable challenges I faced, from which I also learned a lot: The sheer mass of the codebase: Man, Mutter is huge !! Coupled with the fact that my project cut across every layer and almost every aspect of it. I wasn’t building a compositor, but I had to understand how a lot of it worked. This wasn’t the kind of project that dealt with a single subsystem. Debugging, debugging and debugging: Logs are good and have their place, but also their limits. This project required using the debugger a lot. I’ve become so much more comfortable with sifting through logs and stack frames, and stepping through thousands of lines of code. And here are three notable lessons I learned (more of): There’s always a simpler solution to any problem (thanks, Jonas). Keep digging, never give up: Some of the “bugs” I encountered just kept on giving. Some were like playing whack-a-mole, others like the hydra. Life is all about resilience. Community matters more: It’s good to get the job done, but the people we meet along the way are more important. Throughout the course of this project, I got to do things I never imagined I would (at least, not this soon), like chatting on a kernel dev IRC . I could go on forever, but let’s call it a wrap here for now. Thanks A huge thank you to my mentors, Jonas Ådahl, Robert Mader, and Carlos Garnacho, for believing in me and for the guidance and hands-on help throughout. Thanks to Google and the GNOME Foundation for this awesome opportunity. Finally, thanks to the entire GNOME community and everyone who followed along this summer, asked questions, or gave feedback. GSoC has ended, but this isn’t done yet, and neither am I – more soon!

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.

In Some Changes to GNOME Security Tracking, I reported: I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done. This is because I was planning to leave my job at Red Hat on December 31 due to some internal Red Hat policy changes. But this timeline has now unexpectedly moved forward two months, to October 30. Accordingly, I will now discontinue tracking newly-reported security issues on October 1, 2026. During October, I will focus only on tracking issues reported prior to October 1. By November 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

If your agentic workload involves the agent being able to run arbitrary code (like bash or equivalent), then you should not use a “LLM as part of your app” framework like LangChain, BeeAI, OGX etc. Instead, run OpenCode, goose, or another general coding agent inside a sandbox such as OpenShell. Sandboxing limits what the agent can access directly. For privileged effects, it is best augmented with a pattern like safe outputs: the agent emits a structured, unprivileged request that separately trusted code validates and applies. A compact decision tree Can it run bash or arbitrary code? ├─ Yes → Run a generic agent in a sandbox └─ No → Are you *really* sure *all* of your tool calls (MCP or builtin) don't accidentally expose "execute arbitrary code"? ├─ Yes → OK, maybe LangChain or equivalent makes sense └─ No → Goto start I also think the builtin sandboxing in most agent tools (like Claude Code and Gemini CLI) is a bad idea, and it’s better to just ensure the entire thing is sandboxed. Related to all of this, a key thing anyone making an “agent” needs to ask is “how is this different from just writing an agent skill”. From my previous post you’ll know that I think GitHub Agentic Workflows is a good reference baseline for applying agentic AI (background/task oriented) safely and effectively. And there an “agent” is almost exactly just an agent skill, but with a bit of YAML defining its integration with the outer system. Why should it be harder than that? I just don’t see it making sense for custom agents written in frameworks like LangChain to proliferate in most use cases. Sure you can use LLMs to generate it, but it’s even more secure and understandable to not have that code at all. Even for the use case of an interactive chat bot, do you really need a custom app versus just MCP tools for an already generic frontend? I doubt it. I don’t think it makes sense for most organizations to have proliferation of custom bespoke agents like these LangChain-style frameworks encourage. Skills and sandboxed generic agents are just easier to understand and work with.

Hello! I'm Angelo Verlain, a Software Engineering student, and I've been working for the last 3 months easing the debugging process of GJS apps by adding Debug Adapter Protocol (DAP) support to GJS as part of Google Summer of Code (GSoC 2026). A debugger is software for executing a computer program in an environment that allows for programming-level inspection and control. A debugger is often used to debug, but can be used for other goals including testing. Common features of a debugger include stepping through code line-by-line, breaking into the program's flow of control, managing breakpoints, and reporting and modifying memory. ¹ What is GJS? GJS or GNOME JavaScript is a JavaScript interpreter that allows developers to write code that can leverage GLib/GObject and various other libraries that work with GObject Introspection like GTK, Libsoup, etc... In practice, GJS allows you to write GNOME/GTK Applications and GNOME Components in JavaScript. The GNOME Shell & Extensions, GNOME Weather, GNOME Audio Player, GNOME Maps, Workbench are all examples of projects powered by GJS. What is DAP? The Debug Adapter Protocol is a a specification that describes how messages are passed between a debugger client (for example, your IDE) and server (such as the Node.js or any other language runtime). It specifies and communicates pausing & continuing execution, setting breakpoints, stepping through the code, viewing stack traces, and more. It works by defining a standard way for your development tool (e.g. GNOME Builder, VS Code, Zed, etc...) to connect to a debugger. Today, you can already debug applications and libraries written for/with Android, Node.js, Deno, C, C++, Rust, Python and more. This project aims to make GJS applications debuggable in your favourite editor or debugger by implementing a DAP adapter for GJS. Adding DAP to GJS GJS already supports debugging programs by use of the --debugger flag, which spins up a GDB-style CLI interface where you invoke it by running gjs --debugger [file-name].js and writing commands like breakpoint [line], step, frame to set breakpoints, step through the code and print the stack frame respectively. It works well, but it's different from the GUI debugging that’s more popular these days. Here's an example of GJS debugging the following code saved as test2.js function print(i) { console.log(i); } for (let i = 0; i < 10; i++) { print(i); } If GJS had support for DAP, you wouldn’t be limited to just using the text mode debugger, but could debug applications using your favourite editor (Zed, VS Code, etc…) The workflow would be easier too: Press F5 to debug (standard hotkey), specify the path to your entrypoint, and then run the program. To set a breakpoint, simply type the debugger keyword or click in the gutter/margin of your editor (even after your program has started execution!). When the program reaches that breakpoint, you will have a nice stack trace showing where the program stopped, and give you options to inspect the current variables in the different scopes, continue execution, or step next, in our out of frames. Here's an example of debugging the same script using VS Code's Node.js adapter (the experience we want): Note that you can more clearly see the variables, call stack and breakpoints in the debugger. Scope My work is focused on launching & debugging GJS apps. The scope is also limited to launching & debugging GJS applications or running scripts in the GJS interpreter and debugging them. Attaching to already running applications is not in scope. Concretely this also means that debugging components like the GNOME Shell is not in scope. Furthermore, I have only written an extension for Zed since it’s the editor I use, but other editor extensions like VS Code, Builder, and Emacs could be implemented as a follow-up task and will be relatively easy since GJS itself implements the DAP specification and we just need to bridge the two. If you want support for a specific editor or debugger, please let me know :). Progress I've made significant progress on the project. The project period is coming to a close and I’ve made significant progress. Currently, the following is implement: A work-in-progress GJS DAP Extension is implemented, which allows you to debug GJS applications inside the Zed Editor. It's not yet published to the Zed Extension Store though You are able to launch a GJS program or run a file and break on entry Automatically pausing on debugger statements Ability to add breakpoints by clicking in the gutter/margin of the code editor (even while the app is running!) When execution pauses, you are able to resume execution to the next statement, or step in/out of functions/methods/scopes. When execution pauses, you can see all the stack frames When execution is paused, you can also inspect the different scopes and the variables defined in all of the scopes My next steps will focus on the following: Implement a VS Code Extension so you can also debug GJS applications in VS Code in addition to Zed Allow configuring breaking on Caught and Uncaught exceptions Figure: Debugging a program with a visual debugger (Zed), showing breakpoints (red circle in the gutter), current line highlighted and variables I’m looking forward to sharing my progress when we get to the end of the program! Expect another blog post in the next couple of weeks.

  Almost two months ago I went to my first GUADEC conference. While I’ve been busy since then, writing proper travel report has been something I’ve been putting off for a while. Without much further ado, here’s a report of my impressions Tower of Hercules in A Coruña First impressions It’s always a bit nervous to go visit a conference for the first time. While I’ve been at many conferences where I’ve given talks on international stages before, GUADEC has felt different to me. Mostly because there’s so many people I’ve known from online interactions, yet nobody that I have ever met in real-life. While it’s usually a pretty obvious conclusion that people that are nice online are so in real life as well, there’s always that voice inside that fears feeling as a complete outsider. While I’m not new to FOSS, having used Linux since 2006, and publishing applications within the GNOME-ecosystem since 2022. I am still a relative newcomer when it comes to engaging a bit more active and vocally. Fortunately, I found directly that people were really nice. And actively tried to engage me in discussions as well. Many gnomies recognized me, and approached me first. Which nice feeling welcomed into an established community, and definitely makes it easier to engage on other fronts as well. On the way to lunch Talks There’s been a lot of interesting talks and workshops that stuck with me. I’ll just do the egomaniacal thing and talk about my own talk first: A Brief History of Graphs. The reason I’m putting it on top is not that it’s the best one, but it was obviously a highlight to be able to present my journey within this project to the rest of the GNOME community. The talk is about how I started developing applications, and the lessons learned along the way through community feedback and GNOME Circle. A large part of the main focus ended up being pretty design-focused. But that’s also where much of the lessons are to be learned. You cannot create a great app without putting design first, before the technology. And by that I mean design in a big way. Not how it looks, but think about what it should do before even considering what it could potentially do given the technology at hand. Designing from a technology-first mindset leads to a worse experience for all. It’s food for another blog, but I don’t think it’s a coincidence that every project that explicitly claims to put technology over people¹ kinda sucks. My talk during the second day Either way, it’s been my entry point into GNOME, and has given me a lot of fulfillment over the years. I encourage everyone to start to contribute and engage. It’s gotten much more difficult over the years thanks to shortcuts in the form of text-prediction machines, but there’s really a lot of value of getting it wrong and learning along the way.  It wouldn’t be there without the human interactions behind that journey. Enough babbling about my own talk, here’s just a list of talks that I found particularly interesting: Towards a Local-First Desktop – by Julian Sparber and Tobias Bernard. This in particular is a very important topic to me. I don’t want to sound like an alarmist, but we need to prepare for a future where we may not always have access to a large centralized internet. Not only has this been proven by recent geopolitical circumstances, it’s not like we’re making any progress in avoiding a major climate catastrophe. Local-first technology allows us to remain resilient, even when our centralized infrastructure is under pressure, be it due to geopolitical pressure or by force of nature. Very interesting talk about a very cool technology. The related local-first workshop in particular has been really cool as well. We hacked together a quick implementation of local file transfer within a few hours. Julian showed us how easy it is to get local sync to work with p2panda. I will definitely hack further on this in the future when I have more time on my hands. In the end we managed to send information between devices in a simple Python program. Session Save/Restore – By Adrian Vovk. I never really realized the potential of this feature, Adrian makes a really good case of showing what this feature would provide. But most interesting to me was how complex things are. Once the first prove of concepts were shared a while ago, you’d might make the mistake of thinking it’s just some formal implementation, but there’s a lot of moving parts, and the talk really provides a get a good sense of why these implementations take as long to develop. Fantastic work by Adrian. Performance profiling Mutter, GNOME Shell & apps with Tracy – by Ivan Molodetskikh (YaLTeR). I don’t do Mutter or Shell development, nor have I really used profilers in the past. But Ivan really shows how powerful profilers (Tracy in particular here) can be. I’m highlighting this talk in particular because it inspired me to do some profiling in Graphs (with plain cprofile), nothing as fancy, but we’ve had some significant performance upgrades since then! GNOME Internationalization: accessibility for all over the world – Very nice talk by Guillaume Bernard about internationalization. This one has mostly stuck to me because he has some very clear examples how difficult translations can be. While some things might be obvious, such as the order of words being different, but there’s a lot more subtleties than expected such as counting and pluralization being different as well. He makes a really good case about why it’s important as app developers to use proper practice such as not breaking up sentences, using gender-neutral language, and using the correct categorization and calls to gettext. Beyond #RRGGBB: cross-application color palettes the slightly hard way – By Nathan Willis. While color pallets are maybe not the sexiest topic for everybody, I find it super-interesting to listen how such settings are a bit of an unstandardized clusterfuck where pallets are all stored differently with different names, formats and locations. While I don’t have the impression that this is better in the closed source world, it is less than ideal in creative work when working with multiple applications. Very entertaining talk to listen to. Lightning Talk: GNOME Shell Design Dreams – Obviously the Design dreams talk had to be included. It’s just very cool to see the thoughts and plans on the future of Shell. It’s no wonder this talk did numbers online as well. I’m in particular looking forward to improved search, and improved quick settings. Traveling to and in A Coruña Getting to A Coruña was not ideal, but not terrible either. Unfortunately travelling by train was not very viable for us from Sweden, but we are lucky enough to have an international airport in Linköping with direct flights to Amsterdam. From there, it’s single flight to Madrid, and then another one to A Coruña. All by all, we woke up at 04:00, and arrived somewhere around dinnertime. Traveling to and from the venue worked relatively well. There’s a local app for public transport, where you can bus-rides for dirt-cheap. Buses went often. Walking around within the city was less practical. I realize I’m probably a bit spoiled from my own hometown. But to me A Coruña felt very car-centric with very trafficked roads going everywhere, and only a minority percentage of the public spaces being dedicated to pedestrians. This is not a city where I would dare to take a bicycle, which I was considering at first as an alternative to the bus. Where I’d have to add that I’m saying this having grown up in the Netherlands, where bicycles often are prioritized over both pedestrians and cars. In fact, it’s the only country in the world with more bicycles than people. The beach was very nice. Being situated at the Atlantic, A Coruña has a wonderfully mild climate compared to most of the European South. Living in the North, temperature is always a bit of a concern when traveling to Southern Europe during the summer, especially nowadays. Temperatures in general were around a comfortable 25°C. We had some warmer days were the temperature passed 30°C, but given we were in a European heatwave where Madrid was close to 40°C, I cannot complain. The Venue The venue was hosted at the Informatics Faculty of the University in Coruña. It was easy to find the entrance from the bus, and it offered a nice public space for the coffee breaks and general mingling. The main stage was large and comfortable. The second stage, where I had my own talk was hosted in a regular classroom on the top floor. Whilst it’d have been nice to have the stages somewhat closer, the path to the second stage was labeled very clearly, and we were never over capacity in any of the stages. Another really nice thing is that there were many possibilities to charge electronic devices. On my own laptop, which doesn’t last for much more than a few hours, this has been very useful. Especially during the local-first workshop. The conference itself went smooth with no major delays or unexpected outages. Shoutout to the organizers for making this a success! One area that I would have liked to see some improvement was the availability of plant-based options. In particular during the first day, there were no non-meat options on the menu, and the restaurant staff did not seem prepared for multiple people wanting to have a vegetarian alternative. This also is related to the fact that vegan options in general seem very niche in Spain (or at least this city), but for an international conference the restaurant staff should probably have been a bit more prepared for such dietary requirements. My initial ambition was to keep myself to completely plant-based options during the trip, but quickly gave up on that when arriving to A Coruña. I found the official* GNOME-branded ice-cream. (*Not official) Special Thanks I really want to give a special thanks to the GNOME Foundation. Partly to all the people who made this possible by organizing this. The local team in A Coruna, the volunteers, and anyone else that took part in organizing this. Also thanks to the people making nicer pictures than me, this includes the staff that has been hired for this. All images apart from the top one with the tower, and me holding an ice cream have been stolen from the GNOME Cloud. The conference overall has been a real nice experience, and it really gives energy to do more. There’s been some areas where I’m getting a bit more further involved in the meantime as well. Also, I should really thank the GNOME Foundation for sponsoring my travel. It’s been a very expensive trip from Sweden, even when going alone, and I couldn’t have taken those expenses without getting reimbursed for part of the trip. It is really appreciated, and these programs really help for new people to get involved! Sponsored by the GNOME Foundation 1 – To be fair, these projects claim to put technology over politics, not over people. It should be noted that they never mean marginal tax rates, it’s always about policies like the CoC and the right to kick down at disenfranchised minorities such as trans people. Ergo, putting technology over politics in this context is by definition putting technology over people. Unless you don’t count minorities as people. With some of these folks, you never know.

I’m on a VPN setup with several friends that, obviously, includes a VoIP network. I also have an old magicJack adapter and a deep and abiding need to use hardware in ways I should not. There was obvious synergy here. Plugging in the magicJack gives a USB vendor id of 0x06e6, which belonged to a company called TigerJet who made a range of chips for hooking up phones to computers, either via USB or PCI. Some more digging suggested that it was a 580 part, and someone had conveniently uploaded some reference code and datasheets, so figuring out how to talk to the chip wasn’t terribly difficult. Once configured it simply sends HID events whenever a user hits a phone key or changes the hook state, and otherwise exposes a USB audio device that can be spoken to using the stock kernel driver. It also has the ability to generate dial tone and assert ring signal, giving a full traditional phone experience. So you’d think this would be a super easy project, but I’d made things harder for myself by deciding I wanted to tie directly into Asterisk rather than just smashing an existing SIP stack onto the device. Asterisk uses channels to talk to devices, and channels end up as compiled C code that Asterisk can load dynamically. I didn’t want to have to deal with the pain of compiling stuff and matching ABIs and everything so writing a new channel from scratch was unappealing. Fortunately, the websocket channel is available in recent versions of Asterisk and provides a convenient way to get audio in and out, but that still leaves the job of handling incoming and outgoing calls. That’s handled with the Asterisk Rest Interface, which can initiate a call or respond to an incoming one and bridge various channels together to produce a bidirectional audio stream. There’s a convenient async Python library that handles the low level protocol. Code for all this is here1, and works for my use case, but I should really abstract out the asterisk side and the magicJack side to make it easier to adapt to other devices. That’s a job for later, though. For now, you get this: Your browser doesn't support HTML5 video. Here is a link to the video instead. This has also been an excuse for me to figure out how to make Tangled work, which I’ll write about at some later point. But self-hosted git repo with a convenient collaboration plane! ↩︎

In 2025 I was honored to be selected for the first cohort of Sovereign Tech Fellows, a program by Germany’s Sovereign Tech Agency to improve the resilience of the open source ecosystem by supporting maintainers directly (complementing their existing support for larger FOSS organizations). Back in 2025, I was only working very limited hours – however, this has changed in 2026. For the second half of 2026, I am working again as a Sovereign Tech Fellow, but this time with significantly increased hours. After finishing my PhD, I do have time now for new tasks (and new jobs!), and the fellowship presents an amazing opportunity to really advance projects that I maintain or am part of. This also has a very nice effect on contributors and bug reporters, as their feedback gets addressed a lot faster. With some luck, this ultimately will help finding new (co)maintainers for projects as well (although in the age of AI, a lot of how open source used to work is much more uncertain, but that is a matter for a different blog post). The fellowship is time-limited, so I am intending to make the time I currently have count! So, what’s planned? I am involved in many projects, but three of them will be getting attention as part of the fellowship. I know I am notoriously slow at blogging, but expect more details on each of them very soon. Here’s an overview: Freedesktop.org, Specifications and Organization I maintain the Freedesktop Specifications, which is an area of Freedesktop that has traditionally been a bit chaotic. This “worked” in the past, because Freedesktop was never intended to be a formal standards body, but more a shared space where people could throw a lot of code and ideas over the wall and see what sticks and what people can collaborate on. While I very much love the spirit of this and want to keep it in some form, we definitely would benefit not just from more formalization and better procedures, but also from better organization of the specifications in general. A lot of conflicts can be avoided by that. I will work on improving procedures, crunching through the (lots!) of pending bug reports and MRs, and to make the specifications site better searchable and accessible (similar to how Mozilla’s MDN presents information, but I am not sure if we will get quite that far). I also intent to add a compatibility matrix for specifications, so if a desktop opts out of any one of them (or does not implement them yet) that fact is documented and authors of applications know what they can expect. This will allow us to move a lot faster and avoid a lot of conflict, because there is no implicit assumption that “everybody will implement everything” anymore (which has never been quite true anyway). Hopefully, this will ultimately result in a Freedesktop that is both a lot more useful for application authors who want to bring their project to Linux, as well as developers of desktop environments who need to see which specifications are available and which ones are current. In addition to that, I have also worked on a Freedesktop.org website refresh, which is pretty much done in its first iteration (pending sysadmin action). The aim there is to have a more official website, separate from user-contributed wiki content, that showcases what Freedesktop is and which projects are using it for hosting. Once the new website is live, I will also review every page again, archive dead projects in their own section and reorganize the software and specifications directory. Those sections are severely outdated and are missing recent efforts from the community, while still containing long-dead old projects (remember HAL? ). AppStream A lot of extra maintenance work will be (has been!) done on it. This includes things such as JPEG-XL support (blog post soon), sandboxed media processing, support for newer specification additions, better OARS integration (and potentially migrating it to fd.o infrastructure), improvements and API stabilization for libappstream-compose and a lot of bugfixing and resolution of issues found by AI code review. AppStream was originally designed to parse only trusted data from vetted Linux distribution sources – this is no longer the case in today’s world and in the way Flatpak uses it, so we need to increase resilience of the project. I am also exploring a project that could vastly improve search accuracy for AppStream. Stay tuned for that. PackageKit & System Upgrades Many years ago, people thought we would all migrate to atomic Linux distributions and slowly not need PackageKit anymore. This has not turned out to be the case, and there are still plenty of reasons to use a package-based OS, especially in development environments. At the same time, PackageKit has been basically the same for years, and its older architecture is beginning to show. It being a daemon who’s literal job it is to modify the entire system also makes it one of the most security-sensitive components that a Linux system can have, while simultaneously making it near-impossible to sandbox. My plan is to create PackageKit 2.0 by building on the great foundation of PackageKit 1.0, but modernizing it. This will include simplifying its code and removing a bunch of features that have no more use in modern desktops, while also adding some features that PackageKit never had but that would be useful to expose to frontends (still no to interactivity an terminal-progress forwarding though!). PK 2.0 will also allow me to solve a few design issues that have been worked around in the past, by replacing them with better solutions. This will be a painful transition, as PackageKit 2.0 will break all interfaces PackageKit has – and those interfaces have been frozen for more than a decade. However, I do fully expect this change to be worth the effort. In addition to that, I intend to look into the offline-update procedure again and improve it. The current multi-reboot operation comes with downsides, that newer systemd features such as soft-reboot can alleviate. The end result should be a much smoother, less annoying offline-update experience for users (I especially want to get rid of updates running on system startup, which I consider quite bad from a usability perspective). The new behavior is in the early drafting stages and may need direct support from systemd. I will share more about it once I can. That’s a lot of tasks! Yes! I will see how far I get. I am moving project-by-project though, to allow me to focus on one project at a time, rather than scattering my attention continuously. Amazingly, this means that the major tasks for AppStream are already almost done, and we are nearing the 1.2.0 release. AppStream got priority, because the new Freedesktop Flatpak runtime will be released soon, and because I want FlatHub/Flatpak to have access to the new AppStream release sooner. Freedesktop and PackageKit are next on the task list. Either way, a lot of progress is coming – if you have any feedback or want to help out, please don’t hesitate to reach out! All work is happening fully in the open, so you can also chime in on the respective GitHub/GitLab tasks . You can also expect blog posts about key features or interesting changes, so stay tuned!

Week 30 This week's icon is for Titouan Real's project: Era: "Manage your time" Check out all weekly app icons created so far in the gallery and follow my icon creation adventures as they happen (including sketches) on the Fediverse. Need icons? I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Join as a community sponsor to maintain a steady supply of app icons to the Linux ecosystem (every little helps!).

In recent weeks, I’ve been working on adding key rotation support to flatpak, so that repositories which sign their commits and summary files with a key with an expiry date have a way to push updates to that key to all the clients which use them. Currently that’s not possible without each client manually having its config updated to use the new key data (even if the change in key data is just to bump the expiry date). In the process I’ve learned a few more things about GPG keys, subkeys, signatures, UIDs, etc., which I thought I might dump here in case it’s useful for someone else (or me, in the future). I don’t claim to be an expert, so I may still be misunderstanding some bits. GPG is complex. One thing which has helped ground things is finding the documentation in RFC 4880 (and related) which defines the GPG packet format. One thing which keeps flatpak’s use of GPG simple is that it doesn’t use any of the web-of-trust features or trust-on-first-use (TOFU). Its use of GPG is limited to the keyring format (essentially pubring.gpg), for storing and publishing public and private keys, subkeys, signatures, revocations, UIDs; and using them to sign and verify OSTree commits and various repository files (summary, summary.idx, etc.). Quick primer on the parts of GPG GPG has keyrings: collections of primary keys. A primary key has public and private/secret parts. The way flatpak uses it, the secret part of a key always stays on the server, and is used to generate signatures. The public part is published by the server and configured in every client using that repository, used to verify the commit signatures. Each client has one keyring per remote it has configured. Typically this contains one primary key, but it could contain several, any of which can be used to verify signatures from that remote. A key is identified using a fingerprint, a 40-character hex string. It can also be identified using a key ID, which is a substring of the fingerprint. There’s also keygrips, but let’s ignore those. You can see fingerprints for keys using gpg --list-keys --fingerprint. A primary key has one or more subkeys (at least in flatpak’s usage). All of these keys have public and private/secret parts as above. Each key has a usage which indicates what GPG will let you use it for, such as certifying, signing, authenticating, encrypting. The primary key is typically used to certify its subkeys by creating cross-certification signatures which bind them to the primary key, forming a short chain of trust — anyone who trusts the primary key should trust a subkey which it cross-certifies. You can see subkeys as the sub lines using gpg --list-keys --with-subkey-fingerprint. The [SCE], [S], [E] (etc.) fields show the usage flags for a key. The other usage we care about is signing (flatpak doesn’t use authentication or encryption usages). GPG separates keys by usage to prevent attacks where a key is used for a purpose it’s not intended for, and because keys used for different purposes often need to be treated with different levels of care. In particular, separating by usage means the private/secret part of the primary key can be kept completely offline, and only brought out in a special key signing ceremony when a new subkey needs to be generated and cross-certified. This reduces the risk of the very valuable primary key, which is the root of every client’s trust in the repository, being leaked. So, we use a signing subkey for day-to-day signing of OSTree commits. For a big flatpak repository, the private/secret part of this subkey might be kept in a hardware security module, so it can’t be exfiltrated from the server if the server were compromised. But there’s still the risk of a compromised server being used to sign things it shouldn’t (such as malicious apps). That’s a matter for server security, but we can somewhat mitigate against the possibility of the signing subkey being leaked by setting an expiration date on it. Clients might choose not to trust signatures made by it after that date; and gpg certainly wouldn’t allow it to be used to create new signatures. The expiry date of a key is shown as an expires field in the gpg --list-keys --with-subkey-fingerprint output. What happens when the subkey expires? By that point, the administrators should have generated another subkey, cross-certified by the primary key in a key signing ceremony (I assume the ceremony involves cake). The private/secret part of the new subkey needs to stay secret, as before; but the public part needs to be distributed to every client’s keyring, along with the new cross-certification signature from the primary key, so the clients know they can trust signatures made by that subkey. That’s the bit which flatpak is currently lacking. So in summary: GPG has keyrings. Keyrings have primary keys. Primary keys have one or more subkeys and cross-certification signatures from the primary key on those subkeys. Each subkey has a usage, but flatpak only uses certify (for the primary key) and sign (for the subkeys). Keys can have expiration dates. And if you want to see the full contents of a keyring, run gpg --list-keys --with-colons. It’ll output everything (no filtering) in a machine readable format described here (best reference I’ve been able to find), which is sometimes easier to use than remembering which --with-blah option to pass to GPG to get it to show the information you want. What else does GPG have? Quite a few things. We’ll ignore the big things which are not relevant to flatpak. Each primary key also has one or more UIDs. These are like subkeys in that they are cross-certified by the primary key. Each UID is a user identity — typically a name and email address. If you were using GPG in a web of trust, the binding between the primary key and a UID is what you sign that you trust when you sign someone’s key in a key signing party. The UIDs are listed below each primary key in gpg --list-keys. Flatpak doesn’t need UIDs, but they are an unavoidable part of GPG — each primary key must have at least one. A flatpak repository will typically put a server contact email address in the UID and then everyone will ignore it. UIDs can be revoked; for example if someone loses control of the email address in it and wants their friends to no longer trust emails from it. Flatpak currently doesn’t use this. What else can be revoked? The cross-certification signatures! You may have heard of a GPG revocation certificate. This is a way of revoking an entire primary key. But there’s also a way of revoking a particular cross-certification signature, meaning that the primary key is still valid/trusted, but the owner of the primary key has lost control of one of the subkeys, and that subkey should no longer be trusted. This is different from key expiration, as it’s a statement that something has explicitly gone wrong. Because of how GPG is built up as a series of packets of different types, a signature revocation is actually a revocation packet appended to the primary key. This means you can re-cross-certify a subkey after revoking it, by appending another cross-certification packet. And even revoke it again after that. Not sure if there’s a use case for this or if it’s just a consequence of the packet format, but this behaviour does play havoc with working out whether to trust a subkey. Cross-certification signatures can also have an expiration date built into them, separate from the expiration date of the subkey. I’m not sure of the use case for this either, but there must be one. Some notes on running GPG on the command line GPG is historically famously hard to use. I feel this has got better in recent years, particularly for scripting it. In particular it’s added a whole load of --quick-blah commands to generate keys, set expiries, etc. from scripts. One thing which repeatedly tripped me up before I stopped trying to fight it was its concept of a ’homedir’. GPG needs to look for its keyring (and trust database, and various other files) somewhere, and will not run without them, so you always need to pass it a ‘homedir’ to look for them in. By default, this will be ~/.gnupg, so it’s very easy to accidentally end up operating on your personal GPG keyring when you’re trying to do something in a project. If using GPG as a tool or in a script, I think you should always create a temporary homedir, pass it as gpg --homedir=/path/to/temp and explicitly import whatever keys or context you need into this homedir before doing whatever operation you need. This is necessary even if ‘all’ you want to do is view a downloaded .gpg keyring, because what GPG displays may be affected by the trust database in its homedir. So to view a downloaded keyring you should still do something like mkdir temp; gpg --homedir=./temp ./path/to/download.gpg. If you are trying to sign something, you will typically pass the fingerprint or key ID of a primary key to GPG; for example as gpg --local-user 0xfingerprint --sign ./path/to/file. GPG will helpfully use the usage flags of the subkey of that primary key to choose which subkey to sign with. If you want to sign with a specific subkey, you need to suffix the fingerprint with an exclamation mark (!) otherwise GPG will still choose what it thinks is the most appropriate subkey, which might not align with the subkey you carefully chose. This ! suffix format is common throughout the GPG command line interface for when you want to specify a specific subkey. Sorry That was more of a braindump than I imagined when I set out to write this. I hope some of it is useful; feedback welcome if I’ve got anything wrong. If any GPG experts fancy reviewing key rotation support in flatpak, the draft implementation is here.

Hello,Here’s some thoughts on software for August. Bear with me on these broad categories but I think you can group most software projects into one of these groups: art, infrastructure, and activism. Art is primarily to communicate experiences and feelings to others. Making video games is art. Making digital musical and instruments and visual effects is art. The drawing you did as a child that’s stuck on somebody’s fridge is art. The 3rd year computing student’s university coursework, uploaded to Github without comment and abandoned forever… that’s art, or at least, it’s a sketchbook. The thorny entry to the IOCCC, the optimized inner loop deep in some graphics toolkit, that only a handful of people will ever look at, but all of them will agree: that’s art. People make art for fun, learning and practice. Infrastructure is stuff that is needed and expected for the world to function. The definition of infrastructure changes over time, as societies adopt and depend on new technologies. Roads, milk delivery, electricity, bakeries, aqueducts, supermarkets, the internet, trams, the lift in your apartment building, and so on. Many societies depend on software projects now. Web browsers, phone cells, operating systems, social networks, software developer tools, power grid management, Google Maps, and so on. People make infrastructure for money, or perhaps out of a sense of duty. Activism is a desire to bring about a particular social or political goal or change. I don’t know when the first activist software project started, but it was no later than the 1980s when the GNU project began its stated mission to make proprietary software unviable via copyleft, and many free software projects followed along. The design of the GNU C compiler was shaped by the mission. Tor began in the 2000s with the goal of ensuring private, uncensored internet access. Bitcoin began with the stated aim of destroying the financial system, the wake of the 2008 bank crisis. Although in many countries it’s now regulated financial infrastructure, which shows you that projects can move between these categories over time. People spend our energy on activism based on our beliefs, usually a sense of wanting to make the world a better place for everyone, or at least for ourselves, and our friends and family. Not everything fits into these categories (the biggest gap I can see is experiments and research) but let’s keep this short, I want to use them to look at the conversations I keep seeing in the open source world this year. When one person sees a project as activism and another sees it as infrastructure, you see some genuinely confused conversations happening. Codeberg banned projects with largely AI generated code from the site, and Sourcehut is considering doing the same. If you see these projects as Git hosting infrastructure similar to Gitlab and Github, then that decision makes very little sense. Why would they want to host fewer projects? However if you see the project as a group of activists trying to reduce the power and influence of US tech firms, and limit the harms of rapid of adoption of AI, then it makes a lot of sense. Linux decided to allow some LLM use and not put too many limits, as long as its making the project better. If you see Linux as a bunch of engineers building infrastructure then it’s a very logical decision. But if you thought your contributions were part of some activist movement then that might be a disappointing decision. Every so often I hear someone say things like “please keep politics out of software”. You can infer that they’re probably talking about infrastructure software — and it’s as misguided as if they said it about any other infrastructure. Is an aqueduct political? If one country is seen as stealing another country’s water then… yes. Can a shipping lane be political? Yes, see numerous examples, including the ongoing US-Iran conflict. Can a road be political? Yes, if it crosses a border, especially if it’s in dispute. Ask someone old from Berlin or the north of Ireland about whether roads can be political. Maintaining software takes a lot of effort. If someone is putting in that effort without being paid, they have some other motivation for doing it. Humans rarely do difficult, laborious work for no reason. Our motivation might be to learn, to show off, to have fun, to meet people, to collaborate with friends, or it might be to work towards some kind of political or societal change. I’ve probably contributed to open source for all of these reasons at different times. We are increasingly referring to open source software as “digital infrastructure” and funding some of the maintenance work via corporate money and public money. This is great, but it requires the project to frame itself as infrastructure rather than activism. You are unlikely to get funding from Microsoft if you openly state that your goal is to destroy Microsoft. You are unlikely to get funding from a government if your stated goal is to destroy the modern financial system or prevent all forms of censorship. Activists using open source licenses have something of a problem to deal with. If your goal is to bring about world peace, you hardly want people building drones and missiles using the software you develop. Yet the open source movement have made it clear that if you try to limit who can use your software, it’s no longer open source. And, many software engineers have made it clear they don’t give a shit about software licensing anyway and they’ll use your code however they want without even reading the license. You can control access to software infrastructure, of course, just like you can put soldiers and passport controls on a bridge or a road. But you can’t call it open source any more. The GNOME desktop project is art, infrastructure and activism. The discussion on Reddit is mostly people who design and post desktops and themes for fun. Several corporations build products with GNOME, and treat it as infrastructure. And then there are contributors who want to bring about change, perhaps weakening the power of Big Tech by spreading an ethical alternative to Android and iOS. GNOME hasn’t made a statement on AI use, and I don’t think we’ve tried very hard to discuss it so far. I wonder if we’re putting it off because we’d have to also discuss whether our goal is to maintain some infrastructure, or build something cool-looking, or bring about meaningful societal change?

Over the summer of 2026, I worked towards bringing the option of playing Vocab-Style puzzles to GNOME Crosswords as part of Google Summer of Code. This entailed adding support to the puzzle library, and writing the backend of the algorithm responsible for grid generation. Jonathan Blandford provides a thorough rundown on the ins and outs of Crosswords with these slides. The first few weeks of the start of GSoC were spent by adding a drop-down calendar widget to Crosswords Editor, and storing GDate data as ISO8601. We decided to integrate this into my design despite it not being directly related to the proposed project because it still contributed to the Crosswords app. For the new puzzle type, I started with adding support to the puzzle library, libipuz, which is responsible for formatting and representing puzzles styled as ‘paper-and-pencil’ crosswords. My primary mentor and I bounced ideas back and forth for some time before we started designing and writing the algorithm. We landed on an idea and I created an initial design document for the plan of action to follow for the summer. We decided that aiming for both the backend and frontend in one summer may be more work than we initially thought, so we concluded on focusing exclusively on getting a working algorithm to build from. The bulk of this summer consisted of writing and reconfiguring the depth-first search backtracking algorithm.   GitLab Links to Code: An overview of my GitLab profile can be found here. Implementation of New Vocab Puzzles This is the bulk of the algorithm and unit tests. The user inputs a word, the word gets analyzed in a recursive function to check for crossings and constraints, we save the state of the board, backtrack if needed, and present a grid. Vocab Ipuz Adding new class for IpuzVocab to support vocab puzzles in the puzzle library (libipuz). Check for Island Words There may be a word in a list that may not share any intersection points with any others no matter how many backtracks are done. Consequently, this affects grid creation in a timely manner and may prevent grid generation at all by stating it false. We can compare the bitmask of words in the list before we even activate the algorithm to detect a word that would potentially conflict with the others. Date Validation Previously, the Crosswords Editor had a free-for-all AdwEntryRow. However its purpose is to present a legible date to the user, and store the date in ISO8601 format. I used GDateTime, GDate, and a Gtk Calendar widget to add a drop-down calendar in the date box. The chosen date presented in Gregorian style to the user, and stored as ISO8601 to the backend. Added Dispose to Shapebg Releases references to GObjects that Shapebg owns and frees Shapebg’s remaining memory.   Design Docs: Updated Design Doc  Vocab Design Doc   Blog Post Links (Most Recent -> Oldest): GSoC 2026 Final Report – Laureen Caliman Vocab-style Crosswords Update | Final Stretch Intern Experience at GUADEC Update on Crosswords Backtracking Algorithm Pick a Word, Any Word Extending Libipuz GSoC Project Start Introduction Post   I also gave a lightning talk at the 2026 GNOME Users and Developers European Conference here. Thank you to the GNOME Travel Committee for making that opportunity possible. I still have some work to do for both Libipuz and Crosswords: finish the island-checking function detailed above, open a new MR to choose the most compact/square grid out of 500 options and present that to the user directly rather than them cherry-pick through a large selection,  create a new MR to add photos of the puzzle in libipuz using gi-docgen, convert the 500-generated grid code to a PuzzleTask, and incorporate the frontend to make this a fully-functioning part of the game. I would like to thank my primary mentor, Jonathan Blandford, and my other mentor, Federico Mena Quintero, for their guidance, feedback, patience, and teaching. This program was exactly what I needed to become better at development and serves as my rock to open-source contributions. I learned a lot of valuable skills such as document reading, how much to push in a commit, how to slow down trying to get a lot done at once, but simultaneously how to speed up my progression on the parts that actually matter, code with brevity, and a whole lot of dealing with nasty version control! I intend to continue contributing to GNOME Crosswords as well as the overall GNOME Foundation. I look forward to collaborating with more people involved in the Foundation!  

Overview My project was to write the Pitivi Timeline Ruler in Rust using GTK4 and create GObject bindings for it. The project goals overall went well, and I was able to complete the widget successfully along with adding a layout manager structure to the ruler for child widgets to be added from the Pitivi/Python side. My standalone repository contains a working Python demo to verify successful FFI functionality. Integration into the Pitivi application is not complete. The GTK4 port branch is still a work in progress and is not quite ready yet for deployment. My commit adding the ruler to the WIP GTK4 branch can be found here. My repository containing all of my commits and the standalone widget with demos can be found here Plan Going Forward I will stay actively involved in the GTK4 porting effort, apply for GNOME membership and stay involved in the Pitivi project. The GNOME community has been very welcoming, and I plan on continuing to contribute both to Pitivi and the broader GNOME ecosystem for the foreseeable future. Design General Architecture A major structural change that has been made after mentor feedback was to move application orchestration out of the widget itself, and keep more of the logic on the app side. The design is a "dumb widget, smart app" framework, where the ruler does not own editor policy. The app provides the logic for how to handle gestures and what to do when the user interacts with the widget. One example of this is that project_duration was removed as a property entirely, and logic around bounds is now handled entirely on the app side. This allows the widget to be used in a variety of contexts, and allows the app to handle bounds in whatever way is appropriate for the context. The rendering code also received a fairly large cleanup. Previously, the widget stored several pieces of drawing state separately, including adjustments, cached Pango layouts, and font descriptions. These have now been grouped into a single DrawingState struct behind one RefCell. This made ownership easier to follow, and allows the code to release it's mutable state borrow before connecting or disconnecting signals. I also introduced a labels_dirty flag so timeline labels are only recalculated when they're actually needed during the snapshot phase, rather than repopulating the cache with every setter or adjustment call. The widget follows font and color settings from the users GTK4 theme, allowing user theme changes seamlessly. Time Markers The ruler utilizes a BTreeMap to cache the text markers that are visible at the current window size plus a half a screen size buffer over either edge. I used a BTreeMap because it offers high efficiency insertion, deletion, and lookup for this case where our markers are sorted. The ruler recalculates the spacing needed between labels by calculating an intentionally wide timecode using the current font and some padding. This measurement is cached until a change in frame-rate or font invalidates it. Labels include frames when zoomed in below 1 second, and drop the frame count when zoomed out past that point. Major Ticks and Intervals Major divisions are calculated using a two-mode strategy. First, the pixel density is calculated to determine whether a one-second interval can meet the minimum label spacing. If so, frame-aligned intervals are used, with the smallest interval meeting the minimum label spacing selected. If one second is too narrow for a label, frame alignment is abandoned in favor of whole-second intervals, selecting the smallest interval that meets the minimum label spacing from a pre-defined list. This list can be tuned later to meet Pitivi's UI needs. Minor Ticks After discussing ticks with some video editors, I realized that frame alignment is more important to the video editing community than clean time divisions. Because of this, I made the decision to implement a reverse modulo loop to consider possible intervals from largest to smallest that accurately divide frames. The resulting spacing is also checked against the minimum tick spacing to make sure we don't end up with a block of ticks that are too close together. The result is that our minor ticks are asymmetrical and are not even as the user zooms in and out, but they do always accurately divide by frames in the major interval. Layout Manager & Layout Child We needed some mechanism to position arbitrary external widgets (play-head, markers, loop-brackets) on the timeline. The timeline uses nanosecond timestamps, so the parent ruler determines x-cords for the children based on the zoom and horizontal scrolling position. I introduced two objects (public C-wrapper and Engine): PitiviTimelineLayoutChild Subclasses gtk::LayoutChild. Metadata wrapper for generic widgets dropped onto the timeline. Adds a custom GObject property for timestamp. PitiviTimelineLayoutManager Subclasses gtk::LayoutManager and is installed on PitiviTimelineRuler. Creates the custom layout child for each child widget. overrides measure() and allocate(). During allocation, the manager reads the ruler's ns_per_pixel, horizontal adjustment, and the child's time stamp to determine the child's x-coordinate. The child is centered on it's time stamp and scrolls with the ruler. The Python demo shows an example using ruler.add_marker(playhead, 0) to add a play-head at the start of the timeline. Bindings and Build The FFI layer in ruler.h and capi.rs expose the following small API: pitivi_timeline_ruler_new() creates a ruler as a GtkWidget. pitivi_timeline_ruler_clocktime_from_pos() converts an x coordinate to a nanosecond time stamp. pitivi_timeline_ruler_add_marker() adds a child widget at a time stamp and returns a layout-child object. The properties of the ruler are exposed as GObject properties, and can be set and retrieved using standard GObject property accessors. The Process Challenges The FFI bindings were a major challenge for me. I ran into significant challenges fixing bugs and understanding conceptually how the Rust bindings actually worked. My initial FFI attempt did compile, but I had to work through significant GTK initialization and headless CI issues. The fixes show up in my commit history as changes of a couple of small lines of code, but the time spent understanding the issues was significant. I also came into this with very limited knowledge about Flatpak and Meson. Getting myself to a point where I understood what the build systems were doing took a significant amount of effort. I think I spent about the same amount of time reading about GIR, GObject, Flatpak and Meson as I did writing the code. For a very small percentage of the actual code, those tools required the most attention. I view this learning as really valuable for future work in the GNOME space, and I tried to take as much time as I could afford to do my best to genuinely deepen my understanding. The rendering logic, while similar to previous GTK4 widgets I had built, ended up having numerous rounds of refactoring and learning. I wrote about 4 different strategies for scaling, multiple designs for splitting time and frames and multiple minor tick rules. Even once I was settled on a design, I had multiple waves of finding cache inefficiencies, clearing stale entries, and removing precision and allocation bugs. The ruler is visually small, but the underlying math and rendering logic took quite a bit of work to really get to a professional standard. I would not be surprised if the logic changes again in the future as I continue to work on the Pitivi GTK4 port and get feedback from the community. Major Milestones May 3: Built the initial window render as a standalone GTK4 application. May 8: Added the initial GObject getter/setter structure, a GtkScrolledWindow test, and zoom bounds. May 9-13: Drew the initial major and minor ticks, changed the scale to nanoseconds per pixel, and added Pango labels to test scale behavior. May 14-28: Reworked time stamp math, wrote code to extract frame-rate from video's GES timeline which was later scrapped, and refactored rendering of ticks to draw a single interval and then paint it repeatedly across the ruler. May 30-June 4: Wrote the dynamic label-width measurement, minimum tick spacing, and frame-oriented major/minor interval selection structure. Added gtk::Scrollable interface to the ruler. June 6-26: Refined cache eviction for scrolling. I also addressed zoom drift, font and DPI changes, adjustment-signal cleanup, and precision around the playhead coordinates. I wrote the unit tests for subdivision and timecode math in this period as well. June 30-July 3: Removed redundant APIs, moved gesture handling to the app side, refactored types throughout the codebase, and removed the widget's project-state ownership. July 5-25: Created the initial FFI bindings and the layout manager and layout child, and then attended GUADEC in A Coruña, Spain. I managed to resolve the GTK initialization CI issues and successfully exposed the ruler and layout child. July 26-29: Added dirty-label cache invalidation and consolidated the rendering state into DrawingState struct. These optimizations simplified borrow management and reduced thrashing the Pango cache. August 1-12 - Added the Python demo to python/test.py, fixed allocation updates for children widgets near the start of the ruler during zoom changes, added Meson build, added the Meson test target that runs the Rust tests. August 12-Present: I am currently battling through adding my ruler to the Pitivi GTK4 port branch. Special Thanks I would like to send a massive thank you to my mentors, Yatin and Alex Băluț. I was going pretty significantly off track a few times throughout the project and I got nudged in the right direction at some critical moments. I would also like to thank the GNOME travel committee. Getting to attend GUADEC was a really incredible experience. Sergey Bugaev took a lot of time to sit and work through some of my bugs with me and help provide some guidance. As a long time GNOME daily user, getting to spend time and meet maintainers and Federico was a really exciting opportunity. GSoC has been a great experience, and I am very grateful for the opportunity to work on this project. I am looking forward to continuing to contribute to the GNOME ecosystem.