(This is an updated version of an older post - the introduction remains the same, the technical details are different)

Linux draws a distinction between code running in kernel (kernel space) and applications running in userland (user space). This is enforced at the hardware level - in x86-speak¹, kernel space code runs in ring 0 and user space code runs in ring 3². If you’re running in ring 3 and you attempt to touch memory that’s only accessible in ring 0, the hardware will raise a fault. No matter how privileged your ring 3 code, you don’t get to touch ring 0.

Kind of. In theory. Traditionally this wasn’t well enforced. At the most basic level, since root can load kernel modules, you could just build a kernel module that performed any kernel modifications you wanted and then have root load it. Technically user space code wasn’t modifying kernel space code, but the difference was pretty semantic rather than useful. But it got worse - root could also map memory ranges belonging to PCI devices³, and if the device could perform DMA you could just ask the device to overwrite bits of the kernel⁴. Or root could modify special CPU registers (“Model Specific Registers”, or MSRs) that alter CPU behaviour via the /dev/msr interface, and compromise the kernel boundary that way.

It turns out that there were a number of ways root was effectively equivalent to ring 0, and the boundary was more about reliability (ie, a process running as root that ends up misbehaving should still only be able to crash itself rather than taking down the kernel with it) than security. After all, if you were root you could just replace the on-disk kernel with a backdoored one and reboot. Going deeper, you could replace the bootloader with one that automatically injected backdoors into a legitimate kernel image. We didn’t have any way to prevent this sort of thing, so attempting to harden the root/kernel boundary wasn’t especially interesting.

In 2012 Microsoft started requiring vendors ship systems with UEFI Secure Boot, a firmware feature that allowed⁵ systems to refuse to boot anything without an appropriate signature. This not only enabled the creation of a system that drew a strong boundary between root and kernel, it arguably required one - what’s the point of restricting what the firmware will stick in ring 0 if root can just throw more code in there afterwards? What ended up as the Lockdown Linux Security Module provides the tooling for this, blocking userspace interfaces that can be used to modify the kernel and enforcing that any modules have a trusted signature.

But that comes at something of a cost. Most of the features that Lockdown blocks are fairly niche, so the direct impact of having it enabled is small. Except that it also blocks hibernation⁶, and it turns out some people were using that. The obvious question is “what does hibernation have to do with keeping root out of kernel space”, and the answer is a little convoluted and is tied into how Linux implements hibernation. Basically, Linux saves system state into the swap partition and modifies the header to indicate that there’s a hibernation image there instead of swap. On the next boot, the kernel sees the header indicating that it’s a hibernation image, copies the contents of the swap partition back into RAM, and then jumps back into the old kernel code. What ensures that the hibernation image was actually written out by the kernel? Absolutely nothing, which means a motivated attacker with root access could turn off swap, write a hibernation image to the swap partition themselves, and then reboot. The kernel would happily resume into the attacker’s image, giving the attacker control over what gets copied back into kernel space.

This is annoying, because normally when we think about attacks on swap we mitigate it by requiring an encrypted swap partition. But in this case, our attacker is root, and so already has access to the plaintext version of the swap partition. Disk encryption doesn’t save us here. We need some way to verify that the hibernation image was written out by the kernel, not by root. And thankfully we have some tools for that.

Trusted Platform Modules (TPMs) are cryptographic coprocessors⁷ capable of doing things like generating encryption keys and then encrypting things with them. You can ask a TPM to encrypt something with a key that’s tied to that specific TPM - the OS has no access to the decryption key, and nor does any other TPM. So we can have the kernel generate an encryption key, encrypt part of the hibernation image with it, and then have the TPM encrypt it. We store the encrypted copy of the key in the hibernation image as well. On resume, the kernel reads the encrypted copy of the key, passes it to the TPM, gets the decrypted copy back and is able to verify the hibernation image.

That’s great! Except root can do exactly the same thing. This tells us the hibernation image was generated on this machine, but doesn’t tell us that it was done by the kernel. We need some way to be able to differentiate between keys that were generated in kernel and ones that were generated in userland. TPMs have the concept of “localities” (effectively privilege levels) that would be perfect for this. Userland is only able to access locality 0, so the kernel could simply use locality 1 to encrypt the key. Unfortunately, localities are typically only available on systems that implement a Dynamic Root of Trust Measurement like Intel’s TXT, and most consumer systems have no support for this. So, we need another approach.

TPMs have a set of Platform Configuration Registers (PCRs), intended for keeping a record of system state. The OS isn’t able to modify the PCRs directly. Instead, the OS provides a cryptographic hash of some material to the TPM. The TPM takes the existing PCR value, appends the new hash to that, and then stores the hash of the combination in the PCR - a process called “extension”. This means that the new value of the TPM depends not only on the value of the new data, it depends on the previous value of the PCR - and, in turn, that previous value depended on its previous value, and so on. The only way to get to a specific PCR value is to either (a) break the hash algorithm, or (b) perform exactly the same sequence of writes. On system reset the PCRs go back to a known value, and the entire process starts again.

