I've struggled with focus earlier this year. I felt pulled in all directions, overwhelmed by the world, and generally miserable. I decided to abstain from using social media for a week to see if anything would change.

The Joy of Missing Out was so strong that I ended up staying off social media for 3 whole weeks. I realized that engaging with social media harmed my mental health, and I could develop strategies to improve my relationship with it.

The social media I use

Text-based social media

I used Facebook in my youth but deleted my account about 10 years ago. Since then, I've been using text-based social media. I primarily browse Mastodon and Bluesky to know what people in my circles think about and to follow the news.

I tried actively using LinkedIn for a while but couldn't endure it. The feed is full of inauthentic posts, sales pitches, and outrageous takes to get engagement. LinkedIn is primarily a DM inbox for me now.

I abandoned the rest

I used to browse Reddit via the Apollo third-party client. In June 2023, Reddit decided to charge for its API, effectively making Apollo unusable since the developer couldn't afford the absurd amount of money they charged for it. Given the time and attention sink it had become for me, I decided use Apollo's decommissioning as an opportunity to quit Reddit.

I tried Instagram, but it just didn't stick. I've also explored Pixelfed to find inspiration from fellow photographers, but the behavior of its single maintainer didn't inspire confidence, so I left quickly.

TikTok, YouTube Shorts, and other short video platforms are the opposite of what I want. I need calm and room for nuance. I occasionally watch videos on YouTube but never follow the recommendations.

The impact social media has on me

I knew social media could influence people, but I thought I would notice if it dramatically changed how I feel, think, and behave. It turns out I was wrong. Social media changed me in several ways.

(In)tolerance to boredom

At the beginning of the experiment, I still had social media apps on my phone. The first thing I noticed was how often I grabbed my phone with my thumb hovering over the Mastodon app icon out of pure habit.

Forcing myself to stay off social media made me realize that the only moment I was left alone with my thoughts was in the shower. Even in bed, I frequently grabbed my phone to check something or see what was happening while I couldn't sleep. The anxiety-inducing nature of social media made it even more difficult to find sleep.

Sense of overwhelm / FOMO

When I grabbed my phone at night, when I browsed social media after a meeting, when I checked my feed after being focused on something else, I saw new posts.

I tried to curate my feed, but whatever I did, new content kept appearing. Always more posts crafted to get my attention. Always new things to care about. The world would never stop and constantly go in the wrong direction. It felt overwhelming.

Speed of thought

The influx of information in my feed was too massive for me to ingest, besides my family and work duties. I ended up skimming through the posts and articles they linked to instead of taking the time to read and understand them properly.

Skimming content didn't just make me lose information. It also made me mentally switch to a "high-speed mode," where I didn't take the time to think and do things properly. Once in this mode, I felt restless and rushed things. Focusing on anything was painful.

Big Bad World

I am not part of many minorities, but I care about making the world a better place for as many fellow humans as possible. I need to hear about other people's problems and consider them when elaborating solutions for my own issues. In other words, I care about the intersectionality of struggles.

To that effect, I subscribed to accounts reporting what their minority is struggling with, effectively building a depressing feed. Awareness of what others struggle with is essential, but being completely burned out by a constant flux of bad news is draining.

Punchline thinking

Mastodon's developers try not to make it a dopamine-driven social media. But the concept of short posts that people can boost and like is naturally dopamine-inducing. I had already noticed that I am prone to addictive behaviors and pay extra attention to that.

However, I hadn't noticed that whenever I wanted to talk publicly about a problem, I tried to find a punchline for it. I tried to find concise, impactful sentences to catch people's attention and craft a post that would make the rounds.

Writing longer-form posts on my blog forced me to consider the nuances, but I don't write a blog post for every single opinion I have. Thinking in punchlines made my thoughts more polarized, less nuanced, and, truth be told, more inflammatory.

What I changed

I embraced not knowing

I acknowledged that I don't need to know about things the moment they happen. I also realized that sometimes people will make an issue appear bigger than it is for the sake of engagement (even on the Fediverse).

My solution is to get my news from outlets I trust. These outlets will not only tell me about what happened but also about the consequences and what I can do about it. It helps combat the feeling of powerlessness in an unjust world.

I also subscribed to news via RSS. I am using miniflux as a minimal, cheap, and privacy respecting RSS service, and the ReadKit apps on macOS and iOS.

I added friction

Social media can take a significant toll on me, but it's not all negative. They have helped me meet excellent people, discover fantastic projects, and spread some of my ideas. I have not vanished from social media and will likely not.

But I added friction to make it more difficult for me to browse them compulsively. I removed their apps from my phone and logged out of their websites on my computer. If I want to browse social media, I must be in front of a computer and log in. This has to be intentional now, not just compulsive.

I monitor my screen time

When I wanted to lose weight, a very effective strategy has been to count calories. Knowing how many calories I burned when exercising and how many calories I absorbed when eating a cookie made the latter less appealing to me.

The same applies to screen time. Knowing how much time I spend in front of a website or app helps me realize that I need to give it less attention. Apple's Screen Time feature has helped me monitor my usage.

With all these changes, I feel much happier. I can focus on my work, read more books, and happily spend an hour or so every night reading documentation and working on pet projects.

15 Apr 2025 7:00am GMT

I'm currently serving as a member of the GNOME Foundation Board of Directors, and am also a member of the Foundation's Executive Committee. The last major GNOME Foundation update was back in October 2024, when we announced our budget for the current financial year, along with associated staffing changes. There have been some communications since then, particularly around events strategy and board membership changes, but it's been a while since we provided a more complete general update.

This update is intended to fill that gap, with a summary of the GNOME Foundation's activities over the past six months or so. You will hopefully see that, while the Foundation is currently operating under some challenging circumstances, we have been active in some significant areas, as well as keeping on top of essential tasks.

Board of Directors

The Board of Directors has been busy with its regular duties over the past six months. We continue to have regular monthly meetings, and have been dealing with high-level topics including ED hiring, finances, committee memberships, and more.

There have been a few membership changes on the board. We had an empty seat at the beginning of the board year, which we appointed Philip Chimento to fill. Philip is a previous board member with a lot of experience, and so was able to easily pick up the reins. We are very grateful to him for helping out.

In January, Michael Downey resigned from the board, and recently we filled his empty seat by appointing Cassidy Blaede. Members of the community will already be familiar with Cassidy's contributions, and I think we can all agree that he will be a fantastic director.

Both of these seats are due for re-election in the summer, so the appointments are relatively short-term.

Michael was previously serving as treasurer, a position which we have been unable to fill from the existing pool of directors. We are currently in the process of speaking to a couple of candidates who have expressed an interest in taking on the position.

Executive Director Hiring

Most readers will know that we lost our previous Executive Director, Holly Million, back in July 2024. We were extremely fortunate to be able to appoint Richard Littauer as interim ED shortly afterwards, who has did an incredible amount for the Foundation on a part time basis last year. Richard continues to serve as our official ED and has been extremely generous in continuing to provide assistance on a voluntary basis. However, since his availability is limited, finding a new permanent ED has been a major focus for us since Holly's resignation. We advertised for candidates back in September 2024, and since then the ED search committee has been busy reviewing and interviewing candidates. Thanks to this work, we hope to be able to announce a new Executive Director very shortly.

We are immensely grateful to the members of the ED search committee for their contributions: Deb Nicholson, Jonathan Blandford, Julian Sparber, Julian Hofer, Rob McQueen, and Rosanna Yuen. We also owe a huge debt of thanks to Richard.

Programs

"Programs" is the term that gets used for the impactful activities undertaking by non-profits (contrasted with activities like fundraising which are intended to support those programs). The GNOME Foundation has a number of these programs, some of which are established responsibilities, while others are fixed-term projects.

Sovereign Tech Fund

The Foundation has been hosting the ongoing Sovereign Tech Fund-ed development project which has been ongoing since 2023. The management of this work has been handled by the GNOME STF team, which has in recent times been managed by Tobias Bernard and Adrian Vovk. You can read their incredible report on this work, which was published only last week.

The Foundation's role for this project is primarily as a fiscal host, which means that we are responsible for processing invoices and associated administration. Thibault Martin was working for us as a contractor to do much of this work. However, with STF ramping down, Thibault has passed his responsibilities on to other staff members. Many thanks for your efforts, Thibault!

While most of the STF funded work has now concluded, there is a small amount of remaining funding that is being used to keep one or two developers working.

Alongside the existing STF-funded program, we have also been working on a hosting agreement for a new STF proposal, which is being worked on by Adrian Vovk. This agreement is almost complete and we hope to be able to provide more details soon.

GIMP

The GNOME Foundation is the fiscal host for the GIMP project and this entails regular work for us, mostly around finances and payments. Recently we have been helping out with a grant program that the GIMP project has set up, allowing the GIMP project to make better use of the funds that the Foundation holds for them.

Digital Wellbeing

We are currently about three-quarters of the way through a two year development project focused on digital wellbeing and parental controls. This program has been funded by Endless and is being led by Philip Withnall. We have also been lucky to have assistance on the design side from Sam Hewitt. The new digital wellbeing features that arrived in GNOME 48 were a significant milestone for this project.

The Exec Committee has recently been doing some development planning with Philip for the final phase of this work, which we hope to include in GNOME 49.

Flathub

Flathub continues to be a significant area of interest for the GNOME Foundation. We are currently contracting Bart Piotrowski as the main Flathub sysadmin, thanks to ongoing generous support from Endless. Bart continues to enhance Flathub's infrastructure as well as proving ongoing support for this hugely successful platform.

In December, we advertised for an additional short-term role to develop the Flathub organisation. Interviews for the role have been concluded and we have selected a candidate who will be starting work in the next few weeks, with the goal of getting the payments and fundraising systems online.

GNOME Project Support

General support for the GNOME project is a core part of the Foundation's role, and is something which occupies a lot of the Foundation's time. The activities in each of these areas deserve blog posts of their own, but here's a quick summary:

• Infrastructure. We continue to support GNOME's development infrastructure, primarily by paying for Bart's work in this area. Plenty has been happening behind the scenes to keep our development systems working well. We are grateful for the past and ongoing support of Red Hat including Andrea Veri's time and server hosting, as well as significant new support from AWS allowing us to move to a cloud-based infastructure.
• Travel. Unfortunately the budget for community travel has been limited this year due to the Foundation's overall financial situation, but we continue to provide some funding, and GNOME Foundation staff have been working with the travel committee as we approach GUADEC.
• Events. Foundation staff continue to support our events. In December we had a successful GNOME.Asia in Bengaluru, India. Linux App Summit is happening next week in Tiriana, Albania, and preparations for GUADEC 2025 are ongoing. We additionally held a short community consultation around our events strategy back in October, and this is something that the board has had discussions about subsequently.
• Communications. Finally, despite reduced headcount, we continue to devote some staff time to operating GNOME's social media accounts.

In addition to these ongoing areas of support, there have been additional one off support tasks which the Foundation has taken care of over the past six months. For example, we recently paid for the Google API keys used by Evolution Data Server to be certified.

Administration

Outside of programs, we have been busy with the usual background tasks that are necessary to keep the Foundation operating. That includes maintaining our books, filling in legal paperwork when it's needed, keeping the board updated about the organisation's finances, and talking to donors.

Conclusion

So much has been happening in the GNOME Foundation over the past six months, that it has been challenging to fit it all into a single post, and there are many items which I did not have the space to cover. Nevertheless, I hope that this summary provides a useful overview, and goes some way to showing how much has been going on behind the scenes. With no full-time ED and a reduced staff, it has been a challenging period for the Foundation. Nevertheless, I think we've managed to keep on top of our existing responsibilities and programs, and hopefully will have more capacity with the additional a new full-time Executive Director very soon.

It should be said that, since Richard reduced his hours at the end of 2024, much of the Foundation's "executive" work above has fallen to a combination of existing staff and the Executive Committee. It is a large burden for a small team, and I think that it's fair to say that the current setup is not easy to sustain, nor is it 100% reliable.

We are hopeful that appointing a new ED will help ease our resource pressures. However, we are also very interested in welcoming any additional volunteers who are willing to help. So, if participating in the kinds of activities that I've described appeals to you, please contact me. We can easily create new positions for those who think they might be able to have a role in the organisation, and would love to talk about what skills you might be able to bring.

14 Apr 2025 4:39pm GMT

This year I have again received a grant from the WMF to attend to the annual Wikimedia Hackathon, this year is in Istanbul. I'm very grateful to them.

