Accessibility in the free and open source world is somewhat of a sensitive topic.

Given the principles of free software, one would think it would be the best possible place to advocate for accessibility. After all, there’s a collection of ideologically motivated individuals trying to craft desktops to themselves and other fellow humans. And yet, when you look at the current state of accessibility on the Linux desktop, you couldn’t possibly call it good, not even sufficient.

It’s a tough situation that’s forcing people who need assistive technologies out of these spaces.

I think accessibility on the Linux desktop is in a particularly difficult position due to a combination of poor incentives and historical factors:

• The dysfunctional state of accessibility on Linux makes it so that the people who need it the most cannot even contribute to it.
• There is very little financial incentive for companies to invest in accessibility technologies. Often, and historically, companies invest just enough to tick some boxes on government checklists, then forget about it.
• Volunteers, especially those who contribute for fun and self enjoyment, often don’t go out of their ways to make the particular projects they’re working on accessible. Or to check if their contributions regress the accessibility of the app.
• The nature of accessibility makes it such that the “functional progression” is not linear. If only 50% of the stack is working, that’s practically a 0%. Accessibility requires that almost every part of the stack to be functional for even the most basic use cases.
• There’s almost nobody contributing to this area anymore. Expertise and domain knowledge are almost entirely lost.

In addition to that, I feel like work on accessibility is invisible. In the sense that most people are simply apathetic to the work and contributions done on this area. Maybe due to the dynamics of social media that often favor negative engagement? I don’t know. But it sure feels unrewarding. Compare:

Now, I think if I stopped writing here, you dear reader might feel that the situation is mostly gloomy, maybe even get angry at it. However, against all odds, and fighting a fight that seems impossible, there are people working on accessibility. Often without any kind of reward, doing this out of principle. It’s just so easy to overlook their effort!

So as we prepare for the Global Accessibility Awareness Day, I thought it would be an excellent opportunity to highlight these fantastic contributors and their excellent work, and also to talk about some ongoing work on GNOME.

If you consider this kind of work important and relevant, and/or if you need accessibility features yourself, I urge you: please donate to the people mentioned here. Grab these people a coffee. Better yet, grab them a monthly coffee! Contributors who accept donations have a button beneath their avatars. Go help them.

Calendar

GNOME Calendar, the default calendaring app for GNOME, has slowly but surely progressing towards being minimally accessible. This is mostly thanks to the amazing work from Hari Rana and Jeff Fortin Tam!

Hari recently wrote about it on Mastodon. In fixing one issue, Hari accidentally fixed at least two other issues. Jeff, as an exemplary product manager and co-maintainer, was the one who noticed and also blogged about these collateral fixes.

If you consider this kind of work important, please consider getting them a coffee!

Elevado

Back when I was working on fixing accessibility on WebKitGTK, I found the lack of modern tools to inspect the AT-SPI bus a bit off-putting, so I wrote a little app to help me through. Didn’t think much of it, really.

But the project started getting some attention when Bilal Elmoussaoui contributed to it while testing some accessibility work in GNOME Shell. After that, Matthias Clasen – of GTK fame – and Claire – a new contributor! – started sending some nice patches around.

In preparation for the Global Accessibility Awareness Day we have made the first public release of Elevado! The project is evolving mostly without me these days, and it’s all thanks to these people.

GTK

Of course, almost nothing I’ve mentioned so far would be possible if the toolkit itself didn’t have support for accessibility. Thanks to Emmanuele Bassi GTK4 received an entirely new accessibility backend.

Over time, more people picked up on it, and continued improving it and filling in the gaps. Matthias Clasen and Emmanuele continue to review contributions and keep things moving.

One particular contributor is Lukáš Tyrychtr, who has implemented the Text interface of AT-SPI in GTK. Lukáš contributes to various other parts of the accessibility stack as well!

Design

On the design side, one person in particular stands out for a series of contributions on the Accessibility panel of GNOME Settings: Sam Hewitt. Sam introduced the first mockups of this panel in GitLab, then kept on updating it. More recently, Sam introduced mockups for text-to-speech (okay technically these are in the System panel, but that’s in the accessibility mockups folder!).

Please join me in thanking Sam for these contributions!

Infrastructure

Having apps and toolkits exposing the proper amount of accessibility information is a necessary first step, but it would be useless if there was nothing to expose to.

Thanks to Mike Gorse and others, the AT-SPI project keeps on living. AT-SPI is the service that receives and manages the accessibility information from apps. It’s the heart of accessibility in the Linux desktop! As far as my knowledge about it goes, AT-SPI is really old, dating back to Sun days.

Samuel Thibault continues to maintain speech-dispatcher and Accerciser. Speech dispatcher is the de facto text-to-speech service for Linux as of now. Accerciser is a venerable tool to inspect AT-SPI trees.

Eitan Isaacson is shaking up the speech synthesis world with libspiel, a speech framework for the desktop. Orca has experimental support for it. Eitan is now working on a desktop portal so that sandboxed apps can benefit from speech synthesis seamlessly!

One of the most common screen readers for Linux is Orca. Orca maintainers have been keeping it up an running for a very long time. Here I’d like to point out that we at Igalia significantly fund Orca development.

I would like to invite the community to share a thank you for all of them!

… and more!

I tried to reach out to everyone nominally mentioned in this blog post. Some people preferred not to be mentioned. I’m pretty sure I’ve never got to learn about others that are involved in related projects.

I guess what I’m trying to say is, this list is not exhaustive. There are more people involved. If you know some of them, please let me encourage you to pay them a tea, a lunch, a boat trip in Venice, whatever you feel like; or even just reach out to them and thank them for their work.

If you contribute or know someone who contributes to desktop accessibility, and wishes to be here, please let me know. Also, please let me know if this webpage itself is properly accessible!

A Look Into The Future

Shortly after I started to write this blog post, I thought to myself: “well, this is nice and all, but it isn’t exactly robust.” Hm. If only there was a more structured, reliable way to keep investing on this.

Coincidentally, at the same time, we were introduced to our new executive director Steven. With such a blast of an introduction, and seeing Steven hanging around in various rooms, I couldn’t resist asking about it. To my great surprise and joy, Steven swiftly responded to my inquiries and we started discussing some ideas!

Conversations are still ongoing, and I don’t want to create any sort of hype in case things end up not working, but… maaaaaaybe keep in mind that there might be an announcement soon!

Huge thanks to the people above, and to everyone who helped me write this blog post

---

¹ – Jeff doesn’t accept donations for himself, but welcomes marketing-related business

Now that the new planet.gnome.org website is live, we have added Libravatar and Gravatar support. Instead of having the Planet website host user images itself, we are giving members the choice to use profile images/avatars from these services.

If you are interested in updating your profile picture, check out the instructions at https://gitlab.gnome.org/Teams/Websites/planet.gnome.org#adding-an-avatar and file an issue. Extra points if you do a merge-request!

The old hackergotchis are an important part of our community’s history, so I set up a static website to host the old files. Feel free to file an issue if you want yours taken down from there.

Some people seem to have an outrageous number of containers on their system. That can create pretty bad performance with Ptyxis when it is using a GtkPopoverMenu to show you the container list.

Nightly will now use a custom popover backed by GtkListView which should help with that. Additionally, you can filter them now easily. To bring up the menu, alt+, can be used.

Now that libfoundry use has proliferated I need to get all the core abstractions in place for the proverbial 1.0.

There is already a device manager and provider abstraction in libfoundry with the typical back-ends. There are providers for the local system (so native architecture) and deviced which connects to a device on the local network.

Builder supports cross-architecture building and running even when you do not have a cross-toolchain available. So this must be added to Foundry too. The mechanics are handled by qemu-user-static and binfmt when properly packaged on your distribution. Fedora manages to have this setup correctly if you dnf install qemu-user-static.

Practically speaking, that means if you install a Flatpak SDK for another architecture you can use it to build/run your application (at a performance penalty). Qemu-user-static uses a combination of syscall-translation and instruction-translation which can have significant overhead, but it does work.

You can use Foundry now to do this rather easily.

$ cd project/
$ foundry enter
$ foundry device list
ID            Active  Name                             Chassis      System
qemu:riscv64  No      My Computer (riscv64 Emulation)  workstation  riscv64          
qemu:x86_64   No      My Computer (x64_64 Emulation)   workstation  x86_64           
native        Yes     My Computer                      workstation  aarch64-linux-gnu
$ foundry device switch qemu:x86_64
$ foundry run
...

Since I’m running on an aarch64 laptop right now, qemu:x86_64 device emulation is available.

If you have a cached build you might want to purge that so it doesn’t try to incrementally rebuild your project.

$ foundry pipeline purge
$ foundry run

If you want to export a Flatpak to test on another system, you can export as normal. However this time it will be for your alternate architecture.

$ foundry export
...
Artifacts:
  /path/to/x86_64-main/app.devsuite.Test.Devel.flatpak

Hopefully that makes things easier for people who want to test other devices/architectures such as GNOME on a handheld device.

• Mail chew, sync with Dave.
• Published the next strip around job titles, hierarchy and contribution:
• All Hands call, sync with Philippe, poked at an interesting bug.

• Planning call, catch up with Andras, monthly management meeting, sync with Tracie. openDesk partner call.

Hello GNOME!

I am Varun R Mallya, a 3rd-year engineering student at the Indian Institute of Technology, Roorkee. I’m now part of the GNOME community as a Google Summer of Code 2025 intern :). I will be working on the Sysprof project under the mentorship of Christian Hergert.

What I’ll be doing in the coming weeks

My proposal titled “Adding eBPF profiling capabilities to Sysprof” aims to add eBPF profiling capabilities to Sysprof. This will allow users to profile their applications using eBPF, which is a powerful and flexible tracing technology for the Linux kernel. The project will involve implementing a new backend for Sysprof that uses eBPF to collect profiling data, as well as integrating this backend into the existing Sysprof user interface.

You can take a look at my proposal here

I’ll start off by mostly validating what I wrote in the proposal and building small eBPF programs that achieve the functionality, even if inefficiently. My proposal aims to replace the data we got from /proc files using equivalent eBPF programs. Each time I manage to extract data for a type of /proc file, I will write a blog on how it works and exactly how I did it. It will indirectly serve as documentation for people who want to continue work on this after I’m done with it.

After I’m done with this, I’ll add a pipeline to Sysprof that will compile these programs and add them to the final ELF. This will involve a lot of work to make it compatible with older kernel versions since a small part of what I’m doing relies on features available in newer kernels (I might be wrong here, but I don’t know yet—I’m talking about bpf timers and bpf iterators). This will involve BTF and CORE, which I’m currently reading about.

About me

I like any kind of systems programming mostly. eBPF certainly gets me excited and I’ve been doing a lot of reading on it, to be very honest. I’ve also been working on a few open-source projects like GCC-Rust (GCC’s new independent Rust compiler btw, check it out), Reth (The Rust implementation of Ethereum), WasmEdge (A WebAssembly runtime) and I’m also involved in a few projects in my university. I’m actually a Mechanical Engineering student undergoing training, so I’m currently doing some research on drone swarming and GPU-based fluid simulations under my profs. Apart from this, I work on libp2p for Protocol Labs (currently doing some interop work between the Python and Go implementations of it.)

I recently saw somebody ask

Is Fedora accessible now ?

To which I want to say: yes! But this question does not really have a  simple yes-or-no answer. There is lots of nuance to it. A better question would be:

Is this system usable for *me* ?

Accessibility is about making our software usable (and, ideally, pleasant to use) for as many people as we can.

It has been a year since we last gave an update on accessibility (a11y) in and around GTK. Time to look at what has happened in this space since then. On the surface, it might seem that the answer is: not much. But lets look a bit closer.

A new backend

We merged the AccessKit a11y backend in GTK 4.18. This is pretty big news for GTK on platforms other than Linux. For the very first time, GTK applications can be accessible on Windows and macOS. This is also the first rust dependency in GTK.

If you want to try it out, build GTK with the -Daccesskit=enabled build option, and set

GTK_A11Y=accesskit

in the environment. The AccessKit backend works on Linux as well, but we are still defaulting to at-spi here. If you are ever uncertain which a11y backend GTK is using, you can find this information in the inspector.

The new backend was created by Matt Campbell as part the STF initiative.

Keyboard shortcuts in orca

One of the remaining gaps in the Wayland a11y support was the lack of support for the special keyboard shortcuts that are traditionally provided by the orca screen reader.

Another result of the STF initiative was a prototype for a new a11y protocol, including support for these shortcuts, but it was not complete and unmerged.

Thankfully, Lukáš Tyrychtr and Carlos Garnacho cooperated on extracting the relevant parts and completed the shortcuts support. This closes one of the biggest remaining “Wayland accessibility” gaps in  GNOME 48.

An accessible web browser

Georges Basile Stavracas Neto put a lot of effort into making webkitgtk accessible, in particular when it is used in a flatpak sandbox. You can watch his GUADEC talk from last year to learn all about the complexities of this task. But he succeeded, so GNOME Web is now a fully accessible, fully sandboxed web browser.

This was work was also supported by the STF initiative.

A new accessibility tool

Elevado is a new tool to let you browse and explore what apps expose on the a11y bus. The existing tool for this, accerciser, has not been in active development for a long time, so it is good to have an alternative.

The new tool just got ported to rust, so its cool. And it just saw its first release. Try it out!

Elevado was started by Georges to help with his work on a11y in webkitgtk.

The long tail

Beyond these big headline features, there have been many smaller improvements to a11y in GTK and related libraries:

• A number of missing accessible labels, tooltips and key bindings have been added in the file chooser
• List boxes now provide information to make orca say the right thing
• The a11y overlay in the GTK inspector will now show you when your buttons are too small as click targets
• ATs can receive notification about platform state (such as focus) changes, and custom accessible implementations can emit such notifications
• We now provide information about shortcuts and mnemonics for actions in the form that orca expects
• Reporting of text attributes has been improved (a contribution from the LibreOffice team)
• libadwaita toast notifications are now announced to AT
• The accessible representation of many libadwaita action row widgets has been improved

Summary

Accessibility in GNOME is continuously improving, thanks to the contributions of many people. Thanks to everybody who helps!

The big refactor

With Newsflash being one of the earliest gtk-rs applications it went through a lot of iterations already as the ecosystem evolved:

• from just slapping widgets together in structs to subclassing support in gtk-rs
• from just cloning everything to weak references with the clone!-macro
• from GtkBuilder xml to blueprint
• from interacting with Listboxes directly to GLib.ListModel based ListViews

 

 

Enclosures to the front row

So far Image, Audio and Video attachments were hidden behind a small button in the header bar. No more. With Newsflash 4.0 the article view is a hybrid of Gtk for the header with title, author, date, etc. And a web view for the HTML content. This means Newsflash can show widgets for attachments right in the article itself.

Misc

• Clear article pane if selection in article list goes away
• Allow manual hiding of the sidebar
• New user agent based on app name
• Option to set custom user agent per feed (only relevant for Local RSS)
• Subcategories (also mostly only relevant for Local RSS)
• Local RSS: in addition to etags, use cache-control header to reduce traffic to feeds

And many smaller fixes and improvements you can read about in the change log.

Sadly I had to deactivate the webkit DMABuf Renderer for now. I discovered a bug creating the now needed larger frame buffers for articles. Fingers crossed that this will get fixed and the DMABuf render can be re-activated.

Available on flathub beta channel

Version 4.0.0-beta1 is available on the flathub beta channel. The first few bugs have already been found and squashed. But I’m sure there are more to discover.

Make sure to back up your data and settings before switching to the beta in case a migration eats your database.
~/.var/app/io.gitlab.news_flash.NewsFlash/config/news-flash/
~/.var/app/io.gitlab.news_flash.NewsFlash/data/news-flash/

This is a response to Allan’s response to my most recent blog post. For context, I think it’s important to note that I’m happy that Allan is on the board now, along with some of the other new members coming from the community who joined in the past year. As I think I made clear in my last post, my concerns with the Foundation are with some of its structures, and the leadership predating this year’s board. I have huge respect for the effort Allan has put into the Foundation since he rejoined the board last year, I know it’s thankless work in difficult circumstances. I don’t know why Allan felt the need to issue a personal reply, seeing as this is not about him. However, since he did, I wanted to clarify a few points.

