As you may be aware, the entire GNOME community has been on the receiving end of a coordinated harassment campaign for the past year. All GNOME users and contributors with a public profile, and those active on Matrix, are being harassed.

I want to share my personal perspective on this, as the GNOME Foundation Executive Director. There are some things that need to be said about these events, and I want to provide some reassurance for community members.

 

People At Risk

It is important for us to recognize that there are members of our community who are particularly at risk from the recent harassment campaign. Here, I am specifically referring to those people for whom this kind of harassment poses a genuine physical threat. The harassment frequently takes the form of anti-LGBTQIA+ (most frequently anti-trans), racist, misogynist, anti-semitic, and anti-muslim messages.

Individual targets of the harassment have included Staff members, Board members, Foundation members, and users. Our community includes people living under oppressive, authoritarian regimes. It includes people in war zones. It includes refugees. These people are all acutely at risk.

Please know that if you belong to one of these groups, you are always welcome in the GNOME community. We will do everything we can to ensure your safety in our community. We will not tolerate threats to your safety.

 

Psychological Harm

In addition to risk of physical harm, one component of this coordinated harassment campaign is the use of disturbing images, intending to cause psychological harm. The attackers’ very possession of these images is an international crime.

These attacks have been stopped on Discourse, our forum tool. The GNOME moderation team is actively engaged with the Matrix moderation team to reduce (and ultimately eliminate) users’ exposure to these images on the Matrix protocol.

If you have received one of these images, your best course of action is to email [email protected]. Specific, actionable advice is provided in The GNOME Handbook’s Matrix: Staying Safe section.

 

My Personal Experience

I was quite surprised to witness — and then find myself on the receiving end of — this harassment campaign when I began my new role with the GNOME Foundation. Because I’m a relatively new community member, I want to discuss my experience in case it is helpful to anyone else.

The first time I was on the receiving end of one of these images, my response was to go to my partner and say, “I’m feeling sick and anxious. I really need a hug.” This was also my response to the first few harassment messages I received. I was advised by other staff members not to respond to the people sending these messages of harassment. I’m glad I took their advice. Engaging will not help.

I have tried on many occasions to have compassion for those instigating and carrying out the harassment. They are clearly misguided — and not well. I have spent many years cultivating compassion but I still find myself struggling with this. Often thinking of the attackers leaves me feeling angry instead of compassionate.

If I catch myself directing angry thoughts toward those people carrying out the harassment campaign, I instead try my best to direct compassion toward those who are suffering because of it: the community. It is easy to feel compassion for the victim and if I focus my attention on the people who continue to work tirelessly on GNOME in spite of these attacks, I always end up with a smile on my face.

If you are feeling angry or frustrated, perhaps this approach will help you, too.

 

Commitment

Not every safety violation is created equal. Trolling and flame wars require a stern conversation — and perhaps moderation. A Code of Conduct violation necessitates the involvement of the Code of Conduct Committee — and perhaps the Board. Crimes demand the engagement of lawyers and law enforcement.

Of the harassment campaign I have heard the following euphemisms:

• “The spam.”
• “They are bullies.”
• “These people trolling us.”
• “These people seem like jerks.”
• “An annoying technical issue with federated protocols.”

They are not simply “bullies”. Their actions do not constitute “trolling”. These are crimes.

It is my commitment to you as members of this community that the Foundation will pursue the most appropriate course of action whenever your safety is violated, to the degree it is violated. This is part of why the Foundation exists: an incorporated entity can engage other organizations in more significant ways than any one person can.

The Foundation stands with you.

 

Previously it was mentioned that Python and C++ do iteration quite differently. Python has "statefull" objects that have a .next() method that returns a new object or throws a StopIteration exception. Incidentally Rust does exactly the same thing, except that it uses an optional type rather than an exception. C++ does not work like this, instead it has a concept of a "start" and "end" of a sequence and the machinery keeps incrementing the start until it reaches the end.

At the end of last post it was said that it is difficult to integrate an object of the former type with C++'s native language facilities, at least without macros.

Now we'll look how to integrate an object of the former type with C++'s native language facilities without any macros.

In fact, it only took fewer than 30 lines of code to do. The caveat being that it is probably fairly easy to break it. But it works for me.

Here it is being used.

There is also a second, similar helper class that takes ownership of the object being iterated over.

Hi, we’ve started a new project: a Farsi-language podcast version of This Week in GNOME.

Each week, we read and summarise the latest TWIG post in Farsi, covering updates from GNOME Core, GNOME Circle apps, and other community-related news. Our goal is to help Persian-speaking users and contributors stay connected with the GNOME ecosystem.

The podcast is hosted by me (Revisto), along with Mirsobhan and Hadi. We release one short episode per week.

Since I also make music, I created a short theme for the podcast to give it more identity and consistency across episodes. It’s simple, but it adds a nice touch of production value that we hope makes the podcast feel more polished.

We’re also keeping a GitHub repository in which I’m uploading each of my episode scripts (in Farsi) in Markdown + audio files. The logo and banner assets have been uploaded in SVG as well for transparency.

You can listen to the podcast on:

• • Spotify
  • Castbox
  • Podcast Index
  • Telegram: @gnome_fa
  • Or via RSS feed

Let us know what you think, and feel free to share it with Farsi-speaking friends or communities interested in GNOME.

Welcome to the third instalment of the Foundation Report! Instalment? Installment? English is dumb. Okay, here goes!

## Opaque Stuff

• 3rd party consultation on safety issue continues
• researching some software choices for process automation
• asking individuals about their goals – no name-dropping because I’m not sure everyone would be comfortable
• international finance is the worst but the problem is fixed now

 

## Meeting People

I’m meeting fewer people and getting more grunt work accomplished but I still met plenty of lovely folks this week. I also met some people after last week’s report: Jef Spaleta is the Fedora Project’s new Lead. He and I agreed all new business deals will be done in the curling rink instead of the golf course. Matthias Clausen gave me a bit of a history lesson and also convinced me I need to talk to more old-timers: the sense of perspective decades of involvement brings is valuable.

I met Tobias and chatted about how the Foundation can increase support to contributors. Rosanna introduced me to our bookkeeper and her advisor so I could get an intro to our bookkeeping process and a walk-through of our last CPA review. Maria and I had a lovely chat about her 20+ years as a GNOME user/contributor and the value of logistics, communications, and admin folks in a very tech-heavy organization… I found myself nodding along with so much she had to say.

I got a chance to meet Aaditya from GNOME Nepal! What he and his team are doing there is after my own heart: getting GNOME, Linux, and other freie software into the hands of aspiring hackers and students. He’s essentially already running the style of repair cafe that the endof10.org campaign will teach people to run and I sincerely hope he’ll have time to help with End Of 10 (but he’s a busy guy!) as I think he has so much to offer. I was shocked to learn that GNOME Nepal is only one year old. They’ve already accomplished so much.

Rosanna and I met the CommitChange team, who help us with gnome.org/donate. They have some neat stuff going on and they explained where they can help us with tweaks to their software and API, analytics, and campaign management. We’re hoping to do something with CommitChange very soon but I won’t say what until it’s baked because it’s not my baby.