Some PCRs are different. PCR 23, for example, can be reset back to its original value without resetting the system. We can make use of that. The first thing we need to do is to prevent userland from being able to reset or extend PCR 23 itself. All TPM accesses go through the kernel, so this is a simple matter of parsing the write before it’s sent to the TPM and returning an error if it’s a sensitive command that would touch PCR 23. We now know that any change in PCR 23’s state will be restricted to the kernel.

When we encrypt material with the TPM, we can ask it to record the PCR state. This is given back to us as metadata accompanying the encrypted secret. Along with the metadata is an additional signature created by the TPM, which can be used to prove that the metadata is both legitimate and associated with this specific encrypted data. In our case, that means we know what the value of PCR 23 was when we encrypted the key. That means that if we simply extend PCR 23 with a known value in-kernel before encrypting our key, we can look at the value of PCR 23 in the metadata. If it matches, the key was encrypted by the kernel - userland can create its own key, but it has no way to extend PCR 23 to the appropriate value first. We now know that the key was generated by the kernel.

Unfortunately it turns out that some people actually make use of PCR 23, and restricting it to the kernel makes them sad. There are other resettable PCRs, but only in non-0 localities, so (a) we can’t reset them on most systems and (b) we’ll just find someone who uses them anyway and run into the same problem. We need a different approach.

Thankfully TPMs have a small chunk of non-volatile RAM that can be used for storing things, and by “storing” I mean they can be used in a range of different ways. One of these is effectively as additional PCRs. These values can be configured such that they work the same way as PCRs, with the only way to modify them being to append a new hash to their existing value and update the new value to the hash of that merged value. We can allocate one of these for in-kernel use and reject any access from userspace, and also there are officially allocated ranges (so people shouldn’t be using random values) and the namespace is large enough anyway that w eshouldn’t collide with anyone, so we can carve one of those out and use it for this purpose.

Unfortunately, though, these NV indexes aren’t included in the creation data we get when we create a key, so we need another approach. TPMs have the concept of sessions, a series of commands executed in sequence. A flag allows these sessions to be “audited”, with the TPM keeping a running track of the hash of the commands executed and the results returned. At the end of the session you can ask for a signed copy of this hash, and if you’ve kept a log of all the commands then you can verify that they match that signed hash and know that this log represents a real communication with the TPM. If we read the NV index and generate the key inside the same session, we can verify that the key we’re looking at was created while the NV index had a specific value, and if only the kernel can set that value then we know that the key was generated by the kernel.

Or, well, can we? Only new kernels would impose the restriction on modifying that NV index. An attacker could boot an old kernel, generate a key there in userland, sign a hibernation image with it, and then reboot into a new kernel. The new kernel would see a valid signature with a valid NV index associated with it and have no way to know it was generated from userland rather than the kernel. We need to be able to tell the difference between kernels that implement this feature and ones that don’t, and we need to do that without being able to go back in time to change old kernel behaviour. We can extend a PCR to indicate we implement the new functionality, but so can an attacker running an old kernel.

The normal approach to determining whether an event occurred in a specific phase of the boot process is to “cap” the PCRs - extend them with a known value that indicates a transition between stages of the boot process. Any events that occur before the cap event must have occurred in the previous stage of boot, and since the final PCR value depends on the order of measurements and not just the contents of those measurements, if a PCR is capped before userland runs, userland can’t fake the same PCR value afterwards. If Linux capped the PCRs before userland started running, we’d be able to place a measurement there before the cap occurred and then prove that that extension occurred before userland had the opportunity to interfere. We could simply place a statement that the kernel supported the NV index restrictions there, and we’d be fine.

Unfortunately Linux doesn’t currently do this, and adding support for doing so doesn’t fix the problem - if an attacker boots a kernel that doesn’t cap a PCR, they can just cap it themselves from userland. So, we’re faced with the same problem: booting an older kernel allows the system to be placed in an identical state to the current kernel, and a fake hibernation image can be written out. Solving this requires a PCR that was being modified after kernel code was running, but before userland was started, even with existing kernels.

Thankfully, there is one! PCR 5 is defined as containing measurements related to boot management configuration and data. One of the measurements it contains is the result of the UEFI ExitBootServices() call. ExitBootServices() is called at the transition from the UEFI boot environment to the running OS, and the kernel contains code that executes before it. So, if we measure an assertion regarding whether or not we support restricted access to NV indexes into PCR 5 before we call ExitBootServices(), this will prevent userspace from spoofing us (because userspace will only be able to extend PCR 5 after the firmware extended PCR 5 in response to ExitBootServices() being called). Obviously this depends on the firmware actually performing the PCR 5 extension when ExitBootServices() is called, but if firmware’s out of spec then I don’t think there’s any real expectation of it being secure enough for any of this to buy you anything anyway.

