Update on what happened across the GNOME project in the week from September 18 to September 25.

Third Party Projects

Titouan Real announces

Era is a new calendar app for mobile and desktop that grows with your needs. It’s simple and calm for everyday use, while powerful features remain available when you need them. Use Era in a small window alongside other apps for multitasking, or switch to fullscreen for complex planning. It syncs your events with most online providers and continues working when you’re offline.

This week Era’s first beta version was released on Flathub, following more than a year of development. Download Era from Flathub now and report any bugs you can find.

For those interested in the technical details, Era is written in Rust and built with libadwaita for the GNOME desktop. We’re also working towards Android support and an APK is available from the CI pipeline. Under the hood, Era uses an extensible, modular calendar backend. It currently integrates with Evolution Data Server, while an experimental peer-to-peer backend based on p2panda is also available in devel builds.

Contributions are welcome, whether through code, testing, translations, or design. Check out the repository and join the conversation on our Matrix channel: https://matrix.to/#/%23era:gnome.org to get involved.

Particular thanks go to Philipp Sauberzweig for working on the design, as well as to everyone that helped me across the GTK, Libadwaita, Rust ❤️ GNOME and other communities!

Tanay announces

Deep Dive - Submerge into Deep Focus

This week I launched Deep Dive my second app after Whisp, Deep Dive is an active productivity timer built for the GNOME desktop. Based on the concept of “Submerging,” it operates on the principle that deep work requires strict boundaries. When you start a timer, you go underwater where distractions cannot reach you—you either finish the dive, or you deliberately “Give Up” and surface early.

You can choose between a Pomodoro Session or a Timer Session but that is not it -

Other Features Include :

• Submerge Mode: Locks the timer, completely preventing you from pausing or skipping your focus session.

• Break Overlays: Forces you to step away with a full-screen overlay during your scheduled screen breaks.

• Do Not Disturb Integration: Automatically silences system notifications while you are submerged in a work block.

• Project Tracking: Securely logs your focused time against specific projects locally on your device with graph based Stats

• User Customizability: All of this is customizable from length of the Pomodoro to Break Limits even Notifications

Deep Dive is now officially available on Flathub:

Website: https://tanaybhomia.github.io/DeepDive/ Flathub: https://flathub.org/en/apps/io.github.tanaybhomia.DeepDive Repository: https://github.com/tanaybhomia/DeepDive Support me : https://tanaybhomia.github.io/donate.html

Feedback is always welcome.

Capypara says

This week I updated Field Monitor. Field Monitor is a remote desktop client designed for GNOME that is optimized for connecting to virtual machines. It’s now more stable and performant than before and it’s UI has been simplified. It now also supports direct QEMU/D-Bus connections for configured KVM/QEMU libvirt VMs.

Download on Flathub: https://flathub.org/apps/de.capypara.FieldMonitor

Will Warner announces

Quadrapassel 51.0 has been released!

Here’s what is new:

• Added the Cornish translation
• Updated translations: Lithuanian, Russian, Belarusian, Czech, Ukrainian, Georgian, Chinese (China), Slovenian, Swedish, Brazilian Portuguese, Kazakh, Hungarian
• Fixed a bug where blocks would not stop moving if the game lost focus
• Fixed a bug where game keys wouldn’t work once if they were pressed before to starting a game
• Added a -1 difficulty, where the level never increases
• Modernized the ‘Game Over’ view
• Modernized the game themes and removed the tango and tango flat styles
• Changed the game stats to use cards
• Replaced the ‘Appearance’ dialog with an ‘Appearance’ page in the preferences

You can get Quadrapassel on Flathub.

Will Warner also announces

Solitaire 51.0 is out!

Here’s what is new:

• Added the Polish and Finnish translations
• Updated translations: Slovenian, Ukrainian, Chinese (China), Georgian, Kazakh, Brazilian Portuguese, Swedish, Cornish, Georgian
• Made target card stacks dim
• Made cards show different cursors
• Fixed bug where redoing a move would not run the solver
• Changed the game save feature to allow up to 4 saves at a time
• Improved focus, dragging, and selection indication
• Moved the appearance selector to the preferences, and improved its layout
• Made the new game button save the current game and always move to the game selection
• Moved unfinished games to a new section
• Moved the undo and redo buttons to the menu
• Changed the window color to have better contrast
• Fixed a crash when the waste was clicked while empty in the Pyramid game
• Changed the pyramid game rules to only require the pyramid to be empty for a win

You can get Solitaire on Flathub

Rat Cornu says

ratic music player had small improvements the past weeks with the new releases 0.4.2 and 0.4.3! The musics in the queue can now be reordered, and a small menu button is next to them to perform some actions, like going to the music album, or showing a dialog with the music tags. A right click on a music on the main view also open the same menu. Moreover, a noticeable change in the settings occurred, making clearer what picking a music does. Other small things has been fixed. You can check the new versions on flathub, on the repo, or even come discuss with us on our matrix room! Thanks again for all the people that contribute to the localization on weblate!

ckappgit says

AkiZip, our GTK4 archive front-end manager written in Python, has been updated to 0.4.0 on Flathub!

You can now process multiple files at once instead of being restricted to single-file operations.

A core maintainer has also returned to active development to help move the project forward.

Additionally, the security vulnerability fixed back in version 0.3.4 (GHSA-pxfq-f5pr-6crv) has now been officially assigned CVE-2026-92699.

Update AkiZip on Flathub and check out the repository!

Links: GitHub: https://github.com/AkiZip/AkiZip Flathub: https://flathub.org/en/apps/top.akizip.akizip

Alexey Volkov announces

Tailor - Create Bootable Drives

A tailor stitches - this one stitches OS images onto your flash drive

Recently launched Tailor - application for bootable USB creation without hunting .iso on internet.

Tailor has own OS catalog, using osinfo-db base. Pick OS family, edition, version, arch, then click ‘Create Bootable USB’. Image downloads (stays cached for rewrite later), Tailor checks checksums and starts writing.

GTK/Adwaita does not mean that Tailor is Linux-only: it is available on Windows too!

Tailor is now officially available on Flathub:

Repository: https://altlinux.space/qualimock/Tailor Flathub: https://flathub.org/apps/org.altlinux.Tailor Windows builds: https://altlinux.space/qualimock/Tailor/releases

Feedback is always welcome.

Lanséria says

New week, new update! Hello everyone, this week I’ve updated PedantiK to version 1.7.0, with two features : hints and list of previously guessed words.

You can now reveal random words in the page to help you if you get stuck, and all your guesses will be shown in a sidebar, allowing you to review what you’ve already guessed!

Thank for the community to suggesting these ideas! And have fun :D

xjuan reports

Casilda 1.6 Released!