Last, we met a couple great folks who are interested in helping out in the Treasurer role at the Foundation. If you know anyone who’s a spreadsheet powerhouse, the Tufte of Reporting, or obsessed with carefully-balanced budgets, please encourage them to email me or Rob!

 

## Ideas, Docs, Walls, Files

I’ve started to corral my scatterbrained ideas into some homes. They’re still spread out between paper notebooks, Markdown files, voicenotes, and my extremely frazzled family members. I’ll probably stop telling them about all the cool people I’m meeting and all the ideas I have by … GUADEC? Maybe.

We’ve started an internal “Foundation Handbook” to match handbook.gnome.org. This is only visible to Staff and Board members, as it contains a great deal of PII and other private information. It has a loooong way to go, but the goal is for it to provide the same beautiful, central documentation location (for banking, staff tools, ops, and so on) that the Project Handbook does. Public information about the Foundation won’t go in here, of course, as it still belongs on foundation.html. If you join the Board, you’re welcome to help us keep it clean and organized so we easily know where everything is and so it’s easy to onboard future Boards, EDs, and other Staff. (No, I’m not planning to leave anytime soon.)

We’ve rebooted the Staff project wall. We don’t keep track of Ops tasks in here (since they’re recurring) but, rather, anything Executive: Follow up with so-and-so, document XYZ process, make a one-time social media post for an organizational partner, etc. We’re also making heavier use of the Board wall, bit by bit.

Nextcloud! We’re… trying to use it. Collecting all our files into Nextcloud will take some time, but we’ve started to push toward using it with some boring old policy junk. We just have to keep up the gardening and it will become a thing of beauty, eventually.

 

## Fundraising

We’ve talked a little about fundraising with the Board (I’m still relatively new) but as the smaller fires are each extinguished, fundraising is taking up more headspace. This is a major concern for me. Perhaps the major concern. The conversation with CommitChange yesterday was one small step toward this. We’ve also started some “market research.” (I’m not sure what else to call it.) When it comes to individuals and organizations that have never donated to GNOME before, I want to know:

• Do they understand how important GNOME is, as infrastructure?
• Where do we find them to ask them to donate? (If not within GNOME itself.)
• Do they want anything for their donation? Or do we just need to reach them?

 

## GUADEC

Kristi and I sat and had a long look through the GUADEC budget and our current expenses. She also very patiently explained to me the event expectations of Europeans as they differ from Americans. Still plenty for me to learn about how our events are planned, but Kristi’s got me off to a great start.

 

## End of 10

Joseph from endof10.org and KDE Eco fame has been in touch continuously. Sri posted a call for a GNOME endof10.org Promo Team on the Engagement blog. It’s going to be here before you know it! If you want to get involved, ping us in #engagement:gnome.org or #endof10-en:kde.org.

If you don’t know what I’m talking about, go watch Joseph’s Linux App Summit talk! It’s great and he does a fantastic job of explaining the importance of this effort.

 

## “Wow, yay, transparency”

I’m very grateful to everyone who has thanked me for these little Foundation Reports. I’m glad I’m not just screaming into the void with these and that a few people are getting value out of them. However, I do have one request.

On occasion (though rarely), these compliments have come paired with (or couched in) a complaint about previous EDs, other folks on staff, or the Board. I would encourage folks who are framing things this way to stop, as it’s a very unhelpful way to communicate. We need to remember that everyone works differently. I’m a loudmouth, so I’m loud. Most people on staff and on the Board are not. Instead, they have their nose to the grindstone. I think most of them struggle to find the time to talk about their work at the end of the workweek. Most of them work late into the night. Most of them work weekends. It’s been a long year (or…five?) for the Foundation and most of them are very tired.

Because I am loud, I will do my best to be loud for them. Week after week, I’ll talk more about what “we” are doing — please understand that “we” is mostly them. If I tell you about work that’s happening at the Foundation, that work didn’t magically start when I joined in May. It’s been happening for years and I’m just doing my best to make it a little more visible.

Instead of thanking me for my ridiculous infoblog, please redirect your thanks to someone on staff. Thank someone on the Board for their tireless service. Thank a contributor whose work comes pouring in, year after year. Send a box of chocolates in a DM. Drop them a little thank-you email. Give them a high-five at GUADEC. (Virtual or otherwise.)

And if you’re feeling very energetic, run for the Board so you can help out.

 

Learn more about this blog, my GSoC 2025 project with GNOME, and my background in open source development.

Thanks to the work of Christian Gmeiner, support for annotating time regions using Sysprof marks has landed in Mesa.

That means you’ll be able to open captures with Sysprof and see the data along other useful information including callgraphs and flamegraphs.

I do think there is a lot more we can do around better visualizations in Sysprof. If that is something you’re interested in working on please stop by #gnome-hackers on Libera.chat or drop me an email and I can find things for you to work on.

See the merge request here.

I'm happy to share that 3 major IPU6 camera related kernel changes from linux-next have been backported to Fedora and have been available for about a week now the Fedora kernel-6.14.6-300.fc42 (or later) package:

1. Support for the OV02C10 camera sensor, this should e.g. enable the camera to work out of the box on all Dell XPS 9x40 models.
2. Support for the OV02E10 camera sensor, this should e.g. enable the camera to work out of the box on Dell Precision 5690 laptops. When combined with item 3. below and the USBIO drivers from rpmfusion this should also e.g. enable the camera on other laptop models like e.g. the Dell Latitude 7450.
3. Support for the special handshake GPIO used to turn on the sensor and allow sensor i2c-access on various new laptop models using the Lattice MIPI aggregator FPGA / USBIO chip.

If you want to give this a test using the libcamera-softwareISP FOSS stack, run the following commands:

sudo rm -f /etc/modprobe.d/ipu6-driver-select.conf
sudo dnf update 'kernel*'
sudo dnf install libcamera-qcam
reboot
qcam

Note the colors being washed out and/or the image possibly being a bit over or under exposed is expected behavior ATM, this is due to the software ISP needing more work to improve the image quality. If your camera still does not work after these changes and you've not filed a bug for this camera already please file a bug following these instructions.

See my previous blogpost on how to also test Intel's proprietary stack from rpmfusion if you also have that installed.

comments

Since the set of rpmfusion intel-ipu6-kmod + ipu6-camera-* package updates from last February the FOSS libcamera-softwareISP and Intel's proprietary stack using the Intel hardware ISP can now co-exist on Fedora systems, sharing the mainline IPU6-CSI2 receiver driver.

Because of this it is no longer necessary to blacklist the kernel-modules from the other stack. Unfortunately when the rpmfusion packages first generated "/etc/modprobe.d/ipu6-driver-select.conf" for blacklisting this file was not marked as "%ghost" in the specfile and now with the February ipu6-camera-hal the file has been removed from the package. This means that if you've jumped from an old ipu6-camera-hal where the file was not marked as "%ghost directly to the latest you may still have the modprobe.d conf file around causing issues. To fix this run:

sudo rm -f /etc/modprobe.d/ipu6-driver-select.conf