That’s what this patchset does. Review feedback so far seems positive, although James Bottomley suggested a design improvement. My approach of using an NV index as a PCR and generating a signing key made sense as a consequence of my original approach involving PCR 23, which had been to use the key creation data and not use audit sessions at all. But the goal isn’t to use a key - it’s to prove that hibernation occurred in-kernel, and while signing is one way of doing that, there are others. His suggestion is to simply record the hash of the hibernation image into the NV index and then read that back as part of the audit session. On resume we verify the audit session log is legitimate, read the hibernation image, and compare the hash of the hibernation image against the hash in the log. If it matches, and if the PCR 5 value matches, we know the audit session happened in kernel and that the hibernation image hasn’t been modified.

It still seems like we’re missing something, though. If we’re not storing a key anywhere, how do we verify the audit session? To explain this we’re going to need to go into some details about how TPM keys work in the first place. TPMs can produce a special kind of key called an Attestation Key, or AK. Attestation keys are used to sign attestation statements from the TPM, such as PCR quotes or audit logs. We need a separate key type for this in order to prove that the signature was generated as part of an attestation - normal TPM signing keys are fundamentally designed to sign arbitrary material, and so can be used by userland to sign something that looks identical to an attestation record. By being able to distinguish the types of key the TPM uses, we can prove that a signature was generated using an AK, and so know that it’s a real TPM attestation (because nothing other than the TPM can sign stuff with an AK).

But even beyond this distinction, TPMs have different key types. Ordinary keys are generated using an RNG and will be unique. Primary keys are generated using a seed that is used as an input into a key derivation function. For a given TPM, using the same seed to generate the same type of primary key will always generate the same primary key⁸. We can have the kernel deterministically generate an AK during suspend in order to sign the audit log, and then generate the same key again on resume to validate it. This means we don’t need any other form of trusted storage for the AK - the TPM already provides that functionality.

This is all rather complicated but I’ve been thinking about this for some time now and I haven’t come up with a cleaner solution. The only real open issue is the degree to which machines actually perform the PCR 5 extension. If it turns out there’s a bunch that don’t we’ll need to come up with some alternative approach to identifying whether the kernel supports this functionality, but the design is such that that should be invisible to userspace so adding alternatives later shouldn’t be an issue. Filtering accesses to the NV index is also not super clean, and depends on there not being alternative mechanisms to get at the TPM by sending raw commands. Again, this is intended to be opaque to userland and can be improved if we come up with something better later on (such as a secure way to pass a secret to the kernel on boot that can be used as an auth value for acess to the NV index).

Anyway. Time to go and fix the next thing.

LinuxDays 2026, the largest open-source event in Czechia, took place on the first weekend of October, and we had a Fedora & CentOS booth there again. This time, we got a smaller table and our booth equipment was more modest because no one traveled from Brno by car—we only had what we could carry on the train. However, we had quite a few nice stickers and one Framework laptop, which generated a lot of attention again.

I was happy that I didn’t have to staff the booth alone; I was accompanied by Vojtěch Trefny, a long-time Fedora contributor.

Even though CentOS Stream has existed for seven years now, we still received questions like: “Oh, CentOS is still alive? I thought Red Hat killed it a long time ago.” This was typically the starting point for a conversation about the differences between the original CentOS and CentOS Stream, as well as their relation to Red Hat Enterprise Linux.

Most questions about Fedora were related to Framework, which didn’t come as a surprise given that we were showcasing Fedora Linux 45 on a Framework Laptop 16. People asked whether there is any cooperation between Fedora and Framework, whether Fedora Linux is a good OS for Framework hardware, and whether Framework is a good laptop option for Fedora Linux. To all of that, we had very positive answers.

It was an exhausting weekend because we had dozens of conversations, but it was also refreshing to meet Fedora and CentOS users and hear feedback directly from them. I’d like to thank Fedora for sponsoring my trip and Vojtěch for helping me with the booth.

I remember back in 2020, people were complaining that we didn’t have enough documentation for creating GNOME Shell extensions. They said it was almost impossible to figure out where to start. They were right, learning all of it without proper documentation was a huge challenge for me too.

So, I decided to learn the GNOME Shell source code and shared what I learned in a YouTube tutorial series. I spent countless hours learning and making those videos, and the community was very happy to finally have guides and documentation.

On the GNOME side, Sriram Ramkrishna started the GNOME Extensions Rebooted project. When he noticed my tutorials, he invited me to join the team to help write documentation. I spent many hours learning GTK4 and the GNOME Shell 40 source code to write the famous GNOME Shell 40 Port Guide. I’d argue that many extension authors would have given up without it. Migrating from GTK3 to GTK4 and adapting to the changes between 3.38 and 40 was overwhelming. I wrote the guide with many examples, so developers could easily understand how to port their code.