Since 2024 I'm very interested in the Wikibase platform since we are using it at LaOficina and is a main topic for the DHwiki WG. I'm not going into details but, from the very beginning, my first thoughs of involvement in the hackathon are related with Wikibase. Specially the need of «productization» and reduce entry barriers for Wikibase adoption, at least in my personal experience. Lately I've been thinking in very specific goals I think could be done in the hackathon:

• T391815 Wikibase Request for Comment: essential minimalist ontology
• T391821 Wikibase Request for Comment: an inventory of Wikibase related artifacts
• T391826 Wikibase Request for Comment: Wikibase Suite full multimedia proof of concept configuration
• T391828 Wikibase Request for Comment: a method for portable wikibase gadgets

The point is, I can't do this alone. I have beend working on most of these things for months, but still are finished. Many different skills needed, lack of experience on some of them, etc.

So, the goal of this post is to call for action other attendants at the hackathon to join to work on them. The most relevant required skills (from my lack of skills point of view) are about MediaWiki integration, configuration and programming. For T391828, the most important is to be familiar with MediaWiki gadgets and for T391815, some practical experience in setting up ontologies in Wikibase.

All the practical results will be offered to the Wikibase developers for their consideration.

If you are interested please reach me in Telegram or at your preference. I also would love to set up a Wikibase zone in the hacking space for people working with Wikibase, with these or other tasks.

So, I'll see you soon in Istanbul o/

13 Apr 2025 10:00pm GMT

Hello, chat! I'm Revisto, and I want to share my journey to GNOME Circle and how I became a GNOME Foundation member. I'll discuss my experiences and the development path of Drum Machine. This is the first part of the "Journey to GNOME Circle" series.

I love Free and Open Source communities, especially GNOME and GNOME Circle. I find contributing to open source communities far more rewarding than contributing to projects maintained by a single individual. If you find the right community, there are many experienced, generous, and humble people you can learn from. You can explore various projects maintained by the community, experience consistent quality, be surrounded by an amazing community, and even enjoy some perks!

I found the GNOME community to be one of the best in the FOSS industry. Why?

• There are lots of apps and projects you can contribute to, from GTK to Terminal to GNOME Shell itself.
• It has a welcoming community full of experienced people.
• GNOME looks fantastic, thanks to Jakub Steiner. The GNOME design is stunning. It has great documentation and handbooks for beginners, making it super beginner-friendly.
• Different ways to contribute, you can help with documentation, programming, design, translation, create new apps, and more.
• Membership perks.

GNOME Foundation Membership?!

The GNOME Foundation offers membership to its active contributors. Whether you're an active translator, help with documentation, enhance GNOME's appearance, or generally MAKE GNOME BETTER, you can apply for membership. Additionally, if your app gets into GNOME Circle, you qualify for membership.

What are the perks?

Here are some of the perks in summary. You can find complete information here.

• Email Alias (nickname@gnome.org): gnome.org email addresses are provided for all Foundation members. This address is an alias which can be used as a relay for sending and receiving emails.
• Your own blog at blogs.gnome.org: Foundation members are eligible to host their blog on blogs.gnome.org.
• Listing on Planet GNOME: Foundation members who have blogs can have them included on planet.gnome.org.
• Travel sponsorship for events: Foundation members are eligible for travel sponsorship to GNOME conferences and events.
• Nextcloud (cloud.gnome.org): GNOME hosts a Nextcloud instance at cloud.gnome.org. This provides a range of services, including file hosting, calendaring, and contact management.

These are useful and beneficial for your reputation and branding. I use my email alias for GNOME-related work at AlirezaSh@gnome.org, and have my blog at alirezash.gnome.org, and sync my Obsidian notes with Nextcloud on GNOME infrastructure. Unfortunately, I couldn't get my travel sponsorship as a speaker at events because I'm from Iran, and due to OFAC regulations, which is so unfair.

What's GNOME Circle?

I've always had the idea of creating beautiful, useful apps for Linux. There were many apps I needed but couldn't find a good version for Linux, and some apps I wished had better GUIs.

GNOME Circle is a collection of applications and libraries that extend the GNOME ecosystem.

"GNOME Circle champions the great software that is available for the GNOME platform. Not only do we showcase the best apps and libraries for GNOME, but we also support independent developers who are using GNOME technologies."
- GNOME Circle

In GNOME, we have core apps like Terminal, GNOME Shell, Text Editor, etc., and we have GNOME Circle apps. These are apps that independent developers have created using GNOME technologies (GTK and Libadwaita), following the GNOME Human Interface Guidelines, and meeting the app criteria. Once accepted, these apps become part of GNOME Circle.

GNOME Circle has lots of really cool apps that you should check out. It includes Curtail, an application to compress your images; Ear Tag, an audio file tags editor; Chess Clock, which provides time control for over-the-board chess games.

GNOME Circle is really cool, full of beautiful apps and creative developers.

Insert image of fun little stuff that looks like ideas here.

App Idea?