and then reboot. I'll also add this as post-install script to the ipu6-camera-hal packages, to fix systems being broken because of this.

If you want the rpmfusion packages because your system needs the USBIO drivers, but you do not want the proprietary stack, you can run the following command to disable the proprietary stack:

sudo ipu6-driver-select foss

Or if you have disabled the prorietary stack in the past and want to give it a try, run:

sudo ipu6-driver-select proprietary

To test switching between the 2 stacks in Firefox go to Mozilla's webrtc test page and click on the "Camera" button, you should now get a camera permisson dialog with 2 cameras: "Built in Front Camera" and "Intel MIPI Camera (V4L2)" the "Built in Front Camera" is the FOSS stack and the "Intel MIPI Camera (V4L2)" is the proprietary stack. Note the FOSS stack will show a strongly zoomed in (cropped) image, this is caused by the GUM test-page, in e.g. google-meet this will not be the case.

Unfortunately switching between the 2 cameras in jitsi does not work well. The jitsi camera selector tries to show a preview of both cameras at the same time and while one stack is streaming the other stack cannot access the camera. You should be able to switch by: 1. Selecting the camera you want 2. Closing the jitsi tab 3. wait a few seconds for the camera to stop streaming 4. open jitsi in a new tab.

Note I already mentioned most of this in my previous blog post but it was a bit buried there.

comments

Hello everyone! 👋

I’m Ahmed, a senior Computer Science student at Helwan University. I’m thrilled to be part of Google Summer of Code 2025 with GNOME! This blog post is the first in a series I’ll write throughout the summer to share my journey. I’ll start with how I got into open source, why I chose GNOME, and what my project is all about.

---

🌐 Why Open Source?

My interest in open source began out of frustration, other platforms were too heavy, resource-consuming, or simply didn’t respect user privacy. Open source software offered me freedom: to learn, to understand, and to use tools that align with my values.

Update on what happened across the GNOME project in the week from May 16 to May 23.

GNOME Core Apps and Libraries

GLib ↗

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

Philip Withnall reports

Axel Karjalainen has added SYSLOG_IDENTIFIER to journald log messages outputted by GLib’s default log handler, which should make journal messages from your app easier to find (see https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4589)

Web ↗

Web browser for the GNOME desktop.

adrian reports

Web has gained a preferences page that allows toggling WebKit features at run-time. Tech Preview builds of the browser will show the settings page by default, while in regular releases it is hidden and may be enabled with the following command:

gsettings set org.gnome.Epiphany.ui webkit-features-page true

This should allow frontend developers to test upcoming features more easily. Note that the settings for WebKit features are not persistent, and they will be reset to their default state on every launch.

GNOME Circle Apps and Libraries

Déjà Dup Backups ↗

A simple backup tool.

Michael Terry announces

Déjà Dup Backups has landed support for restic mount which lets you restore files using your native file manager (instead of the previous in-app file browser)

Third Party Projects

tfuxu announces

Halftone 0.7.0 introduces a long-awaited feature: support for image zooming! From now on, you can easily check even the smallest details simply by using the scroll wheel or gestures on your touchpad/touchscreen.

This release also improves stability and user experience by properly handling and informing the user about errors occurring during image loading. No more endless loading screens!

As always, you can download it from Flathub.

Semen Fomchenkov announces

Hello everyone This week, at ALT Gnome and ALT Linux Team, we released the settings center we developed with support for libpeas-based plugins. I have prepared a short text with its description, I hope it will help to better understand the essence of the idea. And some app UI screenshots: https://altlinux.space/alt-gnome/Tuner/src/branch/main/data/screenshots

Tuner is an extensible settings management center for GNOME, featuring a modern graphical interface built with Libadwaita. Designed with a focus on flexibility and user convenience, Tuner allows every GNOME user to assemble a personalized control center tailored to their system configuration needs.

Key Features:

• Plugin-Based Architecture: Tuner leverages libpeas to provide a dynamic and modular ecosystem. This means any developer can contribute their own functionality in the form of a plugin, offering unlimited opportunities for expansion and customization.

• Simplified GSettings Integration: Inspired by the GNOME Refine project, Tuner implements a mechanism for creating widgets using .blp (Blueprint) files. This simplifies the binding of GSettings keys to interface elements and significantly reduces boilerplate code for developers.

• Modern Libadwaita Interface: The user interface follows GNOME HIG guidelines, ensuring a clean, adaptive, and touch-friendly experience.

• Distribution-Specific Modules: GNOME-based distributions can use Tuner as a hub for distribution-specific settings. For example, a TunerPanel module for managing panel mode, integrated into the “Appearance” section(Created by TunerTweaks module) for ALT Linux, has already been implemented.

Getting Started with Plugin Development:

Developers interested in extending Tuner can refer to the quick guide on plugin creation. The guide includes an example of writing a plugin in Vala and integrating it with Tuner’s architecture. Additionally, template repositories are available for creating plugins in both Vala and Python, along with documentation in Valadoc format.

Phosh ↗

A pure wayland shell for mobile devices.

Guido says

Phosh 0.47.0 is out:

phosh’s Feedback Quick Setting now has a status page featuring a “Do not disturb” toggle (that sets the profile to “silent” and disables notification banners) and a button for quick access to the Feedback settings (to e.g. tweak Feedback for individual apps or tune ring tones).

The on screen keyboard makes better use available space when showing auto completions, adds Emojis to the auto completions and can show a popover for the currently typed character.

There’s more, see the full details at here

That’s all for this week!

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

Hello. It is May, my favourite month. I’m in Manchester, mainly as I’m moving projects at work, and its useful to do that face-to-face.

For the last 2 and a half years, my job has mostly involved a huge, old application inside a big company, which I can’t tell you anything about. I learned a lot about how to tackle really, really big software problems where nobody can tell you how the system works and nobody can clearly describe the problem they want you to solve. It was the first time in a long time that I worked on production infrastructure, in that, we could have caused major outages if we rolled out bad changes. Our team didn’t cause any major outages in all that time. I will take that as a sign of success. (There’s still plenty of legacy application to decommission, but it’s no longer my problem).

During that project I tried to make time to work on end to end testing of GNOME using openQA as well… with some success, in the sense that GNOME OS still has working openQA tests, but I didn’t do very well at making improvements, and I still don’t know if or when I’ll ever have time to look further at end-to-end testing for graphical desktops. We did a great Outreachy internship at least with Tanju and Dorothy adding quite a few new tests.

Several distros test GNOME downstream, but we still don’t have much of a story of how they could collaborate upstream. We do still have the monthly Linux QA call so we have a space to coordinate work in that area… but we need people who can do the work.

My job now, for the moment, involves a Linux-based operating system that is intended to be used in safety-critical contexts. I know a bit about operating systems and not much about functional safety. I have seen enough to know there is nothing magic about a “safety certificate” — it represents some thinking about risks and how to detect and mitigate them. I know Codethink is doing some original thinking in this area. It’s interesting to join in and learn about what we did so far and where it’s all going.

Giving credit to people