Today we have all the documentation needed to start and maintain extensions, but nowadays, people are just simply vibe coding GNOME Shell extensions without reading any of it before submitting it to EGO. To be honest, in the age of LLMs, it feels like our documentation is feeding LLMs more than actual human developers.

For years, I tried my best to help the community, answering questions daily and reviewing extensions submitted to EGO, often spending 4 to 10 hours a day managing the whole extensions eco system. GNOME was incredibly generous this year and awarded me the GNOME Pants Award 2026 for my contributions to GNOME and the extensions ecosystem. That was a major personal milestone, and honestly, a testament to the growth of our community as a whole.

I’m writing this post because since early 2025, the volume of submissions has exploded. The vast majority are AI generated, and the huge workload is pushing me close to burnout. To be clear, all of my work is unpaid. While managing this volume easily matches a full-time job, my monthly donations remain close to zero. Given how many people use GNOME extensions daily, I truly believe our community can help make this workload doable. If you find value in what I do or if my work has helped you out over the years, please consider supporting me through donations. Without financial support, I simply won’t be able to keep going at this pace.

AI generated extensions, especially when prompted by non developers are frequently bloated and poorly designed. Because extensions run directly inside the GNOME Shell process, quality control is critical. Low-quality, AI generated code directly threatens the stability of the entire shell, and vibe coders need to realize that. As someone who reviews code across all of EGO, I can tell you that LLMs produce needlessly complex, hard to read code that takes significantly longer to review. To make matters worse, some submitters rely on AI to generate replies during the review process. I even received a response that accidentally pasted the LLM’s instructions intended for the user:

Then, respond to the specific points it points to and maintain a real public repository, with testing instructions and development history. This gives the base reviewer to evaluate maintenance and quality, without trying to hide anything.

On a positive note, a while back I published An Open Letter to AI for Generating GNOME Shell Extensions to fix specific code patterns their models were generating incorrectly and I noticed most of those issues disappear just a few weeks after that post, which is great news, but also proof of just how heavily our documentation is feeding these LLMs.

Anyway, we need viable solutions to keep the EGO ecosystem stable, trustworthy, and sustainable:

• I’m asking developers who understand GTK and GNOME Shell source code to join the review team. I am happy to mentor and teach you the review process. Please note that while this is a volunteer role, we need people who can be consistently available during the week.
• As many of you know, we introduced the Shexli linter a few months ago to make the review process easier. We need someone to help us improve it. The workflow is straightforward: reviewers identify false negatives and false positives during reviews, and you fix them in Shexli.

If you are interested in joining the review team or helping with Shexli, please reach out to us on GNOME Extensions Matrix channel. Thanks for being part of the GNOME community!

Week 33

This week's icon is for Tau Gärtli's project:
Ripples: "Rip CDs"

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

Update on what happened across the GNOME project in the week from October 2 to October 9.

GNOME Circle Apps and Libraries

Brage Fuglseth reports

This week Concessio was accepted into GNOME Circle. Concessio helps you understand and convert between unix permissions representations. Congratulations!

Ronnie Nissan reports

This week I released Concessio version 1.0.0. I am very proud that it got accepted into GNOME circle as announced above, it also got the following improvements.

• A full rewrite from Gjs to Vala, making Concessio very fast, the code base clean and easier to contribute to.
• Redesigned the file opening workflow
• Added drag and drop support for opening files
• Added support for changing file permissions, with the ability to undo changes
• Improved the umask calculator to calculate from umask, file, or directory permissions
• Improved accessibility throughout the app
• Improved input validation and editing behavior
• Updated translations

I am also working on writing libacl binding for vala so I can add ACLs support to Concessio later on, if you have experience with writing bindings and this project interests you, please reach out. Thanks!

Third Party Projects

Ronnie Nissan says

This week I also updated my other apps, Sitra and Embellish.

They both got the latest GNOME runtime 51, Embellish also was also updated to NerdFonts v3.5.1 which adds the messing Devicons that were promised in v3.5.0.

I would also like to announce that I am looking for a maintainer for Sitra, if anyone is interested in a Vala GTK4+Libadwaita program, please reach out, if I find you are willing to take care of the project, I will hand it over completely.

Tanay announces

Whisp V1.6.0 -Runtime Update and Fixes

New Features

• Note Statistics (::count): Type ::count anywhere in your note to instantly inspect word, character, and line count statistics.
• Asterisk Lists: Create and format bulleted lists using standard asterisks (*) alongside dash lists.
• Shortcut Recorder Improvements: Pressing Backspace inside the shortcut recorder now cleanly clears or disables assigned shortcuts.

Fixes & Maintenance

• List Toggling Refactor: Fixed Ctrl+S list item toggling to prevent multi-checkbox stacking and unintended line deletions.
• GNOME 51 Runtime: Updated Flatpak runtime to GNOME 51.
• Slate Mode Polish: Fixed update notification banner layout in Slate Mode.
• Compose Key Fix: Corrected key press handling for Compose Key combinations.
• Ubuntu Icon & D-Bus Fixes: Fixed missing application icon issues on Ubuntu desktop sessions.