If GNOME Circle sounds interesting to you, or you like GNOME Foundation membership perks, or you appreciate the open-source community, or you want to create an app that fulfills your own needs, you should have an idea. What app do you want to develop? I believe we all have ideas. Personally, I really want a good VPN client for Linux (because of censorship in Iran, it's vital), or a good-looking, user-friendly download manager, among other apps.

I highly recommend you check out other applications on GNOME Circle. There are lots of creative projects there that can inspire you. Some of my favorites:

• Wike: Search and read Wikipedia articles.
• Komikku: Discover and read manga & comics.
• Fretboard: Look up guitar chords.
• Ear Tag: Edit audio file tags.

I think it's a good idea to check if your idea has already been implemented. You can check the apps in GNOME Circle and also check the apps that are being reviewed by the GNOME Circle Committee to become part of the circle soon: GNOME Circle Issues.

Although you can submit a new app with a similar idea to an existing app, I believe it would be better to bring new ideas to the circle or even contribute to existing circle apps that align with your idea.

On a side note, I really enjoy reading other people's app requests and discussions here. I've been reading them to familiarize myself with the application acceptance process and understand the possible reasons an app might get rejected.

Insert image of an online drum machine here.

Since I'm a music producer (listen to my work here), I really like the idea of making music production in Linux easier. I had music-related ideas for my first app in the Circle: synthesizers, drum machines, and eventually a DAW (Digital Audio Workstation). I started simple and went with Drum Machine. I looked at different online drum machines, such as drumbit.app and onemotion.com/drum-machine, then I started thinking about how I wanted my own drum machine to look like and I drew this (I know it doesn't look good; I'm bad at drawing >-<).

Now I had motivation, an idea, and wanted to actually start making.
I'll detail the development process and evolution of Drum Machine in the next post, so stay tuned!

You can find me here:

• Mastodon: @revisto@mastodon.social
• Blog: blogs.gnome.org/AlirezaSh
• GitHub: github.com/revisto
• LinkedIn: linkedin.com/in/revisto
• Telegram (Personal): t.me/revisto
• Telegram (Tech Channel in Farsi): t.me/revistoTech

Thanks for reading!

13 Apr 2025 3:16pm GMT

The 2023/2024 GNOME STF project is mostly wrapped up now, so it's a good moment to look back at what was done as part of the project, and what's next for the projects we worked on.

As a brief refresher, STF (Sovereign Tech Fund, recently renamed to Sovereign Tech Agency) is a program by the German Government to support critical public interest software infrastructure. Sonny Piers and I applied with a proposal to improve important, underfunded areas of GNOME and the free desktop and got an investment of 1 Million Euro for 2023/2024.

While we've reported individual parts of what we were able to achieve thanks to this investment elsewhere, it felt important to have a somewhat comprehensive post with all of it in one place. Everyone on the team contributed summaries of their work to help put this together, with final editing by Adrian Vovk and myself.

Table of contents:

• Accessibility
  • Newton
  • Orca
  • WebkitGTK
  • Spiel
• Platform
  • Libadwaita
  • GTK CSS
  • Notification API
  • Notifications in GNOME Shell
  • Global Shortcuts
  • XDG Desktop Portal
  • Flatpak and Sandboxing
  • Nautilus File Chooser Portal
  • GNOME Online Accounts
  • Language Bindings
  • GLib
• QA, Developer Tools, and GNOME OS
  • Transition to Sysupdate
  • Immutable OS Tooling
  • Security Tracking
  • GNOME OS Installer
  • Buildstream
  • OpenQA
• Security
  • Home Directory Encryption
  • GNOME Keyring
  • Key Rack
  • Glycin
  • Bluetooth
  • Bug Bounty Program
• Hardware Support
  • Mutter and GNOME Shell
  • Variable Refresh Rate
  • GNOME Shell Performance
• Design Support
• Planning, Coordination & Reporting
• What's Next

Accessibility

Accessibility is an incredibly important part of the GNOME project, community, and platform, but unfourtunately it has historically been underfunded and undermaintained. This is why we chose to make accessibility one of the primary focus areas for the STF project.

Newton

The Assistive Technology Service Provider Interface (AT-SPI) is the current accessibility API for the Linux desktop. It was designed and developed in the early 2000s, under the leadership of Sun Microsystems. Twenty years later, we are feeling its limitations. It's slow, requiring an IPC round trip for each query a screen reader may want to make about the contents of an app. It predates our modern desktop security technologies, like Wayland and Flatpak, so it's unaware of and sometimes incompatible with sandboxing. In short: it's a product of its time.

The STF project was a good opportunity to start work on a replacement, so we contracted Matt Campbell to make a prototype. The result was Newton, an experimental replacement for the Linux desktop accessibility stack. Newton uses a fundamentally different architecture from AT-SPI, where apps push their accessibility information to the screen reader. This makes Newton significantly more efficient than AT-SPI, and also makes it fully compatible with Wayland and the Flatpak sandbox.

The prototype required work all across the stack, including GTK, Mutter, Orca, and all the plumbing connecting these components. Apps use a new Wayland protocol to send accessibility info to Mutter, which ensures that the accessibility state an app reports is always synchronized with the app's current visual state. Meanwhile, the prototype has Orca communicate with Mutter via a new D-Bus Protocol.

This D-Bus protocol also includes a solution for one of the major blockers for accessibility on Wayland. Due to Wayland's anti-keylogging design, Orca is unable to intercept certain keys used to control the screen reader, like Insert or Caps Lock. The protocol gives this intercept functionality to screen readers on Wayland. Recently, RedHat's Lukáš Tyrychtr has adapted this part of Matt's work into a standalone patch, which landed in GNOME 48.

As part of this work, Matt added AccessKit support to GTK. This library acts as an abstraction layer over various OS-specific accessibility APIs, and Matt's experimental fork included support for the Newton Wayland protocol. As a side effect, GTK accessibility now works on Windows and macOS! Matt's original patch was rebased and merged by Matthias Clasen, and recently it was released in GTK 4.18.

Finally, to test and demonstrate this new accessibility stack, Matt integrated all his changes into a fork of GNOME OS and the GNOME Flatpak Platform.

For more details about Newton's design and implementation, including a demo video of Newton in action, you can read Matt's announcement blog post, and his subsequent update.

Orca

The STF project allowed Igalia's Joanmarie Diggs to rewrite and modernize much of Orca, our screen reader. Between November 2023 and December 2024 there were over 800 commits, with 33711 insertions and 34806 deletions. The changes include significant refactoring to make Orca more reliable and performant as well as easier to maintain and debug. Orca is also used on other desktop environments, like KDE, so this work benefits accessibility on the Linux desktop as a whole.

Orca now no longer depends on the deprecated pyatspi library, and has switched to using AT-SPI directly via GObject Introspection. As part of this replacement, a layer of abstraction was added to centralize any low-level accessibility-API calls. This will make it significantly easier to port Orca to new platform accessibility APIs (like Newton) when the time comes.

Over the years, Orca has added many workarounds for bugs in apps or toolkits, to ensure that users are able to access the apps they need. However, enough of these workarounds accumulated to impact Orca's performance and reliability. The STF project allowed the majority of these workarounds to be investigated and, where possible, removed. In cases where workarounds were still necessary, bugs were filed against the app or toolkit, and the workaround was documented in Orca's code for eventual removal.

There is arguably no single "correct" order or number of accessibility events, but both order and number can impact Orca's presentation and performance. Therefore, Orca's event scheduling was reworked to ensure that events are recieved in a consistent order regardless of the source. Orca's event-flood detection was also completely reworked, so that apps can no longer freeze Orca by flooding it with events.

A lot of work went into increasing Orca's code quality. A couple of tightly-entangled systems were disentangled, making Orca a lot more modular. Some overly complicated systems were refactored to simplify them. Utility code that was unnecessarily grouped together got split up. Linter warnings were addressed and the code style was modernized. Overall, Orca's sources are now a lot easier to read through and reason about, debug, analyze, and maintain.

Finally, building apps that are compatible with screen readers is occasionally challenging. Screen readers have complicated rules about what they present and when they present it, so sometimes app developers are unsure of what they need to do to make Orca present their app correctly. To improve the developer experience around building accessible apps, there's now a new guide with tips and techniques to use. This guide is very much a work in progress, and additional content is planned.

WebKitGTK

WebKitGTK is GNOME's default web rendering engine. GTK4 significantly reworked the accessibility API for GTK widgets, so when WebKitGTK was first ported to GTK4, a major missing feature was the accessibility of web pages. The screen reader was simply unable to see web content visible on screen. As part of the STF project, Igalia's Georges Basile Stavracas Neto added support for GTK4's new accessibility APIs to WebKitGTK. This landed in WebKitGTK 2.44, the first stable release with GTK4 support.

Around the same time, Joanmarie removed Orca's custom WebKitGTK handling in favor of the generic "web" support, which aligns WebKitGTK's user experience with Firefox and Chromium. This gives Orca users an additional choice when it comes to web browsing. Please note that there are still a couple of accessibility bugs that must be fixed before Orca users can enjoy the full benefits of this change.

The last hurdle to fully functional accessibility in WebKitGTK was Flatpak. Web browsers are generally hard to make work in Flatpak, due to the interaction between Flatpak's sandbox and the browser's own sandboxing features, which are usually either turned off, weakened, or replaced downstream. WebKitGTK, however, has strong support for sandboxing in Flatpak, and it actually uses Flatpak's native subsandboxing support directly. Unfourtunately, the way the sandboxes interacted prevented WebKitGTK from exporting its accessibility information to the system. Georges takes a deep dive into the specifics in his GUADEC 2024 talk.

Since that talk, Georges added features to Flatpak (and a follow-up) that made WebKitGTK work with the screen reader. This makes GNOME Web the first web browser that is both fully accessible and fully Flatpak sandboxed!

Spiel

Text-to-speech (TTS) on Linux is currently handled by a service called SpeechDispatcher. SpeechDispatcher was primarily built for use in screen readers, like Orca. Thus, TTS on Linux has generally been limited to accessibility use cases. SpeechDispatcher is modular, and allows the user to replace the speech synthesizer (which defaults to the robotic-sounding eSpeak) with something that sounds more natural. However, this configuration is done via text files, and can thus be nontrivial to get right, especially if the user wishes to integrate a proprietary synthesizer they might have paid money for.

Eitan Isaacson ran up against these limitations when he was implementing the Web Speech API into Firefox. So, he created Spiel, a new TTS framework for the Linux desktop. Spiel is, at its core, a D-Bus protocol that apps and speech synthesizers can use to communicate. Spiel also has a client library that closely emulates the Web Speech API, which makes it easy for apps to make use of TTS. Finally, Spiel is a distribution system for voices, based on Flatpak. This part of Spiel is still in the early stages. You can learn more about Spiel via Eitan's GUADEC 2024 Talk.

As part of the STF project, Andy Holmes and Eitan implemented an initial working implementation of Spiel in Orca, demonstrating its viability for screen readers. This helped stabalize Spiel, and encouraged engagement with the project. The Spiel client and server libraries were also hardened with sanitizer and static analysis testing.

Platform

The GNOME Platform consists of the libraries, system and session services, and standards provided by GNOME and Freedesktop. In short, this is the overarching API surface that we expose to app developers so that they can write GNOME apps. Clearly, that's very important and so we focused much of the STF's funding there. In no particular order, here's some of the work that the STF made possible.

Libadwaita

Starting with GTK4, we've decoupled GTK from GNOME's design guidelines. This means that GTK4 no longer includes GNOME's style sheet, or GNOME-specific widgets. This has many benefits: first and foremost, this makes GTK4 a much more generic UI toolkit, and thus more suitible for use in other desktop environments. Second, it gives GNOME the flexibility to iterate on our design and UI without interfering with other projects, and on a faster timescale. This leads to "platform libraries", which extend GTK4's basic widgetry with desktop-specific functionality and styles. Of course GNOME has a platform library, but so do other platforms like elementary OS.

Adwaita is GNOME's design language, and so GNOME's platform library is called libadwaita. Libadwaita provides GNOME's style sheet, as well as widgets that implement many parts of the GNOME Human Interface Guidelines, including the machinery necessary to build adaptive GNOME apps that can work on mobile phones.

The STF project allowed libadwaita's maintainer, Alice Mikhaylenko, to close a few long-standing gaps as well as finish a number of stalled projects.

Bottom Sheets

Libadwaita now provides a new bottom sheet widget, which provides a sheet that slides up from below and can be swiped back down off screen. Optionally, bottom sheets can have a bottom bar that's visible when the sheet is collapsed, and which morphs into the sheet whenever the user activates it. This pattern is common with many apps that wish to show some short status on a main page, but a detailed view if the user wants one. For example: music player apps tend to use this kind of pattern for their "now playing" screens.

This shipped in libadwaita 1.6, and apps like Shortwave (shown above) are already using it.

Adaptive Dialogs

Traditionally, in GNOME dialogs were just separate child windows of the app's main window. This made it difficult, sometimes, to create dialogs and popups that behave correctly on small windows and on mobile devices. Now, libadwaita handles dialogs completely within the app's main window, which lets them adapt between floating centered pop-ups on desktop, and bottom sheets on mobile. Libadwaita's new dialogs also correctly manage the appearance of their own close button, so that users have the ability to exit out of dialogs even on mobile devices where windows don't normally have a close button.

This shipped in libadwaita 1.5 and many apps across GNOME have already been updated to use the new dialogs.

Multi-Layout View

Libadwaita already provides a system of breakpoints, where widget properties are automatically updated depending on the size of the app's window. However, it was non-trivial to use breakpoints to swap between different layouts, such as a sidebar on desktop and a bottom bar on mobile. The new multi-layout view allows you to define the different layouts an app can use, and control the active layout using breakpoints.

Work on multi-layout views started before the STF project, but it was stalled. The STF project allowed it to be completed, and the feature has shipped in libadwaita 1.6.

Wrap Box

Libadwaita now provides a new wrap box widget, which wraps its children similarly to how lines are wrapped in a text paragraph. This allows us to implement various layouts that we've wanted to, like the list of search filters in this mockup, or toolbars that wrap onto multiple lines when there's not enough room.

Like the multi-layout view, this work was stalled until the STF project. The feature shipped in the recent libadwaita 1.7 release.

Toggle Groups

Libadwata also now provides a new toggle group widget, which is a group of buttons where only one at a time can be selected. This pattern is pretty common in GNOME apps, and usually this was implemented manually which was awkward and didn't look great. The new widget is a big improvement.

Toggle groups were originally implemented by Maximiliano Sandoval, but the work was stalled. The STF project allowed Alice to bring this work over the finish line. The feature is part of libadwaita 1.7.

GTK CSS

GTK uses a custom version of CSS to style its widgets, with extensions for defining and transforming colors. These extensions were limited in various ways: for instance, the defined colors were global for the entire stylesheet, but it would be very convenient to have them per-widget instead. The color functions only worked in sRGB, which isn't the optimal colorspace for some kinds of calculations.

Thanks to work by Alice Mikhaylenko and the rest of the GTK team, GTK now has support for the standard CSS variables, color mixing, and relative colors, with a variety of color spaces. The old extensions have been deprecated. This work has already shipped in GTK 4.16, and many apps and libraries (including libadwaita as of 1.6), are making extensive use of it.

This work gets us one step closer to our long-term goal of dropping SCSS in the future, which will simplify the development and distribution process for the GNOME stylesheet.

Notification API

Notifications are a critical component of any modern computing experience; they're essential for keeping users informed and ensuring that they can react quickly to messages or events.

The original Freedesktop Notification Standard used on the Linux desktop saw almost no significant changes in the past decade, so it was missing many modern features that users have grown to know and expect from other platforms. There were thus various DE-specific extensions and workarounds, which made it difficult for app developers to expect a consistent feature set and behavior. Even within GNOME, there were technically three different supported notification APIs that apps could use, each of which had a different subset of features. Thanks to STF funding, Julian Sparber was able to spend the time necessary to finally untangle some of the difficult issues in this area.

After evaluating different directions, a path forward was identified. The two main criteria were to not break existing apps, and to reuse one of the existing APIs. We decided to extend Flatpak's notification portal API. The new additions include some of the most essential and highly visible features we're currently missing, like playing a notification sound, markup styling, and more granular control of notification visibility.

The visibility control is especially impactful because it allows apps to send less intrusive notifications and it improves user privacy. On the other hand, one mostly invisible feature to users was the inclusion of the XDG Activation protocol in the new spec, which allows apps to grab focus after a user interacts with a notification. The updated protocol is already released and documented. You can find the list of changes at the pull request that introduced the v2 notifications portal.

While there is still some technical debt remaining in this area, the STF funding allowed us to get to a more sustainable place and lay the groundwork for future extensions to the standard. There is already a list of planned features for a version 3 of the notification portal.

You can read more about this initiative in Julian's blog post on the GNOME Shell blog.

Notifications in GNOME Shell

GNOME Shell provides the core user interface for the GNOME desktop, which includes notification banners, the notification list, and the lock screen. As part of the STF project, Julian Sparber worked on refactoring and improving this part of the GNOME Shell code base, in order to make it more feasible to extend it and support new features. Specifically, this allows us to implement the UI for the v2 notifications API:

• Notifications are now tracked per-app. We now show which app sent each notification, and this also lays the technical ground work for grouping notifications by app.
• Allowing notifications to be expanded to show the full content and buttons
• Keeping all notifications until you dismiss them, rather than only keeping the 3 most recent ones
• Grouping notifications by app

Julian was also able to clean up a bunch of legacy code, like GNOME Shell's integration with telepathy.

Most of these changes landed in GNOME 46. Grouping landed in GNOME 48. For more detail, see Julian's blog post.

Global Shorcuts

The global shortcuts portal allows apps to request permission to recieve certain key bindings, regardless of whether the app is currently focused. Without this portal, use cases like push-to-talk in voice chat apps are not possible due to Wayland's anti-keylogging design.

RedHat's Allan Day created designs for this portal a while back, which we aimed to implement as part of the STF project.

Dorota Czaplejewicz spearheaded the effort to implement the global shortcuts portal across GNOME. She started the work for this in various components all over the stack, e.g. integration into the Settings UI, the compositor backend API, the GNOME portal, and the various portal client libraries (libportal and ashpd). This work has since been picked up and finalized by Carlos Garnacho and others, and landed in GNOME 48.

XDG Desktop Portals

Portals are cross-desktop system APIs that give sandboxed apps a way to securely access system resources such as files, devices like cameras, and more.

The STF project allowed Georges Stavracas to create a new dedicated documentation website for portals, which will make it easier for apps to understand and adopt these APIs. This documentation also makes it easier for desktop environment developers to implement the backend of these APIs, so that apps have complete functionality on these desktops.

Georges and Hubert Figuiere added a new portal for USB devices, and many parts of the platform are being updated to support it. This portal allows apps to list USB devices, and then request access without opening security holes.

The document portal saw some fixes for various issues, and the file transfer portal now supports directories. The settings portal was extended to advertise a new cross-desktop high contrast setting.

Hubert also worked to improve libportal, the convenience library that wraps the portal API for apps to easily consume. It now supports the settings portal, for apps to conveniently recieve light/dark mode, system accent color, and high contrast mode settings. He also fixed various bugs and memory leaks.

WebKitGTK is GNOME's default web engine, for rendering web content in apps. It supports modern web standards, and is used in GNOME Web, our default browser. Georges adjusted WebKitGTK to make use of portals for printing and location services. New features were added to all parts of the stack to enable this. This makes WebKitGTK and every app that uses it more secure.

Flatpak and Sandboxing

Flatpak is the standard cross-distribution app packaging format, and it also provides security through sandboxing. It's split into a few smaller sub-projects: the Flatpak core which implements the majority of Flatpak's functionality, the xdg-dbus-proxy which filters D-Bus traffic to enforce which services sandboxed apps can talk to, and flatpak-builder which app developers can use to build Flatpak packages conveniently.

As part of the STF project, Hubert worked on improving the maintenance situation for the Flatpak core, and fixed various bugs and memory leaks. Hubert and Georges also implemented the necessary groundwork in Flatpak's sandboxing for the new USB portal to function.

In flatpak-builder, Hubert implemented the long-awaited feature to rename MIME files and icons, which simplifies packaging of desktop applications. He also performed some general maintenance, including various minor bug fixes.

The XDG D-Bus Proxy previously relied on some very specific implementation details of the various D-Bus client libraries, such as GLib's gdbus and zbus. This broke when zbus changed its implementation. Thanks to work by Sophie Herold, xdg-dbus-proxy was updated to stop relying on this undefined behavior, which means that all client libraries should now work without problems.

Nautilus File Chooser Portal

The file chooser portal is used by apps to bring up a sandbox-aware file picker provided by the system. It acts as an invisible permission check for Flatpak apps. This portal powers the "Open" or "Save As" actions in apps.

Previously, GNOME's implementation of xdg-desktop-portals used GTK's built-in file chooser dialog widget. This, however, caused some problems. Since the dialog's implementation lived in GTK, and GTK is a dependency of libadwaita, it couldn't use any of libadwaita's functionality to avoid circular dependencies. This meant that the dialog couldn't be made to work on mobile, and didn't look in line with modern GNOME apps. The behavior of the file chooser was similar to Natuilus, our file manager app, but not identical. This would cause confusion among users. It took lots of work to keep both projects at least somewhat in line, and even then it wasn't perfect. The file chooser couldn't benefit from recent performance improvements in Nautilus, and it was missing some of Nautilus's features. For example, the file chooser couldn't generate thumbnails and did not support multiple zoom levels.

António Fernandes extended Nautilus with a new implementation for the file chooser portal (with the help of Corey Berla and Khalid Abu Shawarib doing reviews and fixups). Nautilus can now behave like an open or save file picker dialog, handling all the edge cases this entails. This required a surprising amount of work. For example, Mutter needed improvements to handle attaching Nautilus as a modal dialog, Natuilus itself needed several refactors to support different views (saving files, opening files, normal file browser), the initial portal implementation needed to be reworked to avoid breaking dark mode, and there were several iterations on the design to deal with UX edge cases.

All of this work landed in GNOME 47.

GNOME Online Accounts

GNOME Online Accounts (GOA) is GNOME's single sign-on framework, providing a way for users to setup online accounts to be used across the desktop and preinstalled apps. Since there was no fixed maintainer in recent years, the project fell behind in maintenance, relied on old libraries, used old tooling for tests, and was missing support for open protocols like WebDAV (including CalDAV and CardDAV). Andy Holmes took over maintenance thanks to the STF project, and put it on more stable footing.

GOA used to only have limited WebDAV support as part of its Nextcloud integration. Andy separated the WebDAV support into a standalone integration, which allows users to integrate with more open-source-friendly providers, like Fastmail. This integration was also tested with well-known self-hosted servers.

GOA previously relied on its own webview for Oauth2 login, for providers like Google. Andy replaced this with a secure exchange using the default web browser. This also allowed Andy to upgrade GOA to GTK4 (with reviews by Philp Withnall) and remove the last GTK3 dependency from GNOME Settings. As part of this rework, the backend API was refactored to be fully asynchronous.

Finally, Andy updated GOA's test infrastructure, to use modern static analyzers and better CI tests.

Language Bindings

GLib is GNOME's foundational C library, and includes many common-sense utilities that the C standard library lacks. It also provides a layer of platform-agnostic functionality, which means that C programs targeting GLib are easier to port to other operating systems like Windows. For instance, GLib.DateTime is a set of utilities for getting the current time (which is OS-specific), doing complex math with time, and formatting timestamps for human-readable display.

GObject introspection is GNOME's language binding infrastructure. It allows libraries that are written in C (and, lately, Rust) to be used from other languages, including Rust, Python, JavaScript, Swift, and more! It consists of a set of coding style conventions, annotations (that appear as code comments on functions), an object-oriented type system called GObject, a tool that extracts all of this information into .gir files, a library to parse the these files, and per-language infrastructure to consume this parsed data into the language's type system. This infrastructure enables language bindings to be relatively easy to make and maintain, which in turn enables GNOME's large ecosystem of apps written in a diverse set of languages.

GLib and GObject introspection are tightly coupled projects. GLib defines the type system (including GObject, and the lower-level concepts underneath it), and GObject introspection heavily relies on these types. Conversely, GLib itself is accessible from language bindings, which means that GLib depends on GObject introspection. This complicated dependency situation makes it rather difficult to iterate on our language bindings, and was quite messy to maintain.

As part of the STF project, Philip Withnall started work on merging GObject introspection into GLib. Having them in the same repository means that developing them together is easier, because it can avoid dependency cycles. So far, he was able to move libgirepository, which is a large part of GObject introspection. In practice, this has allowed us to generate the .gir files for GLib as part of its build process, rather than generating them externally.

Building on this work, Evan Welsh was able to start making improvements to our language bindings. Evan added support for annotating async functions (based on work by Veena Nager), so that GObject introspection doesn't need to use heuristics to guess which APIs are async. This allows language bindings to better integrate GNOME's async APIs with the language's native async/await syntax.

Evan's work on async function calls required work across the entire language binding stack, including some more merging of GObject introspection into GLib. Most notably, these new features required new test cases, which meant that GLib's CI needed to use the bleeding-edge version of GObject introspection, which was rather difficult due to the entangled dependencies between the two projects. Evan made these necessary changes, so now it is more feasible to extend the functionality of our language bindings.

Evan then went on to integrate this work across the rest of the stack. In Meson, there's a pending pull request to transition from the old GObject introspection tools to the new GLib tools. In GNOME's JavaScript bindings, Philip started integrating the GLib version of libgirepository, and Evan has since continued this work.

Evan also did some work in GTK to fix an issue that previously skipped some accessibility APIs when generating language bindings. This made it possible for apps written in languages other than C to better communicate their structure to the screen reader, improving the accessibility of those apps.

Finally, Evan worked on advancing GNOME's TypeScript bindings by merging gi.ts and ts-for-gir into a single toolchain which can fully cover GNOME's stack and have accurate enough types to work with existing JavaScript codebases. This was possible thanks to help by Pascal Garber, the maintainer of ts-for-gir. This will enable GNOME's many apps implemented in JavaScript to be ported to TypeScript, allowing for static analysis and increasing code quality. For instance, GNOME Weather was recently ported to TypeScript.

GLib

After merging libgirepository into GLib, Philip was able to port GLib away from gtk-doc and to gi-docgen, GNOME's modern API documentation generator. This brought a much faster build time for documentation, and makes the docs much more useful for users of language bindings. As part of this transition, someone has to go through API-by-API and port all of the documentation to the new gi-docgen syntax. As part of the STF project, Philip was able to port all section introductions and some API documentation comments, but there's a huge number of APIs so more work is still required. As documentation is ported, various improvements can be made to documentation quality.

The STF project also allowed Philip to focus on various ongoing maintenance tasks for GLib, with prominent examples including:

• Reviewed and landed integration with the CHERI processor, which is an new architecture with increased memory security compared to traditional x86/ARM architectures. Having GLib running on it is an important step to bootstrapping an OS. This is the kind of work which wouldn't get reviewed without maintenance funding for GLib, yet is important for the wider ecosystem.
• An important security bugfix for xdgmime, a core component of most desktop environments.
• A security bugfix for gdbus, GLib's D-Bus client library, which is used by the entire GNOME stack.
• Reviewed a race-condition bugfix for GObject's reference counting. This bug caused hard-to-debug crashes and freezes.
• Reviewed some GObject performance improvements

QA, Developer Tools, and GNOME OS

Many issues in our development process come from the fact that there's not enough end-to-end testing with the entire stack. This was the initial motivativation for the GNOME Continuous project, which eventually became GNOME OS as we know it today. GNOME OS powers our automated QA process, and allows some limited direct testing of new GNOME features in virtual machines.

However, GNOME OS has a lot more potential beyond that as a QA and development tool. It's 90% of the way there to being a usable OS for GNOME developers to daily drive and dogfood the latest GNOME features. This is sometimes the only way to catch bugs, especailly those relating to hardware, input, and similar situations that a VM can't emulate. Also, since it's a platform we control, we saw the opportunity to integrate some quality-of-life improvements for GNOME developers deep into the OS.

Transition to Sysupdate

Switching GNOME OS away from ostree and to systemd-sysupdate opened the doors to more complete integration with all of systemd's existing and future development tools, like systemd-sysext. It also enabled us to build security features into GNOME OS, like disk encryption and UEFI secure boot, which made it suitable for daily-driver use by our developers.

This work started before the STF's investment. Valentin David and the rest of the GNOME OS team had already created an experimental build of GNOME OS that replaced ostree with systemd-sysupdate. It coexisted with the official recommended ostree edition. At roughly the same time, Adrian Vovk was making a similar transition in his own carbonOS, when he discovered that systemd-sysupdate doesn't have an easy way to integrate with GNOME. So, he made a patch for systemd that introduces a D-Bus service that GNOME can use to control systemd-sysupdate.

As part of the STF project, these transitions were completed. Codethink's Tom Coldrick (with help from Jerry Wu and Abderrahim Kitouni) rebased Adrian's D-Bus service patch, and it got merged into systemd. Jerry Wu and Adrien Plazas also integrated this new service into GNOME Software.

Adrian continued improving sysupdate itself: he added support for "optional features", which allow parts of the OS to be enabled or disabled by the system administrator. This is most useful for optionally distributing debugging or development tools or extra drivers like the propriertary NVIDIA graphics driver in GNOME OS.

GNOME OS also needed the ability to push updates to different branches simultaneously. For instance, we'd like to have a stable GNOME 48 branch that recieves security updates, while our GNOME Nightly branch contains new unfinished GNOME features. To achieve this, Adrian started implementing "update streams" in systemd-sysupdate, which are currently pending review upstream.

Codethink wrote about the sysupdate transition in a blog post.

Immutable OS Tooling

Thanks to GNOME OS's deep integration with the systemd stack, we were able to leverage new technologies like systemd-sysext to improve the developer workflow for low-level system components.

As part of his work for Codethink, Martín Abente Lahaye built sysext-utils, a new tool that lets you locally build your own version of various components, and then temporarily apply them over your immutable system for testing. In situations where some change you're testing substantially compromises system stability, you can quickly return to a known-good state by simply rebooting. This work is generic enough that the basics work on any systemd-powered distribution, but it also has direct integration with GNOME OS's build tooling, making the workflow faster and easier than on other distributions. Martín went into lots more detail on the Codethink blog.

A natural next step was to leverage sysext-utils on GNOME's CI infrastructure. Flatpak apps enjoy the benefits of CI-produced bundles which developers, testers, and users alike can download and try on their own system. This makes it very natural and quick to test experimental changes, or confirm that a bug fix works. Martín and Sam Thursfield (with the help of Jordan Petridis and Abderrahim) worked to package up sysext-utils into a CI template that GNOME projects can use. This template creates systemd-sysext bundles that can be downloaded and applied onto GNOME OS for testing, similar to Flatpak's workflow. To prove this concept, this template was integrated with the CI for mutter and gnome-shell. Martín wrote another blog post about this work.

Security Tracking

To become suitable for daily-driver use, GNOME OS needs to keep track of the potential vulnerabilities in the software it distributes, including various low-level libraries. Since GNOME OS is based on our GNOME Flatpak runtime, improving its vulnerability tracking makes our entire ecosystem more robust against CVEs.

To that end, Codethink's Neill Whillans (with Abderrahim's help) upgraded the GNOME Flatpak runtime's CVE scanning to use modern versions of the freedesktop-sdk tooling. Then, Neill expanded the coverage to scan GNOME OS as well. Now we have reports of CVEs that potentially affect GNOME OS in addition to the GNOME Flatpak runtime. These reports show the packages CVEs come from and a description of each vulnerability.