The new GNOME website, which I really like, describes the project as “An independent computing platform for everyone”.

There is something political about that statement: it’s implying that we should work towards equal access to computer technology. Something which is not currently very equal. Writing software isn’t going to solve that on its own, but it feels like a necessary part of the puzzle.

If I was writing a more literal tagline for the GNOME project, I might write: “A largely anarchic group maintaining complex software used by millions of people, often for little or no money.” I suppose that describes many open source projects.

Something that always bugs me is how a lot of this work is invisible. That’s a problem everywhere: from big companies and governments, down to families and local community groups, there’s usually somebody who does more work than they get credit for.

But we can work to give credit where credit is due. And recently several people have done that!

Outgoing ED Richard Littauer in “So Long and Thanks For All the Fish” shouted out a load of people who work hard in the GNOME Foundation to make stuff work.

Then incoming GNOME ED, Steven Deobald wrote a very detailed “2025-05-09 Foundation Report” (well done for using the correct date format, as well), giving you some idea about how much time it takes to onboard a new director, and how many people are involved.

And then Georges wrote about some people working hard on accessibility in “In celebration of accessibility”.

Giving credit is important and helpful. In fact, that’s just given me an idea, but explaining that will have to wait til next month.

I savored every episode, knowing this was going to be one of those rare shows, like Severance season one, that you only get to experience for the first time once. It pulls you into a vivid, immersive world that’s equal parts mesmerizing and unsettling. A place you’re fascinated by, but would never want to be put in. The atmosphere seeps into you — the sound design, the environments, the way it all just lingers under your skin. You can’t shake it off.

And now I’ve watched the final 12. episode and I already miss it. So I need to say: watch it. It’s something special.

The series is a full-length expansion of the short Scavengers by Joseph Bennett and Charles Huettner (With visible improvements across the board). They’ve cited Nausicaä as a major influence, but if you’re into Akira, you’ll catch a few visual nods there too. It’s brutal. It’s gorgeous. And honestly, I haven’t been this excited about an animated series in a long time.

Neither Netflix nor HBO wanted to greenlight the second season. But the show has come to a very satisfying closure, so I’m not complaining.

★★★★★

• Mail chew, early call, sync with Dave.
• Published the next strip around how private initiative can smooth roads:
• More catch-up, sales team call.

First of all, what's outlined here should be available in libinput 1.29 but I'm not 100% certain on all the details yet so any feedback (in the libinput issue tracker) would be appreciated. Right now this is all still sitting in the libinput!1192 merge request. I'd specifically like to see some feedback from people familiar with Lua APIs. With this out of the way:

Come libinput 1.29, libinput will support plugins written in Lua. These plugins sit logically between the kernel and libinput and allow modifying the evdev device and its events before libinput gets to see them.

The motivation for this are a few unfixable issues - issues we knew how to fix but we cannot actually implement and/or ship the fixes without breaking other devices. One example for this is the inverted Logitech MX Master 3S horizontal wheel. libinput ships quirks for the USB/Bluetooth connection but not for the Bolt receiver. Unlike the Unifying Receiver the Bolt receiver doesn't give the kernel sufficient information to know which device is currently connected. Which means our quirks could only apply to the Bolt receiver (and thus any mouse connected to it) - that's a rather bad idea though, we'd break every other mouse using the same receiver. Another example is an issue with worn out mouse buttons - on that device the behavior was predictable enough but any heuristics would catch a lot of legitimate buttons. That's fine when you know your mouse is slightly broken and at least it works again. But it's not something we can ship as a general solution. There are plenty more examples like that - custom pointer deceleration, different disable-while-typing, etc.

libinput has quirks but they are internal API and subject to change without notice at any time. They're very definitely not for configuring a device and the local quirk file libinput parses is merely to bridge over the time until libinput ships the (hopefully upstreamed) quirk.

So the obvious solution is: let the users fix it themselves. And this is where the plugins come in. They are not full access into libinput, they are closer to a udev-hid-bpf in userspace. Logically they sit between the kernel event devices and libinput: input events are read from the kernel device, passed to the plugins, then passed to libinput. A plugin can look at and modify devices (add/remove buttons for example) and look at and modify the event stream as it comes from the kernel device. For this libinput changed internally to now process something called an "evdev frame" which is a struct that contains all struct input_events up to the terminating SYN_REPORT. This is the logical grouping of events anyway but so far we didn't explicitly carry those around as such. Now we do and we can pass them through to the plugin(s) to be modified.

The aforementioned Logitech MX master plugin would look like this: it registers itself with a version number, then sets a callback for the "new-evdev-device" notification and (where the device matches) we connect that device's "evdev-frame" notification to our actual code:

libinput:register(1) -- register plugin version 1
libinput:connect("new-evdev-device", function (_, device)
    if device:vid() == 0x046D and device:pid() == 0xC548 then
        device:connect("evdev-frame", function (_, frame)
            for _, event in ipairs(frame.events) do
                if event.type == evdev.EV_REL and 
                   (event.code == evdev.REL_HWHEEL or 
                    event.code == evdev.REL_HWHEEL_HI_RES) then
                    event.value = -event.value
                end
            end
            return frame
        end)
    end
end)

This file can be dropped into /etc/libinput/plugins/10-mx-master.lua and will be loaded on context creation. I'm hoping the approach using named signals (similar to e.g. GObject) makes it easy to add different calls in future versions. Plugins also have access to a timer so you can filter events and re-send them at a later point in time. This is useful for implementing something like disable-while-typing based on certain conditions.

So why Lua? Because it's very easy to sandbox. I very explicitly did not want the plugins to be a side-channel to get into the internals of libinput - specifically no IO access to anything. This ruled out using C (or anything that's a .so file, really) because those would run a) in the address space of the compositor and b) be unrestricted in what they can do. Lua solves this easily. And, as a nice side-effect, it's also very easy to write plugins in.[1]

Whether plugins are loaded or not will depend on the compositor: an explicit call to set up the paths to load from and to actually load the plugins is required. No run-time plugin changes at this point either, they're loaded on libinput context creation and that's it. Otherwise, all the usual implementation details apply: files are sorted and if there are files with identical names the one from the highest-precedence directory will be used. Plugins that are buggy will be unloaded immediately.

If all this sounds interesting, please have a try and report back any APIs that are broken, or missing, or generally ideas of the good or bad persuation. Ideally before we ship it and the API is stable forever :)

[1] Benjamin Tissoires actually had a go at WASM plugins (via rust). But ... a lot of effort for rather small gains over Lua

Call for Participation – Promo Team for endof10.org

We are putting out a call for participation to create a small team to promote End of 10. Supporting the endof10 gives us a unique opportunity to reach disaffected Windows users who are forced to buy a new computer to use the latest Windows 11.

What

This team will work on promoting the End Of 10 Project (and its website) and encourage migration from Windows to GNOME or a sister desktop project. Most important is to grow our user base and grow our app ecosystem.

Who

We are looking for a diverse global team 4-5 people who can help with creating a promotion and coordinating with the KDE and End Of 10 teams.

Why