A simple Wayland compositor widget for GTK 4

This release includes Clipboard and Drag&Drop integration with the host compositor.

You can read more about it at blogs.gnome.org/xjuan/2026/09/24/casilda-1-6-released/

Release Notes:

• Add DnD and clipboard support
• Add support xdg_foreign protocol
• Fix modifiers in pointer button press events
• Add keyboard Caps/Num/Scroll Lock support
• Fix popup of popup crash
• Fix maximized/fullscreen state handling
• Fix modifiers flags creation (Evgenii Danilin)
• Drop cursor surface listeners when the surface is destroyed (Evgenii Danilin)
• Close dup’d plane FDs when a dmabuf import fails (Evgenii Danilin)
• Advertise a valid output scale to avoid a scale-0 assert (Evgenii Danilin)
• Unref the wayland GSource (Evgenii Danilin)
• Meson config cleanup (Val Packett)
• Use gtk api for snapping to device pixel grid

Давид Султаниязов says

ReadySet 0.13.1

The modular application for installing and initializing the ReadySet system was already mentioned in TWIG #233, and we’re back to tell you what we’ve done in the meantime.

New plugins

ReadySet has started to acquire built‑in plugins for convenient use in various distributions:

• date-and-time — selecting the date, time, and time zone, including auto-selection by language;
• software — adding ThirdParty repositories: Flathub, proprietary solutions, and so on;
• network — configuring Wi‑Fi and the computer’s name on the network;
• privacy — privacy settings. For now, this only includes enabling automatic geolocation detection;
• license-agreement — accepting the license agreement.

ReadySet is already in use!

Now ReadySet is used in some systems of the ALT Linux family — ALT Mobile (a system for mobile devices), ALT Regular Gnome (a regularly updated image), and ALT Atomic Onyx (an atomic distribution with GNOME).

Currently, it is used as a master for initial setup for these systems, and later it is planned to use it as an installer for ALT Atomic systems — the development of the plugin has already begun.

Adaptive interface

The main improvement to the interface was the enhancement of adaptability. ReadySet can operate in three modes depending on the screen size and format:

• for tablets and portable set‑top boxes — a horizontally elongated small screen;
• for mobile devices — a vertically elongated small screen;
• for computers — a large screen.

Some widgets have been moved to the libcase library, which other projects will be able to reuse.

Architectural changes

ReadySet now supports various operating modes:

• installer — a mode for use as an installer;
• initial-setup — a mode for the initial setup wizard;
• existing-user — a mode for additional configuration during updates and the introduction of new functionality.

Special attention has also been paid to integration with GDM for running in kiosk mode and seamless transition into the system immediately after the initial setup is completed, without the need to re‑log in as the user.

For developers

For testing in CI/CD, images are built based on ALT Atomic Minimal with GNOME and Phosh, with ReadySet added; these can then be installed on a virtual machine to test functionality.

In the future, it is planned to create a knowledge base so that other distribution developers can integrate ReadySet into their ecosystem.

dabrain34 reports

🎉 New Release Announcement: GstPipelineStudio v0.6.0 🎉

It’s a great pleasure to announce the release of GstPipelineStudio version 0.6.0! This release adds an auto-suggest engine that proposes the next element to connect to your pipeline, brings GstPipelineStudio to three languages and moves the interface to libadwaita.

Highlights:

• Auto-suggest engine proposing the next element to add
• Caps typing with typefind and demuxer caps discovery
• Open Media URI dialog for uri-property elements
• Pipelines list view and multi-node rubber-band selection
• Read-only graph mode during playback
• Translations for French, Spanish
• Reworked UI with libadwaita dialogs and GraphView themes
• Category badges and media-type colors on elements
• GStreamer 1.28.7, GTK 4.22.4 and libadwaita 1.9.2
• HTTPS support bundled on Windows and macOS
• Rework the GStreamer log handler

Participants:

• Stéphane Cerveau — maintainer and main contributor
• Dillon Hemphill
• Translations contributed through Weblate

🚀 Upgrade Now!

To get the latest version of GstPipelineStudio, visit the project’s page and check out the Changelog for more details.

Happy streaming! 🎬📡

Bilal Elmoussaoui reports

I have released a new beta version of oo7 crates in preparation of it adoption in the wider linux distribution communities. You can find more details at https://github.com/linux-credentials/oo7/releases/tag/0.7.0.beta

Shell Extensions

swink announces

Now Playing Card puts a little equalizer in your top panel. Click it for cover art, seeking and controls. It works with any player: Spotify, browsers, whatever. Install it and forget about it. It took about a month from first commit to store. The idea took an evening. The rest went to cover art, because every player sends it differently.

Get it: https://extensions.gnome.org/extension/10736/now-playing-card/ Source: https://github.com/epogonii/nowplaying-card

swink says

Wisp, a GNOME Shell extension that brings snapper into the top bar.

On most btrfs systems snapper keeps taking snapshots in the background, yet restoring from one usually means dropping to the terminal. With Wisp you can list your snapshots, check what changed since any of them, pull back individual files, or roll the entire system back, all from the panel.

Get it: https://extensions.gnome.org/extension/10755/wisp/ Source: https://github.com/epogonii/wisp

somepaulo says

The Weather Or Not extension has been updated for GNOME 51. The code has been almost completely rewritten to use underlying functionality already available in Shell instead of recreating them. Generally, the extension now works much more clearly than before.

On the user facing side of things, there’s now a smooth transition when weather data changes and a spinner for when data is first loaded on boot, on location change or after a long time without a connection. Stale weather data gets dimmed after an hour with no successful updates.

Last but not least, accessibility has been improved with proper support for detecting keyboard presses and for the reduced motion setting.

The new version has already been approved and is live on EGO..

Miscellaneous

Hari Rana | TheEvilSkeleton (any/all) 🇮🇳 🏳️‍⚧️ reports

The “3. Probabilistically Automated” label has been appointed throughout the GNOME/ namespace on GNOME GitLab, for labeling tickets/issues and merge requests that use artificial “intelligence”. This new label describes itself as the following:

Major or total reliance on “AI” / LLMs / stochastic parrots to generate code or bug reports. Usually accompanied by a lack of proper testing, and writing reports or finalizing patches based on plausibly sounding intended behavior rather than correctness of code.

We decided to use “probabilistically automated” as the label to avoid anthropomorphizing artificial “intelligence”.

The discussion took place in the Calendar Matrix room, with contributors from different projects (specifically, Document Scanner and Nautilus). Calendar already used the “Probabilistically Automated” label but only internally, which was also announced on GNOME Discourse. Document Scanner was the second one to use the label in the project by recreating the label, and one of the Nautilus developers was looking into recreating the label for Nautilus. Since this was a lot of duplicated effort, we decided to appoint it throughout the GNOME/ namespace, so every project that bans AI contributions can also use this label. The only thing that needed to be done was to tweak the wording and then appoint it.

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!