Links : Download | Github | Website | Donate

Whisp Development is made possible by users like you, If Whisp brings you value do consider donating.

tfuxu announces

Flood It 3.0 released, finally bringing resizable game boards and toggable number indicators on colors.

Check it out on Flathub!

Titouan Real reports

Era 0.2.0 is out. Download Era from Flathub now and report any bugs you can find.

Era is a calendar app for mobile and desktop, designed to stay simple for everyday use while offering powerful tools when you need them. It syncs with most online calendar providers and works offline, too.

What’s new:

• Move events with drag and drop within the month view, or drag an event into another app to export or share it as an ICS file.
• Import external calendar events with high-performance parsing.
• If Era 0.1.0 felt slow, give 0.2.0 a spin! Major performance optimizations are live in this release, with even more speedups currently in development.

Era is also available on GNOME Nightly for the latest features, bug fixes, and performance improvements.

Anton Isaiev announces

RustConn is a connection manager for SSH, RDP, VNC, SPICE, Telnet, Serial, Kubernetes, Web, and Zero Trust, built with GTK4 and Libadwaita.

Version 0.23 is out, bringing major interface updates, workflow enhancements, and security hardening since 0.22:

User Interface & Experience:

• Rebuilt the main window layout around the GNOME HIG with separate sidebar and content pane header bars (matching Files and Settings).
• Protocol filters are now neatly folded behind a single Filter button.
• True fullscreen mode now hides both the header bar and tab bar for an unobstructed session view.
• Added keyboard passthrough to hand desktop shortcuts (such as Super and Alt+Tab) directly to embedded RDP and VNC sessions.

Connection & Session Management:

• Keystrokes can now be broadcast across groups of tabs, not just individual split panes.
• Any pane within a split can now be reconnected in place independently.
• External FreeRDP and VNC viewers can now be pinned on a per-connection basis.
• Zero Trust sessions with expired cloud logins now provide a one-click re-authentication flow (AWS, Google Cloud, Azure) directly within the tab.
• Added per-connection command macros triggered by keyboard shortcuts.
• Clusters can now automatically collect members matching a regular expression.
• Context menus now feature a dynamic Copy submenu showing only existing connection details, alongside an Edit Connection action.

Credentials & Protocols:

• Added a read-only mode and search-from-root toggle for secret backends (Bitwarden, 1Password, Passbolt, pass, KeePass), allowing vault discovery without granting write access.
• Added support for KeePass databases protected by YubiKey Challenge-Response slots, complete with interactive “touch your key” prompts.
• Connection editor can now auto-detect a host’s MAC address for Wake-on-LAN in one click.
• Added opt-in H.264 support for RDP via Cisco OpenH264.
• Added a dedicated KDC address field for Kerberos authentication on realmd/sssd environments.

Security Hardening:

• Multi-line terminal pastes now require confirmation via an interactive preview, preventing pastejacking attacks.
• Added route-change warnings: RustConn alerts before sending stored credentials if a connection’s host, port, account, or jump host changed since the last run.
• Hardened embedded RDP file downloads against hidden dotfiles (e.g., .bash_profile) and bidirectional-override character exploits in filenames.
• Centralized argument sanitization for FreeRDP launches to drop unauthorized parameters (e.g., /shell:, /proxy:) from imported profiles.

Plus numerous stability improvements and bug fixes.

Thanks to everyone who uses RustConn, reports bugs, contributes or supports the project - this cycle was driven largely by issues people filed. 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/

Rat Cornu announces

Ratic got a new version 0.4.4 this week, with two big changes!

First, the dynamic background (based on the current music cover image) does not mess with colors anymore. It is much cleaner and consistent thanks to the color thief algorithm.

Second, lyrics are now supported in ratic, both synced and unsynced! For synced lyrics, the current line is highlighted to follow your song, and you can click on the line you want to jump on to seek this particular position in the music.

You can check the new version 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! I never imagined that so many languages would be added to a small project like mine.

Shell Extensions

swink announces

Now Playing Card got several updates.

It adds an animated indicator to the top bar with a compact media card for any MPRIS player: cover art, a seekable progress bar and transport controls.

Recent updates (1.0.4–1.0.8) bring:

• a spectrum analyzer that moves with the sound itself
• a redesigned popup: one surface, rounded cover art, slimmer controls, and separate tiles when several players are running
• covers given as web addresses (e.g. Spotify) now load without an empty square while they download
• a right-click menu on the panel button to choose visibility and open settings
• click the speaker to mute, click again to restore the volume
• the card follows the shell theme’s text colour, so light themes on a dark system (and the reverse) look right

Source code is on GitHub.

GNOME Fellowship