The promotion will be used to educate the public on re-using their windows 10 computers in new ways by running on a community supported operating system.

How

You can participate by reaching out to us on #engagement:gnome.org on Matrix.

If you are interested in End Of 10 but don’t feel you can commit to the Promo Team, you are welcome to join #endof10-en:kde.org on Matrix.

With Foundry I want to make LSP management much easier than it currently is in Builder.

We have the foundry lsp run python3 command where python3 can be replaced with any language for which there is an installed LSP plugin. This will start an LSP using all the abstractions (including cross-container execution) and provide it via stdin/stdout.

But what happens when you have a half-dozen language servers for Python with new ones added every week? There is a simple builtin tool now.

Keep in mind the language identifiers should match GtkSourceView language identifiers.

# Make clangd the preferred LSP for C
foundry lsp prefer clangd c

# Make sourcekit-lsp preferred LSP for C++
foundry lsp prefer sourcekit-lsp cpp

# Make ruff the preferred LSP for Python3
foundry lsp prefer ruff python3

If there is a clear LSP that your project should be using by all contributors, add --project and it will update the value in the projects settings.

I’m not a professional web designer. I’ve been making websites for decades, but I haven’t kept up with the latest browser quirks and common approaches. What I do have is a solid grasp of the web’s foundations—thanks to my time teaching IP networking at the university.

My journey with Linux started when I struggled to get PHP running on Windows. (To my surprise, my student side project autoroku.cz kept running in production for years.)

At SUSE I’ve tasted the DRY principles while working on a Rails project, SUSE Studio. I left PHP behind and embraced static site generators like Middleman, then Jekyll as it integrated into GitHub. But over time, maintenance fatigue pushed me further—back to basics. No SASS. No site generators. Just clean, modern HTML and CSS.

People are often surprised to see major projects like gnome.org, brand.gnome.org, circle.gnome.org and my own jimmac.eu built with plain HTML. Yes you do repeat yourself and inconsistencies creep in. But with integrated version control and web based editors, fixes are a click away. More people can edit plain HTML than any bespoke stack.

Do I miss some form of include()? Sure. Would I reach for Jekyll+markdown when someone else is responsible for the content? Probably. But for focused, small sites, nothing beats good old HTML.

• Up in the night, caught up with admin; checked-out, another day of interesting talks to partners & friends at the OS Founders Summit, good to hear about progress left & right.
• Worked on the Eurostar home, got back rather late, late call with a friend.

Earlier in this blog we looked at how to generate a justified block of text, which is nowadays usually done with the Knuth-Plass algorithm. Sadly this is not, by itself, enough to create a finished product. Processing all input text with the algorithm produces one very long column of text. This works fine if you end result is a scroll (of the papyrus variety), but people tend to prefer their text it book format. Thus you need a way to split that text column into pages.

The simplest solution is to decide that a page has some N number of lines and page breaks happen at exact these places. This works (and is commonly used) but it has certain drawbacks. From a typographical point of view, there are at least three things that should be avoided:

1. Orphan lines, a paragraph at the bottom of a page that has only one line of text.
2. Widow lines, a paragraph that starts a new page and has only one line of text.
3. Spread imbalance, where the two pages on a spread have different number of lines on them (when both are "full pages")

Determining "globally optimal" page splits for a given text is not a simple problem, because every pagination choice affects every pagination choice that comes after it. If you stare at the problem long and hard enough, eventually you realize something.

The two problems are exactly the same and can be solved in the same way. I have implemented this in the Chapterizer book generator program. The dynamic programming algorithm for both is so similar that they could, in theory, use shared code. I chose not to do it because sometimes it is just so much simpler to not be DRY. They are so similar, in fact, that a search space optimization that I had to do in the paragraph justification case was also needed for pagination even though the data set size is typically much smaller in pagination. The optimization implementation turned out to be exactly the same for both cases.

The program now creates optimal page splits and in addition prints a text log of all pages with widows, orphans and imbalances it could not optimize away.

Has this been done before?

Probably. Everything has already been invented multiple times. I don't know for sure, so instead I'm going to post my potentially incorrect answer here on the Internet for other people to fact check.

I am not aware of any book generation program doing global page optimization. LibreOffice and Word definitely do not do it. As far as I know LaTeX processes pages one by one and once a page is generated it never returns to it, probably because computers in the early 80s did not have enough memory to hold the entire document in RAM at the same time. I have never used Indesign so I don't know what it does.

Books created earlier than about the mid eighties were typeset by hand and they seem to try to avoid orphans and widows at the cost of some page spreads having more lines than other spreads. Modern books seem to optimize for filling the page fully rather than avoiding widows and orphans. Since most books nowadays are created with Indesign (I think), it would seem to imply that Indesign does not do optimal page splitting or at least it is not enabled by default.

When implementing the page splitter the reasons for not doing global page splitting became clear. Computing both paragraph and page optimization is too slow for a "real time" GUI app. This sort of an optimization really only makes sense for a classical "LaTeX-style" book where there is one main text flow. Layout programs like Scribus and Indesign support richer magazine style layouts. This sort of a page splitter does not work in the general case, so in order to use it they would need to have a separate simpler document format.

But perhaps the biggest issue is that if different pages may have different number of lines on each page, it leads to problems in the page's visual appearance. Anything written at the bottom of the page (like page numbers) need to be re-placed based on how many lines of text actually ended up on the page. Doing this in code in a batch system is easy, doing the same with GUI widgets in "real time" is hard.

It’s everyone’s favorite time of year, election season! …Okay, maybe not the most exciting thing—but an extremely important one nonetheless.

For anyone who doesn’t know, GNOME is comprised of many parts: individual contributors and maintainers, adhoc teams of volunteers, a bunch of open source software in the form of apps and libraries, a whole bunch of infrastructure, and—importantly—a nonprofit foundation. The GNOME Foundation exists to help manage and support the organizational side of GNOME, act as the official face of the project to third parties, and delegate authority when/where it makes the most sense. The GNOME Foundation itself is governed by its elected Board of Directors.

If you contribute to GNOME, you’re eligible to become a member of the GNOME Foundation, which gets you some perks (like an @gnome.org email address and Matrix account, blog hosting and syndication, and access to Nextcloud and video conferencing tools)—but most importantly, GNOME Foundation members vote to elect the Board of Directors. If you contribute to GNOME, I highly recommend you become a member: it looks good for you, but it also helps ensure the GNOME Foundation is directly influenced and governed by contributors themselves.

I’m Running for the Board!

I realized today I never actually announced this on my blog (just via social media), but this past March I was appointed to the GNOME Foundation Board of Directors to fill a vacancy.

However, the seat I filled was up for re-election in this very next cycle, so I’m happy to officially announce: I’m running for the GNOME Foundation Board of Directors! As part of announcing my candidacy, I was asked to share why I would like to serve on the board. I posted this on the GNOME Discourse, but for convenience, I’ve copied it below:

Hey everyone,

I’m Cassidy (cassidyjames pretty much everywhere)! I have been involved in GNOME design since 2015, and was a contributor to the wider FreeDesktop ecosystem before that via elementary OS since around 2010. I am employed by Endless, where I am the community architect/experience lead.