GNOME and KDE have started to consider LLM policies, and we should talk about what this is really about.

KDE caught everyone's attention first by igniting a flame war with an LLM-friendly draft that ended up being deleted, causing a few bans, and having a bunch of people go full "Some of you may die, but that is a sacrifice I am willing to make". GNOME has not proposed anything official, but some teams (gnome-calendar, loupe, libadwaita, gnome-software, Circle, among others) already have strong policies in place, and there is now an informal draft to ban all LLM contributions to GNOME projects and infrastructure.

However I believe these discussions are not about nitpicking workflows but rather about the raison d'être, the reason to be, of FLOSS projects.

Communities Or Completionism

My take is that there are currently two ways of thinking about why FLOSS exists, or should exist. So far, both sides have coexisted but the growing acceptance of LLMs into some developer workflows has disrupted the balance.

We can call one of these sides "collectivism". This frames FLOSS to be about accomplishing things together, enjoying the journey and bonds that big goals tend to create. The fun is the collective effort and challenge. Overcoming language and social barriers is part of the reward. "The journey is the destination", "FLOSS is the friends we made along the way", etc.

On the other side there is "completionism", where FLOSS is "just a product" and its only goal is to always be better, faster, safer. Any fun to be had is in individually solving technical problems and requirements. Social bonds may happen, but colleagues are more coworkers than community. This is a "100% allglitches alltricks" TAS speedrun. The "we are apolitical", "we only care about the code" view.

My assessment is that the collectivist framing finds FLOSS primarily a social exercise that rewards you with experiences, bonds, and ideas outside of your niche interests. Some times you even get good software as a bonus! The second framing sees FLOSS as a tool to scale the complexity of your individual computer interest, like graphics or security. FLOSS is a convenience compared to manually rebasing patches and forks all the time.

The problem we are facing is that LLMs have given the second group a lever to stop giving the collectivist framing any room. When the LLM can get you 80% of the way to your goal, there is no need to "waste" time in mentoring, discussion, or convincing others. The temptation compounds if you are considered an expert in your field. You can surely fill in the last 20%, right? Is anyone going to challenge not only the machine, but also the expert?

Progress At All Costs

Since LLMs present themselves as neutral, and dispassionate, opposition to their output becomes opposition to objective progress: bug fixes, security hypotheticals, features. Progress is whatever the LLM, under my own careful eyes, says it is. Interactions with others become formalities, since the LLM is simply boosting my own, already expert and close to infallible, output. Right?

Unfortunately this "expert slop", where expert is a self-perceived title, carries a corporate framing that damages interactions. Others become, at best, fungible coworkers, and, at worst, annoying speed bumps in the race to 100% completion of any software interest the expert has. No more mentoring, debating, flame wars. "Progress" is the only goal. The line must go up.

There is more to say about how this machiavellian framing causes far more important harms and externalities, in the name of LLMs themselves, or apparent LLM-assisted progress. Think of any group and you will find out they have been handed part of the bill for these externalities:

• The people who will lose their homes, schools, lives, in the Global South because of El Niño 2027
• The towns destroyed by data center illegal and irresponsible practices
• The price of all consumer goods going through the roof because of financial speculation
• The pensioners who might lose their pension when the bubble finally pops.

These are the real costs in the "Progress At All Costs" that LLMs bring into FLOSS. These are the people who will pay the bill, behind the scenes and far from our screens, so that some big brain engineers can avoid reading documentation, writing boilerplate, learning unfamiliar code, or, worse, working with others.

FLOSS As Principled Software

Almost ten years ago Allan Day described GNOME as Principled Software because of its commitment to always doing the right thing, in code or design, because it was the right thing and not because of ease, pressure, or hype. I believe this is why so many other FLOSS projects have always looked at GNOME for guidance on what good FLOSS should be. This discussion is just another opportunity to continue to meet this expectation.

Recent discussions have shared similar sentiments like reminding us that we do book clubs because we want to read and enjoy books, not to just discuss over summaries because it is "more productive". That when pressed to accelerate FLOSS, to make the line go up, we have to ask for whom do we want to be more productive, efficient, faster?. And that every decision is political and affect other people around you.

We already know that LLM productivity is not real, just a self perception, that LLMs are just a fairy tale to maintain tech stocks hypergrowth, by farming engineers for engagement, and the latest in a series of attacks to commoditize tech workers. Knowing all this, are we still going to play along with big tech's lies and exploitation? Or, are we going to make another principled stand?

GNOME did not need LLMs to produce 30 years of creative engineering, design, localization, inclusion, and collaboration that has been shared with people around the world. It does not need to throw away this incredible legacy simply because LLMs happen to farm our worst individualist impulses.

We came this far without compromising our principles, let's not start now.

DnD Release

I am very happy to announce a new version of Casilda!

A simple Wayland compositor widget for Gtk 4 originally created for Cambalache

This new version brings Drag&Drop and clipboard support / integration with the host compositor which means you can drag something from a host application and drop it on an application window embedded in a Casilda compositor widget and vice versa!

After a very rugged GUADEC presentation where I tried to show how to create simple Gtk application from slides made with Cambalache using a Casilda compositor to embed GNOME Builder and Cambalache itself I decided to fix all the issues I found so I could redo the presentation and upload it as a video.

This is a screenshot of the slider window, inside it there is a Casilda compositor (green line) used to embed a Cambalache instance which uses another CasildaCompositor (red line) to preview the UI.

Things that possi-bly could go wrong and did:

• Clipboard (Could not copy paste snippets)
• Keyboard numeric pad
• Keyboard modifiers in pointer events (I could not use Alt+Click to force create widgets)
• Example application connected to host compositor instead of Casilda widget
• Gnome Builder fullscreen window state broken
• Popover tooltips crash

After fixing all the bugs and keyboard support I started working on adding Clipboard integration with the host.

Clipboard support

Integrating the clipboard between Casilda and Gtk was fairly easy since all I needs to be done is copy all the clipboard data provided by wlroots wlr_seat::request_set_selection event to GdkClipboard and call wlr_seat_set_selection() on GdkClipboard changed signal.

Wlroots client to Gtk

In other to do this I created a new GdkContentProvider that uses a wlr_data_source as the source of the data and set the provider as the content of the clipboard with gdk_clipboard_set_content().

Internally when a clients wants to get data from the clipboard the new provider creates a unix pipe to read data from wlroots by writing to the pipe with wlr_data_source_send() and reading form the other end using g_output_stream_splice_async().

 Gtk to wlroots to client