The Ban Itself

From the perspective of many people in the community, especially volunteers not affiliated with any company, Sonny was our representative on the board, trying to fix long-standing problems with the Foundation. Those of us who worked closely with him on the STF team knew how difficult and frustrating this was for him. In that already tense, low-trust situation, Sonny being banned the way he was obviously looks political — how could it not?

If you ban a board member after they try to address the community’s concerns with the Foundation you really need to do a good job communicating why you’re not just getting rid of uncomfortable opposition. What we got instead was silence and appeals to authority. Of course, given that trust in the structures was low to begin with, that was not very convincing to anyone who knew some of the backstory. “Trust me, I’ve seen more evidence” doesn’t work when there are serious concerns about the process as a whole.

My sense is that a big part of the problem is that the board/CoCC never tried to talk things through with Sonny to clear up potential misunderstandings in the CoC complaint, and as a result everyone is operating off of different facts.

Due to CoC confidentiality and the alleged infractions having happened in private settings without other parties present it’s incredibly hard to find any common ground here. I still think a mediation with everyone involved would have been a good path forward, but we’ve seen no interest from the Foundation side in continuing/re-starting something like that. Therefore, it seems we’re at an impasse — those who trust the structures will continue to do so, and those who don’t will continue not to.

The Aftermath

Allan’s post makes the claim that those of us criticizing the way this has been handled are asking for people who make important contributions to the project to be treated differently in the eyes of the CoC — I’m not sure where this is coming from, because nobody has asked for that.

However, in doing something as drastic as an immediate, long-term ban the board and CoC committee should be concerned with avoiding collateral damage. Other community members who are directly or indirectly affected should not be left hanging with no communication and lots of extra work.

Some thought should be put into which modules, programs, or initiatives might be affected by a ban, and measures taken to avoid adverse effects. None of that was done in this case. As an example: I was working with Sonny on a daily basis co-organizing the STF project, and even I didn’t get any official communication of Sonny’s ban when it happened.

In this case, the fallout from messing this up was massive. I don’t think I need to repeat what this meant for the STF project and contractors, but it didn’t stop there. For example, Sonny’s two Google Summer of Code interns also lost all contact to their mentor, with zero communication from anyone. Other volunteers had to scramble and fill in for Sonny, to avoid the interns failing their GSoC evaluations.

Independently of the questions around the validity of the ban itself, the damage caused by the way it has been (mis-)handled has been severe enough that someone should take accountability for it. While it’s true that some directors have apologized to the STF team in private, this does not seem sufficient given the gravity of the failures. There need to be some concrete consequences if the Foundation wants to be credible again in the eyes of the community.

The Independent Review

It’s true that there was an external review of the CoC decision, but unfortunately it did not bring any clarity. This is primarily because the evidence of the case itself was not examined at all, it was only a review of CoC procedures. The report we got was extremely vague and only made high-level process recommendations, it did not answer any of the actual questions around the ban.

This is why I’m confused about the claim that the report said the ban was justified — I’m assuming this was a misunderstanding. In my (and others, see e.g. Andy’s perspective) reading of the report, it only says that such a ban is within the purview of the CoC committee, and does not comment on the merits of this particular case.

---

There’s obviously a lot more to say, but my goal here was just to clear up a few misconceptions I’ve seen in recent discussions.

I’d like to thank everyone who has reached out and expressed their solidarity after the previous post. It’s clear that even a year later, many people across the community are still feeling hurt, confused, and isolated by the way this has been handled. Between that and the people who seem to think the elephant is just fine where it is and should be actively ignored I think we unfortunately have a lot to work through as a community.

I’d also like to thank Allan for the work he has done and is continuing to do on the Foundation side. I know having to deal with the fallout from this ban on top of everything else is not making things any easier. This situation really sucks for everyone, and I hope we can bring it behind us.

We are excited to announce that the GNOME Foundation is sponsoring an Outreachy internship project for the June 2025 to August 2025 internship round!

Outreachy provides internships to people subject to systemic bias and impacted by underrepresentation in the technical industry where they are living.

The intern will work with mentors Jonathan Blandford, Federico Mena Quintero, and Tanmay Patil on the project Add Wordlist Scoring to the GNOME Crosswords Editor.

The intern’s blog will soon be added to Planet GNOME, where you can follow their project updates and learn more about them. Stay tuned!

May 12 is the International ME/CFS Awareness Day. Since I have been living with ME/CFS for some time, I want to use this day as an opportunity to talk a bit about this topic.

The Illness

The main symptom of ME/CFS is an intolerance against physical, cognitive, and emotional exertion. For me, that means that activities like preparing dinner or cleaning my room can overload my body. Usually, the full consequences of this only become visible after roughly 24 hours. The state after such an overload is also called a crash. The resulting symptoms for me include exhausted muscles, feeling like I got the flue, pain in joints and muscles, disrupted sleep, brain fog, headaches, and more. Depending on the severity, these symptoms will disappear again after a day or a week of rest. Not resting during a crash, is an easy way to prolong the symptoms and just feeling incredibly miserable. Following these limitations is a bit challenging at times. Therefore, some of these symptoms are quite a frequent issue for me.

In contrast to severe cases of ME/CFS, I’m usually still having a considerable amount of energy available, with a score of 30 on the CFIDS Disability Scale. Cases with a score 0, which implies being constantly bedridden and unable to care for oneself, do exist. One of the recent more prominent cases has been the one of Diana (Physics Girl).

While I am able to manage my every day life, having to manage my resource that much, and planning ahead for basic tasks like my weekly hair wash is quite exhausting. Not having extra resources available for unexpected events in life is honestly also pretty frightening at times. Due to ME/CFS and other disabilities like Autism, I have been at “full reduced earning capacity” for more than 10 years now. That’s the formal term in Germany for people that can’t work at least 3 hours per day.

Perspectives for Treatment

ME/CFS is a syndrome, a label for a collection of symptoms that have been observed in many patients. Nobody knows what’s the cause, how it works, or even if it’s one illness or a bunch of illnesses that all manifest similarly. Equally, there is no direct treatment. There are some treatments that can be tried to manage some of the symptoms, but usually, it needs some luck to find anything that has any positive effect. Generally, ME/CFS can get better on its own. But, like everything with ME/CFS, the likeliness of this happening is unknown.

The key in managing ME/CFS is pacing. That means knowing one’s body’s limits and trying to not exceed them. This is especially important since, as described before, the main symptoms have a very delayed onset, making it impossible to just rely on the direct feedback of one’s body. If the body is clearly reacting, I am already deep in crash territory. For me, that especially means to limit physical activities like vacuuming to not more than 30 minutes and to lie down afterward. Walking is currently possible up to about 1 km on good days. But I am still struggling to follow what I know is good for me. But I am improving.

ME/CFS can be caused by infections like influenza or COVID. While COVID can cause a lot of different health issues, often lumped together under the vague term ‘long COVID’, ME/CFS is one of these potential long term effects. ME/CFS has long been mostly ignored by medical research, or worse, been labeled as a psychological problem that can be fixed by “just going out more” – which of course just worsens the symptoms. Even still, large studies are published that try to support these theories. While these studies are of laughable quality (German), they managed to hinder proper research and treatment for ME/CFS for far too long. What’s even more infuriating is that some of these studies seems to be influenced by insurances that want to avoid claims by ME/CFS patients. But COVID brought ME/CFS enough attention that things are slowly changing. A lot of trials for vastly different medications are ongoing. ME/CFS has also reached such an importance that treatment and research for it is explicitly mentioned twice in the coalition agreement of Germany’s new government. Research is slowly getting an idea of what is happening in the body of ME/CFS patients. Damaged Mitochondria, immune system reactions, changes in blood cells, involvement of the nervous system, abnormalities in brain MRI’s, and many more. However, it is still very much unclear which of these things are cause and which are effect.

Working on GNOME

I am very happy that I have the capacities to contribute to GNOME. Programming has been calming and fulfilling for me for a very long. I wish I could contribute more, but slowly chipping away on my projects is also fine :) Since last year, I have also started to accept donations and do a bit of contract work like for GNOME STF. This extra money, on top of my social benefits, helps me to buy some nice woodworking tools (I rarely have energy to use, oh no) or give me the luxury of not having to contemplate if I can afford to take a taxi to a doctor’s appointment. I am very grateful for that!

It’s been a big first week for me at the GNOME Foundation! I hear from many folks that they’d like to hear more about the goings-on inside the Foundation and this will hopefully be the first of many reports you’ll get from me. This one might be a tad verbose so please bear with me.

If I had more time I would have written you a shorter letter, and all that.

 

## Bootstrapping

It’s April 23rd. Whether you’re starting a new job, starting a company, or building your first house, everything is bootstrapping. I needed an email account — for obvious reasons but also because I’m the sort of person who won’t respond to GNOME-related email from my personal account. And email’s important. But to get an email address, it helps to know our SRE, so Rosanna connected me to Bart so I could start pesting him, despite the fact we hadn’t really had 15 minutes to sit down and chat over tea yet. Bart, as it turns out, is an insanely efficient person and so — despite the cart-before-the-horse email situation — I was set up with email, Nextcloud, and all our other services faster than perhaps any for-profit I’ve ever worked for. Off to a good start. (You can find my email on the Foundation’s Teams page and you are welcome to reach out to me there if you have a GNOME-related topic you’d like to discuss.)

 

## Linux App Summit

After that, I spent the weekend attending Linux App Summit, which Kristi was organizing. The conference was smooth, down to the tiniest details, and it’s the most included I’ve ever felt in an online conference, as a remote attendee. I even snuck in a couple live questions after the talks! All the talks were great, but if I had to choose my top 3, I’d say:

1. End Of 10: A Windows 10 to Linux Upcycling Campaign — Joseph works for our friends at KDE and this campaign is just so much fun. Get outside, meet some new friends, bring an old laptop back to life.
2. Tuba: A fork success story by Evangelos “GeopJr” Paterakis — For us old people, it’s easy to miss just how modern, easy, and delightful building apps like Tuba can be on the modern Linux desktop. GTK is mature, the stack is strong, and you can hack in TypeScript, Python, Rust, or Vala (which this talk is about). This talk does a fantastic job of telling that story. A lot of Linux users are already developers, local-first makes desktop development cool again, and I think they’re missing out on some modern fun.
3. I’ll cop out. Watch any of the Flatpak/Flathub talks. Flatpak rules. Because of it, I can run modern apps on Debian Stable in 2025! — and these were all great.

Of course, there were plenty of other juicy topics: AI, Android, Flutter on Desktop, Open E-ink, SPARQL, printers, GTK4, GNOME Circle, The Linux Ecosystem In The Large, and openKylin. I wish I’d been there.

Thanks to all the organizers, presenters, and attendees!

 

## FOSS United

I had a conversation with Nemo about his new position on the FOSS United Foundation board, what FOSS United was hoping to achieve, and how GNOME can be involved. I really like what they’re doing over there and I hope it’s the first conversation of many.

 

## Workgroup Work

We have some tool decisions to make. We’ve got a few places for CRM data at the moment, but it would be nice if we could consolidate. Raising money for the Foundation, in the large, means a lot of conversations. But for the time-being, we’ll stick with Nextcloud, GitLab, CommitChange, and all our current payment providers — as much as it everyone loves it when the newest and least-experienced staff member says “let’s switch tools!” we won’t do that just yet. If/when we outgrow these tools, we might consider Frappe, SuiteCRM, or another freie CRM tool. CRM is a tough nut to crack. There’s a reason Salesforce is worth a quarter-trillion dollars. (No, we will not be using Salesforce.)

We use Nextcloud for everything at the Foundation, including member accounts. I also use it at my friendly neighbourhood self-hosting group. While setting up my calendars, I found a bug in GNOME Calendar which led me to the GitLab issue, which led me to Jeff’s suggestion that someone test out the fix with GNOME Builder. I’d never done this. I hadn’t technically started working for the Foundation yet, and I love me a good yak-shave, so I thought I’d give it a go.

Y’all. GNOME Builder is bananas. I pulled the branch, clicked a button, and had a new GNOME Calendar to test in about… 30 seconds? No makefiles. No docker images. My bug was fixed, I switched from the .deb to the Flatpak (which I probably should have been on anyway), and the very heavens opened up.

 

## Meeting People!

I had a proper conversation with Bart, instead of just hounding him for favours. I’ll have to get accustomed to him dropping punchlines in the middle of random conversations so I don’t spit my chai all over my keyboard. Bart’s rad and if you use any GNOME services, he’s … the guy. It’s a good thing he’s very good at what he does. (Okay, he’s one of two guys, but we’ll get to Andrea soon enough.)

I chatted with Federico, who is one of GNOME’s original founders and someone I knew back in the early 2000s only by his hackergotchi. He sits on the board now. He’s sent me more policy docs and GitLab issues than I’ve even had time to read yet… thankfully, he’s a very sweet and patient person. GNOME is incredibly lucky to have one of its founders with the project after so many years.

I met my friend Richard, who’s a non-profit CRM consultant. I’m new to the non-profit game (at least as an employee), and I’m going to tap every resource I can. He had a lot of really good questions about GNOME’s brand awareness and where our revenue comes from. As I said in my intro post, we need to stabilize the Foundation’s books if we want to support development with more than infrastructure, operations, and events (not that those aren’t important!) and the more friends we have helping out, the better.

I began publishing my own onboarding docs for the Board and I started a Carmack-style .plan, in case any of the Board are interested in a firehose of transparency. I have a lot of thoughts on effective transparency but, when in doubt, start with the firehose. The .plan isn’t public because it contains a lot of PII. Sorry. Most of it will be turned into the base for these weekly notes. (Assuming I can keep up with these notes.)

It’s May 1st. My first official day of work. I chatted with Allan for a few hours. This would be one of many 3-hour calls with Allan, and I appreciate his seemingly-infinite patience. He’s contributing an absolute ton of time to keep things running but he also seems unphased by the work. British sensibilities, maybe, but I look forward to a time when I’m giving him space rather than taking it away from him. I started working on notes, documentation, and my first blog post in the GNOME world.

On May 2nd, I published my first post, explaining what this blog will be and added the blog to Planet. I had a call with Kristi, where I had an opportunity to thank her for all her work on LAS the previous weekend. Kristi really knows how to make these things work and I’m looking forward to helping her integrate those skills more deeply with the community. I have a lot to learn from her.

I had a call with Rosanna — our first since she interviewed me! Like Allan and Federico, she’s a walking archive of information about the project, the Foundation, and their history. It’s a good thing she’s so easy to talk to … I’m going to be spending a ton of time with her as I get booted up. Every minute spent with Rosanna is valuable. She’s currently handling all sorts of accounts, EORs for contractors and staff like me, conversations, contracts, financial reports, the bookkeeper… you name it. Again, I hope I’m soon net-positive in these interactions, instead of just asking a million questions over 3-hour meet.gnome.org calls.

As an aside: BigBlueButton is really good! Or maybe Bart’s maintenance of it is really good. I don’t know. But it’s been a fantastic resource. If you are tired of colleagues inviting you to Zoom calls with a thousand pop-ups stealing focus before you can even get on the call, meet.gnome.org is a membership benefit that I bet a lot of GNOME contributors under-utilize. If you’re a contributor, start using it! If you’re not, start contributing!

I spoke to an old colleague who was also an Outreachy intern in a former life. She had nothing but good things to say about the program and her mentor. I wanted to learn more about the program, how it could be improved (from her perspective, as a hacker), and other effective ways to introduce people to the GNOME community and GNOME hacking… Outreachy or otherwise. In the end, I felt she had some pretty lucid advice:

1. Meet people where they are. They might not be on Free Software platforms, so welcome them on Telegram, Slack, Discord, social media, etc.
2. Explain why GNOME is so significant in the first place. These folks are new to the industry and this is the least background they’ll ever have.
3. Help them submit a patch.
4. Help them learn skills to find a job. I hear TypeScript and Rust might be popular soon.