I am particularly proud of my work in early design, communication, and advocacy around both the FreeDesktop color scheme (i.e. dark style) and accent color preferences, both of which are now widely supported across FreeDesktop OSes and the app ecosystem. At elementary I coordinated volunteer projects, lead the user experience design, launched and managed OEM partnerships, and largely maintained our communication by writing and editing regular update announcements and other blog posts. Over the past year I helped organize GUADEC 2024 in Denver, and continue to contribute to the GNOME design team and Flathub documentation and curation.

I was appointed to the GNOME Foundation board in March to fill a vacancy, and I am excited to earn your vote to continue my work on the board. If elected, I will continue my focus on:

• Clearer and more frequent communication from the GNOME Foundation, including by helping write and edit blog posts and announcements

• Exploring and supporting fundraising opportunities including with users, OEMs, and downstream projects

• Ensuring Flathub continues to be recognized as the premier Linux app store, especially as it moves to enable financially supporting the developers of FOSS apps

• More widely communicating the impact, influence, and importance of GNOME and Flathub to raise awareness beyond the existing contributor community

• Helping ensure that the Foundation reflects the interests of the contributor community

I feel like the GNOME Foundation is at an important transformation point, and I look forward to helping steer things in the right direction for an effective, sustainable organization in support of the GNOME community. Regardless of whether I am elected, I will continue to contribute to design and communication as much as I’m able.

Thank you for your consideration!

Become a Member, and Vote!

Voting will be open for two weeks beginning June 5, 2025. If you contribute to GNOME, now is a great time to ensure you’re a member so you can vote in time; check the GNOME Discourse announcement for all of the specific dates and details. And don’t forget to actually vote once it begins. :)

It’s strange being alive while so much bad shit is going on in the world, right? With our big brains that invented smartphones, quantum computers and Haskell, surely we could figure out how to stop Benjamin Netenyahu from starving hundreds of thousands of children? (Or, causing “high levels of acute food insecurity” as the UN refer to it).

Nothing in the world is simple, though, is it.

Back in 1914 when European leaders kicked off the First World War, the collective imagination of a war dated back to an era where the soldiers wore colourful jackets and the most sophisticated weapon was a gun with a knife attached. The reality of WWI was machine guns, tanks and poison gas. All that new technology took people by surprise, and made for one of the deadliest wars in history.

If you’re reading this, then however old or young you are, your life has been marked by rapid technological changes. Things are still changing rapidly. And therein lies the problem.

In amongst the bad news I am seeing some reasons to be optimistic. The best defense against exploitation is education. As a society it feels like we’re starting to get a grip on why living standards for everyone except the rich are nosediving.

Lets go back to an older technology which changed the world centuries ago: books. I am going to recommend a few books.

Technofeudalism (by Yannis Varoufakis)

The book’s preface outlines the theory: capital has mutated into a much more powerful and dangerous form of itself. Two things caused it: the “privatization of the internet”, and the manner in which Western governments and central banks responded to the financial crisis of 2008. The strongest part of the book is the detailed telling of this story, from the beginnings of capitalism and its metamorphoses during the 20th century, to the panicked central banks keeping interest rates near zero for over a decade, effectively printing money and giving it to the wealthy, who in turn decided it was best to hang onto all of it. Out of this he declares capitalism itself is dead, replaced by a more powerful force: technofuedalism.

Yanis’ concept of technofuedalism is this:

Markets, the medium of capitalism, have been replaced by digital trading platforms which look like, but as not, markets and are better understood as fiefdoms. And profit, the engine of capitalism, has been replaced with its feudal predecessor: rent. Specifically, it is a form of rent that must be paid for access to those platforms and to the cloud more broadly.

Many people depend on cloud platforms for basic needs. For example, access to work. Think about how many people earn a living through apps: Uber drivers, food delivery couriers, freelancers advertising via Google or Meta, and so on. But it’s not just individuals. Many capitalist businesses now rely on sites like Amazon.com for most of their sales. Everyone has to pay cloud rent to the overlord.

Yanis likens this to a colonial town where all the shops are owned by the same guy, who happens to be named Jeff. This isn’t your traditional monopoly, though — because cloud platforms also “personalize” your experience of the site. You get recommendations perfectly tailed to your needs. For consumers, the platform owners control what you see. For participants, they control who is paying attention. This he calls cloud capital.

The concept of cloud capital needs better definition in the book, but I think the attention economy is the most interesting aspect, and it is what leads to the other counterintuitive side effect: many people creating value for cloud platforms do it for little or no money. Apple doesn’t pay you to make app store apps. Tiktok don’t pay you to upload videos. The book claims that capitalist companies like General Motors pay about 80% of their income to workers as salary payments, while Big Tech companies tend to spend less than 1% of their income paying workers.

In my last status update I mentioned some disillusionment with open source projects in the age of AI. Here’s another perspective: contributing to some open source projects now feels like giving free labour to cloud platform owners.

The Free Software movement dates from the 1980s, when operating systems were a source of power. Microsoft created an illegal monopoly on operating systems in the 90s and became the richest and most powerful company in the world; but today, operating systems are a commodity, and Microsoft makes more money from its cloud platform Azure.

It’s great that we maintain ethical, open computing platforms like GNOME, but the power struggle has moved on. I don’t expect to see huge innovations in desktop or mobile operating systems in the next decade.

Meanwhile, maintaining ethical cloud platforms is still a minority pursuit. Writing software doesn’t feel like the difficult part, here. The work needed if we have the will to climb out of this technofuedal hole is community organization and communication. The most valuable thing the major cloud platforms have is our attention. (And perhaps the most valuable thing we have in the open source world, is our existing communities and events, such as the Linux App Summit).

Why does this book give me hope? It gives a structure to the last 18 years of fucked up goings on in the world of power and politics. And it helps us analyze exactly what makes the big tech companies of the USA and China so powerful.

If the cloudalists got to you already and you don’t have the attention span to buy and read a book any more, don’t worry! There’s also a video.

The Trading Game (by Gary Stevenson)

I’m late to the party with this one. Gary started a blog ten years ago (wealtheconomics.org), and now runs a online video channel (GarysEconomics).

He knows a lot about money and the super-rich. He knows that people are addicted to accumulating wealth and power. He knows that living standards for working people are getting worse. He knows that politicians won’t admit that the two things are linked. And he has over a million subscribers to his channel who know that too.

Why does it give me hope? First, he’s focused on helping us understand the problem. He does have a clickbait solution — “Tax wealth, not work” — but he also acknowledges that it’s slow, difficult and messy to affect national politics. He’s realistic about how difficult it is to tax the super-rich in a world of tax havens. And he’s been going at it for 10 years already.

Careless People (by Sarah Wynn-Williams)

I listened to long discussion of this book on a podcast called Chisme Corporativo, run by two chicas from Mexico working to demystify the world of big business and USA power that controls much of the world.

The fact that Chisme Corporativo exists makes me very happy. If we’re going to live in a world where US corporations have more power than your own government — particularly the case in Latin America — then it makes a lot of sense to learn about US corporations, the people who run them, and why they make the decisions they do.