GNOME OS Installer

To make GNOME OS more appealing to our developer community, we needed to rework the way we install it. At the moment, the existing installer is very old and limited in features: it's incompatible with dual-boot, and the current setup flow has no support for the advanced security features we now support (like TPM-powered disk encryption).

Adrian started working on a replacement installer for GNOME OS, built around systemd's low-level tooling. This integration allows the new installer to handle GNOME OS's new security features, as well as provide a better UX for installing and setting up GNOME OS. Most crucially, the new architecture makes dual-boot possible, which is probably one of the most requested GNOME OS features from our developers at the moment.

Sam Hewitt made comprehensive designs and mockups for the new installer's functionality, based on which Adrian has mostly implemented the frontend for the new installer. On the backend, we ran into some unexpected difficulties and limitations of systemd's tools, which Adrian was unable to resolve within the scope of this project. The remaining work is mostly in systemd, but it also requires improvements to various UAPI Group Specifications and better integration with low-level boot components like the UEFI Secure Boot shim. Adrian gave an All Systems Go! talk on the subject, which goes into more details about the current status of this work, and the current blockers.

Buildstream

Buildstream is the tool used to build GNOME OS as well as the GNOME SDK and Runtime for Flathub, building the bases of all GNOME apps distributed there.

Previously, it was not possible to use dependencies originating from git repositories when working with the Rust programming language. That made it impossible to test and integrate unreleased fixes or new features of other projects during the development cycle. Thanks to work by Sophie Herold the use of git dependencies is now possible without any manual work required.