To go in the other direction I created a new wlr_data_source that uses a GdkClipboard as source and set selection with wlr_seat_set_selection()

Internally gdk_clipboard_read_async() is called to initiate the data read when wlr_data_source send() method is invoked to send the data to the client.

 Drag & Drop support

Integrating D&D was not as easy as the clipboard. Setting it up to work within Casilda is easy enough other than wiring up some events all I had to do was draw the drag icon surface.

The first thing I did after getting the drag surface was draw it at the pointer coordinates which produced blurry results since pointer coordinates are fractional which means they do not always align with the pixel grid.

That was all nice and good but now I needed to start integrating the drag with Gtk (host compositor) so right after calling wlr_seat_start_pointer_drag() I created a GdkDrag with gdk_drag_begin() and used gtk_drag_icon_set_from_paintable() to set the drag icon and I noticed it was still blurry!!!

After a minute of confusion I realized that Gnome Shell (mutter) must be making the same mistake I did before so I decided to see if I could fix it!

Thanks to Michel Dänzer for guiding me and reviewing my MR, Gnome Shell 51 should have sharp drag icons!

Now back to integrating DnD with the host compositor.

These are all the different use cases that are needed to make D&D work transparently across host and guest compositors:

• Casilda client to Casilda client
• Casilda client to Host client
• Host client to Casilda client

Of course wlroots only contemplates the first use case, the other two cases are specific to Casilda.

Casilda to Host

So far we can detect when a client start a drag, let wlroot handle it and create a GdkDrag to let Gtk initiate another drag at the host level.

This means that when a client embedded in a CasildaCompositor initiates a drag there are two simultaneous drags at the same time, in the guest and host compositors. Keep in mind Casilda always delegates drag icon rendering to the host compositor.

During normal operation Casilda gets events from an event controller, but while on a drag operation events are not sent to the client at least not in the normal way, for that you can use a GtkDropTargetAsync and connect to the various signals for example I use drag-motion to forward events to the client.

Host to Casilda

When a Drag is initiated in the host compositor Casilda reuses the GtkDropTargetAsync created to track motion events and connects to drag-enter signal to create a proxy drag source in wlroots and synthesize a button release event on GtkDropTargetAsync::drop to trigger the drop on the guest side.

Here is a screencast off all the different use cases in action.

As you can imagine getting all this to work together correctly is not trivial and I expect to be subtle bugs in different corner cases so please if you find one of those file a bug and include a screencast if possible.

Release Notes

• Add DnD and clipboard support
• Add support xdg_foreign protocol
• Fix modifiers in pointer button press events
• Add keyboard Caps/Num/Scroll Lock support
• Fix popup of popup crash
• Fix maximized/fullscreen state handling
• Fix modifiers flags creation (Evgenii Danilin)
• Drop cursor surface listeners when the surface is destroyed (Evgenii Danilin)
• Close dup’d plane FDs when a dmabuf import fails (Evgenii Danilin)
• Advertise a valid output scale to avoid a scale-0 assert (Evgenii Danilin)
• Unref the wayland GSource (Evgenii Danilin)
• Meson config cleanup (Val Packett)
• Use gtk api for snapping to device pixel grid

Fixed Issues

• #20 “SIGSEGV in server_request_acvtivate”

Where to get it?

Source code lives on GNOME gitlab here

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

Matrix channel

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

Mastodon

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

Happy coding!

KDE is on the news because of a controversial proposal to define an official “AI” (LLM) policy (archived link). Other projects have tried their hand at similar policies and stances but, in my opinion, they miss the mark about the goal of such initiatives. I think that the point of these statements is shaping social norms and not micro-managing developer workflows. They should be about signalling what kind of behavior we want, and what kind we reject.

This proposal does not go into detail about the many problems that LLM have caused to society, workers, the environment. It goes without saying that all these ills are fundamentally opposed to the humanist spirit of GNOME.

With all that in mind, here is what I personally think a GNOME LLM policy could be:

A GNOME Project LLM Policy

The GNOME Project prioritizes the social and human aspects of
collective software creation. Therefore:

1. LLMs ("AI") can not be used to create or modify
anything submitted to GNOME, or hosted on GNOME infrastructure.

You might be asked to prove your code meets this requirement.
You might be banned for trying to circumvent this policy.

Example Guidelines for Contributors

These are just a draft of the kind of criteria one could use to evaluate if a submission fits the policy.

• You must be able to personally reason and explain your changes
• You must be able to demonstrate knowledge of the problem space you are working on
• You must solve the underlying issue, not just its symptoms
• You must respect the time of fellow contributors
• You must not impersonate yourself through chatbots, agents, or other automated systems

This Is About The Future Of GNOME

GNOME is not just software that happens to ship every six months. That is just a delusion we have been holding up for the last 30 years to keep our loose group of colleagues, friends, and acquaintances, together.

GNOME exists as a collective that find joy in reaching beyond our individual limitations to achieve something bigger. These people, this joy, are the whole point of the project. Contributors are not payroll, a liability, that we hope to downsize next quarter.

“Come do free labor for a handful of corporations by reviewing chatbot output in your free time” is not an attractive proposition to young talented people in 2026. If we want GNOME to continue we need to create an attractive and inviting social space where people are valued as people.

Just like the Foundation is moving to individual donations to stop depending on just a handful of companies, we need to look for the next 100 people that will donate a tiny bit of their time, instead of hoping that corporations will keep 10 overworked engineers on staff. We already have seen how companies will happily abandon a whole chunk of GNOME on a whim.

GNOME is not just software, and it should protect the social and human aspects that make it special. Our success metric is the community and social bonds we create. In the most literal sense GNOME is about the journey and the friends we make along the way.

Free Palestine.

FAQ

How do you enforce this?

You can not. People will still send LLM generated code. This policy makes it explicit that we do not welcome these careless submissions. We have a Code of Conduct that is 80% about telling other people what our values are, and 20% about handling unwanted behavior (“enforcing”). This is similar.

What if people simply lie about not using LLMs?

This is the same problem as authorship, in the copyright sense. Whenever we receive new code we have to assume that “beyond a reasonable doubt” said code has been authored by the person contributing it. We make our best guess. The attached guidelines are a suggestion to make these new guesses.

Ok. But what if people are really good at lying?

This policy is about the majority that will not even try to lie. See previous questions.

With the imminent release of GNOME 51, I realised I hadn’t released an update to Bobby in a few months.

The long tail of crash reports after a release just doesn’t seem to happen anymore when working with Rust. It’s just done and I moved on to other things.

Search

Bobby follows the GNOME version number scheme for convenience, but I did not want to let a major version bump go by without at least one new useful feature. So I’ve added search.