The book review quotes a part where Mark Zuckerberg finally realized that Facebook was instrumental in the first Tromp election campaign, and just how much power that endows the company with.

And he digested this bombshell for three hours, and his thought process led him to this: “Maybe I should run for president!”

That’s the type of person we are dealing with.

What’s next

Inequality keeps rising and living standards are getting worse for everyone except the super rich. But we are learning more and more about the people and the processes responsible. Information is a seed for bringing society into better balance again.

I’m going to leave you with this quote I stole blatantly from Gary Stevenson’s website:

“If we can really understand the problem, the answer will come out of it, because the answer is not separate from the problem.”
― J. Krishnamurti

Have you read any of these books? What else would you add to this list?

We’re happy to have released gst-dots-viewer, a new development tool that makes it easier to visualize and debug GStreamer pipelines. This tool,  included in GStreamer 1.26, provides a web-based interface for viewing pipeline graphs in real-time as your application runs and allows to easily request all pipelines to be dumped at any time.

What is gst-dots-viewer?

gst-dots-viewer is a server application that monitors a directory for .dot files generated by GStreamer’s pipeline visualization system and displays them in your web browser. It automatically updates the visualization whenever new .dot files are created, making it simpler to debug complex applications and understand the evolution of the pipelines at runtime.

Key Features

• Real-time Updates: Watch your pipelines evolve as your application runs
• Interactive Visualization:
  • Click nodes to highlight pipeline elements
  • Use Shift-Ctrl-scroll or w/s keys to zoom
  • Drag-scroll support for easy navigation
• Easily deployable in cloud based environments

How to Use It

1. Start the viewer server:

   gst-dots-viewer
   

2. Open your browser at http://localhost:3000
3. Enable the dots tracer in your GStreamer application:

   GST_TRACERS=dots your-gstreamer-application
   

The web page will automatically update whenever new pipeline are dumped, and you will be able to dump all pipelines from the web page.

New Dots Tracer

As part of this release, we’ve also introduced a new dots tracer that replaces the previous manual approach to specify where to dump pipelines. The tracer can be activated simply by setting the GST_TRACERS=dots environment variable.

Interactive Pipeline Dumps

The dots tracer integrates with the pipeline-snapshot tracer to provide real-time pipeline visualization control. Through a WebSocket connection, the web interface allows you to trigger pipeline dumps. This means you can dump pipelines exactly when you need them during debugging or development, from your browser.

Future Improvements

We plan on adding more feature and  have this list of possibilities:

• Additional interactive features in the web interface
• Enhanced visualization options
• Integration with more GStreamer tracers to provide comprehensive debugging information. For example, we could integrate the newly released memory-tracer and queue-level tracers so to plot graphs about memory usage at any time.

This could transform gst-dots-viewer into a more complete debugging and monitoring dashboard for GStreamer applications.

Demo

Hey GNOME and GSoC! 👋

This is my first blog post on Planet GNOME and actually, my first blog post ever! I’ll be using this space to share updates on my Google Summer of Code 2025 project and other GNOME contributions I make along the way or even after GSoC ends. Of course, most posts for now will focus on my GSoC work.

🛠️ My GSoC Project: Improving JSON, XML, and YAML Integration in Vala

My GSoC project is about improving how Vala handles JSON, XML, and YAML. Right now, working with these formatting languages in Vala can be tedious. I’ll be contributing improvements to make parsing and emitting data in these formats easier and more intuitive for developers.

I’ll also be diving into some compiler design topics and exploring Vala projects that already use these formats, to better understand current pain points and use cases.

Thanks 🙏

Also, big thanks to Felipe Borges for maintaining Planet GNOME, and to my mentor Lorenz Wildberg, who will be mentoring me on this project. 💙

Celebrating 200 Weeks of This Week in GNOME! 🎉

What a milestone! We’re thrilled to celebrate the 200th post of This Week in GNOME - that’s nearly four years of showcasing the amazing work, features, and people that make GNOME thrive.

• 200 weeks of curated updates
• 2.051 individual news entries
• 1.527 images showcasing the latest features
• 259 people who are part of the TWIG community

From new features, fresh designs, bug fixes but also exciting app launches — TWIG has become a vital pulse of the GNOME community.

Whether you’re a reader, contributor, or part of the community behind the scenes — thank you for being a part of this journey! ❤️

Launching TWIG 2.0

Nearly four years after its launch, I’m delighted to unveil a completely revamped thisweek.gnome.org! Welcome to TWIG 2.0 — featuring a modern technical foundation, a refreshed design, exciting new features, and so much more!

• Modernized design, now in line with the fabulous gnome.org redesign
• New dedicated landing page showing the latest numbers
• Beautiful autogenerated cover images for each post
  • Showcasing a featured project from the week
  • Include a screenshot in your update — with a bit of luck, it’ll appear on the post’s cover!
  • Each screenshot is dynamically decorated with the latest Adwaita wallpaper
• Revamped posts page, feel nostalgic when you scroll through 200 weeks of GNOME history
• New post filter make it easy to find updates on specific projects
• Click on a contributor name to see their past TWIG submissions
• Click-and-hold images in posts to view them in full size
• Extended Open Graph protocol support, so posts look great when shared on social media
• Improved RSS/Atom feed with richer metadata and better formatting
• Rebuilt with Astro, offering a faster and more modern experience
• …and many more improvements!

Have fun with TWIG 2.0, I’m looking forward to your feedback!

And now, as usual, to the happenings across the GNOME Project in the week from 09 May to 16 May 😉.

Accessibility

Georges Stavracas (feaneron) says

Today (May 15th) is the Global Accessibility Awareness Day. To celebrate it, I wrote about the unsung heroes that keep on fighting against all adverse conditions around the Linux desktop in order to improve its accessibility. You can read more here.

GNOME Core Apps and Libraries

Mutter ↗

A Wayland display server and X11 window manager and compositor library.

jadahl says

Mutter, GNOME’s compositor framework that GNOME Shell is built on top of, got a new developer tool this week, the “Mutter Development Kit”. This new development kit provides a new way to run a nested GNOME Shell instance inside a GTK app which will provide various tools useful for compositor and shell development. The tool it has so far is touch emulation, but more will come.

Maps ↗

Maps gives you quick access to maps all across the world.

mlundblad announces

Labels such as street names and house numbers can now be clicked to show the place information (and easily add them to favourites) in Maps. Pictures here: https://gitlab.gnome.org/-/snippets/7004 https://gitlab.gnome.org/-/snippets/7005

GNOME Circle Apps and Libraries

Izzy (she/her) says

Binary 5.3 has just been released as a small update. It comes with many translation updates and a few small updates.

Development hasn’t been too active lately due to uni work and personal issues. I’m hoping to work on it a lot more over the summer and hopefully past that. In the mean time, get it now on flathub: https://flathub.org/apps/io.github.fizzyizzy05.binary

NewsFlash feed reader ↗

Follow your favorite blogs & news sites.