That was a long two days of video calls, but really energizing. I had a belief that people were working hard in (and around) GNOME, but evidence is the only true friend of science. I wasn’t wrong.

 

## Paperwork

May 5th, I configured some tax junk, drafted my intro blog post, got the lowdown on the horrible, illegal spam attacks on Matrix, and attended the Staff and Executive Committee meetings.

May 6th, I got my intro post onto Planet and Discourse … so the cat was out of the bag and I started getting inbound calls. And messages. And so on.

I had a great call with Julian to learn about his time on the Board and his thoughts on some current community tensions, including how we can improve transparency. I had another long call with Rosanna, where she started to provide me all the background on how we manage expenses, our grants, and how we do financial reviews. I had a call with an ex-colleague, Manu, who has a bunch of fundraising network connections for us. (Did I mention we could really use a CRM?) I set up a call with Joseph from endof10.org to talk about how we can collaborate.

May 7th, time to put myself on the Team page, make Rob and Allan suffer through (yet another) 3-hour onboarding call with me, spend 2 hours talking to Pablo about his time on the board, RFCs, GNOME Design’s vision, his transparency expectations of me, and his dreams for pmOS. And another 2-hour call with Rosanna because she apparently has infinite patience for teaching me. We talked about passwords, planning elections, 990s, and more financial reports. (501c3s have a lot of financial reporting!) She also suggested for a second time that I try to speak to Karen Sandler, who everyone I’ve spoken to thus far says is amazing. “You really need to talk to Karen,” is commonly heard. But since everyone on the planet seems to feel that way, Karen’s time is also very limited.

 

## End Of 10, Infrastructure

It’s May 8th. I had a long call with Joseph from KDE and End of 10 who, because of who he is, was willing to speak to me on his day off. What a great dude. I wasn’t sure what our relationship with our KDE friends would be like and I still have a lot to learn there. But I really hope we can find some strong alliances with them and other freie computing platforms. They are doing some amazing work — not just with eco.kde.org, but everywhere.

I got a chance to speak to Neil McGovern. I’ve spoken to Holly and Richard about their experiences as Executive Director, but Neil was in the role for a long time and it was really helpful to hear his perspective and pick up some of his old 501c3-focused resources.

Then: infra! I gobbled two hours of Bart’s valuable time to get an infrastructure walkthrough. Where are all our boxes? What services are we running? What’s our backup strategy/ies? How bad does a service outage need to be before I call you while you’re on vacation? The usual. Then I spoke to Andrea for a couple hours. He was previously with the Foundation as an SRE and he’s now a Principal SRE at Red Hat… but he still gives us a lot of time and love. He walked me through our costs and just how much in-kind donations we receive from AWS, DigitalOcean, Canonical, CDN77, and Fastly every year. It’s… a lot. GNOME infrastructure is non-trivial and it’s amazing it’s entirely handled by two people, one of which is a volunteer. And they maintain Flathub! Yeesh.

tl;dr – Our infra is well taken care of. I hope we can find people to help Bart and Andrea sooner than later, but the project’s in good hands.

Boring stuff: review the election schedule (Andrea again — thank you, Andrea!), get access to the bank, review a contract, clean up some GitLab vestiges from bygone eras.

I stayed up too late talking to Adrian (Vovk) on Matrix. We were both a little excited. I’m looking forward to chatting with him on a call soon. I don’t know much about GNOME OS, but I plan to!

 

## Today

MORE ONBOARDING. Yes. There’s plenty to learn. Our relationship to GIMP, the future of Flathub (both in management and sysadmin worlds), GUADEC, elections, the STF grant, Digital Wellbeing, the Travel Committee, Conflict of Interest policies, grant programs, event financing, the trifecta of Flathub + KDE + GNOME, and fundraising. Always Be Fundraising.

Rob and Allan have sat with me for ages, at this point. There’s more to go through. But I can tell you that if you were worried your President and Vice President aren’t grinding for you… well, they are. I don’t know when they sleep or do their day jobs.

This afternoon, I got a chance to speak with Alice about her work on libadwaita and with Rosanna about next week’s board meeting and her report prep for that. Also… more user accounts. There are quite a few financial tools required to keep the Foundation moving along, contractors paid, invoices cleared, and compliance met.

On that note: if you love accounting and want to spend some time on the Board with these lovely folks, there are elections coming up! Mmm. Spreadsheets.

I do apologize. This first weekly update was (a) more than a week long because I cheated and (b) mostly about my experiences… which isn’t very informative. I hope to tell more stories about what’s going on with the staff, the board, the community, our friends, and the project (as I see it) in the future.

See you next week!

The GNOME Foundation is delighted to announce the appointment of Steven Deobald as our new Executive Director. Steven brings decades of experience in free software, open design, and open documentation efforts to the Foundation, and we are excited to have him lead our organization into its next chapter.

“I’m incredibly excited to serve the GNOME Foundation as its new full-time Executive Director,” said Steven Deobald. “The global network of contributors that makes up the GNOME community is awe-inspiring. I’m thrilled to serve the community in this role. GNOME’s clear mission as a universal computing environment for everyone, everywhere has remained consistent for a quarter century—that kind of continuity is exceptional.”

Steven has been a GNOME user since 2002 and has been involved in numerous free software initiatives throughout his career. His professional background spans technical leadership, business development, and nonprofit work, and he was one of the founding members of Nilenso, India’s first worker-owned tech cooperative. Having worked with projects like XTDB and Endatabas and founding India’s first employee-own, he brings valuable experience in open source product development. Based in Halifax, Canada, Steven is well-positioned to collaborate with our global community across time zones.

“Steven’s wealth of experience in open source communities and his clear understanding of GNOME’s mission make him the ideal leader for the Foundation at this time,” said Robert McQueen, GNOME Foundation Board President. “His vision for transparency and financial resilience aligns perfectly with our goals as we support and grow the diversity and sustainability of GNOME’s free software personal computing ecosystem.”

Steven plans to focus on increasing transparency about the people and processes behind GNOME, reestablishing the Foundation’s financial stability, and building resilience across finances, people, documentation, and processes to ensure GNOME thrives for decades to come. You can read more from Steven in his introductory post on his GNOME blog.

Heartfelt Thanks to Richard Littauer

The GNOME Foundation extends its deepest gratitude to Richard Littauer, who has served as Interim Executive Director for the past ten months. Despite initially signing on for just two months while simultaneously moving to New Zealand and beginning a PhD program, Richard extended his commitment to ensure stability during our search for a permanent director.

During his tenure, Richard worked closely with the board and staff to pass a balanced budget, secure additional funding, support successful events including GUADEC, and navigate numerous challenges facing the Foundation. His dedication to ensuring GNOME’s continued success, often while working across challenging time zones, has been invaluable.

“I knew this day would come at some point,” Richard shared in his farewell post. “My time has been exceedingly difficult… I feel that I have done very little; all of the gains happened with the help of others.” Richard’s humility belies the significant impact he made during his time with us, creating a solid foundation for our new Executive Director.

Richard will return full-time to his PhD studies at Te Herenga Waka Victoria University of Wellington, but remains available to the GNOME community and can be reached via Mastodon, his website, or at richard@gnome.org.

Looking Ahead

As we welcome Steven and thank Richard, we also recognize the dedicated contributors, volunteers, staff, and board members who keep GNOME thriving. The Foundation remains committed to supporting the development of a free and accessible desktop environment for all users around the world.

The GNOME community can look forward to meeting Steven at upcoming events and through community channels. We encourage everyone to join us in welcoming him to the GNOME family and supporting his vision for the Foundation’s future.

During this quarter, all employees are asked to become familiar with using AI technologies. In the last months I explored using AI for code editing and pull request reviews, but I wrote about that separately. But today is another Red Hat day of learning, so I looked at something more hands-on: Install and run InstructLab on my own laptop again, and experiment with it. TL/DR: This just reinforced my experience from the last two years about AI being too bad and too expensive for what I would expect it to do.

Goal In the Cockpit team we spend a lot of our time on PR reviews. That’s time well spent – we all learn from each other, it keeps the code quality high and ourselves honest. But most certainly there is room for optimization: There are always silly or boring things like typos, inconsistent formatting, or inefficient algorithms; and humans also have selective and subjective sight, i.e. are often missing things.

Update on what happened across the GNOME project in the week from May 02 to May 09.

GNOME Foundation

steven announces

We have our first Foundation Report since I joined as ED! I hope these are less verbose and less rambling in the future… and also less focused on the minutiae of what I spent my week on. With each passing week, they will (hopefully) come to encompass more of what’s going on at the Foundation, at a higher level. For now, I’m meeting many, many lovely folks and finding out just how hard everyone is working.

Read the long ramble on my blog.

Internships

Felipe Borges announces

We are happy to announce that five contributors are joining the GNOME community as part of Google Summer of Code 2025!

This year’s contributors will work on backend isolation in GNOME Papers, adding eBPF profiling to Sysprof, adding printing support in GNOME Crosswords, and Vala’s XML/JSON/YAML integration improvements. Let’s give them a warm welcome!

In the coming days, our new contributors will begin onboarding in our community channels and services. Stay tuned to Planet GNOME to read their introduction blog posts and learn more about their projects.

If you want to learn more about Google Summer of Code internships with GNOME, visit gsoc.gnome.org.

GNOME Core Apps and Libraries

Video Player (Showtime)

Watch without distraction

kramo says

Video Player (codenamed Showtime) is replacing Videos (Totem) as GNOME’s default video player.

It will be included in GNOME 49, but it can already be installed from Flathub.

Third Party Projects

Jan Lukas says

I’ve released the first version of Typewriter to flathub. It is a, as of now, basic Typst editor with built-in live preview, template browser and export dialog. If you’re interested in a local-first Typst experience come join and contribute code and ideas.

Gitlab flathub

ranfdev announces

I’m announcing that DistroShelf is finally available on flathub ! Sometimes, there are certain programs that aren’t available on your favorite distro… They are available for Ubuntu, but you don’t want to reinstall your OS just for that program.

* DistroShelf enters the chat *

It enables you to run containers that are highly integrated with your host system, using distrobox. In other words, it lets you install that program you want, inside a Ubuntu container. Then, you can use the program as if it were installed on your real distro! The program will see all your folders, all your devices… as you expect.

But you can run more than simple ubuntu containers! You can run pretty much any distro you want. I use it to run a development environment with the latest and greatest tools, inside an arch linux container.

Try it while it’s hot!

Parabolic

Download web video and audio.

Nick says

Parabolic V2025.5.0 is here!

This release contains a complete redesign of the Qt/Windows app that features a much more modern experience. yt-dlp was also updated to the latest version to fix many website validation issues and some other features/fixes were added.

Please note, as many of you may have seen already, development of Parabolic and the set of Nickvision apps has slowed down. This is due to me starting a new full-time job and thus leaving only the weekends for me to work on these projects. This does not mean I am stopping development, it just means that releases, updates, and fixes will unfortunately take longer now. I appreciate all of your support and patience for these updates. Any C++ developers who would like to work on the projects with me as well are more than welcome too and are encouraged to reach out to me on Matrix!

Here’s the full changelog:

• Added the display of the file size of a format if it is available
• Fixed an issue where file paths were not truncated correctly
• Redesigned the Qt app for a more modern desktop experience
• Updated yt-dlp to fix some website validation issues

GNOME Websites

Felipe Borges announces

It’s alive! Welcome to the new planet.gnome.org!

A few months ago, I announced that I was working on a new implementation of Planet GNOME, powered by GitLab Pages. This work has reached a point where we’re ready to flip the switch and replace the old Planet website.

This was only possible thanks to various other contributors, such as Jakub Steiner, who did a fantastic job with the design and style, and Alexandre Franke, who helped with various papercuts, ideas, and improvements.

As with any software, there might be regressions and issues. It would be a great help if you report any problems you find.

If you are subscribed to the old Planet’s RSS feed, you don’t need to do anything. But if you are subscribed to the Atom feed at https://planet.gnome.org/atom.xml, you will have to switch to the RSS address at https://planet.gnome.org/rss20.xml

Miscellaneous

Sid says

GNOME GitLab now uses macOS runners sponsored by MacStadium for managing our macOS CI pipeline. The setup consists of 2 Mac mini (M1, 8-core CPU, 10-core GPU, 16GB RAM, 1TB SSD) along with Orka (Orchestration with Kubernetes on Apple) virtualization. This is a significant bump in hardware specs compared to the current solution, allowing us to run more builds simultaneously. Thanks to MacStadium for sponsoring this infrastructure upgrade!

For more details refer to https://blogs.gnome.org/sid/2025/04/27/macstadium-sponsors-gnome-macos-ci-infrastructure/.

That’s all for this week!

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

I'm usually not a huge fan of personal growth books. As I pointed out in my Blinkist review, most books of this genre are 300 pages long when all the content would fit on 20. I read Deep Work by Cal Newport, with an open but skeptical mind.

A case for deep work

The book is split in two main sections. In the first section, the author makes a case for deep work. He argues that deep work is economically viable because it can help you learn new skills fast, a distinctive trait to successful people in tech, especially when competing with increasingly intelligent machines. This argument is surprisingly timely now, at the peak of the AI bubble.

He then explains that deep work is rare because in the absence of clear indicators of productivity, most people default to appearing very active shuffling things around. This argument clearly resonated with my experience for all my career.

Newport closes the first section by explaining why deep work is actually important for us humans because it limits our exposure to pettiness, makes us empirically happier than shallow work, and because it helps us find meaning to our work.

Rules for deep work

In the second section, the author lays out the four rules to enable deep work:

1. Decide the length of your deep work sessions, establish a ritual for them, keep track of your consistency and hold yourself accountable to it, and refrain from overworking since it decreases your global productivity.
2. Since the Internet can be very distracting, establish some time blocks with Internet and some without, and enforce the rule strictly even if it seems silly.
3. Pick up the right tools for your job by assessing the positive but also the negative impact. Most of the time that means "get off social media." Also avoid fast-paced entertainment since it can undo all the day training and embrace boredom as a way to train your focus.
4. Use every minute of your day intentionally by scheduling them, even if that means redoing your schedule several time as new priorities emerge. Quantify the depth of your work and ask your boss for a shallow work budget. Finish early so your day is tightly time boxed and shallow work becomes even more expensive (so easier to refuse). Become hard to reach so you don't spend your day in your inbox.

An insightful book

Like in all personal growth books, storytelling takes many pages in Deep Work, but here it supports nicely the argument of the author. The book was pleasant to read and helped me question my relationship to technology and work.

In the first section the author backs his claims about the importance of focus with evidences from academic studies. Of course since the second section is all about establishing new rules to allow deep work, it's not possible to have proofs that it works. With that said, I bought a late edition and would have liked an "augmented" conclusion with evidence from people who used the methodology successfully in the real world.

You can find my key takeaways from the book by having a look at my reading notes.

I’m incredibly excited to serve the GNOME Foundation as its new full-time Executive Director.

As Richard mentioned, I am receiving the baton from him, after his tenure as the GNOME Foundation’s interim Executive Director. Richard helped guide the Foundation through some rough terrain and, after all that, I’m especially grateful that Richard has been so generous with his time. All the best, Richard. Thank you for everything you do! It always feels good to make a new friend like Richard and I don’t think he’ll be a stranger to the GNOME community, even once he’s neck-deep in his PhD thesis.

It is precisely that community — that global network of friends — that has me so excited to work with the GNOME Foundation. The word “excited” really doesn’t do it justice. I have been involved in many free software, open design, and open docs efforts over the years. But none of those have the gargantuan history, community, and installed base of GNOME. It is a privilege to serve GNOME, and I’m grateful. That gratitude is the entire reason I’m here and I’d like to take the rest of this post to explain where that feeling comes from — and what I hope to do with it.

 

## My story

Since I am new to the GNOME community, I’ll start by sharing some background on myself.

I grew up in a village of 1000 people in western Canada and, within that village, I was unquestionably “that computer nerd kid.” I built a graphical MUD before the term “MMORPG” was coined. The code was awful. I started my first web development company when I was 15 years old. It was very 1996.

      

I started a couple more businesses in University, around the time I started using Linux and GNOME: MonoHost, which provided ASP.net webhosting on Linux, and a small software consultancy. Neither of those stuck.