It uses case-insensitive fuzzy matching to filter out rows and highlight cells using the system accent colour as you type.

Simple yet effective!

Future

There are now two big features left that I want to implement:

• Encrypted file support
• Updating values in place

I’m not sure which one to work on in the next cycle, so let me know in this poll on the Fediverse which is most useful to you.

Happy equinox and don’t forget to sanitise your database inputs!

WPE WebKit and WebKitGTK 2.54 have been released with a bunch of improvements and new APIs as usual, but there’s one point that kept the Igalia WebKit graphics team busy for the whole cycle: the new Skia-based compositor. The replacement of Cairo with Skia for content rendering has been a success and it’s already well integrated and optimized. We thought we could try to use Skia for the composition too and replace TextureMapper with Skia. TextureMapper was introduced in 2010 for the Qt port and later adopted by other ports. It uses the OpenGL ES API and maintains a collection of shader programs to paint different content. Nowadays TextureMapper is mostly the same code and shader programs, and it’s unmaintained and missing features. However, the performance was good and it has served us really well all these years. So, this time the goal was not to get better results in benchmarks, but to modernize the implementation, reduce the amount of code to maintain ourselves (like all shader programs) and make it easier to implement the missing features and fix existing bugs. This post is a summary of all the work we have done this cycle to implement the new Skia compositor.

SkiaCompositingLayer

The first step was adding an SkiaCompositingLayer class to replace TextureMapperLayer and adapt all the code to use one or the other depending on an environment variable. The initial implementation was based on the TextureMapper one for the things that are common like iterating the layer tree, computing transformations, etc. The way layers produced their contents didn’t change, so we were receiving textures for tiled content, video buffers, WebGL, accelerated 2D canvas, etc. SkiaCompositingLayer created a Ganesh Skia surface to draw those textures using SkCanvas::drawImageRect(). This initial implementation was enough to run the default MotionMark test suite, since it doesn’t use other composition features. Even though performance was not the goal, we had to make sure we didn’t regress. This initial implementation was neutral in MotionMark. We needed tests to implement those features and measure performance at the same time, so we decided to add a new set of tests to MotionMark, just extending the existing tests to require composition, which makes sure that filters, masks, path clipping, transformations, etc. were done by the compositor.

Filters

We first tried implementing filters using an intermediate surface like TextureMapper does. It worked, but the MotionMark score in the filters test was much worse. We realized that with Skia we could implement most of the filters without using an intermediate surface. All filter types except blur and drop shadow can be simplified to an SkColorFilter with SkImageFilter::asAColorFilter() which can be implemented without an intermediate surface, just by setting the color filter in the SkPaint we pass to SkCanvas::drawImageRect(). This not only fixed the performance regression, but also gave better results than TextureMapper, which always needs an intermediate surface.

Masks

There are two different kinds of masks: image mask, where the source mask is an image already, and clip path, where the mask is represented by a path to be clipped. In TextureMapper both are implemented the same way using intermediate surfaces. The mask is painted into a surface and then the masked layer creates an intermediate surface where its contents are first painted and then the mask contents on top using DstIn blend mode. Skia has APIs that allowed us to implement both cases in a much simpler and more efficient way. In the case of image masks, where we already have an image, we paint the mask contents once and keep it cached, and then the masked layer creates an SkShader for the image mask that is passed to SkCanvas::clipShader() without having to paint into an intermediate surface. Clip path masks are even easier, because we can just take the path we get and build an SkPath we can pass to SkCanvas::clipPath(), without having to paint the mask as an image at all or use any other intermediate surface. Once again, masks were not only easier to implement but they ended up being more performant too.

3D contexts

The implementation of 3D layer contexts is fairly independent of TextureMapper and OpenGL, so we could just take it almost as it was, using SkPath to build the clips and a few other adaptations. We could also fix existing bugs like the z-ordering that has always been broken in TextureMapper.

Blend modes

TextureMapper never supported blend modes and they were easy to implement with Skia just using the SkPaint property for it. This made several layout tests start passing.

Batched painting

After implementing all the features we were at a point in which we had the same or better performance in all tests except for three MotionMark compositing tests that were giving much worse results. Those tests use small layers and give a high result which means we end up adding a lot of layers to the scene before we start skipping frames. The root cause was the large number of layers filling the command queue of Ganesh. Skia Ganesh queues the GL drawing operations instead of sending them to the GPU right away. When the surface is flushed for whatever reason, the queued GL drawing operations are then processed and sent to the GPU. This allows Skia to apply nice optimizations like merging several tasks and reducing the amount of draw operations we end up sending to the GPU. In those tests where a lot of layers are created and painted to the compositor Skia surface the internal command queue ends up being huge too. Processing and analyzing such a long queue to optimize what we send to the GPU required more CPU work than what we save by optimizing the GL draw operations. Skia provides an API that allows us to do the batching ourselves. Since the compositor already has information to decide what operations could be merged together, we could reduce the internal queue size in many cases. We can merge SkCanvas::drawImageRect() operations as long as they share the same color filter, blend modes and sampling options. In the best case scenario we could reduce the whole internal queue to just one operation. This time the change improved the results of those tests getting them to about 93% of the TextureMapper score, but still a bit behind.

Promise images

The Skia Ganesh backend requires that an SkImage backed by a texture is created for the current thread GrDirectContext, even if it’s borrowing an existing texture. In WebKit all textures are created with a sharing GL context so that they can be accessed and destroyed from different threads with the same sharing GL context. So, for a layer whose content is an image we had to create a texture in the compositing thread to upload the pixels if the image was not accelerated, or for accelerated images get the texture identifier of the image, and then create another SkImage from the compositing thread borrowing the texture for the current GrDirectContext. The Skia Ganesh backend provides an API to create promise images, which can be created from any thread but targeting a specific thread, providing a fulfill callback that will be called on the target thread when the SkImage is first used to retrieve the wrapped texture. This way we can create the SkImage from the main thread for the compositing thread without using OpenGL at creation time. For non-accelerated images we realized we don’t need to manually create the texture and upload the pixels in the compositor, we can just pass the unaccelerated SkImage to the compositor SkCanvas and Skia will handle it internally much more efficiently than we did. And this change improved those compositing tests much further than we expected. The reason turned out to be the batching from the previous section: Skia merges the entries of an image set by comparing texture proxy pointers, and until now we were wrapping the texture in a new SkImage on every frame for every layer, so hundreds of layers drawing the very same image produced hundreds of different proxies that Skia could not merge. Passing the same SkImage every time collapses all of them into a single draw operation, which is the best case we described above. With batched painting and promise images together we could beat TextureMapper significantly.

Deferred Display Lists (DDL)