Peter Eisenmann says

I posted my monthly GNOME Fellowship update for the “slow” month of September 🐢 https://blogs.gnome.org/p3732/fellowship-report-september-2026-moria/

Sophie (she/her) announces

CMYK support in glycin and more – all in my September report for my GNOME Fellowship.

Sovereign Tech Agency

Philipp Sauberzweig reports

I’ve blogged about another month of GNOME Design and Community Management as part of my Sovereign Tech Fellowship. I reflect on how the Fellowship has changed the conditions for my contributions, share updates on the GNOME Circle program, and show some exciting progress on standardising Scale Row and improving Calendar.

Check out the full blog post!

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 wanted to start this post with saying September was a bit of a slower month, as I was on vacation for a good chunk of it, but turns out that still quiet some things happened

Nautilus

The pathbar completion improvements I mentioned in the last post landed. Completions are now reused when in the same directory. On top of that, further suggestions are now directly shown when accepting a previous suggestion.

I also created a (somewhat hacky) solution to immediately start completing when navigating to the end of the entry, which did not land yet. I also finished the (initial) graphical app chooser changes, which now has a “Show All” tile. This needs design input, but testing turns out to be a bit tricky as the Flatpak version uses the app chooser portal. Meanwhile, the code cleanup part of the app chooser rework already landed after Khalid Abu Shawarib reviewed it. In general Khalid reviews most of my nautilus MR, which I am very thankful for.

Other than that I…

• Created an MR that adds support for the star column in Recent and Search and also allows hiding the column altogether.
• Fixed up a cleanup of the audio/video extension plugin, which drops custom content type lists and gives it a more generic name.
• Landed more code cleanups related to how file metadata is set.
• Made use of SPDX licence specifiers consistently across the whole project.
• Continued work on the xdg-user-dirs replacement MR.

Sushi

As sushi is (currently) only ever presented as a dialog to nautilus, it didn’t need an app icon in the past, but with modern app distribution approaches (it’s installable via Flathub) that no longer applies. I filed an app icon request some months ago, in which Jakub Steiner and I together now jammed up a shiny new icon:

 

My composition suggestion Jakub’s refined version

 

Sushi tries to show cover art when possible. This also included the capability to download cover art (something I fixed in July but seemingly forgot to mention). The downloaded covers were not stored in the file – a previewer shouldn’t modify files after all – so it was a rather obscure feature to have.

Fetching covers of course involved sending queries to other people’s computers, which might be unexpected default behavior, especially since html previews started asking for confirmation before fetching web content. Thus, Tau Gärtli and I agreed on removing this niche feature. As a replacement, I implemented something that seems more useful to me – support for cover art files that are in the same folder as the song, such as folder.jpg or cover.png.

Sometimes file previewing fails due to various reasons (missing codecs, corrupted file, …). Instead of the previous dedicated page, I adjusted sushi’s error handling so that basic file information is still shown, while the error is indicated by a banner:

Other small changes:

• I fixed a bug of my own creation that prevented some mouse interactions. The fix is included in the 51.1 release that landed on Flathub.
• Sushi now use the default .Devel developer version suffix
• Renderer loading times are limited now, preventing infinite load screens

gnome-autoar

Libarchive, the library used by gnome-autoar supports multi-threaded compression for some file types (7zip, xz, zstd), so I added an option to enable this in gnome-autoar. If all goes well nautilus will make use of this soon.

I also fixed a signal parameter bug that was blocking a gnome-shell MR. The cause was that gnome-autoar correctly emits its signals in the main thread, but didn’t wait for responses in the asynchronous thread that initiated the signaling. For simple fire-and-forget signals that wouldn’t be an issue, but not only do some of gnome-autoar’s signals have return values, there even is one particularly peculiar case of a signal with an out parameter – something I couldn’t find another example of in other projects.

I also created a handful of cleanup MRs, which bring the repository up to the standard of a modern (GObject-based) C project: a gobject-linter CI job, SPDX licence specifiers, G_LOG_DOMAIN usage, code cleanups and more.

Roadmap

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

Freed from his shackles, Autoar learns that they all along had the capability to do multiple things at the same time. With this, cleaning up the library is no problem and even the strangely wound looking glass on the signaling lookout gets fixed. Through it the group can be seen moving into the depths of the gnome caves. With them they carry rations in the form of paper scrolls, depicting such accurate portrays of sushi that fiction and reality is not distinguishable to mortal digestion systems.

Important note: All statements in this blog are fictional.

It has been another productive month working on GNOME Design and Community Management as part of my Sovereign Tech Fellowship, and I want to share some of the most interesting developments.

Introduction

I want to begin by highlighting how much the Sovereign Tech Fellowship has changed the conditions under which I contribute to GNOME. As a volunteer, I had to fit my contributions around my day job, working on GNOME in the evenings and during holidays. The Fellowship has enabled me to significantly expand the scope of my work. I can focus more on platform-level design and work on structural changes that make it easier for others to contribute. This type of work reaches many people, and it makes me feel particularly effective.