After University, my professional software career can be broken down into two 10-year chunks: pre-crash and post-crash.

The first ten years is a blur. I joined ThoughtWorks when they had fewer than 500 employees, got involved in the early agile (lower-case “a”) software movements, used Rails before 1.0, wrote C#, Ruby, Java, JavaScript, and Clojure, joined DRW, built large distributed systems, led teams, got bored, moved to India, and started Nilenso Software with seven friends. Nilenso Software is India’s first employee-owned technology cooperative and it still exists today.

Two years into Nilenso, I had a bicycle crash and three botched eye surgeries while visiting a client in California. I was left partly blind. I have a crushed optic nerve, vitrectomy, and scleral buckle. (I suggest… not looking up example videos.)

After the bicycle crash, I found it difficult to code — or even use a computer at all, at certain contrasts. White backgrounds, for example, still cause me instant headaches. And so I began a decade of recruiting, sales, management, startups, fundraising, and product consulting. After leaving Nilenso, I volunteered with nonprofits and worked on two open source database products: XTDB and Endatabas. After closing down Endatabas, I began interviewing with the GNOME Foundation, which brings me here.

I moved back to Canada during Covid and I now live in Halifax, on the east coast. (One timezone east of New York, Europeans will be happy to note!) I still ride bicycles. I run in the park, swim in the ocean, canoe to islands, and climb rocks. I play board games. I write a little code on weekends. I meditate Vipassana. I have an off-grid cabin by the ocean that requires constant repairs. I drive an old truck. Due to an inside joke that went too far, I only wear black suits with white shirts. On any given day, I can smoothly transition between business meetings, weddings, and funerals. As one does.

Over the past three decades, I have been inspired by many open source projects but the aspect of GNOME that inspires me the most is the clarity of its mission. There is never any disagreement about the mission: GNOME is a universal computing environment. It is for everyone, everywhere.

I’m in awe of this.

If you’ve ever been involved in the creation of a software product, you’ll appreciate just how exceptional it is for one product (especially one so large) to retain a single mission like this for a quarter century. That kind of continuity doesn’t just magically happen. Let’s talk about that for a second.

 

## Gratitude

Over the past few days, with each conversation I’ve had with folks in the community, I found myself increasingly grateful for the decades of work put into GNOME. A person forgets just how much time, energy, leadership, and passion has gone into a project of this size.

I’ve been using GNOME since 2002. By the late 2000s, it was becoming very easy to take GNOME for granted. By GNOME 3, it’s safe to say I did take GNOME for granted. This is a good thing, in a way. We take the water utility or electricity in our homes for granted precisely because they work so perfectly and invisibly that their origins can be forgotten.

But GNOME isn’t financed by billions of tax dollars. It’s easy to forget that, too. My friends and colleagues over the years have compared GNOME to MacOS and Windows, apples-to-apples, as if GNOME were also built by a 3-trillion-dollar corporation. If your open source project is compared favourably to competitors with a $6T aggregate market cap, you’re doing something right.

This continuity is magical, but it’s magic created by the many contributors who make GNOME happen, release to release, year after year.

I don’t want to feel this gratitude alone. As part of our work at the Foundation, I hope we can bring this feeling to many of GNOME’s users.

 

## Transparency

Bringing that feeling to users means showing them the people and processes behind GNOME. None of us can understand infrastructure like GNOME without a window into it. So many of the systems we rely on every day are hidden from us. I have always loved this Hans Rosling comment:

Sometimes, when I turn the water on to wash my face in the morning and warm water comes out just like magic, I silently praise those who made it possible: the plumbers. When I’m in that mode I’m often overwhelmed by the number of opportunities I have to feel grateful to civil servants, nurses, teachers, lawyers, police officers, firefighters, electricians, accountants, and receptionists. These are the people building societies. These are the invisible people working in a web of related services that make up society’s institutions. These are the people we should celebrate when things are going well.

The contributors, maintainers, board members, and Foundation staff are these plumbers. Even in my short few days with the Foundation, I’ve seen everyone working hard behind the scenes to keep the lights on and ensure GNOME 49 will be a success, even if it feels like GNOME 48 was just released moments ago.

I want millions of GNOME users to see what I’ve had the privilege to see: the life and energy of the folks who keep GNOME running for us.

We should celebrate. We have every reason to.

 

## Intentions

Of course, transparency isn’t a switch we can just turn on. It’s a constant effort we apply to our own processes. It’s iterative. It’s work. But it can also be fun! Knowing that everyone else is trying their hardest can be the most energizing motivation, and I’m excited to help.

Beyond transparency, I hope we can re-establish the GNOME Foundation’s … well, foundations. The Foundation exists to support GNOME, to support design and development, to support contributors.

A big part of this is financial stability. Ultimately, the Foundation should support new growth. But to begin with, we need bedrock.

One word to describe these intentions is resilience: across finances, people, documentation, and processes. Let’s build an environment that lasts another 27 years.

 

I would like to have my blog indexed on GNOME Planet. GNOME Planet’s repo, however, doesn’t appear to be licensed – there’s no note about the license on https://gitlab.gnome.org/Infrastructure/planet-web, and no license file in the repo.

It would be difficult to add a license now, as there have been thousands of commits to the repo, with a lot of individual contributors. Relicensing might require contacting each one of these authors.

But I don’t like committing to repositories which are not licensed. I’m not even sure I can – do I maintain my copyright, or does the new owner? How would that fall out in court? In which jurisdiction is gnome-planet – the US?

So I asked ChatGPT (itself a pretty odd legal move) whether I could license a commit. Unsurprisingly, it says that no, you can’t, because a repository is a work in itself, and that license would take over. This is obviously garbage. When I asked it to clarify, it said that you might be able to, but it would “violate norms”. Sure, that seems accurate, but I am glad that ChatGPT is not my lawyer.

I figure, if my work is my work, there’s no reason I can’t license a change to a file. Whether not that license will be enforced is anyone’s guess, but legally, I should be responsible for my own lines of code. So, I opened this pull-request: https://gitlab.gnome.org/Infrastructure/planet-web/-/merge_requests/163. I noted in the commit that the license is an MIT license, and then I noted that in the PR comment field, too.

Technically, the MIT license demands that the license be shared with the commit. So I’ve just amended the commit to include the license, too, which satisfies my needs.

I don’t think that there will ever be a technical issue with licensing for this repo. And I don’t know if Felipe will merge my commit. But it is an interesting experiment.

➜ planet-web git:(feat/add-my-feed) git show HEAD
commit 3acaff792c635e9c277d892f37b45997b0b57d70 (HEAD -> feat/add-my-feed, richardlitt/feat/add-my-feed)
Author: Richard Littauer <richard+github@burntfen.com>
Date: Tue May 6 09:38:38 2025 +1200

Adding my ID

This commit is licensed under an MIT license.

MIT License Copyright (c) 2025 Richard Littauer

Permission is hereby granted,
free of charge, to any person obtaining a copy of this software and associated
documentation files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to the
following conditions:

The above copyright notice and this permission notice
(including the next paragraph) shall be included in all copies or substantial
portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF
ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