When we switched to Skia for painting, we kept the threaded rendering model, just using a separate smaller queue for GPU rendering workers. The GPU workers created their own GrDirectContext to paint the layer tiles. The resulting textures were re-wrapped in the compositing thread for the compositor GrDirectContext using fences for the proper synchronization. We knew this was not the recommended way to use Skia Ganesh from multiple threads, but with TextureMapper we had no other option. However, with the Skia compositor we can do it the recommended way by using a single GrDirectContext in the compositing thread and use Deferred Display Lists (DDL) and promise images to paint the tiles. With DDL, GPU workers no longer use GL at all and they don’t need a GrDirectContext, they paint tiles into a display list that records the GL drawing operations, but without touching GL. For image drawing operations recorded into the DDL, promise images are used too. Since this is now all CPU work we can remove the smaller GPU worker queue and use a single queue with more workers. The compositor replays the DDL into an SkSurface that is then passed to the compositor SkCanvas.

This change fixed rendering glitches on Android and was performance neutral for the whole composition suite and for most of the MotionMark tests, but in MotionMark 1.3 at 15fps it cost 29% in Suits and 14% in Leaves, while improving Images by 9%. Correctness and the other benefits of DDL made us accept those regressions.

Damage

TextureMapper already supported using damage information to optimize the painting while compositing, but it has always been disabled at run time because there were issues we never managed to fix. With the Skia compositor we decided to start from scratch and properly handle the damage information while compositing to render only the parts of the frame that actually changed. I’m not going to go into detail here because Nikolas Zimmermann has written an amazing blog post about it with all the details.

Current situation

The Skia compositor is finished and enabled by default in 2.54. Even though it was not the main goal, it performs better than TextureMapper in most of the benchmarks we run: the composition suite we added is 45% faster, and MotionMark 1.3.1 is 35% faster. The exception is MotionMark 1.3 at 15fps with GPU rendering, which comes out flat, because the Suits and Leaves tests are still about 26% and 10% behind due to the deferred display lists trade-off described above.

We are already working on fixing existing issues in composition that we never fixed in TextureMapper. In the main branch TextureMapper is now disabled by default at build time, and support will be removed soon for the GTK and WPE ports. In 2.54 it’s still a run-time decision so if you find any issue with 2.54, you can check if it’s a Skia compositor regression by trying TextureMapper with WEBKIT_USE_SKIA_FOR_COMPOSITION=0 environment variable.

Future plans

We are already working on further improvements like using promise images for all external textures we have to pass to the compositor. We will explore the possibility of using Vulkan with the Ganesh backend instead of GL and eventually try the new Graphite backend. And of course we will continue fixing any existing issues related to the compositor.

Bombarded by the deception and lies of the AI industry I chose to sample boy Amodei for the ironic outrage about Chinese companies stealing their dataset. Thus the tune title.

Usually I barely manage to finish up my weekly beats track on a Sunday night. This week I've somehow had some extra time to sink into polishing an actual full track on the Dirtywave M8. Built around the bassline where I've mimicked the approach used on the Analog 4 of fading in a modulated filter and volume pulse over time using slight different tools (the M8 has 4 LFOs and ability to modulate a modulator).

• Pleased by the somewhat quirky conference venue, good to meet lots of old friends & catch up with them; to hand out large numbers of beavers, and to hear various interesting updates on what is going on in Nextcloud the software.
• Gave a very compressed Lighting Talk for five minutes on what we've improved over the last year:
• Enjoyed talking with lots of smart people until late at night with a party, dancing & more - nice. Back to the hotel, and out for a Kebap with Jan, Andy & Tim.

Update on what happened across the GNOME project in the week from September 11 to September 18.

This week we released GNOME 51!

This new major release of GNOME is full of exciting changes, including visual signatures in Papers, Maps offline usage, Files refinements, Calendar usability improvements, many accessibility enhancements, and much more! See the GNOME 51 release notes and developer notes for more information.

Readers who have been following this site will already be aware of some of the new features. If you’d like to follow the development of GNOME 52 (Spring 2027), keep an eye on this page - we’ll be posting exciting news every week!

GNOME Core Apps and Libraries

Libadwaita ↗

Building blocks for modern GNOME apps using GTK4.

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

A few days late, but I published an overview of the new features in libadwaita 1.10.

Internships

Felipe Borges says

We just concluded another successful season of Google Summer of Code with GNOME! In case you missed it, here’s where you can find all the details about the projects and work done by our interns https://feborg.es/wrapping-up-gsoc-2026-with-gnome

GNOME OS ↗

The GNOME operating system, development and testing platform

Ada Magicat announces

We now have documentation, on a website!

We wrote new guides, updated old ones and consolidated most information about GNOME OS and gnome-build-meta in one place. We now automatically publish a small book with up-to-date documentation on installing and using GNOME OS as well as how to contribute to GNOME OS and the GNOME flatpak runtimes

This is the result of many items of work over the last few months.

And we’re not done yet! We have a few more items that need validating and updating.

Ada Magicat reports

Users with little RAM, rejoice! GNOME OS should now stay fast and responsive even if you’re using a lot of RAM.

This is because we now use zswap, a Linux kernel feature that intelligently compresses infrequently used memory contents and writes them to a swap file.

For the few users that had issues with applications being killed due to their system running out of memory, this change should help a lot.

Thanks to Jonas, Sebastian and Valentin for working on this. You can try it out on the latest GNOME OS nightly.

Miscellaneous

albfan reports

Hi, some gitg contributor write this https://medium.com/@divyanshurajput709/one-micro-commit-at-a-time-my-gnome-journey-and-oosc-4-0-9b36236c4066

Third Party Projects

Deimos Hall says

Metamorphosis is an app to edit metadata. This week it received a new app icon by Hylke Bons and an update that improves the user experience with four categories to let users discover what to edit in an easier way. But it’s an ongoing work. If you find the tool useful, I need you. Please help me to drive the decisions for the future of the app, I want it be able to edit metadata of any kind of popular file formats as well as general date & time system metadata.

My goal is a tool that covers:

• Geotagging and Metadata Editor
• An app to change the modification date / timestamps of one or more files on the filesystem
• JExifToolGUI replacement
• Is coded by hand (no AI)

Download it on Flathub.

Daniel Elia announces

Convey, a GTK4 email client, has finally launched on Flathub!

It’s a fork of Geary with Microsoft 365 support, GTK4, as well as a bunch of bugfixes and UX improvements, notably fixing scroll issues on the conversation list, more predictable keyboard navigation and improved legibility in dark mode.

We’re now on version 50.1, with 50.2 on the horizon. Graph accounts now persist their folders so they load offline, folder keyboard navigation is predictable, Escape deselects conversations (with autoselect off in Trash and Junk), and dark mode rendering and context menu positioning in the message body are fixed.