Additionally, Buildstream is also used by the Freedesktop.org project for its SDK and runtime. Most other runtimes, including the GNOME runtime are based on it. With the newly added support for git source, it has now become possible to add new components of the GStreamer multimedia framework. Components written in Rust were previously missing from the runtime. This includes the module that makes it possible to use GStreamer to show videos in GNOME apps. These functions are already used by apps like Camera, Showtime, or Warp.

OpenQA

Quality assurance (QA) testing on GNOME OS is important because it allows us to catch a whole class of issues before they can reach our downstream distributors. We use openQA to automate this process, so that we're continuously running QA tests on the platform. Twice a day, we generate GNOME OS images containing all the latest git commits for all GNOME components. This image is then uploaded into openQA, which boots it in a VM and runs various test cases. These tests send fake mouse and keyboard input, and then compare screenshots of the resulting states against a set of known-good screenshots.

Codethink's Neill Whillans created a script that cleans up the repository of known-good screenshots by deleting old and unused ones. He also fixed many of our failing tests. For instance, Neill diagnosed a problem on system startup that caused QA tests to sometimes fail, and triaged it to an issue in GNOME Shell's layout code.

Building on the sysext-utils work mentioned above, Martín made a prototype QA setup where GNOME's QA test suite can run as part of an individual project's CI pipeline. This will make QA testing happen even earlier, before the broken changes are merged into the upstream project. You can see the working prototype for GNOME Shell here, and read more about it in this blog post.

Security

GNOME and its libraries are used in many security-critical contexts. GNOME libraries underpin much of the operating system, and GNOME itself is used by governments, corporations, journalists, activists, and others with high security needs around the world. In recent years, the freedesktop has not seen as much investment into this area as the proprietary platforms, which has led to a gap in some areas (for instance: home directory encryption). This is why it was important for us to focus on security as part of the STF project.

Home Directory Encryption

systemd-homed is a technology that allows for per-user encrypted home directories. Most uniquely, it has a mechanism to delete the user's encryption keys from memory whenever their device is asleep but powered on. Full Disk Encryption doesn't protect data while the machine is powered on, because the encryption key is available in RAM and can be extracted via various techniques.

systemd-homed has existed for a couple of years now, but nobody is using it yet because it requires integrations with the desktop environment. The largest change required is that homed needs any "unlock" UI to run from outside of the user session, which is not how desktop environments work today. STF funding enabled Adrian Vovk to work on resolving the remaining blockers, developing the following integrations:

• Extending systemd-homed with the ability to store large binary blobs of user metadata, like profile pictures.
• Extending the GNOME login screen service (GDM) with the ability to show a special out-of-session unlock UI, to meet the aforementioned requirement.
• Adding plumbing to systemd-logind that notifies GDM when it's time to show the out-of-session unlock UI.
• Integrating systemd-homed with AccountsService, which currently acts as GNOME's database of users on the system. Previously, homed users didn't appear anywhere in GNOME's UI.

In addition, Adrian triaged and fixed a lot of bugs across the stack, including many blockers in systemd-homed itself.

This work was completed, and a build of GNOME OS with functional homed integration was produced. However, not all of this has been merged upstream yet. Also, due to filesystem limitations in the kernel, we don't have a good way for multiple homed-backed users to share space on a single system at the moment. This is why we disabled multi-user functionality for now.

For more details on the subject, you can watch Adrian's All Systems Go! talk.

GNOME Keyring

The infrastructure to securely store secrets (i.e. passwords and session tokens) for apps on Linux is the FreeDesktop Secret Service API. On GNOME, this API is provided by the GNOME Keyring service. Unfourtunately, GNOME Keyring is outdated, overly complex, and cannot meet the latest security requirements. Historically, it has also provided other security-adjacent services, like authentication agents for SSH and GPG. There have been numerous efforts to gradually reduce the scope of GNOME Keyring and modernize its implementation, the most recent of which was Fedora's Modular GNOME Keyring proposal. Unfortunately, this work was stalled for years.

As part of the STF project, Dhanuka Warusadura took over the remaining parts of the proposal. He disabled the ssh-agent implementation in GNOME Keyring, which prompted all major distributions to switch to gcr-ssh-agent, the modern replacement. He also ported the existing gnome-keyring PAM module with reworked tests, following the modern PAM module testing best practices. With this work completed, GNOME Keyring has been reduced to just a Secret Service API provider, which makes it possible for us to replace it completely.

As the replacement for this remaining part of GNOME Keyring, Dhanuka extended the oo7 Secret Service client library to also act as a provider for the API. OO7 was chosen because it is implemented in Rust, and memory safety is critical for a service that manages sensitive user secrets. This new oo7-daemon is almost ready as a drop-in replacement for GNOME Keyring, except that it can not yet automatically unlock the default keyring at login.

As part of this project, Dhanuka also took care of general maintenance and improvements to the credential handling components in GNOME. These include gnome-keyring, libsecret, gcr and oo7-client.

Key Rack

Key Rack is an app that allows viewing, creating and editing the secrets stored by apps, such as passwords or tokens. Key Rack is based on oo7-client, and is currently the only app that allows access to the secrets of sandboxed Flatpak apps.

Key Rack was previously limited to displaying the secrets of Flatpak apps, so as part of the STF Project Felix Häcker and Sophie Herold worked on expanding its feature set. It now integrates with the Secret Service, and makes management of secrets across the system easier. With this addition, Key Rack now supports most of the features of the old Seahorse ("Passwords and Keys") app.

Glycin

Glycin is a component to load and edit images. In contrast to other solutions, it sandboxes the loading operations to provide an extra layer of security. Apps like Camera, Fractal, Identity, Image Viewer, Fotema, and Shortwave rely on glycin for image loading and editing.

Previously, it was only possible to load images in apps and components that were written in the Rust programming language. Thanks to work by Sophie Herold it is now possible to use glycin from all programming languages that support GNOME's language binding infrastructure. The new feature has also been designed to allow Glycin to be used outside of apps, with the goal of using it throughout the GNOME platform and desktop. Most notably, there are plans to replace GdkPixbuf with Glycin.

Bluetooth

Jonas Dreßler worked on some critical, security-relevant issues in the Linux Bluetooth stack, including work in the kernel, BlueZ, and GNOME's Bluetooth tooling (1, 2, 3).

Bug Bounty Program