diff --git a/config/gnome/config.ini b/config/gnome/config.ini
index 9ea71857..4829be43 100644
--- a/config/gnome/config.ini
+++ b/config/gnome/config.ini
@@ -3513,3 +3513,7 @@ outreachy = 1
[https://conduct.gnome.org/feed/]
name = Code of Conduct Committee
#nick =
+
+[https://blogs.gnome.org/richardlitt/feed/]
+name = Richard Littauer's blog
+nick = richardlitt

A few weeks ago I was invited to talk about firmware updates for servers using fwupd/LVFS at Prem’Day 2025. I gave the hardware vendors a really hard time, and got lots of instant feedback from customers in the the audience from the “little green thumbs” that people could raise. The main takeaway from the Prem’Day community seemed to be that proprietary tooling adds complexity without value, and using open ecosystems enable users to better operate their infrastructure.

Since getting back to the UK I’ve had some really interesting discussions with various companies; there might be some nice announcements soon.

Recently, Tobias Bernard posted a retrospective of his (and our) experience engaging with the GNOME Foundation regarding the removal of Sonny Piers from our community, followed by a response from Allan Day. I know it's difficult and stressful to talk about; a lot of people just want it to go away. It took a long time to write this.

The details regarding the removal of Sonny Piers will never be publicized, but I respectfully disagree that all discussion of the community impact should happen internally. Regardless of the circumstances at the time, the GNOME Foundation made a decision to publicly remove Sonny Piers from the community and if we are asked to assume good faith, we should be able expect the same good faith when we criticize governance.

# Safety in the Community

The case of Sonny Piers includes GNOME Foundation membership, a seat on the board of directors and employment as a project coordinator. Circumstances these complex do not relate to the Code of Conduct Committee (CoCC) in its typical operation.

The Engagement Team also plays an active role in day-to-day moderation, as well as the community members from diverse backgrounds serving as moderators in the many project channels. Recently a member of the CoCC helped organize a communication channel and new guidelines for moderators, which has already improved coordination and response times across the various platforms.

The GNOME community is a safe place to engage in open source and the matters discussed here should not prevent you from reporting an incident or flagging content for moderation.

CoC Links

• Code of Conduct
• Report an Incident

# Opaque Context

The following is a very incomplete timeline, providing some amount context for my personal perspective.

In July 2024, many of us in the community were shocked to hear that Sonny Piers had been removed as a GNOME Foundation director, stripped of his membership, had all accounts locked and a permanent ban put in place. More unsettling, he was named as the recipient of a Code of Conduct complaint, but obviously without any details regarding the incident.

With such limited information, for many there was little justification to protest the decision itself, except that the degree of disciplinary action implied behaviour extremely out of character for Sonny.

By October, three months had passed and lacking any meaningful resolution, enough concern had grown in parts of the community to have a conversation. It was decided to compose a letter directly to the Board and, after lengthy discussion of the content, those that agreed signed and it was received generally well by the Board.

The resulting meetings were draining for everyone involved, often with visible exertion of good faith from those present. The many constructive results include several amendments to CoCC procedures, more comprehensive and equitable agreements for contractors, and a fair amount of clarification regarding the constraints the Board was under at the time.

By December, I had withdrawn from most social spaces in the community. During the period of engagement with the Board, there were a conspicuous number of public references made to toxic influencers and after a very disappointing comment from a relevant party, I closed my Mastodon account. Aside from compounding the stress of the meetings, I considered I might be compelled to publicly defend Sonny and compromise our efforts with the Board.

In January, Tobias published Re-Decentralizing Development and seeing the reactions include sentiments like "Cult of Sonny" more or less vindicated my decision to withdraw from social spaces. Some clearly assumed there had been no effort to resolve the matter internally and the spectre of a toxic influencer meant attempts to engage publicly were unlikely to be taken in good faith.

# Good Faith

There are legitimate concerns about an effort to undermine the Code of Conduct (CoC), for the sake of meritocracy. In other words, there are those concerned about different rules being applied to those who contribute more substantially or have more social capital. This is not paranoia; it's the state of justice in many of our real-world societies.

The opposing concern is that the CoC has been used as a tool to defend the status quo or enforce minority opinion as policy. Or as Tobias puts it:

[...] we’re now in a situation where large parts of the community do not trust our CoC structure because they feel it can be weaponized as part of internal power struggles.

Code of Conduct reports must be confidential and the decisions of the committee must be unimpeachable; under no circumstance can they become a matter of public opinion.

Unsurprisingly, there are very few situations that justify revealing any participant of a Code of Conduct report. Doing so has resulted in reputational damage such that an uncensored Google search of the name "Sonny Piers" returns pages of tabloid smear and speculation of criminality. Yet in the many months since, there has been no indication that this served the interests of community safety.

Although I acknowledge the community ban has since been relaxed to one year, I would like if we could each appreciate that to be stripped of membership, barred from ever holding a position in the Foundation and permanently banned from all community spaces is to be told, "You are irredeemable". Again, in the time of Sonny's absence, there have been no signs that the safety of the community ever warranted a permanent ban.

The good faith assumption seems to be that these actions were taken to send a message: the Code of Conduct will be enforced, regardless of a person's stature in the community. Unfortunately, if that was the intention, a number in the community have already expressed confusion that this situation received treatment so different from their own.

# Trust and Accountability

I spent a fair amount of time recently deciding whether I would renew my Foundation membership or not. Those in the Foundation working to rectify the breakdown of communication and policy are the reason I decided to stay. However, there are also those in the Foundation who have made me feel an unwelcome bystander to the very public condemnation of a colleague, only be told not to cause a fuss.

I strongly believe the CoCC operated on an unfounded assumption of bad faith: that Sonny Piers is a toxic influence to be immediately and permanently removed from the community. Since July, none of the corroborating signs have surfaced; few have had more contact with Sonny than a short email response, there has been no public appeal to gather signatures, no coup d'état in the Foundation and, with two months left on the community ban, fears of him being exempt from the rules seem moot.

A number of the recent policy improvements were prompted by the findings of the external review commissioned by the Foundation, but I'd like to clarify this was an assessment of whether the Code of Conduct Committee acted within its scope and authority; not a judicial review. The severity of corrective action has not been justified, nor did any review findings or policy changes apply retroactively.

While the Foundation has and will continue to improve, it seems unlikely we will see accountability for the mishandling of a situation that has caused damage to an individual, to the community and trusting relationships. For trust to be restored, we must be assured that Code of Conduct Committee is free from conflicts of interest and is only applied in the interests of community safety.

# Final Thoughts

I don't know what to do about this. I know there are those in the Foundation working very hard to improve the situation and those on the Board aware that they can just ignore criticism until their seat is up for re-election.

The GNOME Foundation is becoming a more important part of the GNOME project every year, but it is still extremely opaque to most of us. If there is a way to educate oneself as a voter I do not know it, and we must accept that has become a serious problem.

We can not have confidence in leaders elected on vague familiarity and then expect accountability from elections separated by two years. And the GNOME Foundation can not build trust in governance by appealing to its own authority.

April was light.

exempi

Released Exempi 2.6.6 to fix security issues from upstream.

libopenraw

Some minor fixes in the thumbnail extraction, with JXL support and locate larger Panasonic previews. Extract the exposure bias for Fuijfilm files. Added the latest Canon cameras (still the support of CR3 is work in progress).

Released alpha.10 on May 1st.

This blog post talked about the "self written C++ standard library" I wrote for the fun of it (code here).

The post got linked by Hackernews and Reddit. As is usual the majority of comments did not talk about the actual content but instead were focused on two tangential things. The first one being "this is not a full implementation of the C++ standard library as specified by the ISO standard, therefore the author is an idiot". I am, in actual fact, an idiot, but not due to project scope but because I assumed people on the Internet to have elementary reading comprehension skills. To make things clear: no, this is not an implementation of the ISO standard library. At no point was such a thing claimed. There is little point in writing one of those, there are several high quality implementations available. "Standard library" in this context means "a collection of low level functions and types that would be needed by most applications".

The second discussion was around the fact that calling the C++ standard library "STL" was both wrong and proof that the person saying that does not understand the C++ language. This was followed by several "I am a C++ standard library implementer and everyone I know calls it the STL". Things deteriorated from there.

The complexity question

Existing container implementations are complex by necessity. They need to handle things like types that can not be noexcept moved or copied. The amount of rollback code needed explodes very quickly and needs to be processed every time the header is included (because of templates). A reasonable point against writing your own containers is that eventually you need to support all the same complexity as existing ones because people will insert "bad" types into your container and complain when things fail. Thus you need to have all the same nasty, complex and brittle code as an STL implementation, only lacking decades of hardening to shake out all the bugs.

That is true, but the beauty of having zero existing users is that you can do something like this:

This is basically a concept that requires the type given to be noexcept-movable (and some other things that could arguably be removed). Now, instead of allowing any type under the sun, all containers require all types they get instantiated with to be WellBehaved. This means that the library does not have to care at all about types behaving badly because trying to use those results in a compiler error. A massive amount of complexity is thus eliminated in a single stroke.

There are of course cases when you need to deal with types that are not well behaved. If you can tolerate a memory allocation per object, the simple solution is to use unique_ptr. OTOH if you have types that can't be reliably moved and which are so performance critical that you can't afford memory allocations, then you are probably going to write your own container code anyway. If you are in the position that you have badly behaved types that you can't update, can't tolerate an allocation and can't write your own containers, then that is your problem.

Iterating things the native way

One of the most common things I do with strings in Python is to split them on whitespace. In Python this is simple as there is only one string type, but in native code things are more complicated. What should the return type of mystring.split() be?

• vector<string>
• vector<string_view>
• A coroutine handle
• The method should be a full template so you can customize it to output any custom string type (as every C++ code base has at least three of them)
• Something ranges something something

There is probably not a single correct answer. All of the options have different tradeoffs. Thus I implemented this in two ways. The first returns a vector<string> as you would get in Python. The second one was a fully general, lazy and allocation-free method that uses the most unloved of language features: the void pointer.

So given that you have a callback function like this:

the split function becomes:

This is as fully general as you can get without needing to muck about with templates, coroutines or monads (I don't actually know what monads are, I'm just counting on the fact that mentioning them makes you look cool). The cost is that the end user needs to write a small adapter lambda to use it.

Iterating things the Python way

The Python iteration protocol is surprisingly simple. The object being iterated needs to provide a .next() method that either returns the next value or throws a StopIteration exception. Obviously exceptions can't be used in native code because they are too slow, but the same effect can be achieved by returning an optional<T> instead. Here's a unit test for an implementation of Python's range function.

Sadly there is not a simple way to integrate this to native loop constructs without macros and even then it is a bit ugly.

Current status

The repo has basic functionality for strings (regular and enforced UTF-8), regexes and basic containers.

Building the entire project has 8 individual compilation and linking steps and takes 0.8 seconds when using a single core on this laptop computer. Thus compiling a single source file with optimizations enabled takes ~ 0.1 seconds. Which is nice.

The only cheat is that pystd uses ctre for regexes and it is precompiled.

I knew this day would come at some point. It is time for me to say farewell to the GNOME Foundation in my capacity as the Interim Executive Director.

Last summer, Rob McQueen messaged me in mid-June asking if I could come on and help GNOME out as the Interim Executive Director. I had applied for the position the year before, and so he was familiar with my work. Some of the other board members knew me well, too – Karen Sandler and Michael Downey had both crossed my paths many times through SustainOSS. Rob wanted me to start as soon as possible, and to fill in as much as I could.

I told him, in no uncertain tones, that this was flat-out impossible.

First, I was one week away from moving to New Zealand from Vermont. The international move had been planned for a couple of years, and was right in the middle of happening. I had signed on to do a PhD at Te Herenga Waka Victoria University of Wellington. I already had a job as one of the co-organizers of CURIOSS and SustainOSS, where I also hosted a weekly podcast. And I had a job as a language consultant, making languages for novelists. I didn’t have a house lined up in Wellington. I would be arriving in winter.

Rob asked very nicely. Somehow, I said yes – on the condition that I would do it part-time, and that they would ramp up their efforts to find a permanent ED as soon as possible, and that under no account would that be me. I signed up for a two-month contract.

That was ten months ago. I went on to renew the contract for another month, and then another two. For the last five months, I have been working with very limited hours and helping where absolutely necessary.

Today, I am happy to say that I am rolling off, because a new Executive Director – a permanent one – has been hired. I am overjoyed. This is exactly what GNOME needs, and I think that he is the right person for the job.

My time has been exceedingly difficult. In the first couple of days on the job, I realized that I would be needed back at GUADEC in Denver, so I flew back from New Zealand for it. I met many on the staff and the board for the first time. For many reasons, that week was incredibly stressful. Slowly, slowly, things got better.

I feel that I have done very little; all of the gains happened with the help of others.

Because of Zana’s leadership and amazing institutional memory, and Michael Downey and Pablo Correa Gómez’s meticulous financial help, we were able to pass a balanced budget through the board, on time. Thank you.

Because of Rob’s long hours and all-encompassing understanding of GNOME, we were able to secure more funding from the Dalio Foundation to help move us forward. Thank you.

Because of Allan Day’s incredibly steady hand and ceaseless effort, we were able to navigate some incredibly difficult conversations that the board was having. Thank you.

Because of the staff – Kristi, Anisa, Zana, Melissa, and Caroline – we managed to host not just a fantastic GUADEC, but also other great events around the globe. Thank you.

Because he was open to be peer-pressured into taking it, Julian Sparber made amazing minutes from all of the meetings we attended. Thank you.

Because of Bart, everything kept running. I think this is what Bart does. Thanks Bart.

Because of Holly’s generosity, I was able to take over much more smoothly. Thank you for your time, Holly.

Because of Federico Mena Quintero and the Code of Conduct Committee, many issues were resolved with contributors, and I’m not talking only about elephants in rooms. I cannot overstate how hard this work is and how much of a struggle it is to do it well. I’m constantly grateful for them keeping spaces safe.

That also applies to other people in the community – thank you, Sri Ramkrishna, Deepesha Burse, Justin Wheeler. I’m missing people. I’m grateful anyway.

Because of Thibault Martin, I was able to figure out what was going on and how to ensure that everyone under STF contracts got paid. Thibault, I miss our almost daily meetings! Thank you.

Because of people in the wider community, I was able to get expert help for tough questions. Thank you to our lawyers, our accountants, and, of course, people like Deb Nicholson of PSF and Robin Riley of Matrix and Leah Silen of NumFOCUS and Gunner of Aspiration and Abby Cabunoc Mayes of SustainOSS and Duane O’Brien and so many, many others. There are many, many people in open source and in the computing space that rely on or support GNOME without ever being thanked, and in some cases without knowing it. Thanks to my partner, Julia – she woke up for those 2:00am board meetings, too (although she mostly fell back asleep). Thank you.

Cassidy Blaede and Philip Chimento stepped up to fill board seats, and because of them we have a stronger board. Karen Sandler, you’re my favorite person. Erik Albers, your calm presence kept all of us on track at the GUADEC board meetings. Thank you.

Because of our sponsors, and everyone on our advisory board, GNOME is able to continue doing what it does. Advisors, thanks for smiling and nodding as I said nothing at all over nachos in Denver. You’re doing the good work. Thank you.

And then, of course, there’s the rest. People like Sid T – I’ve rarely met someone as dedicated and perseverant as Sid. It’s because of him that MacStadium is now sponsoring us. Sid, thank you.

Adrian, thank you. Marie, thank you. Tobias, thank you. Alexandre, thank you.

I could, and should, go on. I know I’ve missed people. I’m not perfect. My time here wasn’t perfect. I’ve lost many, many hours of sleep, not only due to the 2:00am calls, but because some of the decisions I have had to deal with have stretched me, and made me so much more appreciative of the work of other executive directors I know who run similar foundations. (Karen and Michael, when do you sleep). I’ve made mistakes. They are my own, and I am sorry.

Since starting, I have had a single minded goal to make sure that GNOME survives until the next executive director and that I make their job easier. I hope I have succeeded in that goal. But, again, I didn’t accomplish that on my own. That’s not how an Interim Executive Director works. For the last few months, Allan, Rob, Julian, and Zana have been working overtime to allow me to focus on my own work. I am thankful for them, and I think you should be, too.

Steven will do a great job. I wish you the best time of it, Steven – you couldn’t ask for a better community to work with.

I am not, in fact, dying, although this does sound rather eulogaic. I’m just going to spend more time as a user now. I might even have time to post updates on this blog. I hope so.

Reach out whenever, anyone, everyone. I like connecting people. And I like doing what I can to help. You can find me on Mastodon, at my website, and at https://richard.social. Or at richard@gnome. I’ll keep checking it.

Until then,
Thanks.

P.S. It really is pronounced /gno:m/, it’s just so much more fun that way. And the foot logo should stay, alright, it’s a good logo.

 

Some links for technical articles on various topics I read.

The Defer Technical Specification: It Is Time - Explains the proposal for the next C language standard for defer.

A guide to implement ActivityPub in a static site (or any website) - A guide to implement ActivityPub in a static website.

20 years of git - An history of git and its early days.

Celebrating Git's 20th anniversary with creator Linus Torvalds - An interview with Linus Torvalds on the 20 years of git.

I use Zip Bombs to Protect my Server - A technique of serving compressed zeros that a lot of bots don't handle properly.

6 usability improvements in GCC 15 - New in a GCC 15 near you, better error messages.

We have replaced Buildbot with a custom service, and we hope you haven't noticed.

Vorarbeiter is a German word for "foreman" and a living proof of my school-related trauma. The new service is a middleman between GitHub and GitHub Actions. It has been happily humming since April 21st, and largely does what Buildbot did: builds apps, with a sprinkle of publishing logic.

While what happens under the hood is solid, there is no UI yet. Flathub bot will still inform developers about build status for their pull requests, but there is little visibility of what happens post-merge.

Additionally, Vorarbeiter no longer allows to manually publish, cancel or delete builds. The publishing happens every hour regardless of the age of the build. The previous 3-hour-long delay was too conservative, and barely anyone was giving a final test for a post-merge builds. Similarly, cancelling builds doesn't seem as necessary as before. GitHub Actions runners are ephemeral and new commits on the same branch or pull request will automatically cancel the previous in-progress build.

Last but not least, because of limitations of the free GitHub Actions runners, some apps are designated as large builds. Large builds take place on machines provisioned in AWS, boasting faster CPUs and larger disks to accommodate heavier requirements.

While large builds do not incur costs per se thanks to the generous AWS credits for open source projects program, we still want to be mindful of how much credits we are spending, which is why we don't run large runners all the time. This is possible thanks to RunsOn, which handles all the magic for us. It receives pipeline events from GitHub and provisions new machines automatically within seconds, and tears them down the moment the build is finished. This is completely invisible to developers, but is both faster and more cost-effective, even if we were to pay the bill ourselves.

There is still more work to be done. I want to improve observability of the new service to make sure we can have automatic alerts when we have an abnormal build error rate or unprocessed publishing queue. In fact, we already notify maintainers and Flathub admins when a build triggered on the master branch failed, but there is potential to be more proactive here.

The unsolved challenge so far is caching. Every new pipeline re-downloads Flatpak runtimes, SDKs, and source code needed to build the app. Ideally, we should cache at least the runtimes, but with runners being ephemeral, we should also attempt to implement a distributed solution for ccache to reduce build times.

Given the challenging circumstances, this is more than good enough, though! If you encounter any issues with the new workflow, don't hesitate to open an issue in the project's GitHub repository.

Update on what happened across the GNOME project in the week from April 25 to May 02.

GNOME Core Apps and Libraries

Calendar

A simple calendar application.

Hari Rana | TheEvilSkeleton reports

As part of our volunteer-driven accessibility initiative in GNOME Calendar, and for the first time in the 10+ years of Calendar’s existence, we finally completed and merged the first step needed to have a working calendar app for people who rely on keyboard navigation. This merge request in particular makes the event widgets focusable with navigation keys (arrow left/up/right/down) and activatable with space/enter.

Most of GNOME Calendar’s layout and widgets consist of custom widgets and complex calculations, both independently and according to other factors (window size, height and width of each cell, number of events, positioning, etc.), so these widgets need to be minimal to have as little overhead as possible. This means that these widgets also need to have the necessary accessibility features reimplemented or even rethought, including and starting with the event widgets.

Third Party Projects

francescocaracciolo reports

Newelle 0.9.5 Released: Internet Access, Improved Document Reading

🔎 Implemented Web Search with SearXNG, DuckDuckGo, and Tavily 🌐 Website Reading: ask questions about websites (Write #url to embed it) 🔢 Improved inline LaTeX support 🗣 New empty chat placeholder 📎 Improved Document reading: semantic search will only be done if the document is too long 💭 New thinking widget 🧠 Add vision support for llama4 on Groq and possibility to choose provider on OpenRouter 🌍 New translations (Traditional Chinese, Bengali, Hindi) 🐞 Various bug fixes

Source Code Install it from Flathub

Elias Projahn announces

I have published the initial release of a classical music player and organizer designed for GNOME, which will eventually become a full-fledged tool for managing your personal library of classical music. The application is called Musicus and also comes with a small pre-made music library containing recordings that are in the public domain (based on EU legislation). This makes it very easy to try out the app, which is available as a Flatpak bundle. Please note that the application is not yet stable and mature. This is why I am looking for feedback on the design, functionality and, if you are interested in contributing, you!

Hari Rana | TheEvilSkeleton reports

Since Upscaler has just reached 150,000 installs on Flathub, I’m releasing Upscaler 1.5.0! Upscaler is an app that allows you to upscale images locally, securely, and completely offline.

Thanks to Zoey Ahmed’s wonderful contribution, this release introduces the long overdue functionality to load multiple images at once and add them to the queue. This avoids having to load and add each image to the queue, which will significantly speed up the process of adding images to the queue.

The entire async and threading model was ported to the asyncio and threading modules, thanks to the long awaited (pun very much intended) asyncio integration in PyGObject that was made available recently.

Loading images has become much faster and smoother, while using less memory as a direct result of the asyncio and threading port.

This release also makes saving the resulting images completely optional. Additionally, there is now a copy button to copy images without saving them. As such, the process to upscale images has gotten more straightforward than ever – just load the image, set the desired scaling factor and the image type.

The progress rows have gotten a redesign to make them more reminiscent to typical rows with progress bars.

You can get Upscaler 1.5.0 on Flathub: https://flathub.org/apps/io.gitlab.theevilskeleton.Upscaler

Turtle

Manage git repositories in Nautilus.

Philipp announces

Turtle goes async again

Turtle 0.13 was released with proper Nautilus async plugin support!

Turtle switched back to the async update_file_info_full method recently and with this version many improvements have been made to reduce turtle service dbus calls to speed up emblem calculations. There is now also a setting to restrict emblems and the context menu to home folders, to even further reduce unnecessary service calls.

Making async possible again

Turtle used a workaround for a while, because there was a crash in Nautilus when update_file_info_full is used. This issue was fixed with this MR which is available in Nautlius 48+ and has also been backported to Nautilus 47.2 and 46.4.

The flatpak version still uses the sync workaround, because there is no way to guarantee the package is installed on a distro with a Nautilus version including the fix.

Packaging stuff

There was also some progress with debian and fedora packages of Turtle.

If you want to test the package now, there is PPA for Ubuntu 24.04 with the Nautilus fix backported.

Fractal

Matrix messaging app for GNOME written in Rust.

Kévin Commaille reports

A new version of Fractal numbered Eleven? Stranger things have happened… Features come running up that hill:

• Support for login using the OAuth 2.0 API (as used by matrix.org, which recently made the switch to Matrix Authentication Service)
• Overhaul of the page that lists user sessions, with details moved to subpages, for a less cluttered feel, and allowing to rename sessions!
• Rearranged account settings, with a new Safety tab that includes a setting to toggle media preview visibility
• BlurHashes for images and videos, that are used as placeholders while the media is loading or if the preview is disabled
• Contiguous state events are grouped behind a single item

As usual, this release includes other improvements and fixes thanks to all our contributors, and our upstream projects.

We want to address special thanks to the translators who worked on this version. We know this is a huge undertaking and have a deep appreciation for what you’ve done. If you want to help with this effort, head over to Damned Lies.

This version should be available shortly on Flathub.

If you want to join the gang, you can start by fixing one of our newcomers issues. We are always looking for new members!

Blueprint

A markup language for app developers to create GTK user interfaces.

Sophie 🏳️‍🌈 🏳️‍⚧️ (she/her) reports

Blueprint is now part of the GNOME Nightly SDK and is expected to be part of the GNOME 49 SDK. This means, apps relying on blueprint won’t have to install it manually anymore.

Blueprint is an alternative to defining GTK/Libadwaita user interface via .ui XML-files (GTK Builder files). The goal of blueprint is to provide UI definitions that require less boilerplate than XML and are easier to learn. Blueprint also provides a language server for IDE integration.

Many of our GNOME Circle apps are already built with blueprint, as well as some Core and Incubator apps.

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!

WebKitGTK has a bunch of different confusing API versions. Here are the three API versions that are currently supported by upstream:

• webkitgtk-6.0: This is WebKitGTK for GTK 4 (and libsoup 3), introduced in WebKitGTK 2.40. This is what’s built by default if you build WebKit with -DPORT=GTK.
• webkit2gtk-4.1: This is WebKitGTK for GTK 3 and libsoup 3, introduced in WebKitGTK 2.32. Get this by building with -DPORT=GTK -DUSE_GTK3=ON.
• webkit2gtk-4.0: This is WebKitGTK for GTK 3 and libsoup 2, introduced in WebKitGTK 2.6. Get this by building with -DPORT=GTK -DUSE_GTK3=ON -DUSE_SOUP2=ON.

webkitgtk-6.0 contains a bunch of API changes, and all deprecated APIs were removed. If you’re upgrading to webkitgtk-6.0, then you’re also upgrading your application from GTK 3 to GTK 4, and have to adapt to much bigger GTK API changes anyway, so this seemed like a good opportunity to break compatibility and fix old mistakes for the first time in a very long time.

webkit2gtk-4.1 is exactly the same as webkit2gtk-4.0, except for the libsoup API version that it links against.

webkit2gtk-4.0 is — remarkably — mostly API stable since it was released in September 2014. Some particular C APIs have been deprecated and don’t work properly anymore, but no stable C APIs have been removed during this time, and library ABI is maintained. (Caveat: WebKitGTK used to have unstable DOM APIs, some of which were removed before the DOM API was eventually stabilized. Nowadays, the DOM APIs are all stable but deprecated in webkit2gtk-4.1 and webkit2gtk-4.0, and removed in webkitgtk-6.0.)

If you are interested in history, here are the older API versions that do not matter anymore:

• webkit2gtk-5.0: This was an unstable API version used during development of the GTK 4 API, intended for WebKit developers rather than application developers. It was obsoleted by webkitgtk-6.0.
• webkit2gtk-3.0: original API version of WebKitGTK for GTK 3 and libsoup 2, obsoleted by webkit2gtk-4.0. This was the original “WebKit 2” API version, which was only used by a few applications before it was removed one decade ago (history).
• webkitgtk-3.0: note the missing “2”, this is “WebKit 1” (predating the modern multiprocess architecture) for GTK 3. This API version was widely-used on Linux, and its removal one decade ago precipitated a security crisis which I called The Great API Break. (This crisis was worth it. Modern WebKit’s multiprocess architecture is far more secure than the old single-process architecture.)
• webkitgtk-1.0: the original WebKitGTK API version, this is “WebKit 1” for GTK 2. This API version was also widely-used on Linux before it was removed in The Great API Break.

Fedora and RHEL users, are you confused by all the different confusing downstream package names? Here is your map:

• webkitgtk6.0, webkit2gtk4.1, and webkit2gtk4.0: This is the current binary package naming in Fedora, corresponding precisely to the WebKitGTK API version to reduce confusion.
• webkit2gtk3: old name for webkit2gtk4.0, still used in RHEL 9 and RHEL 8
• webkitgtk4: even older name for webkit2gtk4.0, still used in RHEL 7
• webkitgtk3: this is the webkitgtk-3.0 API version, still used in RHEL 7
• webkitgtk: this is webkitgtk-1.0, used in RHEL 6

Notably, webkit2gtk4.0, webkit2gtk3, and webkitgtk4 are all the same thing.

Introduction:

GNOME GitLab now uses macOS runners from MacStadium for managing our macOS CI pipeline. This offers significant improvements in supporting the GNOME platform on macOS. In this blog, we’ll cover the event timeline of macOS CI in GNOME GitLab and the technical details of the new infrastructure setup from MacStadium.

Background:

Around mid 2023, the GNOME Infrastructure Team decided to retire the existing macOS CI runners for a handful of reasons as explained in this post by Emmanuele Bassi. They were x86_64 runners which were quite outdated technically, as they were replaced by better and faster Apple Silicon M series ARM SoCs (specifically Apple M1) from Nov 2020.

There was no macOS CI in GNOME GitLab since then. GNOME core projects like GTK, GLib and few apps still provided macOS support on a best effort basis: meaning development and testing would be done on user machines. Though this is far from perfect, this provided some basic macOS support for GNOME projects.

Infrastructure help from René:

René de Hesselle is a member of Inkscape’s Project Leadership Committee and an open source developer who specializes in building, packaging and porting applications to the macOS platform. Looking into the macOS CI issues GNOME projects were facing, René offered to help with the macOS effort in GNOME, which was greatly appreciated by GNOME developers.

René has been assisting core libraries like GLib, GTK and GNOME apps to build in macOS. To address the macOS CI limitation, René went a step further and provided a self hosted GitLab macOS CI runner. With assistance from the GNOME Infrastructure Team, the self hosted runner was made available to projects across GNOME. This proved to be really useful, as it increased the pace of development in macOS.

Scalability and Sustainability Issues:

Over time, as more projects switched to using the self hosted macOS CI runner, it was becoming evident that this solution would not be effective for the scale of GNOME and not sustainable in the long term. René opened this topic for discussion in this post.

It was quite evident that we needed an enterprise solution to offer scalable and sustainable macOS CI service. This is when MacStadium’s FOSS program was highlighted as a possible solution in GNOME Discourse.

MacStadium, FOSS and GNOME:

MacStadium is well known in the open source world for sponsoring developers of open source projects for the Apple platform, including macOS, iOS, tvOS, and watchOS.

The GNOME Team got in touch with MacStadium for sponsoring macOS CI runners under their FOSS program. Though the MacStadium FOSS program was not available as it was already at capacity, MacStadium was excited in partnering with GNOME. Special thanks to Lauren Cabana (Director, Marketing) from MacStadium for actively pursuing this effort and making this collaboration possible.

MacStadium Orka Cluster solution:

As part of this collaboration, MacStadium has offered the following infrastructure setup based on our requirements:

• Orka (Orchestration with Kubernetes on Apple) Cluster.
• Dedicated network with firewall and VPN.
• 1 TB NAS storage.
• 2 x Mac mini (M1, 8-core CPU, 10-core GPU, 16GB RAM, 1TB SSD).

This is a significant bump in hardware specs compared to the current solution, allowing us to run more builds simultaneously. But the biggest benefit is having access to a turnkey solution that provides ephemeral machines: build isolation is no longer a concern and restrictions on customizability can be lifted, making it possible to open macOS CI instance-wide on GNOME GitLab with minimal administrative oversight. This setup is located in MacStadium’s Dublin data center.

Thanks to MacStadium for sponsoring this infrastructure upgrade!

Thanks and Mentions:

• Richard Littauer – for interfacing with MacStadium via calls / emails and active participation.
• René de Hesselle – for actively taking part in all technical discussions.
• Philip Withnall – for coordinating efforts within GNOME.
• Bartłomiej Piotrowski – for setting up GNOME / MacStadium accounts.

This post is a response to what Tobias posted yesterday on his blog. I would really prefer not be writing it. There are many other things that I would prefer to be doing, and I do not enjoy engaging in public disagreements. I honestly find all of this very stressful and unpleasant, but here we are.

For context, I joined the board in July last year, having previously been on the board from 2015 to 2021. This means that I wasn’t on the board during some of the events and decisions described in Tobias’s post. I am assuming that I am not one of the unnamed individuals he is calling on to resign, though I would be significantly impacted if that were to happen.

The post here is a personal view, based on my close involvement with the issues described in Tobias’s post. As such, it is not an official board position, and other directors may disagree with me on some points. It’s possible that the board may produce its own official statement in the future, but boards are inherently slow-moving beasts, and I wanted to get something posted sooner rather than later.

I want to start by saying that it is difficult to respond to Tobias’s post. The Foundation has a policy that we don’t comment on specific code of conduct cases, in order to protect the privacy of those involved. And, when you get down to it, this is mostly about the particulars of one specific case. Without being able to discuss those particulars, it is hard to say very much at all. That, in my opinion, is the elephant in the room.

The other reason that it is difficult to respond is there are just so many broad brush accusations in the blog post. It presents power conflicts and financial mismanagement and reckless behaviour and so on and so forth. It’s impossible to address every point. Instead, what I will do is provide a fairly high-level view of each of the two main themes in the post, while calling out what I consider to be the main inaccuracies. The first of those themes is the code of conduct decision, and the second relates to the performance of the Foundation.

The big elephant

In the blog post, Tobias throws around a lot of accusations and suggestions about the code of conduct decision to suspend Sonny Piers from the GNOME project. His description of the chain of events is both misleading and a misrepresentation of what happened. Then there’s an accusation of recklessness, as well as an accusation that the code of conduct decision was somehow politically motivated. All of this is clearly intended to question and undermine the code of conduct decision, and to present a picture of mismanagement at the foundation.

My view is that, despite the various twists and turns involved in the decision making process for this case, and all the questions and complexities involved, it basically boils down to one simple question: was the decision to suspend Sonny the correct one? My view, as someone who has spent a significant amount of time looking at the evidence, talking to the people involved, and considering it from different perspectives, is that it was. And this is not just my personal view. The board has looked at this issue over and over, and we have had other parties come in to look at it, and we have always come to the conclusion that some kind of suspension was appropriate. Our code of conduct committee came to this conclusion. Multiple boards came to this conclusion. At least one third party who looked at the case came to this conclusion.

I understand why people have concerns and questions about the decision. I’m sympathetic to the experiences of those individuals, and I understand why they have doubts. I understand that some of them have been badly affected. However, ultimately, the board needs to stand up for the code of conduct. The code of conduct is what provides safety for our community. We do not get to set it aside when it becomes inconvenient.

The argument that the code of conduct decision was somehow politically motivated is false. We even had an external reviewer come in and look at the case, who confirmed this. Their report was provided to Tobias already. He continues to make this accusation despite it standing in opposition to the information that we have provided him with.

Tobias seems to think that Sonny’s importance to the GNOME project should have been taken into account in our decision for the code of conduct case. To me, this would imply that project leaders would operate according to a different, less stringent, set of conduct rules from other contributors. I believe that this would be wrong. The code of conduct has to apply to everyone equally. We need to protect our community from leaders just as much as we need to protect them from anyone else.

No one is suggesting that the management of the code of conduct decision was good. Communication and management should have been better. Community members were significantly impacted. We have sincerely apologised to those involved, and are more than willing to admit our failings. We’ve also been working to ensure that these problems don’t happen again, and that’s something that I personally continue to spend time and energy on.

However, to understand those failings, you also have to look back at the situation we faced last year: we had just lost an ED, board members were burned out, and our processes were being tested in a way that they never had been before. We still had all the usual board and foundation work that needed taking care of. In the middle of it all, elections happened and the board membership changed. It was a complex, shifting, and demanding situation, which looks rather different in retrospect to how it was experienced at the time. We learned a lot of lessons, that’s for sure.

The other elephant

The other part of Tobias’s post addresses the performance of the Foundation.

He points out various problems and challenges, some of which are real. Unfortunately, while being convenient, the theory that all of these challenges are the result of the incompetence of a few individuals is, like most convenient answers, incorrect. The reality is more complex.

One of the major factors for the Foundation’s current situation is our recent history with Executive Directors. Neil left as ED in November 2022. It took us about a year to hire Holly, who was ED for seven months, during which time she had to take a non-trivial amount of time off [1]. And the Foundation is a small organisation – there aren’t lots of people around to pick up the slack when someone leaves. Given these circumstances, it’s unsurprising that the Foundation’s plans have changed, or that they didn’t happen in the way we’d hoped.

This is why the current board has been focusing on and expending considerable effort in recruiting a new executive director, who will be joining us very soon. Hurrah!

Tobias’s proposition that anyone who tries to change the Foundation gets burned out or banned is not true. I am living proof of this. I have changed the Foundation in the past, and continue to change it as part of my role as director. The Foundation today is radically different from the one I first joined in 2015, and continues to evolve and change. A lot of this is due to the interventions of previous and current directors over time.

Amid all this, it’s also important not to forget all the things that the Foundation has been successfully doing in recent years! I went into some of this in my recent blog post, which provides more details than I can here. It is worth stressing that the ongoing successes of the Foundation are mostly thanks to the dedication of its staff. We’ve run successful conferences. We’ve supported Flathub during which time it has experienced extraordinary growth. We’ve supported development programs. And the organisation has kept running, sailing through our taxes and registrations and all those other bureaucratic requirements.

On resignations

From the outside the GNOME Foundation can seem a little opaque. Part of the reason for that is that, as a board, we have to deal with sensitive and confidential matters, so much of the work we do happens behind closed doors. However, when you are on the board you quickly learn that it is really much like any other community-based open source team: there’s usually more work to do than we have capacity for, and the majority of the work gets done by a small minority of contributors.

Speaking as part of that minority, I don’t think that it would be beneficial for members of the board to resign. It would just mean fewer people being available to do the work, and we are already stretched for resources. I’m also of the view that no one should be asked to resign in response to upholding the code of conduct. Conduct work is difficult and important. It requires tough decisions. As a community we need to support the people doing it.

And if people think we should have different directors, well, that’s what the elections are for.

Closing

Readers might wonder why the Foundation has not spoken publicly about this topic (reminder: I’m not speaking on behalf of the Foundation here). The main reasons are confidentiality and legal concerns. We also tried very hard to respect the wishes of those who have been involved and affected. Now with Tobias’s post it is harder to avoid saying things in public. I’m personally skeptical of how useful this is: with opaque and complex issues like these, public discussions tend to generate more questions than they do answers. Contributor relationships are unfortunately likely going to get damaged. But again, here we are.

It should be said that while the foundation hasn’t spoken publicly about these issues, we have expended significant effort engaging with community members behind the scenes. We’ve had meetings where we’ve explained as much of what has happened as we can. We even went so far as to commission an external report which we made available to those individuals. We continue to work on improving our processes in response to the, ahem, feedback we’ve received. I personally remain committed to this. I know that progress in some areas has been slow, but the work continues and is meaningful.

Finally: I am sure that there are contributors who will disagree with what I’ve written here. If you are one of those people, I’m sorry that you feel that way. I still appreciate you, and I understand how difficult it is. It is difficult for all of us.

[1] Edit: we were extremely lucky to have Richard Littauer as interim ED for the second half of 2024, and he did a huge amount. However, Richard was only working for us part-time, so was unable to deliver on strategic initiatives.

The desktop team in Red Hat has another open position. We’re looking for someone to work on Flatpak automation, for someone who enjoys working on infrastructure. Although the job description states 2+ years of experience, it’s suitable for juniors. Formal experience can be replaced by relevant open source contributions. Being onsite in Brno, Czech Republic is preferred, but not required. We’re open to hiring good candidates elsewhere, too.

If you’d like to know more about the job before formally applying, don’t hesitate to contact me on Mastodon, Signal, Matrix (@eischmann at fedora.im), or email.

After more than an year after, Boatswain 5.0 is finally out. It took me a long time to push it to the finish line, but I’m relatively happy with how it turned out, and it brings some nice features.

Let’s take a quick look at what’s new in this release!

New Devices

Boatswain 5.0 comes with support for 2 new device models from Elgato: Stream Deck Plus, and Stream Deck Neo.

Support for Elgato Stream Deck Plus came after the massively successful fundraising campaign from last year. A huge thanks to everyone that contributed to it!

As for Elgato Stream Deck Neo, I tentatively introduced support for it without actually having a device to test, so if there’s anyone out there that can test it, that’d be absolutely appreciated.

Support for Stream Deck Plus was probably the main reason it took so long to release Boatswain 5.0. The entirety of the app was originally written under the assumption that all devices were simply a grid of buttons. Introducing a touchscreen, and dials that act as buttons, required basically rewriting most of the app.

I used this opportunity to make Boatswain able to handle any kind of device, with any kind of layout. Everything is represented as regions in a grid layout. Simple Stream Deck devices just contain a button grid; Stream Deck Plus contains a button grid, a touchscreen, and a dial grid.

Keyboard Shortcuts

The new Keyboard Shortcut action allows executing any keyboard shortcut – or any keyboard event in general – on the desktop. This seems to work better than I could have anticipated!

Under the hood, this action uses the Remote Desktop portal be able to inject input on the desktop. Locally controlling the desktop was probably not on the original goals of the portal, but alas, it fit the use case perfectly!

Paired with folders, Keyboard Shortcuts are very powerful, especially for large and complex software with a large number of shortcuts.

Next Steps

This release might be a little disappointing as it took so long, and yet didn’t come as packed with new features. And yet, this was the largest release of Boatswain, perhaps larger than the initial release even.

I’ve reached a point where I’m mostly satisfied with how the internals work now. So much so that, right after the Boatswain 5.0 release, I was able to split the core logic of the app into an internal library, and hide device-specific details from the rest of the app. This paved the way for adding a testing framework using umockdev, and also will allow adding support for devices from other brands such as Loupedeck. If you have any Stream Deck-like device and wish to see it supported in Boatswain, now’s your chance!

For Boatswain 6, I personally want to focus on 2 major features:

1. Make Boatswain use the new USB portal. One of my goals with Boatswain is to make it a reference app, using the most modern platform features available – and adding missing features if necessary. The USB portal is an obvious choice!
2. Remove X11 support. This might come as a controversial decision, but I don’t personally use X11 anymore, do not support it, and will not work on fixing bugs that only exist there. As such, I think it’s fair to just remove X11 support from the apps that I maintain. Practically speaking, this just means removing --socket=fallback-x11, and users can add back this permission using Flatseal; but please do not expect any kind of support anymore.

Some features that would be lovely to have, but we currently don’t have either because we lack platform support (i.e. portals), or simply because nobody sat down and wrote it:

1. Tracking the current desktop state, such as the focused app, the session idle state, etc. This will be useful for contextual actions.
2. Clipboard integration. In theory people can simulate this using the Keyboard Shortcuts action, but proper clipboard integration will work better and in more cases.
3. Picking and launching apps from the host system. This needs to happen through portals which currently don’t exist.
4. A fancy visual icon editor so that people can create their pretty icons in the app! If any UI designer is reading, please consider yourself assigned to this little project.
5. Support for custom backgrounds in the touchscreen. I did not have time to finish it before the 5.0 release, but it shouldn’t be too hard to add it.
6. A proper testing framework!

Finally, I’d like to thank my Ko-Fi and YouTube supporters for all the patience and for enabling me to do this work. The fundraiser campaign last year was a massive success, and I’m happy to see the all this progress! You all are awesome and I truly appreciate the support.

Keep an eye on this space as there may be more good news in the near future!

Over the last two years I’ve worked a bit in my spare time on the user documentation of GIMP, a Free & Open Source Image Editor.
While I personally still consider it pretty bad user documentation regarding style inconsistency, duplication of topics, “organic growth”, and lack of task orientation, I managed to put some lipstick on that pig across nearly 900 commits.
I was sometimes rather ruthless pushing my changes (plus I am only a simple contributor and not a GIMP developer) so I’d like to thank Jacob Boerema for their patience and lenience.

In particular that led to

• pretty consistent and up-to-date user interface dialog screenshots using the default theme (a fun game in a repository with about 2000 images and no filename scheme whatsoever),
• less trivial screenshots; people know how menus look like and all their entries are covered by accompanying text anyway (which created more work for translators),
• all application icons updated to the default monochrome theme, in SVG format, located in one single directory within the docs repository, using the same filenames as in the GIMP code repository (so there’s theoretically a chance of maintenance),
  
• adding some icons to text because “click the fifth icon” isn’t particularly user-friendly (especially for RTL folks),
  
• slightly less quadruplication of string variants expressing the same meaning (which created more work for translators).

An interesting remaining issue is whether to remove outdated ancient localized screenshots and where to draw the line. Does having localized strings in the screenshot (not everybody prefers English) outweigh an outdated user interface in the screenshot (wrong numbers of buttons, or dropdowns instead of radio buttons)? Your mileage may vary.

Obviously there is much more to do, for example maybe rewriting everything from scratch or splitting screenshot files of translatable UI dialogs and non-translatable example images mashed into one single image file into two separate files because, again, translators and lower maintenance costs.

If you enjoy dealing with Docbook and all its quirks, see the open GIMP help issues or even write merge requests.

If my phone is making me miserable my constantly nagging me for attention, surely the solution must be to ditch it and take a dumb phone that can only place calls and send texts?

Except calls are particularly intrusive interruptions, and the only texts I receive are from couriers. My family and friends use iMessage or Signal. And what about the pictures I can snap in a few seconds by pulling my phone from my pocket? What about GPS navigation? What about those parking lots where you can only pay with an app? What if I need to order a cab in a country I don't speak the language of? What about using my phone app as a 2FA from the bank as the PSD2 practically requires?

I thought about using a dumb down smartphone like the Lite Phone III or any of the other dumbed-down Android phones. In practice it doesn't work for me, because most of them either don't let me use the apps I need or let me break out of the dumb mode to use the app. At this point, why using a dumbed down smartphone at all?

I don't need a dumb(ed down smart)phone. I need the convenience of my smartphone, but I need to use intentionally instead of being dragged to it. My phone was already in silent mode all the time because I can't stand being interrupted loudly by it unless it's an actual emergency. But whenever a notification pops on the screen it brightens up, drags my attention to it, and even if I don't want to interact with it it stays in the back of my head until I finally unlock the phone and have a look at what it's all about.

What I was missing was a sense of priority for notifications. To stay focused on what I cared about, I needed my phone to hold back the unimportant notifications and tell me when something important happened. I could already deny some app the authorization to display notifications, but that's a double edged sword. If I do so with messaging apps I end up compulsively checking them to see if I missed anything important.

What solved it for me was the Focus feature of the iPhone. Instead of using the Do Not Disturb mode, I've configured the Personal Focus profile. I configured it so

• No notifications at all appear on my screen.
• If my favorite contacts call me I will be notified.
• If someone calls me twice within three minutes it will bypass the protection.
• If an app has a Time Sensitive notification to send me, it will bypass the protection.

All the rest is filtered out. As a result I have a phone that doesn't actively nag me for attention. Because it notifies me when something truly important happens, I don't have to check it regularly out of Fear Of Missing Out. This tweak is part of a broader effort to reclaim my attention capacity.

In a few weeks it’ll be one year since a board member of the GNOME Foundation was removed from the project entirely (including Gitlab, Matrix, Discourse, etc.) under very suspicious circumstances. Very little has been said or done about this in public since then. The intentions behind keeping everything internal were good — the hope was to get to a resolution without unnecessary conflict. However, because there’s no non-public way to have discussions across the entire community, and with this dragging on longer and longer, what I’ve seen is partial facts and misunderstandings spreading across different sub-groups, making it harder to talk to each other. I’m now convinced it’s better to break the silence and start having this conversations across the entire project, rather than letting the conflict continue to fester in the background.

That’s not to say nothing has been happening. Over the past year, a number of people from the community (including myself), and some members of the board have tried to resolve this behind the scenes. On a personal level, I’d like to thank all the board members involved for their efforts, even if we didn’t always see eye to eye. Medium-term I’m hopeful that some positive policy changes can be made as a result of this process.

One important thing to note is that nobody involved is against Codes of Conduct. The problem here is the Foundation’s structural dysfunction, bad leadership, and the way the CoC was used in this case as a result. I’m aware of the charged nature of the subject, and the potential for feeding right wing narratives, but I think it’s also important to not let that deter us from discussing these very real issues. But just to be extra clear: Fuck Nazis, GNOME is Antifa.

Sonny has been out since last summer, and as far as I know he’s currently not interested in investing more energy into this. That’s understandable given how he’s been treated, but the rest of us are still here, and we still need to work together. For that we need, if not justice, at least closure, and a way forward.

In this case someone was disappeared entirely from the community with no recourse, no attempts to de-escalate, no process for re-integration, and no communication to the rest of the project (not until months later anyway). Having talked to members of other projects’ CoC structures this is highly unusual, especially completely out of the blue against a well-integrated member of the project.

While the details of this case are unknown to most of the community due to the (understandable) need to keep CoC reports confidential, what is known (semi-) publicly paints a pretty damning picture all by itself:

• A first-time CoC complaint was met with an immediate ban
• A week later the ban was suspended, and a mediation promised
• The 2024 board elections were held a few weeks later without informing the electorate about the ban
• 2 months later the ban was re-instated unilaterally, against the wishes of the new board
• There was an (unsuccessful) vote to remove the chairman of the CoC committee from the board and CoC committee

Given the above, I think it’s fair to say that the people who were on the board and CoC committee when the ban happened, have, at the very least, acted with incredible recklessness. The haphazard and intransparent way in which they handled this case, the incoherence of their subsequent actions, and the lack of communication have have caused great damage to the project. Among other things, in Sonny Piers they have cost us one of our most prolific developers and organizers, and in the STF development team our most successful program in recent history.

What perhaps not everyone’s aware of is that we were working on making this team permanent and tried to apply for followup funding from different sources. None of this materialized due to the ban and the events surrounding it, and the team has since been disbanded. In an alternate world where this had not happened we could be looking at a very different Foundation today, with an arm that strategically funds ongoing development and can employ community members.

More importantly however, we’re now in a situation where large parts of the community do not trust our CoC structure because they feel it can be weaponized as part of internal power struggles.

This ban was only the latest in a long series of failures, missteps, and broken promises by the Foundation. In addition to the recent financial problems and operational failures (e.g. not handling internships, repeatedly messing up invoicing, not responding to time-sensitive communication), all strategic initiatives over the past 5+ years have either stalled or just never happened (e.g. Flathub payments (2019), local-first (2021), development initiative (2024)).

I think there are structural reasons at the root of many of these issues, but it’s also true that much of the Foundation leadership and staff has not changed throughout this period, and that new people joining the board and trying to improve things tend to get frustrated and give up quickly (or in Sonny’s case, get banned). This is a problem we need to confront.

To those on the board and CoC committee who were involved in Sonny’s ban: I’m asking you to step down from your positions, and take some time off from Foundation politics. I know you know you fucked up, and I know you care about this project, like we all do. Whatever your reasons at the time, consider what’s best for the project now. Nobody can undo what happened, but in the medium-term I’m actually hopeful that reconciliation is possible and that both the Foundation and community can come out of this stronger than before. I don’t think that can happen under the current leadership though.

To everyone else: My hope in talking openly about this is that we can get closer to a common understanding of the situation. It seems unlikely that we can resolve this quickly, but I’d at least like to make a start. Eventually I hope we can have some mediated sessions for people from across the community to process the many feelings about this, and see how we can heal these wounds. Perhaps we could organize something at GUADEC this summer — if anyone would be interested in that, let me know.

Hello Matrix users, please review the following:

• Update from Matrix Trust & Safety team regarding attacks on the Matrix network
• GNOME’s new Matrix safety guidelines

Be cautious with unexpected private message invites. Do not accept private message invites from users you do not recognize. If you want to talk to somebody who has rejected your invite, contact them in a public room first.

Fractal users: Fractal 11.rc will block media preview by default in public rooms, and can be configured to additionally block media preview in private rooms if desired.

Matrix server administrators: please review the Matrix.org Foundation announcement Introducing Policy Servers.

In my previous post, when I introduced the switch to Skia for 2D rendering, I explained that we replaced Cairo with Skia keeping mostly the same architecture. This alone was an important improvement in performance, but still the graphics implementation was designed for Cairo and CPU rendering. Once we considered the switch to Skia as stable, we started to work on changes to take more advantage of Skia and GPU rendering to improve the performance even more. In this post I’m going to present some of those improvements and other not directly related to Skia and GPU rendering.

Explicit fence support

This is related to the DMA-BUF renderer used by the GTK port and WPE when using the new API. The composited buffer is shared as a DMA-BUF between the web and UI processes. Once the web process finished the composition we created a fence and waited for it, to make sure that when the UI process was notified that the composition was done the buffer was actually ready. This approach was safe, but slow. In 281640@main we introduced support for explicit fencing to the WPE port. When possible, an exportable fence is created, so that instead of waiting for it immediately, we export it as a file descriptor that is sent to the UI process as part of the message that notifies that a new frame has been composited. This unblocks the web process as soon as composition is done. When supported by the platform, for example in WPE under Wayland when the zwp_linux_explicit_synchronization_v1 protocol is available, the fence file descriptor is passed to the platform implementation. Otherwise, the UI process asynchronously waits for the fence by polling the file descriptor before passing the buffer to the platform. This is what we always do in the GTK port since 281744@main. This change improved the score of all MotionMark tests, see for example multiply.

Enable MSAA when available

In 282223@main we enabled the support for MSAA when possible in the WPE port only, because this is more important for embedded devices where we use 4 samples providing good enough quality with a better performance. This change improved the Motion Mark tests that use 2D canvas like canvas arcs, paths and canvas lines. You can see here the change in paths when run in a RaspberryPi 4 with WPE 64 bits.

Avoid textures copies in accelerated 2D canvas

As I also explained in the previous post, when 2D canvas is accelerated we now use a dedicated layer that renders into a texture that is copied to be passed to the compositor. In 283460@main we changed the implementation to use a CoordinatedPlatformLayerBufferNativeImage to handle the canvas texture and avoid the copy, directly passing the texture to the compositor. This improved the MotionMark tests that use 2D canvas. See canvas arcs, for example.

Introduce threaded GPU painting mode

In the initial implementation of the GPU rendering mode, layers were painted in the main thread. In 287060@main we moved the rendering task to a dedicated thread when using the GPU, with the same threaded rendering architecture we have always used for CPU rendering, but limited to 1 worker thread. This improved the performance of several MotionMark tests like images, suits and multiply. See images.

Update default GPU thread settings

Parallelization is not so important for GPU rendering compared to CPU, but still we realized that we got better results by increasing a bit the amount of worker threads when doing GPU rendering. In 290781@main we increased the limit of GPU worker threads to 2 for systems with at least 4 CPU cores. This improved mainly images and suits in MotionMark. See suits.

Hybrid threaded CPU+GPU rendering mode

We had either GPU or CPU worker threads for layer rendering. In systems with 4 CPU cores or more we now have 2 GPU worker threads. When those 2 threads are busy rendering, why not using the CPU to render other pending tiles? And the same applies when doing CPU rendering, when all workers are busy, could we use the GPU to render other pending tasks? We tried and turned out to be a good idea, especially in embedded devices. In 291106@main we introduced the hybrid mode, giving priority to GPU or CPU workers depending on the default rendering mode, and also taking into account special cases like on HiDPI, where we are always scaling, and we always prefer the GPU. This improved multiply, images and suits. See images.

Use Skia API for display list implementation

When rendering with Cairo and threaded rendering enabled we use our own implementation of display lists specific to Cairo. When switching to Skia we thought it was a good idea to use the WebCore display list implementation instead, since it’s cross-platform implementation shared with other ports. But we realized this implementation is not yet ready to support multiple threads, because it holds references to WebCore objects that are not thread safe. Main thread might change those objects before they have been processed by painting threads. So, we decided to try to use the Skia API (SkPicture) that supports recording in the main thread and replaying from worker threads. In 292639@main we replaced the WebCore display list usage by SkPicture. This was expected to be a neutral change in terms of performance but it surprisingly improved several MotionMark tests like leaves, multiply and suits. See leaves.

Use Damage to track the dirty region of GraphicsLayer

Every time there’s a change in a GraphicsLayer and it needs to be repainted, it’s notified and the area that changed is included so that we only render the parts of the layer that changed. That’s what we call the layer dirty region. It can happen that when there are many small updates in a layer we end up with lots of dirty regions on every layer flush. We used to have a limit of 32 dirty regions per layer, so that when more than 32 are added we just united them into the first dirty area. This limit was removed because we always unite the dirty areas for the same tiles when processing the updates to prepare the rendering tasks. However, we also tried to avoid handling the same dirty region twice, so every time a new dirty region was added we iterated the existing regions to check if it was already present. Without the 32 regions limit that means we ended up iterating a potentially very long list on every dirty region addition. The damage propagation feature uses a Damage class to efficiently handle dirty regions, so we thought we could reuse it to track the layer dirty region, bringing back the limit but uniting in a more efficient way than using always the first dirty area of the list. It also allowed to remove check for duplicated area in the list. This change was added in 292747@main and improved the performance of MotionMark leaves and multiply tests. See leaves.

Record all dirty tiles of a layer once

After the switch to use SkPicture for the display list implementation, we realized that this API would also allow to record the graphics layer once, using the bounding box of the dirty region, and then replay multiple times on worker threads for every dirty tile. Recording can be a very heavy operation, specially when there are shadows or filters, and it was always done for every tile due to the limitations of the previous display list implementation. In 292929@main we introduced the change with improvements in MotionMark leaves and multiply tests. See multiply.

MotionMark results

I’ve shown here the improvements of these changes in some of the MotionMark tests. I have to say that some of those changes also introduced small regressions in other tests, but the global improvement is still noticeable. Here is a table with the scores of all tests before these improvements and current main branch run by WPE MiniBrowser in a RaspberryPi 4 (64bit).

Test	Score July 2024	Score April 2025
Multiply	501.17	684.23
Canvas arcs	140.24	828.05
Canvas lines	1613.93	3086.60
Paths	375.52	4255.65
Leaves	319.31	470.78
Images	162.69	267.78
Suits	232.91	445.80
Design	33.79	64.06

What’s next?

There’s still quite a lot of room for improvement, so we are already working on other features and exploring ideas to continue improving the performance. Some of those are:

• Damage tracking: this feature is already present, but disabled by default because it’s still work in progress. We currently use the damage information to only paint the areas of every layer that changed. But then we always compose a whole frame inside WebKit that is passed to the UI process to be presented on screen. It’s possible to use the damage information to improve both, the composition inside WebKit and the presentation of the composited frame on the screen. For more details about this feature read Pawel’s awesome blog post about it.
• Use DMA-BUF for tile textures to improve pixel transfer operations: We currently use DMA-BUF buffers to share the composited frame between the web and UI process. We are now exploring the idea of using DMA-BUF also for the textures used by the WebKit compositor to generate the frame. This would allow to improve the performance of pixel transfer operations, for example when doing CPU rendering we need to upload the dirty regions from main memory to a compositor texture on every composition. With DMA-BUF backed textures we can map the buffer into main memory and paint with the CPU directly into the mapped buffer.
• Compositor synchronization: We plan to try to improve the synchronization of the WebKit compositor with the system vblank and the different sources of composition (painted layers, video layers, CSS animations, WebGL, etc.)

 

Hello, I am pleased to announce a new Cambalache stable release.

Version 0.96.0 – GResource Release!

• • Add GResource support
  • Add internal children support
  • New project format
  • Save directly to .ui files
  • Show directory structure in navigation
  • Add Notification system (version, messages and polls)
  • Unified import dialog for all file types
  • Update widget catalogs to SDK 48

New project format

So far Cambalache project file contained all the data in one file which meant you had to export UI files to xml in order to use them in your build system.

This constraint was added to discourage XML editing by hand which would have introduced incompatibilities since Cambalache’s GtkBuilder feature support was limited.

Now that GtkBuilder support has improved I decided it was the right time to simplify things for developers and save UI data directly in XML format. Not more manual exporting or integrating with the build system.

The project file will store a relative path to the GtkBuilder file and a hash of its contents, currently all it does is print a warning if you edit the file by hand.

<cambalache-project version="0.96.0" target_tk="gtk-4.0">
  <ui template-class="CmbWindow" filename="app/cmb_window.ui" sha256=""/>
</cambalache-project>

Directory structure in navigation

With the project format change it makes sense to show all UI files in the navigation pane as they are in the filesystem.

Unsaved/unnamed files will be stored inline in the project file which comes in handy for WIP UI or as a quick way to define a custom type that does not have a template.

GResource support

Basic GResource support was added to be able to create or edit gresource.xml files. This opens the possibility for Cambalache to support loading assets from a resource path in the workspace, but unfortunately is not yet implemented.

Internal children support

Even tough this is not commonly used anymore, internal children are still used in some classes like GtkDialog. Cambalache will show any internal children in the hierarchy and only export it in the XML file if you change one of its properties or add any children inside.

Notification System

Last but not least I added a simple notification system to inform about new versions and send messages or polls directly to users.

Notifications are polled once a day and only one notification is shown per day. This is how a message notification looks like and it will be used sporadically to inform users about talks or workshops.

New version notifications will show the release notes and include a link to the blogpost and to flathub.

Polls will let you vote and change your vote until the poll close date results are shown after you vote and a final notification will be sent after the poll closes.

Where to get it?

From Flathub

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

flatpak install flathub ar.xjuan.Cambalache

or directly from gitlab

git clone https://gitlab.gnome.org/jpu/cambalache.git

Matrix channel

Have any question? come chat with us at #cambalache:gnome.org

Mastodon

Follow me in Mastodon @xjuan to get news related to Cambalache development.

Happy coding!

We are excited about the Fedora Workstation 42 released today. Having worked on some great features for it.

Fedora Workstation 42 HDR edition
I would say that the main feature that landed was HDR or High Dynamic Range. It is a feature we spent years on with many team members involved and a lot of collaboration with various members of the wider community.

The fact that we got this over the finish line was especially due to all the work Sebastian Wick put into it in collaboration with Pekka Paalanen around HDR Wayland specification and implementations.
Another important aspect was tools like libdisplay which was co-created with Simon Ser, with others providing more feedback and assistance in the final stretch of the effort.

That said a lot of other people at Red Hat and in the community deserve shout outs for this too. Like Xaver Hugl whose work on HDR in Kwin was a very valuable effort that helped us move the GNOME support forward too. Matthias Clasen and Benjamin Otte for their work on HDR support in GTK+, Martin Stransky for his work on HDR support in Firefox, Jonas Aadahl and Olivier Fourdan for their protocol and patch reviews. Jose Exposito for packaging up the Mesa Vulkan support for Fedora 42.

One area that should benefit from HDR support are games. In the screenshot about you see the game Ori and the Will of the Wisps which is known for great HDR support. Valve will need to update to a Wine version for Proton that supports Wayland natively though before this just works, at the moment you can get it working using gamescope, but hopefully soon it will just work under both Mutter and Kwin.

Also a special shoutout to the MPV community for quickly jumping on this and releasing a HDR capable video player recently.

Of course getting Fedora Workstation 42 to out with these features is just the beginning, with the baseline support it now is really the time when application maintainers have a real chance of starting to make use of these features, so I would expect various content creative applications for instance to start having support over the next year.

For the desktop itself there are also open questions we need to decide on like:

• Format to use for HDR screenshots
• Better backlight and brightness handling
• Better offloading
• HDR screen recording video format
• How to handle HDR webcams (seems a lot of them are not really capable of producing HDR output).
• Version of the binary NVIDIA driver released supporting the VK_EXT_hdr_metadata and VK_COLOR_SPACE_HDR10_ST2084_EXT Vulkan extension on Linux
• A million smaller issues we will need to iron out

Accessibility
Our accessibility team has been hard at work trying to ensure we have a great accessibility story in Fedora Workstation 42. Our accessibility team with Lukas Tyrychtr and Bohdan Milar has been working hard together with others to ensure that Fedora Workstation 42 has the best accessibility support you can get on Linux. One major effort that landed was the new keyboard monitoring interface which is critical for making Orca work well under Wayland. This was a collaboration of between Lukas Tyrychtr, Matthias Clasen and Carlos Garnacho on our team. If you are interested in Accessibility, as a user or a developer or both then make sure to join in by reaching out to the Accessibility Working group

PipeWire
PipeWire also keeps going strong with continuous improvements and bugfixes. Thanks to the great work by Jan Grulich the support for PipeWire in Firefox and Chrome is now working great, including for camera handling. It is an area where we want to do an even better job though, so Wim Taymans is currently looking at improving video handling to ensure we are using the best possible video stream the camera can provide and handle conversion between formats transparently. He is currently testing it out using a ffmpeg software backend, but the end goal is to have it all hardware accelerated through directly using Vulkan.

Another feature Wim Taymans added recently is MIDI2 support. This is the next generation of MIDI with only a limited set of hardware currently supporting it, but on the other hand it feels good that we are now able to be ahead of the curve instead of years behind thanks to the solid foundation we built with Pipewire.

Wayland
For a long time the team has been focused on making sure Wayland has all the critical pieces and was functionality wise on the same level as X11. For instance we spent a lot of time and effort on ensuring proper remote desktop support. That work all landed in the previous Fedora release which means that over the last 6 Months the team has had more time to look at things like various proposed Wayland protocols and get them supported in GNOME. Thanks to that we helped ensure the Cursor Shape Protocol and Toplevel Drag protocols got landed in time for this release. We are already looking and what to help land for the next release, so expect a continued acceleration in Wayland protocol adoption going forward.

First steps into AI
So an effort we been plugging away at recently is starting to bring AI tooling to Open Source desktop applications. Our first effort in this regard is Granite.code. Granite.code is a extension for Visual Studio Code that sets up a local AI engine on your system to help with various tasks including code generation and chat inside Visual Studio Code. So what is special about this effort is that it relies on downloading and running a copy of the open source AI Granite LLM model to your system instead on relying on it being run in a cloud instance somewhere. That means you can use Granite.code without having to share your data and work with someone else. Granite.code is still very early stage and it requires a NVIDIA or AMD GPU with over 8GB of video ram to use under Linux. (It also runs under Windows and MacOS X). It is still in a pre-release stage, we are waiting for the Granite 3.3 model update to enable some major features for us before we make the first formal release, but for those willing to help us test you can search for Granite in the Visual Studio Code extension marketplace and install it.
We are hoping though that this will just the starting point where our work can get picked up and used by other IDEs out there too and also we are thinking about how we can offer AI features in other parts of the desktop too.

I’ve always liked the concept of small five-minute games to fill some time. Puzzle games that start instantly and keep your mind sharp, without unnecessary ads, distractions and microtransactions. Classics like Minesweeper and Solitaire come to mind, once preinstalled on every Windows PC. It was great fun during moments without an internet connection.

Unsurprisingly, GNOME provided a collection of similar games since its initial release, preinstalled on several Linux distributions. Although GNOME no longer ships an official game collection, its games live on as separate modules on GNOME GitLab, and I’ve continued playing some of them to this day.

O maintainer, where art thou?

Unfortunately, several games have become unmaintained in recent years. While the games more or less work as expected, users still send occasional feature requests and bug reports that remain unanswered, and the UIs drift further away from modern standards (GTK 4 + libadwaita) each year.

One game stuck in an unfortunate state was Mahjongg (a Mahjong Solitaire clone), suffering from issues such as high CPU usage and freezes when playing the game. While fixing the issues was easy enough, distributing the fixes proved more difficult, with nobody left to include them in a new release.

One year later

After unsuccessfully hunting for poor souls willing to make a new release, my journey as Mahjongg’s new maintainer began a year ago. While my initial plan was to make a single release fixing critical bugs, modernizing the UI and fixing other long-standing issues turned out quite fun in the end. Here are some of the highlights since then:

• All old issues/feature requests addressed and closed (some dating back over a decade)
• Several improvements contributed by users (sequential/random layout rotation, remembering game state between sessions)
• Fixes for various bugs and memory/resource leaks
• Performance improvements, avoiding several seconds of delay when starting the game and changing layouts
• Modernized Scores dialog and other UI/UX improvements, following the latest GNOME Human Interface Guidelines
• Improved tile reshuffling that avoids unsolvable tile arrangements when possible
• Tile drawing ported from Cairo (CPU-based) to GtkSnapshot (GPU-based), for more efficient drawing and less work porting to GTK 5 in the (far) future

Applying for GNOME Circle

It’s perhaps no secret that the old GNOME games are stuck in an awkward place, with some still using legacy GNOME branding despite no longer shipping with GNOME. In search of a better future for Mahjongg, I applied for its inclusion in GNOME Circle, a collection of high-quality apps and libraries that extend the GNOME ecosystem. After good initial impressions, thanks to recent modernization efforts, Mahjongg is on track for inclusion.

Since GNOME Circle currently lacks other games, I would love to see more small games added in the future, whether it be one of the old GNOME games or a completely new one. While it’s up to each maintainer whether or not they want to go through the effort, high-quality games deserve more exposure. :)

Closing words

Thanks to both the Release Team and the Infrastructure Team for helping me get started, as well as everyone who has contributed to Mahjongg so far. Thanks to everyone who helped write the GNOME Project Handbook, making the lives of contributors easier.

A few GNOME games are still unmaintained and use GTK 3:

• 2048
• Four-in-a-row
• Klotski
• Quadrapassel
• Reversi
• Taquin
• Tetravex

If you enjoy a challenge, and are interested in porting a game to GTK 4 + libadwaita and maintaining it, perhaps this is the opportunity for you!

Download Mahjongg

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.

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/

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!

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.

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.

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!

 After a long time of low-maintenance (as in me being out of the picture and doing mostly releases and some trivial/not-so-trivial-but-quick fixes here and there) period for GNOME-Calculator, it's time to reveal what's happening behind the scenes.

Long-story short, pretty late in the 48 cycle two contributors popped up to breathe some life into GNOME Calculator, so much, that I had a pretty hard time keeping track of the merge requests piling up. So most of the kudos for the below-mentioned features go to fcusr and Adrien Plazas, and I hope I will manage to list all of them, and it would be great to have folks using the Nightly Calculator (current development version from flatpak gnome-nightly repo)  to help spot issues/requests in time to be fixed for 49.

So now the features:

Conversion mode

Based on several user requests and the work of fcusr, conversion UI was moved to a separate "mode". Important thing to note here, that conversions using keyboard-only are still possible (e.g. typing 1 kg in g yields the r
esult) in any mode, Conversion view is just a UI/button/touch-friendly way of doing the conversions without typing, similarly to what we had previously in the advanced mode.

 

 

UI cleanup, styling and touch improvements

Both Adrien and fcusr worked on simplifying the UI-related code, dropping old/unnecessary styling, tweaking the looks of buttons, improving the access to toggles/switches to make Calculator easier to use with functions grouped, styled in a meaningful way.

The interface was also "optimized" for smaller screens/touch devices, namely function buttons which up until now only entered the function name to save you some typing will work with some text selected to insert brackets around the selection and add the function.

New functions and constants

 For anyone needing them, new functions have been added:

• greatest common divisor ( e.g. using gcd (456;1584;40;60) yields 4 as a result)
• least common multiple ( e.g. using lcm (456;1584;40;60) yields 150480 as a result)
• combination (e.g. using ncr (9;5) yields 126 as a result)
• 
  permutation (e.g. using npr (9;5) yields 15120 as a result)
• common constants are now available from the memory button (also used for accessing variables)
  

Favorite currencies 

As the list of available currencies for conversion is already huge, scrolling through the currency list for selecting currencies in case you have multiple ones you are used to convert between (given that the last currencies you used should be persisted) is harder, currencies can  be marked as Favorites using the preferences section for Favorite currencies, and the selected ones will appear on top of the currency selector.

GNOME exchange API

Given that we are occasionally having issues with the exchange rate providers (site not being available, site not accepting our user-agent) rendering Calculator currency conversions broken (or even worse, in some cases freezing Calculator completely) the decision was taken to host our own exchange rate API, and with the help of the folks in the GNOME Infrastructure team we have a GNOME exchange API, which will be used for exchange rate retrieval. 

The relevant project is available at https://gitlab.gnome.org/Infrastructure/xchgr8s.

For now, this is basically a static mirror of the providers used so far in Calculator (hence the URL change can be "backported" to any calculator version easily), which does fetch the exchange rates once a day from all providers, and commits them to the repository, from where it will be served via gitlab pages + GNOME reverse proxy + CDN.

This way we have control over the format we provide, we can do any processing on the exchange rates fetched from the external sources, and we can update the currency providers in GNOME Calculator however we want as long as they use one of the formats provided by the exchange-API, be it an existing format or a completely new one added to exchange API.

This was a first step towards fixing a 10-year old, GNOME bugzilla-reported bug still open, but I would say we're on the right track.

 That's all for now, keep up the good work.