Jan Lukas reports

Newsflash 4.0 enters beta which can be checked out in the flathub beta channel. In this release most of the UI code has been refactored to make use of all the Gtk & rust binding goodies that were added over the years. Image, Audio and Video attachments are now all featured more prominently. More can be read here: https://blogs.gnome.org/jangernert/2025/05/12/newsflash-4-0-beta/

Déjà Dup Backups ↗

A simple backup tool.

Michael Terry says

Déjà Dup Backups just landed two big changes, to be released in 49.0:

• A UI refresh to align better with the HIG
• Restic is now the default backend for all builds (not just the flathub one)

Third Party Projects

vallabhvidy announces

Really happy to announce release of version 0.1.3 of Cube Timer🥳. Cube Timer is a tool to time your Rubik’s Cube solves. It tracks your solve time and maintains averages of previous solves. Solves can be organized into different practice sessions as well. It also has a basic scramble generator. The design of Cube Timer was inspired by cstimer.net.

It can be installed from Flathub.

Also Congratulations to TWIG for its 200th edition! 🥳🎉🎉.

Märt Põder says

Nautilus Compare, the context menu diff extension for Nautilus file manager (aka GNOME Files) is back in Debian repositories after five year hiatus. Although updated for Python 3 and GTK 3 already in 2020, the extension using Meld diff and merge tool by default and with localisations for 14 languages was only uploaded and approved about a week ago after months of intensified user demand and with support for latest GTK 4 and Nautilus 43. Extension is still available for earlier releases of Debian family distros in the Launchpad PPA, but can be conveniently installed from default repositories in current development and anticipated official releases.

francescocaracciolo reports

Newelle, AI assistant for Gnome, got updated to 0.9.6, introducing selective profiles and reasoning support for OpenRouter provider.

It can be installed from Flathub

Parabolic ↗

Download web video and audio.

Nick says

Parabolic V2025.5.2 is here! This release contains a bunch of new features that users have been requesting.

Here’s the full changelog:

• Added the ability to pause/resume running downloads
• Added the ability to specify save folder paths in a batch file
• Added the ability to exclude a download from history in advanced download options
• Added a Preferred Audio Codec option to downloads preferences
• Added audio codec information to audio formats
• Added an ETA to downloads’ progress
• Fixed an issue where generic videos would not download correctly

Fractal ↗

Matrix messaging app for GNOME written in Rust.

Kévin Commaille announces

Due to a pesky bug that makes Fractal crash when our users attempt to start a verification, we are releasing Fractal 11.1 only 2 weeks after Fractal 11. And while we’re at it we also backported a few fixes for smaller paper cuts!

This version is available right now on Flathub.

If you want to help us avoid regressions like that in the future, you could use Fractal Nightly. You could even get rid of our remaining bugs yourself!

Miscellaneous

Georges Stavracas (feaneron) announces

Flatpak 1.16.1 is out! It’s the first bugfix release of the 1.16 series. Some highlights of this release:

• Apps with the dri permission can now access /dev/udmabuf too. This may allow for better memory sharing and performance improvements in apps
• Don’t propagate the Wayland socket from host into sandbox if access to the Wayland socket has been denied
• Flatpak now looks for TLS certificates at /etc/containers/certs.d when interacting with OCI registries
• Fix intermittent flatpak-portal crashes by avoiding unnecessary multi-threading. This should help apps and libraries that heavily use the Flatpak portal, such as WebKit and glycin.
• When using parental controls, allow a child account to update existing apps by default, to ensure that security and bugfix updates can be installed
• Make systemd scopes easier to match to Flatpak app instances
• A couple of performance improvements in some specific situations

GNOME Foundation

steven reports

The Foundation Report is out for the week of May 12-16! It’s not any shorter! We’re sorry! ;)

Give it a gander.

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 will be contributing to GNOME Crosswords, as part of the Google Summer of Code 2025 program. My project adds construction aids to the Crosswords editor. These aids provide hints, warnings, and data that help the user create better crossword puzzles.

I have three mentors:

• Jonathan Blandford
• Federico Mena Quintero
• Tanmay Patil

GNOME Crosswords

The GNOME Crosswords project consists of two applications:

• The Crosswords player, which lets you play crossword puzzles.
• The Crosswords editor, which lets you create crossword puzzles.

My project focuses on the Crosswords editor.

To learn more about GNOME Crosswords, check out this GUADEC presentation that Jonathan Blandford, the creator of Crosswords, gave last year.

Crossword construction

Constructing a crossword puzzle is tricky. Constructing a good crossword puzzle is even trickier. The main difficulty lies in finding the right words to fill the grid.

Initially, it’s quite easy. The grid starts off completely empty, so the first few words that you add don’t have any restrictions on them (apart from word length). But as you fill the grid with more and more words, it becomes increasingly difficult to find words to fill the remaining rows/columns. That’s because a remaining row, for example, will have a few of its cells already filled in by the words in the intersecting columns. This restricts the list of possible words for that row.

Something you can run into is that halfway through the construction process, you realize that one or more rows/columns cannot be filled at all, because no word meets the constraints imposed on it by the prefilled cells! In that case, you would need to backtrack and delete some of the intersecting words and try again. Of course, trying to replace a word could lead to other words on the grid needing to be replaced too—so you can get a domino effect of groups of rows/columns on the grid needing to be redone!

And that’s just what you have to deal with to create a valid crossword puzzle. To create a good crossword puzzle, there are many more things to consider, some of which impose further restrictions on the words that you can use. For example:

• Are the words interesting?
• Are there any words that are so uncommon as to feel unfair?
• Does the puzzle have a good variety of parts of speech?
• Is the grid rotationally symmetric?
• Are there any unchecked cells?

To learn more about the crossword construction process, check out How to Make a Crossword Puzzle by The New York Times, as well as How to Create a Crossword Puzzle by Wired.

Suffice it to say, creating a good crossword puzzle is difficult. Thankfully, crossword construction software can make this process easier—certainly not easy—but easier. For example, the GNOME Crosswords editor gives you a list of possible words for each row/column, taking into account any cells in the row/column that are already filled with a letter. We can consider this feature a “construction aid.”

The goal of my GSoC project is to add additional construction aids to the Crosswords editor. These aids will help the user create better crossword puzzles.

Construction aids

Here’s a list of potential construction aids that this project can add:

• Warning for unches (unchecked cells).
• Warning for non-dictionary-words.
• Warning for words with low familiarity.
• Indicator for average familiarity of words.
• Warning for crosswordese (overused crossword words).
• Heat map for hard-to-fill cells.
• Parts-of-speech distribution graph.

Right now, we are in the community bonding period of the GSoC program (May 8 to June 1). During this period, I will work with my mentors to determine which construction aid or aids this project should add, what they should look like, and how they should be implemented. By the end of the month, I will have created some design docs laying all this out. That will make it much easier to hit the ground running, once the coding period starts, in June.

Mini crossword

Here’s a mini crossword that I made! You can try it out by using the Crosswords player.

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.

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!

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 [email protected].

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.

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 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 <[email protected]>
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.

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.

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!