Install it from Flathub, and check out the GitLab repo!

Alain announces

Planify 4.20.0 — Nextcloud Deck, CalDAV reminders, productivity goals, and more

Planify, a task manager with Todoist, Nextcloud and CalDAV support, released 4.20.0 — one of its biggest updates yet. Highlights:

• Nextcloud Deck integration — boards, stacks and cards sync two-way, with labels, drag and drop across boards, and archiving.
• CalDAV reminder sync — reminders now sync bidirectionally with Nextcloud, Radicale, Tasks.org and Thunderbird via standard VALARM.
• Productivity goals — set daily and weekly targets, track them with a mini progress widget, and review an 8-week activity heatmap.
• GNOME Online Accounts detection — existing Nextcloud/CalDAV accounts are detected and can be imported without retyping the server URL.
• Quality-of-life — completed tasks in Today, sort and filter across All Tasks, keyboard project navigation, locale-aware dates, better PDF export, and automatic backup retention.

Read the full release notes here.

Tanay Bhomia announces

Whisp v1.5.0 - Custom keyboard Shortcuts and Gnome Search Integration

This Week I released Whisp 1.5.0 Which includes two main things

1. Integration with the gnome search - Now you can search through your entire notes without even opening the app by using the native gnome search
2. Custom Keyboard Shortcuts - This is one of the most requested feature on the repo and I wanted to develop it for a long time so finally it is here.
3. Adding a Keyboard Shortcut for exporting notes - This shouldve been added in the last release but somehow I missed it

Links:

• Flathub: https://flathub.org/apps/io.github.tanaybhomia.Whisp

• GitHub Repository: https://github.com/tanaybhomia/Whisp

• Project Website: https://tanaybhomia.github.io/Whisp

• Support & Donation: https://tanaybhomia.github.io/Whisp/donate.html

• Personal Website: https://tanaybhomia.github.io

---

Now that we have this app thing out of the way. I wanted to share something ( I wanted this to be a good news and share with you guys that I landed a job but) I sat for an interview for KPMG which I went till the last round of but then got rejected for. I lost motivation for anything actually I really wanted to land this job. But eh. I hope I get a job real soon.

Thank you for your support

Anton Isaiev reports

RustConn 0.22.0 is out - connection manager for SSH, RDP, VNC, SPICE, Telnet, Serial, Kubernetes, Web and Zero Trust (GTK4/libadwaita).

New features: import your existing setup from mRemoteNG, PuTTY and KiTTY, and export RDP connections to standard .rdp files. A one-click private browser tunnelled through any SSH host (embedded or an external Chromium), and a Web connection that can browse through a bastion the same way. Interactive ASK variables that prompt for a value at connect time, plus built-in date, time and environment placeholders in any ${…} field. Terminal colours can now follow the desktop light/dark setting and repaint live when it flips. A monitoring mode that fires on a real shell event - the command finished, with its exit code - and marks the tab until you look at it. Automatic answers to sudo, su and doas prompts on SSH sessions; an output filter that pipes a session through ChromaTerm, ccze or pv before it is shown; FIDO2 passkey redirection for RDP; a searchable connection list in the cluster editor; and an editable login timeout.

Security: SSH passwords are now handed to OpenSSH itself instead of being typed into the terminal, which closes a whole family of “wrong prompt gets the password” bugs; session recordings and logs were storing secrets and were world-readable, both fixed; a debug log could contain an RDP account password in clear; an RDP server could write files outside the folder you picked or make the client allocate gigabytes; and dangerous VNC viewer arguments could be smuggled in from an imported connection. Every secret-backend subprocess now has a deadline, and a password the selected backend refused is no longer redirected somewhere the connect path never reads.

Fixes: a jump host set on a group or globally was stored and shown as inherited, then dropped at connect for SSH, RDP, VNC and SPICE; SPICE and RDP asked for the password every time instead of using the stored one, and failed on Flatpak and macOS; embedded RDP now verifies the server certificate on first use like SSH does for host keys; the embedded web browser lost its login on every restart; RDP clipboard file transfer never actually worked; Bitwarden auto-unlock did nothing in any language but English; a KeePass group password was saved but never loaded back; embedded RDP could be killed by a Windows 11 keepalive; and a pile of macOS paths that assumed Linux now find the real .app clients and runtime directories.

Thanks to everyone who uses RustConn, reports bugs, contributes or supports the project. If you’d like to support development - the repo has a Sponsor link.

https://github.com/totoshko88/RustConn https://flathub.org/apps/io.github.totoshko88.RustConn https://snapcraft.io/rustconn/

Gir.Core ↗

Gir.Core is a project which aims to provide C# bindings for different GObject based libraries.

Marcel Tiede announces

GirCore 0.9.0-preview.1 got released. It features a new API to match GExceptions with errors and supports nullable return values from instance factories.

Shell Extensions

Romain says

Night Theme Switcher, the GNOME Shell extension that automatically toggles the desktop to dark mode at night, has been updated for GNOME 51.

It includes a redesigned preferences window that visually previews the day and night appearances and makes setting multiple commands easier, and adds the long requested features of accent color switching and manual location setting.