At the same time, working on GNOME is now my job, which allows me to maintain a much clearer separation between work and free time. I am really enjoying having more time for sports, and I have also started taking regular piano lessons again. I spent the last two weeks of August on holiday in nature and returned feeling refreshed and motivated.

Thank you very much to the Sovereign Tech Agency for this opportunity!

GNOME Circle

GNOME Circle is a certification for high-quality third-party apps that also serves as an educational program for app developers and designers. Unfortunately, GNOME Circle had to close applications in May because the small team of volunteer reviewers could not keep up with the large backlog of unreviewed apps.

Thankfully, several people responded to the call for reviewers, and Tobias recently introduced Sjoerd, Will, FineFindus and me to the review process. Sjoerd was able to start his first reviews of Concessio and Iconic immediately, drawing on the design experience he gained from receiving the Circle review of his app, Graphs. I also started reviewing two apps: Quadrapassel, a Tetris clone, and Mecalin, a keyboard typing lesson app. Quadrapassel is developed by Will, and my review aims to share some of my design experience before he starts reviewing submissions himself. FineFindus has started reviewing Field Monitor, and Tobias and I provided feedback on their review before it was posted publicly.

This represents a significant increase in our review capacity, and I am optimistic that we will soon complete the remaining reviews and then be able to reopen submissions. I would like to thank all previous and current Circle Committee members for setting up and contributing to this program, as well as for reviewing all the excellent GNOME Circle apps. If you want to get involved, reach out on the GNOME Circle Matrix channel.

Scale Row Standardization

Libadwaita provides several types of boxed-list rows for common use cases, such as text entries, password entries, switches, and dropdowns. However, it has so far been missing a row with a scale, which has led apps to implement custom widgets with inconsistent styling. Let’s change that.

I started the Scale Row design process by collecting screenshots of existing use cases and examples of state-of-the-art designs from other platforms. Looking at other platforms is always helpful, but I also needed to take into account the requirements of our design system and its technical capabilities. Because Scale Row will be based on Action Row, it needs to support a title, subtitle, prefix widgets, and suffix widgets. To make the layout work in narrow windows, it also became clear that the scale should be placed below the title. Several rounds of sketching, mockups, and discussion led to the following preliminary design.

Preliminary Scale Row design applied to common use cases

Originally, I intended to design only the row layout and use the scale as it was. However, aligning the start and end of the scale with the labels and icons required us to change the scale’s padding. That change has already landed in Libadwaita, and we decided to take the opportunity to review the scale’s style as well.

I found that the current style does not follow our design system’s 6-pixel grid, and that the knob is smaller than the minimum target size required by the WCAG accessibility guidelines. I therefore proposed several options inspired by other design systems. What we can adjust is largely restricted by what GtkScale technically supports, and I believe we may settle on the proposed pill-shaped style. The pill-shaped knob satisfies the WCAG requirements because a 24-pixel-diameter circle overlaid at the center of its bounding box does not intersect with adjacent targets, such as the scale’s trough. At the same time, the pill-shaped knob does not increase the scale’s height and therefore does not introduce additional whitespace into Scale Row.

While reviewing the scale style, I noticed that an issue filed in 2024 regarding the scale not aligning with the direction of swipes on touchpads had been resolved. Thanks to Carlos, the physical direction of touchpad gestures is now correctly forwarded in GTK, and GtkRange and GtkScale already follow it. This also means that other Libadwaita widgets with semantic motion, such as NavigationView, SplitView, and Carousel, can finally follow the physical swipe direction on touchpads, regardless of whether the user has selected natural or traditional scrolling in the system settings. Alice has already opened a merge request for this change. Ideally, this change should be coordinated with the shell so that gestures such as the three-finger swipe for switching workspaces or opening the overview also follow the physical swipe direction. We also discovered a bug that causes the knob to appear off-center. The bug has technically always been present, but it was less noticeable with the circular knob.

Technically, Scale Row will be based on Action Row. Alice therefore proposed implementing a generic bottom child that also supports other use cases involving widgets below a row header. I included examples such as toggle groups in narrow layouts and a participant list in a calendar event in the mockups to account for their requirements.

Examples of Action Row bottom child use cases

A New Era for Calendar(s)

Calendar is where I started contributing to GNOME, and I have spent a lot of time designing for it over the past years. The Fellowship enables me to expand my responsibilities to other apps and shift my focus towards platform-level topics. Nevertheless, designing for Calendar will remain important. From a design perspective, it is one of the most complex GNOME apps and uses many patterns that other apps need as well. This makes it an ideal place to develop design patterns and technical solutions that benefit the entire platform.