In addition to the primary STF fund, STA offers other kinds of support for public interest software projects. This includes their Bug Resilience Program, which gives projects complementary access to the YesWeHack bug bounty platform. This is a place for security researchers to submit the vulnerabilities they've discovered, in exchange for a bounty that depends on the issue's severity. Once the bug is fixed, the project is also paid a bounty, which makes it sustainable to deal with security reports promptly. YesWeHack also helps triage the reported vulnerabilities (i.e. by confirming that they're reproducible), which helps further reduce the burden on maintainers.

Sonny and I did the initial setup of this program, and then handed it over to the GNOME security team. We decided to start with only a few of the highest-impact modules, so currently only GLib, glib-networking, and libsoup are participating in the program. Even with this limited scope, at the time of writing we've already received about 50 reports, with about 20 bounty payments so far, totaling tens of thousands of Euro.

For up to date information about reporting security vulnerabilities in GNOME, including the current status of the bug bounty program, check the GNOME Security website.

Hardware Support

GNOME runs on a large variety of hardware, including desktops, laptops, and phones. There's always room for improvement, especially on smaller, less performant, or more power efficient devices. Hardware enablement is difficult and sometimes expensive, due to the large variety of devices in use. For this project we wanted to focus specifically on devices that developers don't often have, and thus don't see as much attention as they should.

Mutter and GNOME Shell

Jonas Dreßler worked on improving hardware support in Mutter and GNOME Shell, our compositor and system UI. As part of this to this he improved (and is still improving) input and gesture support in Mutter, introducing new methods for recognizing touchscreen gestures to make touch, touchpad, and mouse interactions smoother and more reliable.

Thanks to Jonas' work we were also finally able to enable hardware encoding for screencasts in GNOME Shell, significantly reducing resource usage when recording the screen.

The GNOME Shell user interface has also gotten and optimizations for smaller screens, ensuring a better experience on a wider range of devices, with more to follow.

Thanks to work on XWayland fractional scaling in Mutter (1, 2), the support for modern high-resolution (HiDPI) monitors got more mature and works with all kinds of applications now, making GNOME adapt better to modern hardware.

Variable Refresh Rate

Variable Refresh Rate (VRR) is a technology that allows monitors to dynamically change how often the image is updated. This is useful in two different ways. First, in the context of video games, it allows the monitor to match the graphics card's frame rate to alleviate some microstutters without introducing tearing. Second, on devices which have support for very low minimum refresh rates (such as phones), VRR can save power by only refreshing the screen when necessary.

Dor Askayo had been working on adding VRR support to mutter in their free time for several years, but due to the fast pace of development he was never able to quite get it rebased and landed in time. The STF project allowed them to work on it full-time for a few months, which made it possible to land it in GNOME 46. The feature is currently still marked as experimental due to minor issues in some rare edge cases.

GNOME Shell Performance

GNOME Shell, through its dependency on Mutter, is the compositor and window manager underpinning the GNOME desktop. Mutter does all core input, output, and window processing. When using GNOME, you're interacting with all applications and UI through GNOME Shell.

Thus, it's critical that GNOME Shell remains fast and responsive because any sluggishness in Shell affects the entire desktop. As part of the STF project, Ivan Molodetskikh did an in-depth performance investigation of GNOME Shell and Mutter. Thanks to this, 12 actionable performance problems were identified, 7 of which are already fixed (e.g. 1, 2, 3), making GNOME smoother and more pleasing to use. One of the fixes made monitor screencasting eight times faster on some laptops, bringing it from unusable to working fine.

Moreover, the profiling infrastructure improvements (as well as experimental integration with the Tracy profiler, and many smaller bugfixes in profiling code paths) done thanks to the STF funding will make finding and diagnosing performance problems easier in the future.

Ivan also conducted a round of hardware input latency testing for GNOME's VTE library, which underpins GNOME's terminal emulators. He then worked with RedHat's Christian Hergert to address the discovered performance bottlenecks, and then retested the library to confirm the vast performance improvement. This work landed in GNOME 46. For more details, see Ivan's blog post.

Design Support

Close collaboration between developers and designers is an important value of the GNOME project. Even though the bulk of the work we did as part of this project was low-level technical work, many of our initiatives also had a user-facing component. For these, we had veteran GNOME designer Sam Hewitt (and myself to some degree) help developers with design across all the various projects.

This included improving accessibility across the desktop shell and apps, new and updated designs for portals (e.g. global shortcuts, file chooser), designs for security features such as systemd-homed (e.g. recovery key setup) and the new installer (e.g. disk selection), as well as general input on the work of STF contributors to make sure it fits into GNOME's overall user experience.

Planning, Coordination & Reporting

Sonny Piers and I put together the initial STF application after consulting various groups inside the community, with the goal of addressing as many critical issues in underfunded areas as possible.

Once we got the approval we needed a fiscal host to sign the actual contract, which ended up being the GNOME Foundation. I won't go into why this was a bad choice here (see my previous blog post for more), except to say that the Foundation was not a reliable partner for us, and we're still waiting for the people responsible for these failures to take accountability.

However, while we were stretched thin on the administrative side due to Foundation issues, we somehow made it work. Sonny's organizing talent and experience were a major factor in this. He was instrumental in finding and hiring contractors, reaching out to new partners from outside our usual bubble (e.g. around accessibility), managing cashflow, and negotiating very friendly terms for our contracts with Igalia and Codethink. Most importantly, he helped mediate difficult socio-technical discussions, allowing us to move forward in areas that had previously been stuck for years (e.g. notifications).

On the reporting side we collected updates from contractors and published summaries of what happened to This Week in GNOME and Mastodon. We also managed all of the invoicing for the project, including monthly reports for STA and time sheets organized by project area.

What's Next

While we got a huge amount of work done over the course of the project, some things are not quite ready yet or need follow-up work. In some cases this is because we explicitly planned the work as a prototype (e.g. the Newton accessibility architecture), in others we realized during the project that the scope was significantly larger than anticipated due to external factors (e.g. systemd's improved TPM integration changed our plans for how the oo7-daemon service will unlock the keyring), and in others still getting reviews was more challenging or took longer than expected.

The following describes some of the relevant follow-up work from the STF project.

Wayland-Native Accessibility (Newton)

Matt Campbell's work on Newton, our new Wayland-native accessibility stack, was successful beyond our expectations. We intended it as only a prototype, but we were able to actually already land parts of Matt's work. For instance, Matt worked to integrate GTK with AccessKit, which will be at the core of the Newton architecture. This work has since been picked up, updated, and merged into GTK.

However, in some ways Newton is still a prototype. It intends to be a cross-desktop standard, but has not yet seen any cross-desktop discussions. Its Wayland protocol also isn't yet rigorously defined, which is a prerequisite for it to become a new standard. The D-Bus protocol that's used to communicate with the screen reader is ad-hoc, and currently exists only to communicate between Orca and GNOME Shell. All of these protocols will need to be standardized before apps and desktop environments can start using it.

Even once Newton is ready and standardized, it'll need to be integrated across the stack. GTK will get support for Newton relatively easily, since Newton is built around AccessKit. However, GNOME Shell uses its own bespoke widget toolkit and this needs to be integrated with Newton. Other toolkits and Wayland compositors will also need to add support for it.

Platform

Julian Sparber's work on the v2 notification API has landed in part, but other parts of this are still in review (e.g. GLib, portal backend). Additionally, there's more GUI work to be done, to adjust to some of the features in Notifications v2. GNOME Shell still needs to make better use of the notification visibility settings for the lock screen, to increase user privacy. There's also the potential to implement special UI for some types of notifications, such as incoming calls or ringing alarms. Finally, we already did some initial work towards additional features that we want to add in a v3 of the specification, such as grouping message notifications by thread or showing progress bars in notifications.

Spiel, the new text-to-speech API, is currently blocked on figuring out how to distrbute speech synthesizers and their voices. At the moment there's a prototype-quality implementation built around Flatpak, but unfourtunately there are still a couple of limitations in Flatpak that prevent this from working seamlessly. Once we figure out how to distribute voices, Spiel will be ready to be shipped in distros. After that, we can use Spiel in a new portal API, so that apps can easily create features that use text-to-speech.

The work done on language bindings as part of this STF project focused on the low-level introspection in GLib. This is the part that generates language-agnostic metadata for the various languages to consume. However, for this work to be useful each language's bindings need to start using this new metadata. Some languages, like Python, have done this already. Others, like JavaScript, still need to be ported. Additionally, build systems like Meson still need some minor tweaks to start using the new introspection infrastructure when available.

GNOME OS and QA

Much of the work we've started for GNOME OS needs some finishing touches. The new update system, powered by systemd-sysupdate, is still missing support for multiple stable branches. It also doesn't support delta updates yet, which would save on download bandwidth and time by only downloading changes between versions. Finally, we need to finish the work we started on the new GNOME OS installer.

We'd like to finalize and deploy the prototype that runs openQA test cases directly in the CI for each GNOME component. This infrastructure would allow us to increase the QA test coverage of GNOME as a whole.

Encrypting Home Directories

The work to integrate systemd-homed into GNOME is mostly complete and functional, but parts of it have not landed yet (see this tracking issue and all the merge requests it links to).

Due to filesystem limitations in the kernel, we don't have a good way for multiple homed-backed users to share space on a single system. For now, we simply disabled that functionality. Follow-up work would include fixing this kernel limitation, and re-enabling multi-user functionality.

Once these things are resolved, distributions can start moving forward with their adoption plans for systemd-homed.

Long-term, we'd like to deprecate the current AccountsService daemon, which provides a centralized database for users that exist on the system. We'd like to replace it with systemd-userdb, which is a more modern and more flexible alternative.

Keyring

Before the oo7-daemon can replace the GNOME Keyring service, it still needs support for unlocking the default keyring at login. An implementation that partially copies GNOME Keyring's solution has been merged into libsecret, but it's still missing integration with oo7-daemon. Once this is solved, oo7-daemon will become drop-in compatible with GNOME Keyring, and distributions will be able to start transitioning.

Longer term we would like to redo the architecture to make use of systemd's TPM functionality, which will increase the security of the user's secrets and make it compatible with systemd-homed.

Thanks

The 2023/2024 GNOME STF project was a major success thanks to the many many people who helped to make this possible, in particular:

• The Sovereign Tech Agency, for making all of this possible through their generous investment
• Tara Tarakiyee and the rest of the STA team, for making the bureaucratic side of this very manageable for us
• All of our contractors, for doing such wonderful work
• The wider community for their reviews, input, support, and enthusiasm for this project
• Igalia and Codethink for generously donating so much of their employee time
• RedHat and the systemd project for helping with reviews
• Sonny Piers for taking the lead on applying to the STF, and running the project from a technical point of view
• Adrian Vovk for splitting the gargantuan task of editing this blog post with me

11 Apr 2025 6:11pm GMT

Welcome to another month of rambling status reports. Not much in terms of technology this month, my work at Codethink is still focused on proprietary corporate infrastructure, and the weather is too nice to spend more time at a computer than necessary. Somehow I keep reading things and thinking about stuff though, and so you can read some of these thoughts and links below.

Is progress going backwards?

I've been listening to The Blindboy Podcast from the very beginning. You could call this a "cult podcast" since there isn't a clear theme, the only constant is life, narrated by an eccentric Irish celebrity. I'm up to the episode "Julias Gulag" from January 2019, where Blindboy mentions a Gillette advert of that era which came out against toxic masculinity, very much a progressive video in which there wasn't a single razor blade to speak of. And he said, roughly, "I like the message, and the production is excellent, but I always feel uneasy when this type of "woke" video is made by a huge brand because I don't think the board of directors of Proctor & Gamble actually give a shit about social justice."

This made me think of an excellent Guardian article I read last week, by Eugene Healey entitled "Marketing's 'woke' rebrand has ultimately helped the far right", in which he makes largely the same point, with six years worth of extra hindsight. Here are a few quotes but the whole thing is worth reading:

Social progress once came hand-in-hand with economic progress. Now, instead, social progress has been offered as a substitute for economic progress.

Through the rear window it's easy to see that the backlash was inevitable: if progressive values could so easily be commodified as a tool for selling mayonnaise, why shouldn't those values be treated with the same fickleness as condiment preferences?

The responsibility we bear now is undoing the lesson we inadvertently taught consumers over this era. Structural reform can't be achieved through consumption choices - unfortunately, we're all going to have to get dirt under our fingernails.

We are living through a lot of history at the moment and it can feel like our once progressive society is now going backwards. A lot of the progress we saw was an illusion anyway. The people who really hold power in the world weren't really about to give anything up in the name of equality, and they still aren't. World leaders were still taking private jets to conferences to talk about the climate crisis, and so on. The 1960s USA seemed like a place of progress, and then they went to war in Vietnam.

As Eugene Healey says towards the end of his piece, one positive change is that it's now obvious who the bad guys are again. Dinold Tromp appears on TV every time I look at a TV, and he dresses like an actual supervillain. Mark Zuckerburg is trying to make his AI be more right-wing. Gillette is back to making adverts which are short videos of people shaving, because Gillette is a brand that manufactures razors and wants you to buy them. It is not a social justice movement!

The world goes in cycles, not straight lines. Each new generation of people has to ignore most of what we learn from teachers and parents, and figure everything out for ourselves the hard way, right?

For technologists, it's been frustrating to spend the last decade telling people to be wary of Apple, Amazon, Google, Meta and Microsoft, and being roundly ignored. They are experts in making convenient, zero cost products, and they are everywhere. Unless you're an expert in technology or economics, then it wasn't obvious what they have been working towards, which is the same thing it always was, the same that drove everything Microsoft did through the 1990s: accumulating more and more money and power.

You don't get very far if you tell this story to some poor soul who just needs to make slides for a presentation, especially if your suggestion is that they try LibreOffice Impress instead.

When 2025 kicked off, CEOs of all those Big Tech companies attended the inauguration of Dinald Tromp and donated him millions of dollars, live on international news media. In the long run I suspect this moment will have pushed more people towards ethical technology than 20 years of campaigning about nonfree JavaScript.

Art, Artificial Intelligence and Idea Bankrupcy

Writing great code can be a form of artistic expression. Not all code is art, of course, just as an art gallery is not the only place you will find paint. But if you're wondering why some people release groundbreaking software for free online, it might help to view it as an artistic pursuit. Anything remotely creative can be art.

I took a semi retirement from volunteer open source contributions back in October of last year, having got to a point where it was more project management than artistic endeavour. In an ideal world I'd have some time to investigate new ideas, for example in desktop search or automated GUI testing, and publish cool stuff online. But there are two blockers. One blocker is that I don't have the time. And the other, is that the open web is now completely overrun with data scrapers, which somehow ruins the artistic side of publishing interesting new software for free.

We know that reckless data scraping by Amazon, Anthropic, Meta and Microsoft/OpenAI (those US tech billionaires again), plus their various equivalents in China, is causing huge problems for open source projects and other non-profits. It has led The Wikimedia Foundation to declare this month that "Our content is free, our infrastructure is not". And Ars Technica also published a good summary of the situation.

Besides the bandwidth costs, there's something uncomfortable about everything we publish online being immediately slurped into the next generation of large language model. If permissive software licenses lead to extractive behaviour, then AI crawlers are that on steroids. LLMs are incredibly effective for certain use cases, and one such use case is "copyright laundering machines".

Software licensing was a key part of the discussion around ethical technology when I first discovered Linux in the late 1990s. There was a sense that if you wrote innovative code and published it under the GNU GPL, you were helping to fight the evils of Big Tech, as the big software firms wouldn't legally be able to incorporate your innovation into their products without releasing their source code under the same license. That story is spelled out word-for-word in Richard Stallman's article "Copyleft: Pragmatic Idealism". I was never exactly a disciple of Richard Stallman, but I did like to release cool stuff under the GPL in the past, hoping that in a small way it'd work towards some sort of brighter future.

I was never blind to the limitations of the GPL. It requires an actual threat of enforcement to be effective, and historically only a few groups like the Software Freedom Conservancy actually do that difficult legal work. Another weakness in the overall story was this: if you have a big pile of cash, you can simply rewrite any innovative GPL code. (This is how we got Apple to pay for LLVM).

Long ago I read the book "Free as in Freedom". It's a surprisingly solid book which narrates Richard Stallman's efforts to form a rebel alliance and fight what we know today as Big Tech, during which he founds the GNU Project and invents the GPL. It is only improved in version 2.0 where Stallman himself inserts pedantic corrections into Sam Williams's original text such as "This cannot be a direct quote because I do not use fucking as an adverb". (The book and the corrections predate him famously being cancelled in 2019). He later becomes frustrated at having spent a decade developing an innovative, freely available operating system, only for the media and the general public to give credit to Linus Torvalds.

Right now the AI industry is trying to destroy copyright law as we know it. This will have some interesting effects. The GPL depends on copyright law to be effective, so I can only see this as the end of the story for software licensing as a way to defend and ensure that the inventors of cool things get some credit and earn money. But let's face it, the game was already up on that front.

Sustainable open source projects - meaning those where people actually get paid do all the work that is needed for the project to succeed - can exist and do exist. We need independent, open computing platforms like GNOME and KDE more than ever. I'm particularly inspired by KDE's growing base of "supporting members" and successful fundraisers. So while this post might seem negative, I don't see this as a moment of failure, only a moment of inflection and of change.

This rant probably needs a deeper message so I'm going to paraphrase Eugene Healey: "Structural reform can't be achieved just by publishing code online". The hard work and meaningful work is not writing the code but building a community who support what you're doing.

My feeling about the new AI-infested web, more to the point, is that it spoils the artistic aspect of publishing your new project right away as open source. There's something completely artless about training an AI on other people's ideas and regenerating it in infinite variations. Perhaps this is why most AI companies all have logos that look like buttholes.

Visual artists and animators have seen DALL-E and Stable Diffusion tale their work and regurgitate it, devoid of meaning. Most recently it was the legendary Studio Ghibli who had their work shat on by Sam Altman. "I strongly feel that this is an insult to life itself", say the artists. At least Studio Ghibli is well-known enough to get some credit, unlike many artists whose work was coopted by OpenAI without permission.

Do you think the next generation of talented visual artists will publish their best work online, within reach of Microsoft/OpenAI's crawlers?

And when the next Fabrice Bellard comes up with something revolutionary, like FFMPEG or QEMU were when they came out, will they decide to publish the source code for free?

Actually, Fabrice Bellard himself has done plenty of research around large language models, and you will notice that his recent projects do not come with source code…

With that in mind, I'm declaring bankruptcy on my collection of unfinished ideas and neat projects. My next blog post will be a dump of the things I never got time to implement and probably never will. Throw enough LLMs at the problem and we should have everything finished in no time. If you make the thing I want, and you're not a complete bastard, then I will happily pay a subscription fee to use it.

I'm interested what you, one of the dozen readers of my blog, think about the future of "coding as art". Is it still fun when there's a machine learning from your code instead of a fellow programmer?

And if you don't believe me that the world goes in cycles and not straight lines: take some time to go back to the origin story of Richard Stallman and the GPL itself. The story begins at the Massachusets Institute of Technology, in a computing lab that in the 1970s and 80s was at the cutting edge of research into… Artificial Intelligence.

11 Apr 2025 5:23pm GMT

Update on what happened across the GNOME project in the week from April 04 to April 11.

GNOME Core Apps and Libraries

Weather

Show weather conditions and forecasts.

Chris 🌱️ says

GNOME Weather has been ported to from JavaScript to TypeScript! This makes it the second TypeScript app in GNOME Core after Audio Player. If you want to see the changes involved, check out the merge request.

GLib

The low-level core library that forms the basis for projects such as GTK and GNOME.

Philip Withnall announces

Support for file handles in nested containers has been added to gdbus call by Julian Sparber in https://gitlab.gnome.org/GNOME/glib/-/issues/3624. This should make it easier to test some of the portal D-Bus APIs using gdbus call.

GNOME Circle Apps and Libraries

Solanum

Balance working time and break time.

Chris 🌱️ says

Solanum 6.0.0 is out with the following changes:

• The timer's text now scales with window size. You should now see larger text at larger window sizes
• You now have the option to make Solanum go fullscreen when a break starts
• Notifications are now appropriately dismissed when resuming the timer
• We now ship branding colors in our app data
• Miscellaneous metainfo improvements
• Various code modernization updates
• Miscellaneous translation updates

We also now follow the system accent color!

Keypunch

Practice your typing skills

Brage Fuglseth (he/him) announces

This week I released Keypunch 6.0, with more realistic results, extended language support, and a brand new feature called frustration relief. Learn more on my blog.

Third Party Projects

larma reports

Dino 0.5.0 has been released! This release features improved file transfers and two completely reworked dialogs. Full release blog post: https://dino.im/blog/2025/04/dino-0.5-release/

Jeffry Samuel reports

Alpaca, an Adwaita app to chat with local and online AI models will release version 6.0.0 this saturday (April 12) with a lot of new features https://github.com/Jeffser/Alpaca/discussions/678 thanks

Sebastian Wiesner reports

A new release of Picture Of The Day is available. This release improves navigation between multiple Bing images with a new overlay toolbar, adds toolbar buttons to open and save the current image, and fixes some embarrassing crashes and locale issues.

Picture Of The Day is a small GNOME utility to get a fresh daily wallpaper from various sources. It's available from Flathub.

JumpLink announces

Last week I introduced my first app Learn 6502 Assembly on Flathub, and this week I'm happy to announce a update to version 0.2.0.

This new version focuses on improving the learning experience with:

• Help features to make code editing easier for beginners
• Better game controls and display for mobile devices
• New tools to examine your code, including a disassembler and memory viewer
• File management to save and load your programs
• Various usability improvements, including automatic pause when switching screens

The app continues to provide a complete learning environment for 6502 assembly language with an interactive tutorial, code editor, debugger, and visual game console.

دانیال بهزادی reports

As the northern hemisphere welcomes spring with Nowruz - the Persian New Year symbolizing renewal and rebirth - we're proud to announce Carburetor 5.1.0, your gateway to a more free and private Internet. This update blossoms with improvements timed to honor fresh beginnings.

What's New?

• 🌐 Enhanced Locale Support: Resolved issues for English and several other language users for a smoother experience
• 🎨 GNOME HIG Compliance: Refined interface elements that enhance usability and integrate naturally with GNOME design standards
• 📖 Refined Messaging: Updated text across the app for clearer instructions and better user guidance

Nowruz: A Time for Digital Renewal

Just as Nowruz celebrates nature's rebirth by washing away winter's dust, Carburetor helps cleanse your digital footprint. In a world where surveillance dims the light of free expression, this release reaffirms our commitment to ensuring everyone enjoys secure, unfiltered access to the Internet.

francescocaracciolo reports

Newelle 0.9.0 has been released

• 🔈 Added TTS support for Groq and OpenAI compatible APIs
• 🎙️ Added Whisper.CPP support with model manager for speech recognition
• 📃 Added a new API for extensions to create and manage RAG indexes
• 🧠 Improved the model selection popup
• 🔢 Improved LaTeX rendering
• 🚀 A ton of performance improvements and refinements

Newelle is an advanced AI Linux assistant for Gnome. You can download it from Flathub.

Cleo Menezes Jr. reports

The first release of Serigy is now available! Serigy is a proof of concept for a 'clipboard pinner' for GNOME.

Watch a brief video on how to use Serigy.

Get it on Flathub

Flare

Chat with your friends on Signal.

schmiddi says

Flare 0.15.16 was released this week. As the last TWIG entry of Flare was already over a year ago, and there have been 19 releases in the meantime, I'll quickly summarize what happened in that year:

• Four fixes for being unable to link the device, or using Flare as a primary device.
• Four fixes making receiving messages more reliable.
• Two fixes for issues when sending messages and images.
• Fixes for two security issues.
• Two fixes for rare crashes.
• Two performance improvements.
• Six UI bug fixes and minor UI improvements.
• Quite a few more minor things, which you can read in detail in the changelog

As you can see, the focus with Flare has mostly shifted towards stability recently. This should lead to major improvements in the actual day-to-day usability of Flare. So if you tried out Flare before but abandoned it due to issues regarding stability, you should maybe try out Flare again after the recent improvements.

But this of course leads to a stagnation in the features being developed. I don't expect the priority of stability over features to change in the upcoming months as I will very likely be pretty busy and therefore won't be able to implement new features myself. Merge requests for new features and other improvements are of course still welcome, so if you have an idea for a feature you want and know some Rust and GTK, feel free to review the contributing guidelines and developer documentation and send over a merge request.

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!

11 Apr 2025 12:00am GMT

We are running a Fedora 42 GNOME 48 Desktop and Core Apps Test Week! This helps us find last-minute bugs and integration issues before Fedora 42 is ready for a stable release.

You can find how to participate in https://fedoraproject.org/wiki/Test_Day:2025-04-08_Fedora_42_GNOME_48_Desktop_and_Core_Apps

10 Apr 2025 9:38am GMT

• Quickish planning call, partner sales call. Kate, James & Penelope over for lunch - caught up with them.
• Multi-partner call later in the afternoon, dinner, mail chew - feeling somewhat unwell oddly.
• Richard published the first pod-cast, Open Matters - around Document Formats featuring yours truly geeking out on some technical details underneath documents:
  

08 Apr 2025 7:43pm GMT

• Mail chew, sync with Miklos, Chris & Gokay, the marketing team, Naomi, Pedro & Eloy.
• Intermittent patch review, call with Anna, dinner.

07 Apr 2025 9:00pm GMT

Back in December (before I caught the flu working at a farmers market, then Covid two weeks later, then two months of long-Covid) I mentioned that we'd discuss the various subsystems needed in libfoundry to build an IDE as a library.

I used the little bit of energy I had to work on some core abstractions. In an effort to live up to my word lets talk a bit about what went into libfoundry last night.

There is now a DocumentationManager sub-system which handles documentation installed on the host system, chroots, and Flatpak SDKs. It's a bit tricky to make this all work without blurring the lines of abstraction so lets cover how that works.

Generally speaking, we try to avoid plugins depending on other plugins. Sometimes it happens but usually it is an opportunity to make a better abstraction in libfoundry. Lets look at what is needed around documentation.

• We have many SDKs and they all might have documentation available at different locations.
• We primarily have one format we need to support in GNOME, which is the venerable Devhelp2 XML format serving as an index.
• SDKs might contain the same documentation but at different versions (Nightly vs GNOME 48 vs jhbuild for example)
• There may be more formats that matter in the future especially as we look at pulling in support for new languages.
• Adding new search capabilities shouldn't break the API.
• Querying needs to be fast enough to update as you type.

So lets dive into the abstractions.

DocumentationManager

This is the core abstraction you start interfacing with. It is a service of the FoundryContext and therefore can be accessed with Foundry.Context:documentation-manager property.

The documentation manager manages the Foundry.DocumentationProvider plug-in abstractions. Plug-ins that which to contribute to the documentation pipeline must subclass this in their plug-in.

To query documentation, use Foundry.DocumentationManager.query(). As I noted earlier, I don't want new capabilities to break the API so a Foundry.DocumentationQuery object is used rather than a sequence of parameters which would need to be modified.

Avoiding Formats in the API

Since we want to be able to support other documentation formats in the future, it is important that we do not force anything about devhelp2 XML into the core abstraction.

The core result object from queries is a simple Foundry.Documentation object. Like above, we want to avoid breaking API/ABI when new capabilities are added so this object serves as our abstraction to do so. Navigating a tree structure will live here and can be implemented by plug-ins through subclassing.

Additionally, a "devhelp" plug-in provides support for crawling the devhelp2-style directories on disk. But this plug-in knows nothing about where to find documentation as that is relevant only to the SDKs.

This is where the Foundry.DocumentationRoot object becomes useful. SDK plug-ins can implement DocumentationProvider in their plug-in to expose documentation roots. The host-sdk, jhbuild, and Flatpak plug-ins all do this to expose the location of their documentation.

Now the devhelp plug-in can be provided the information it needs for crawling without any knowledge of SDKs.

Fast Querying

The old adage is that the only way to go faster on a computer is to do less work. This is particularly important in search systems where doing an entire query of a database means a lot of wasted CPU, memory, and storage I/O.

To make querying fast the devhelp plug-in indexes information about SDKs in SQLite. Way back in Builder we'd avoid this and just make an optimized fuzzy search index, mmap that, and search it. But now days we've gone from one set of documentation to multiple sets of documentation across SDK versions. The problem domain explodes quite a bit. SQLite seemed like a nice way to do this while also allowing us to be lazy in our searching.

By lazy what I mean is that while we'll start your query, we only retrieve the first few results from the cursor. The rest are lazily fetched as the GListModel is scanned by scrolling. As that is not a very common operation compared to typing, you can throw away a lot of work naturally while still sitting behind the comfortable GListModel interface.

What now?

Since libfoundry already supports SDK management (including Flatpak) you could probably re-implement Manuals in a week-end. Hopefully this also breaks down a bit of the knowledge used to build such an application and the deceptive complexity behind doing it well.

This should also, hopefully soon, allow us to share a documentation implementation across Builder, Manuals, and an upcoming project I have which will benefit from easy access to documentation of object properties.

07 Apr 2025 7:31pm GMT

Spring is in the air, the snow is finally melting away here in the cold north, and Keypunch is getting an update! Let's walk through all the new features and improvements together.

Realistic Results

Up to now, Keypunch's measurements of typing performance have been rather primitive. For speed, it has just compared the total number of typed characters, both correct and incorrect, to the test duration. Likewise, the "correctness" rate is nothing more than the share of correctly typed characters at the time of calculation. If you make a mistake and then correct it, it's not taken into account at all.

These calculations are easy to understand and interpret, but also flawed and potentially misleading. The one for speed in particular has caused some pretty ridiculous result screens because of its uncritical counting. Needless to say, this is not ideal.

I've gone a little back and forth with myself on how to move forward, and ended up overhauling both of the calculations: For speed, Keypunch now counts how many correct characters there are at the end of the test, while the correctness rate has been replaced with real accuracy, based on all operations that have changed the typed text rather than just the final result.

The new calculations come with their own trade-offs, such as the incentive to correct mistakes being slightly reduced. In general, however, I view them as a change for the better.

Frustration Relief

Learning to type is awfully hard. At least it was for me; sometimes it felt like I wasn't even in control of my own fingers. This made me furious, and my number-one coping mechanism was to go berserk with my keyboard and mash random keys in frustration. As one might guess, this did not help me progress, and I probably should just have gone for a walk or something instead.

To safeguard the poor souls who come after me, I'm introducing something I call frustration relief. The concept is simple: If Keypunch detects that you're randomly mashing your keyboard, it will cancel the test and provide a helpful piece of life advice.

I can't understate how much I wish I had something like this a couple of years ago.

Input Improvements

Being a text-centric app with multi-language support, Keypunch inevitably has to work with the many intricacies of digital text input. This includes the fact that the Unicode standard contains more than a dozen different space characters. For a while, Keypunch has supported entering regular spaces in the place of non-breaking ones, and now the same is possible the other way around too. Notably, this is a significant improvement for users of the francophone BÉPO keyboard layout.

New Languages

Keypunch's international community has been hard at work lately, and I'm happy to report a solid upturn in language support. For text generation, these languages have been added:

• Catalan
• Dutch
• Estonian
• Greek
• Indonesian
• Slovak
• Persian

This brings the total language count up to 38! Does Keypunch support your language yet? If not, feel free to open a language request.

On the interface translation side, Keypunch has enrolled in GNOME's common translation system, Damned Lies, allowing it to benefit from the coordinated and high-quality work of GNOME's translation teams. Since the last update, Keypunch has been translated into these languages:

• Catalan
• British English
• Persian
• Finnish
• Indonesian
• Kabyle
• Slovak
• Slovenian
• Chinese

Thanks to everyone who is helping make Keypunch speak their language!

Platform Progression

This Keypunch release is based on GNOME 48, which brings a bunch of external platform goodness to the app:

• The latest Adwaita styling
• Better adherence to the system font settings
• Improved performance
• An "Other Apps" section in the About dialog

While not directly part of the runtime, Keypunch will also benefit a lot from the new Adwaita Fonts. It's exciting to build on such a rapidly improving platform.

Additional Artwork

Apparently, some people are keeping Keypunch in their game libraries. If you're one of them, I've made a couple of assets to make Keypunch integrate better visually with the rest of your collection. Enjoy!

Circle Inclusion

Keypunch is now part of GNOME Circle! I'm happy and grateful to have another app of mine accepted into the program. For full transparency, I'm part of the Circle Committee myself, but Keypunch has been independently reviewed by two other committee members, namely Tobias and Gregor. Thanks!

Final Thoughts

That's it for this update. Initially, I was planning on just doing a platform/translation bump now and holding off the headline features for an even bigger update later on, but I decided that it's better to ship what I have at the moment and let the rest wait for later. There's still more on the roadmap, but I don't want to spoil anything!

If you have questions or feedback, feel free to mention me on Mastodon or message me on Matrix.

Oh, and if you'd like to support my work, feel free to make a donation! I'd really appreciate that.

04 Apr 2025 10:44pm GMT

Update on what happened across the GNOME project in the week from March 28 to April 04.

GNOME Core Apps and Libraries

GLib

The low-level core library that forms the basis for projects such as GTK and GNOME.

Philip Withnall reports

Sam James and Jakub Jelinek fixed a 19-year-old race condition in GClosure in GLib, when they initially thought they were out to fix a gcc optimisation bug! https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4575

GNOME Circle Apps and Libraries

Video Trimmer

Trim videos quickly.

Ivan Molodetskikh says

I released Video Trimmer v25.03, moving the trimming options from the save dialog into the main UI. This makes them more discoverable and allows for better visual feedback down the line.

Identity

Compare images and videos.

Ivan Molodetskikh reports

Identity v25.03 is out with a minor visual refresh for GNOME 48: now using a toggle group for the display mode switcher in the main menu.

Amberol

Plays music, and nothing else.

Emmanuele Bassi announces

Amberol 2025.1 is out. Not many changes, this time, except for an update in the dependencies to use the latest GNOME 48 run time, and the new release of Lofty, the metadata parsing library. This last update should fix various recent issues with malformed fields inside MP3 files.

Third Party Projects

nokyan says

Resources 1.8 has been released, featuring support for new hardware such as the Raspberry Pi's GPU and quality of life changes like type-to-search.

In addition, Resources can now display the link type and speed of GPUs, drives and network interfaces as well as the combined memory and swap usage in the Apps and Processes views in a new column.

Last but not least, Resources is now built using the new GNOME 48 runtime, showing off its new sleek colors when using its dark theme.

As always, the update is available on Flathub. Enjoy!

JumpLink reports

My first app Learn 6502 Assembly is now available on Flathub! This application provides a complete learning environment for 6502 assembly language programming.

The app features an interactive tutorial with step-by-step guidance, a code editor with syntax highlighting, an integrated assembler and debugger showing registers and memory in real-time, and a visual game console to see your code in action.

The application is built with GJS and TypeScript, fully supports Adwaita, and works on both desktop and mobile Linux devices.

Available on Flathub Code on GitHub

youpie reports

Iconic V2025.3.2, is out! Iconic is an application that allows you to add images to folders, to help you differentiate them better. It also has support for changing the icons according to the system accent color. Which makes it look great in combination with Adwaita-colors

Sebastian Wiesner reports

A new release of Turn On is available. With this release Turn On now finds web interfaces on devices and links them in the UI.

Turn On is a small GNOME utility to turn on remote systems such as NAS devices with Wake On LAN magic packets. It's available from Flathub.

Cleo Menezes Jr. announces

Aurea 1.6 has been released with the GNOME 48 runtime and now includes translations for Brazilian Portuguese, Turkish, Georgian, and Italian.

Get Aurea on Flathub

Phosh

A pure wayland shell for mobile devices.

Guido reports

Phosh 0.46.0 is out:

Phosh now allows to set a lockscreen wallpaper, it automatically closes status pages when closing the top panel and shows a spinner when updating the list of Wi-Fi networks in quick settings. There's better cutout/notch support for devices with e.g. a camera in the indicator area and one can now also tweak the maximum haptic feedback strength (and disable it completely).

There's more, see the full details at here

That's all for this week!

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

04 Apr 2025 12:00am GMT

A long overdue dev log. The last one was for September 2024. That's half a year.

libopenraw

Released 0.4.0-alpha9 of the Rust crate. Added a bunch of cameras. Fixed some Maker Note for some Fujifilm camera, and a fews other, also fixed some thumbnailing.

The main API is now faillible with Result<> returned. This should reduce the amount of panics (it shouldn't panic).

Added support for user crops in Fujifilm files as I added support for the GFX 100RF (sight unseen).

Niepce

Changed the catalog format. By changed, it's just that it has an extension .npcat and that it is standalone instead of being a folder. The thumbnail cache will be in the same folder next to it.

Now we can open a different catalog. Also renamed some bits internally to be consistent with the naming.

Removed some UI CSS hacks now that the is an API for Gtk.TreeExpander.set_hide_expander() in Gtk 4.10. Fixed some bug with the treeview not being updated. Removed Gtk.ColorButton (deprecated). Fix some selection issues with the Gtk.ListView.

Moved to Rust 2024.

Added video thumbnailing. Code was inspired from Totem's.

Fixed some bugs with importing hierarchies of folders, and fix deleting a folder with folders.

Still working on the import feature I mentionned previously. It is getting there. My biggest issue that one can't select a Gtk.ListView item by item, only by index, which is complicated on a tree view. On the other hand several of the fixes mentionned above came from this work as I cherry-picked the patches to the main branch.

i18n-format

Fixed my i18n-format crate as the minor version of gettext removed the essential feature I was relying on. Yes this is a semver breakage. I ended up having to split the crate to have a non macro crate. From a usage standpoint it works the same.

The long term is to have this crate be unnecessary.

Other

Other stuff I contributed to.

Glycin

Submitted support for the rotation of camera raw files, and the Loupe counterpart. This is a followup to the camera raw file support in glycin.

02 Apr 2025 12:00am GMT

With GNOME 48 I released libdex 0.10 on the march towards a 1.0. One of the major improved features there was around fiber cancellation.

I'm not going to go into detail about the differences between threads and fibers as wikipedia or your local CS department can probably help you there. But what I will say is that combining __attribute__((cleanup)) (e.g. g_autoptr()) with futures and fibers makes such a nicer experience when writing C.

Thread cancellation is a rather non-portable part of the threading stack across platforms. Some POSIX platforms support it, some don't. Having safe places to cancel can be a real challenge even if you are depending on a threading implementation that can do it.

With fibers, we have a natural cancellation point due to the cooperative nature of scheduling. All (well behaved) fibers are either making progress or awaiting completion of a future. We use the natural await() points to implement cancellation. If everything that was awaiting the future of the fiber has been cancelled, then the fiber can naturally cancel too. The next time it awaits that will just happen and natural exit paths will occur.

When you don't want cancellation to propagate, you still use dex_future_disown() like always (as the fiber itself is a future).

Just to give a quick example of how fibers and futures makes writing C code nicer, here is an excerpt from libfoundry that asynchronously implements the necessary phases to build/run your project with a specific tool, possibly on a non-local system. In the GNOME Builder IDE, this is a series of async callbacks that is extremely difficult to read/debug. But with Foundry using libdex, it's just a few lines of code and every bit as non-blocking.

From foundry-run-manager.c.

g_autoptr(FoundryDeployStrategy) deploy_strategy = NULL;
g_autoptr(FoundryBuildProgress) progress = NULL;
g_autoptr(GSubprocess) subprocess = NULL;
GError *error = NULL;

if (!(deploy_strategy = dex_await_object (foundry_deploy_strategy_new (state->pipeline), &error)) ||
    !dex_await (foundry_deploy_strategy_deploy (deploy_strategy, state->build_pty_fd, state->cancellable), &error) ||
    !dex_await (foundry_deploy_strategy_prepare (deploy_strategy, state->launcher, state->pipeline, state->build_pty_fd, state->cancellable), &error) ||
    !dex_await (foundry_run_tool_prepare (state->run_tool, state->pipeline, state->command, state->launcher, state->run_pty_fd), &error) ||
    !(subprocess = foundry_process_launcher_spawn (state->launcher, &error)))
  return dex_future_new_for_error (error);

At each dex_await*() function call the fiber is suspended and we return to the main loop for additional processing.

In a better world we'd be able to do these without fibers and instead do stackless coroutines. But maybe with a little compiler help we can have that too.

27 Mar 2025 7:09pm GMT

The GNOME Foundation is thrilled to share that registration for GUADEC 2025 is now open!

GUADEC is the largest annual gathering of GNOME developers, contributors, and community members. This year we welcome everyone to join us in the beautiful city of Brescia, Italy from July 24^th to 29^th or online! For those who cannot join us in person, we will live-stream the event so you can attend or present remotely.

To register, visit guadec.org and select whether you will attend in person or remotely.
In-person attendees will notice a slight change on their registration form. This year we've added a section for "Registration Type" and provided 4 options for ticket fees. These costs go directly towards supporting the conference and helping us build a better GUADEC experience.
We ask that in-person attendees select the option they are most comfortable with. If you have any questions, please don't hesitate to reach out to us at guadec@gnome.org.

Register for In-Person Attendance
Register for Remote Attendance

The Call for Participation is ongoing but once are talks are selected you will find speaker details and a full schedule on guadec.org. We will also be adding more information about social events, accommodations, and activities throughout Brescia soon!

We are still looking for conference sponsors. If you or your company would like to become a GUADEC 2025 sponsor, please take a look at our sponsorship brochure and reach out to us at guadec@gnome.org.

To stay up-to-date on conference news, be sure to follow us on Mastodon @gnome@floss.social.

We look forward to seeing you in Brescia and online!

27 Mar 2025 1:44pm GMT