You can install it from the Extensions website, and the [source code is available on GitLab](https://gitlab.com/rmnvgr/nightthemeswitcher-gnome-shell-extension.

That’s all for this week!

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

I like to run my Linux as an operating system, so I usually resort to toolbox for packages and development. However flatpak-builder is distributed as a flatpak itself, so here's how you can go about building flatpaks yourself for when GNOME Nighlies are not enough.

On GNOME OS, some developer tools like git and toolbox are in the base image.

Installing flatpak-builder

flatpak-builder isn't part of base OS though. It is distributed on Flathub as org.flatpak.Builder. Install it like any other Flatpak:

flatpak install flathub org.flatpak.Builder

Building and Installing Locally

Here's how I build Shaper, an icon designer for GNOME symbolics.

flatpak run --command=flatpak-builder \
org.flatpak.Builder --user --install \
--force-clean build-dir org.gnome.design.Shaper.json

And that's it!

Developer extension

There are some extra tools for development available for GNOME OS. You get them by enabling the developer system extension:

sudo updatectl enable devel --now

So instead of installing the flatpak, you get flatpak-builder as a utility.

[Originally written in Czech]

At the very beginning of the last year, Jiří Eischmann wrote a post on his blog about the status of the Czech translation at GNOME, tl;dr: the translation was slowly dying. I would really love to say that it is resolved, but that would be oversimplified. What changed?

During this year we decided to restructure our team and to restore the translation’s former scope and quality. Since spring, I’ve taken on the coordinator role in our Czech translation team—this release is under my lead. Fortunately I have Daniel Rusek beside me, who makes sure nothing goes unnoticed and who proposes further direction of our team, and I am very lucky to work with him.

I am happy to announce that our Czech translation is slowly forming to a pretty nice form, maybe soon as it was before. The first action I have done as coordinator was updating our manual for translators—I made sure it was easy to comprehend without a need for bigger changes from the previous one. I thought it would attract new contributors, which happened in summer right before the release was available to translate.

The core is almost fully translated to Czech, only sysprof is not. There is now also a new translation of foundry. Does it mean GNOME 51 is fully Czech? Unfortunately no. While using GNOME you can still find untranslated strings from the modules that GNOME depends on, like NetworkManager, which is used for VPN connections—but we are still responsible for translating some of them. We also translated a few apps from GNOME Circle, some websites, and some of the modules from freedesktop.org.

Even though we had small updates of user documentation, it’s largely stagnating. But…thanks to Petr Kovář’s awesome work help.gnome.org is now translatable and even translated to Czech language.

(You can find whole overview of translated modules on Damned Lies.)

During this cycle we got new members to our team, half of whom have already translated at least one module. I am very optimistic, and I believe these are not one-off translations but the beginning of long-term collaboration. Daniel Rusek remains reviewing, and I am joining him with doing so too.

That doesn’t mean that the translation is somehow resolved. You have to care about translations as if it were your garden, just having seeds does not imply a harvest, you need to take care of your plants first. We are still just a small group of people who gave up their leisure time and a few hours of sleep for the others. It’s not easy, and we possibly cannot translate for the eternity, that’s why we take your help seriously, we are more thankful for it than maybe you imagine.

Thank y’all.

Don’t let us down

We are grateful for every help with translating. If you want to make GNOME closer to Czech users, we are willing to teach you and navigate through translation. All needed information is listed on our page, or you can directly reach me via Matrix.

It’s been about 4 months since my last GNOME Foundation update. Time flies. I’m sorry that it’s been so long. I will try to do more regular posts again in the future, but perhaps not at the same tempo as before. While I would love to post every other week, it’s hard to sustain.

With that said, let’s jump in. Given the time since my last post, I’m going to focus on the bigger and more recent news items that have happened at the GNOME Foundation.

New board, new officers

The Foundation’s board elections happen every year, and this year’s election completed in July. The election resulted in a number of changes to the board:

• Sri Ramkrishna, Jonathan Blandford and Adrian Vovk joined the board as new/returning directors
• Deepa Venkatraman, our treasurer, secured a new two year term
• Robert McQueen, Federico Mena Quintero and myself all ceased to be directors (Rob failed to be re-elected, Federico didn’t run, I withdrew part-way through the process)

The election was a difficult one for me personally, and left me reconsidering my involvement in the Foundation. This was not because I lacked motivation or commitment, but because the situation around the election had become untenable for me personally. However, I’ve spent a good deal of time since I withdrew my candidacy thinking about my role at the Foundation, and I’ve concluded that I care about this organisation and the progress we’ve made, and I want to see that work through. Conversations I’ve recently had with members of the community have also given me confidence that we can move forward together. In short: I’m happy to be sticking around.

The new board held its annual meeting in August, which is when officers and committees are appointed for the next 12 months. The Board decided to put me into position as Interim Executive Director, with Sri Ramkrishna taking my place as President. This is a good move from my perspective: it recognises that I’ve been doing a lot of the day to day management work (which I will continue to do), and gives the Board more ability to hold me accountable. Sri stepping into the role of President means that he will be my backup.

Other officer changes include Jonathan coming in as Second Vice-President, Cassidy moving from Vice-Secretary to Secretary, and Adrian stepping up as Vice-Secretary. Our other officers remain in post, with Maria as chair, Deepa as Treasurer, and Arun as Vice-President.

Huge thanks to everyone who volunteered for these positions!

In terms of committees, the Executive Committee had a minor reshuffle, with Jonathan, Adrian, and Sri joining, and Julian and Rob departing. The new members of the exec are already taking on work, which is great, and I’m hopeful for the newly reconstructed committee. The Finance Committee had some slight membership changes, with Rob leaving and Sri joining.

Finance and Operations Director

Last April we opened the search for a new paid team member, to join us as our Finance and Operations Director. There are a number of goals for this new position: to enhance the finance and accounting expertise that we have internally, to lead the development of our internal systems and budgets, to ensure the sustainability of finance and compliance tasks, to manage our fiscally sponsored projects, and more generally take ownership of the business side of the organisation.

We had a huge number of applicants apply for the position, and had some extremely high quality candidates to choose from. After going through several rounds of interviews we selected Dawn Matlak for the role, who we are extremely excited about joining us. Those of you who have read my previous posts might remember Dawn’s name: she initially started working with us as a consultant last year, in order to help us prepare for our first formal audit, which happened in March this year. As part of this work she helped us to transform many of our internal systems and processes. We’re thrilled that she is joining the Foundation on an ongoing basis, and are confident that our internal operations will continue to improve under her stewardship.

Dawn is already doing a small number of hours for us each week, which she will continue to do until she properly starts in the role in November.

Many thanks to Arun and Deepa who helped enormously with the hiring process.

FY27 Budget

The Foundation’s financial year runs from 1 October to 30 September, and each financial year requires a new budget, both for planning and as the basis of reporting and spending authorisation. We have all therefore been working hard on the new budget that will come into effect on 1 October. The new budget has been in the works for a while, and has been a major focus for the board over the past few months. Thankfully we got the initial budget approval done last week at the board’s regular September meeting. We’ll follow-up with a more detailed post about the budget as soon as we’re able, so the community can have some insight into how we’re managing our finances.

Events

With GUADEC 2026 wrapped up, Kristi has turned her attention to the next event in our schedule: GNOME.Asia 2026. This is being held in Terengganu, Malaysia, from 31 October to 2 November. There’s a great venue lined up, and Kristi is busy working on the details with a fantastic local team.

Aside from GNOME.Asia, the other recent focus has been GUADEC 2027. We have a couple of options for locations right now, and are in the process of confirming details before we commit to one of them for next year. We’ll share updates as soon as we have more details confirmed.

Fundraising

The end of the calendar year is an important time for non-profit fundraising, and we are currently busy planning our campaign for the end of 2026. I’ll be posting more about this soon, in particular in relation to the budget, but for now I will say that this campaign is going to be critical for our ability to grow and support the GNOME project.

Other

As ever, many other things have been happening at the Foundation, and there’s too much to go into detail about here. Work on GNOME’s infrastructure and Flathub continues, our back office operation continues with finances and other routine paperwork, and the board continues to discuss our long-term plans.

That’s it for now. Many thanks for reading, and feel free to leave questions in the comments.