At the beginning of September, I finalized a new version of the mockup for Calendar’s top-level app structure, based on discussions I had at GUADEC. Since 2024, we have been discussing Calendar’s top-level structure to define a roadmap for developing a fully adaptive app that works equally well on mobile and desktop. This involves several significant changes, and we have not quite reached that goal yet.

I am therefore especially excited to see multiple contributors implementing parts of the design this month. Hari implemented the new layout, Markus resumed work on his merge requests for touchscreen support and the mobile month view, and Zelda is working on the adaptive event details dialog that will replace the event details popover on mobile. Thank you all!

GNOME Calendar’s week view using the new layout

Recently, the first beta version of Era was released after more than a year of development. Era is a third-party calendar app developed by Titouan in close collaboration with me. You can download Era from Flathub and please report any bugs you find.

Initially, I had some concerns about duplicated development efforts, especially because GNOME Calendar is currently a thriving project with many active and skilled contributors. However, the two projects differ in several important ways that justify developing them in parallel. So far, I believe they have benefited from each other.

One of the main differences is that Era already implements my latest designs including year, month, and agenda views adapted for mobile. These views are used for navigation themselves, rather than relying on separate navigation controls. On desktop you can use the small window side-by-side with other apps for multitasking or go fullscreen for complex planning.

Era’s main window showing the month view

Under the hood, Era is written in Rust and uses Clepsydre, an extensible and modular calendar backend. It currently integrates with Evolution Data Server, while an experimental peer-to-peer backend based on p2panda is also available in development builds. Work towards Android support is underway, and an APK is available through the CI pipeline.

Era’s event dialog showing an event with participants

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

September was the release month for GNOME 51. That doesn’t only mean a lot of releases but also the starting point for adding new features! My focus for this week was on adding CMYK support to glycin.

CMYK Support for Glycin

The CMYK color model is mainly used for printing, where CMYK (usually) represents cyan, magenta, yellow, and black ink. Working with CMYK is the standard in professional print. But why would glycin need support for it?

The first reason is proper handling of ICC profiles. Assume a JPEG or TIFF stores an image in CMYK. Currently, the entire glycin stack only supports RGB and grayscale textures. Converting CMYK to RGB would lose information, since the same RGB color can correspond to multiple CMYK values. Take, for example, CMY = 100%, which does represent a 100% black. This can also be represented by K = 100%. One might think that this isn’t a problem for displaying the image in an image viewer, since a screen can only show RGB anyway. But there is a catch: ICC profiles. ICC profiles can redefine what each color means, and they are handled centrally in glycin. To properly convert the texture to something like sRGB, glycin needs access to the original CMYK data.

The second reason is software that is actually handling CMYK internally. That’s what Inkscape does. Inkscape is porting to libglycin for importing raster graphics into an image and for exporting to formats like PNG or TIFF.

Properly supporting CMYK needed a bit more work than I expected. But the implementation is now pretty close to getting merged. Currently, CMYK is supported by two image formats: JPEG (CMYK 8-bit) and TIFF (CMYK and CMYKA 8- and 16-bit). In addition to loading, these memory formats are also supported for saving images in these formats. Only writing CMYKA 16-bit is not yet supported for TIFF. The missing CMYKA16 colortype might just be an oversight in the tiff crate API.

For existing users of glycin and libglycin, nothing will change. The default mode is that all CMYK images get converted to sRGB. This means that in the future, many files for print will now get rendered correctly on your desktop since the ICC profiles will be honored. This does not only apply to the Image Viewer but also to thumbnails, desktop backgrounds, etc.

Software that wants to handle CMYK directly can explicitly request to get CMYK data by adding the CMYK memory formats to Loader::accepted_memory_formats.

Other Work

The final comment period for the GNOME RFC process has begun. It has now been pushed back until October 14th. Ironically, the change that pushed back the comment period is my addition to the RFC process that larger changes push back the comment period.

Luckily, this month didn’t come with quite a mystery bug like last month. But there were a few surprising ones.

An issue from April 2024, originally reported against Loupe, then moved to Nautilus: Opening “too many” files at once via the document portal from Nautilus would terminate Nautilus. This was annoying me because I wanted to open a bunch of files in Amberol. The limit is very low on Debian with 16 files. Fedora’s limit is 253 files. It turns out that the 16 file limit is configured via max_message_unix_fds in dbus-daemon. Fedora uses dbus-broker instead, which hits the kernel’s SCM_MAX_FD. The mystery is solved, the issue is not. Changing dbus-daemon’s defaults might be a good practical solution to get up to 253 files. Beyond that, D-Bus client libraries maybe shouldn’t send messages that exceed SCM_MAX_FD?

Another interesting one was glycin failing on older kernel versions. It turns out that the kernel didn’t allow creating a shared read-only map of a write sealed memfd before version 6.7. Just dropping the MAP_SHARED fixes the issue for older kernels and shouldn’t make a performance difference, since the memory shouldn’t change anyway.

That’s all for this month. Talk to you after the spooky month!

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.