[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.

Back in April I wrote an informal history of the BuildStream project: Status update: 23rd April 2026.

Things escalated and somehow I ended doing a podcast interview with Rich Bowen of the Apache Software Foundation recently, on the Apache PlusOne podcast:

Apache BuildStream — with Sam Thursfield – YouTube

Fame at last!

I didn’t get much time to prepare for this so excuse any clunky explanations or inaccuracies. My main aim was to place BuildStream and Freedesktop in context for an audience who don’t live and breathe operating system integration tools. I’m interested in your thoughts on how successful that was. Comments are enabled on the YouTube video so you can also fact-check us there as needed.

Not a lot of things have landed this cycle, but there's still a bit to list, so let's do that.

Android support

As part of his effort to port GTK to Android, Florian also ported libadwaita demo. The builds are available from CI and the GTK 4 Android page.

He also implemented a settings backend, meaning that libadwaita apps now support system dark mode and accent color on Android (not high contrast or document/monospace fonts though).

Ministream

AdwAboutDialog can be populated from an AppStream metainfo file, via libappstream. While useful, it also causes problems on other platforms, such as Windows (libappstream can't be built using msvc) or Android, due to its dependencies.

Since we only use a small part of appstream (for example, we don't need composing or anything related to networking), he reimplemented the subset libadwaita uses as ministream. It only depends on GLib and it should build fine with msvc, so it should make building libadwaita outside of Linux easier.

CSS class bindings

A fairly common pattern is having property that toggles a style class - e.g. for use with breakpoints. Currently implementing it is a bit annoying, so Jamie Murphy added API for automating it - adw_bind_property_to_css_class().

It's modeled after g_object_bind_property() and works much the same way, incl. allowing bidirectional bindings.

A variant with mapping functions is also available, allowing to bind properties of arbitrary types and not just booleans.

Sidebar additions

AdwSidebar and AdwViewSwitcherSidebar have received a number of additions.

Sidebar prefix and suffix

First, both sidebar widgets now support having prefix and suffix widgets. This can be used for things like adding an account switcher, a prominent title, or a help button at the bottom. While it's not used a lot in GNOME apps at the moment (the only app I'm aware of is a development version of Crosswords), it's a common pattern on other platforms, so it's good to have API for this.

Section suffix

Next, sections can have suffixes in their headers, similar to AdwPreferencesGroup. This can be used to put a spinner or a button in the sidebar sections, similar to what Polari has.

Item prefix

Finally, sidebar items can have prefix widgets. They can be used instead of the icon or together with it, in that case it will be displayed before it. This can be used to display avatars, checkboxes and so on.

Icon changes

Last cycle I announced the new icon work. Unfortunately, it's still not ready, but a few smaller things have landed. First, larger icon sizes now use smaller weight, so new icons in AdwStatusPage and in images with the icon-size (but not pixel-size!) property set to LARGEwill look thinner.

Second, AdwSpinner now also follows icon weight and will look consistent with icons. Apps that use spinners at large sizes outside of AdwStatusPage may have to adjust the weight manually using the -gtk-icon-weight CSS property.

Other changes

• AdwShortcutLabel now uses proper labels for keys like ⌘ or ⌥ on macOS, as well as more natural ordering for modifiers everywhere.

• GtkDropDown can now be used with the .flat style class, and automatically becomes flat in toolbars (which can be undone with the .raised style class, same as for other buttons)

  

• AdwAboutDialog now has the :other-apps-title property, allowing to override the title of the "Other Apps" section.

---

Overall, not a lot has happened. Even this blog post is late, for the first time.

Part of the reason is various health issues, both physical and mental, another part is the state of the world at large and software industry in particular. It's hard to focus at the best of times, let alone when everything is falling apart.

I've been working on a personal project as a means of escapism, but it does mean libadwaita is getting less attention.

---

Thanks to the GNOME Foundation for their support and thanks to all the contributors who made this release possible.

I’ve been working for a while as a contractor as part of the Sovereign Tech Fund (STF) initiative for Flatpak, organized by Modal and Para-Real Ltd. There is a nice write up about the project, giving an overview of the investment and the collaborative effort.

Intents

My involvement has been focused on the Intents, which is an abstract system for apps to declare their offered services. Applications can announce which Intents they support using the Implements key from the Desktop Entry specification, and the default selection mechanism is solved by the intent-apps specification. For example, one could develop a Thumbnailer Intent, which would be then supported by implementing a specific DBus interface (e.g. “org.freedesktop.Thumbnailer1”). That would allow for apps and system components to have a standardized, flatpak friendly way to discover thumbnailers, and use their functionality in the sandboxed world, increasing security. Another use case would be an URI Handler Intent, that would among others let users specify which applications they would like to be opened when clicking a particular link. The overall idea has been going for quite a while, and there are some very good sources to read up on the Intents in general, including Andy Holmes’ “Best Intentions” blog post and Sebastian Wick’s follow up.

Terminal Intent

Last year the intent-apps specification allowing for default selection of Intents was accepted, and the next step is to start implementing them. One that caught interest is the Terminal Intent. Currently, there is no standardized, sandbox friendly way for the system to discover terminal emulators, and use their functionality. It’s not associated with either a mime-type or an URI scheme, which is one of the reasons why changing the default terminal has been challenging for a long time now.

This changes with the proposed spec, that allows applications to implement the “org.freedesktop.Terminal1” Intent, and therefore advertise to the system and other interested users that it’s a terminal emulator, capable of executing commands via a specific D-Bus interface. In GNOME, it will unlock many things we’ve wanted for quite a while, among others: changing the default terminal in Settings, adjusting the behaviour when launching apps meant for terminal, and opening directories from the file manager.

Settings

There’s an early implementation in GNOME Settings for the terminal Intent, that exposes an option to change the default terminal emulator across the system. Applications that are meant to be executed in a terminal window, which is indicated by a “Terminal=true” line in their desktop file, would then launch in the previously selected terminal. Apart from the spec being accepted itself, for the functionality to work correctly, there needs to be support for the intent in GLib, which is being worked on, as well as in the terminal emulators themselves, with both Console and Ptyxis having work in progress implementations.

Settings with an option to choose the default terminal

Below I’ve provided screen recordings of Shell launching Vim in a terminal emulator chosen in Settings, as well as a custom terminal application.

Files

Another cool use case would be opening directories from the file manager in the terminal, adhering to the selected default in Settings. The integration would also cover other terminal related functionality, such as running the scripts as programs in the terminal. There’s a work in progress implementation in GNOME Files.

Here’s another pair of screen recordings, showing Files opening directories and running a custom script in a terminal emulator chosen in Settings.

Testing

As usual, I’ve prepared a custom GNOME OS image that can be used to test the functionality, which I’ve also used to make various screenshots and recordings in this blog post. You’ll need to install it (in GNOME Boxes for example), which takes a simple click and does not require a reboot (magic!). To be able to switch between different default terminals, you’ll want to download the custom build of Ptyxis as well, and install it with a command “flatpak install ptyxis-terminal-intent.flatpak”. Then you can get some applications meant for terminal such as Vim directly in Software, which is preconfigured to get them from Flathub.

Next

Currently, the major blocker for the work is getting the Terminal Intent specification accepted upstream, which needs to be merged before the rest of the ecosystem can fully embrace it. There needs to be consensus from other desktops such as KDE, after which the focus would become the GLib integration, following support from individual applications. And in the future, work on other Intents can begin, unlocking many more possibilities.

I’d like to thank Modal and Para-Real Ltd. for the ability to work on this, as well as Sovereign Tech Agency for sponsoring the work. I also really appreciate the help from the technical leads Sebastian Wick and Adrian Vovk who are always there to answer questions, the organization of the work by Kateryna Omeltschenko who knows how to brighten up a meeting, and Cade Diehm, who’s bravely fighting with the bureaucracy for us. Until the next update!

With GNOME 51 out the door, it's wallpaper reveal season again. This time around it's evolution, not revolution — the set sticks to its geometric roots.

The default is really just a stylistic touch up of the 50 hexagons. The subtle rim highlight received a spotlight and now shines extra bright.

I do keep hoping landscape nature photos eventually join the lineup, but capturing the same scenery under different conditions so the light and dark variants actually make sense is trickier than it sounds. That one's still on the wishlist.

As usual, plenty of concepts didn't make the cut. For every wallpaper that ships, there's a good pile of experiments that never got past the "that's kinda neat" stage.

One thing we keep struggling with is performance in the Appearance panel. The images now include an embedded small thumbnail, so hopefully a faster way to build the initial cache of thumbnails is on the horizon.

We've also started embedding attribution and license straight into the images themselves, so the credits travel with the file instead of living only in the repo. And with Loupe displaying the metadata nicely, you get to see it conveniently.

Guadec happened. It was a extremely well organized event, with plenty of good talk, people that I was longing to see again, and new faces to put a name on.

My experience was however very much soured by interactions with other people within the community, against myself and other members of the community. To the point that I had to take the time to relieve the distress it has caused me, hence the time it took me to write this down.

The mobile shell initiative

The development for a “mobile” GNOME Shell started somewhere around 2022, and at least the supporting parts of it passed as a project sponsored by the first and only round of GNOME projects sponsored by Germany’s Sovereign Tech Fund, as “Increase Range and Quality of Hardware Support”, this was acknowledged in the final STF report.

Making GNOME Shell behave natively on a new form factor is a massive undertaking, and the planning was not sufficient. The first, most glaring mistake was to drive this project from the start with minimal involvement from the existing project maintainers. No consultation happened at any point in planning, not just to ensure the goals were in scope, but also to ensure the project is stewarded towards a point that everyone can walk away with a sense of completion.

The second biggest mistake was in planning for upstreaming, instead the work piled up on a branch in a personal repository.

To be fair, the supporting bits got merged over time, and there’s got to be some breathing room for new initiatives. But sooner or later there’s the harsh reality that the work has to be divided into tractable pieces and pushed in a structured manner through the review process, in order to end up with the work merged upstream.

The Mutter low level pieces were merged over the course of 1 year after the STF project, divided in 3 ( 1 2 3 ) merge requests, and some of the corresponding GNOME Shell changes to make use of this (no longer) new infrastructure were merged as well .

But meanwhile the mobile-shell branch kept piling on, north of 300 patches, with substantial changes to code (diff is +120437 -7156 , by my accounting) and UI. The original author did not make attempts to upstream the changes, and the few efforts from other participants to upstream bits of it or as a whole did not last long , unfortunately. The work is nowadays sitting on its separate repository, using a separate issue tracker.

The mobile BoF at Guadec

This jagged interaction between the people acting as maintainers and the people driving the mobile-shell initiative lead to difficulties in making this work upstreamed in a timely fashion, much to everyone’s disappointment. In this situation, we arrive to this year’s Guadec. There is of course an interest in upstreaming the changes, from Mutter+Shell core developers and maintainers included, so we attend this BoF.

What happened there could be best described as a maintainer shaming session, specifically towards Jonas Adahl, Florian Müllner and myself, for “discriminating/demotivating newcomers”, “wanting to steal the spotlight”, “stalling things on purpose”, … essentially choosing slander as a way to put the blame on us for not having merged the work as-is. Even though this attack was driven by a few closely related to the initiative, it happened in front of 20+ people.

This was not ok

Even though I understand the frustration behind, I find the tactics used on us inexcusable.

Look, the community guidelines at conduct.gnome.org are a bar to meet for everyone, towards everyone. And the guiding principle of them all is pretty simple, we all row the boat roughly in the same direction. Once the basic principles of respect are lost between us, the boat does sink. The main asset that keeps Free Software moving forward is not the code, but the people.

Jonas, Florian and myself are lucky to be paid by our employer to work upstream on GNOME, but I can say for myself (and perhaps the three of us) that I work at Red Hat because I work on GNOME, rather than the other way around. We go well beyond our duties, in ways our employer does not care in the slightest if we do, and in ways it consumes our free time as well. We have looked to nurture the community, mentoring in GSoC and Outreachy more times than it’s worth counting. The accusations of discrimination fall entirely flat.

We so far had no trouble in collaborating with the main developer behind the mobile shell work either, there’s 226 merge requests merged from him in GNOME Shell and 151 in Mutter attesting that.

This strain on relationships is not baggage free. I don’t see myself working with the individuals that drove this attack pretty much anymore with any productive outcomes, and I will avoid that to the extent of my capabilities. There is an unbelievably long road to undo the damage they’ve done.

How to improve from here

The mobile fork is currently sitting in a separate repository, based on a now old release, and contains a number of back-and-forths, FIXMEs, WIPs, and code that has been either already done (albeit differently) or entirely refurbished upstream.

A rebase that is mindful to all these and brings the branch to a plausible up-to-date state is likely to take days to weeks. At this point, it could make more sense to identify the possible topics to split into multiple (many) merge requests, and cherry-pick the patches individually.

After these merge requests are done, they should go through review, and the style/architectural differences between the original author and the maintainers’ mindset be settled. Changes could be merged incrementally, advancing towards the common end goal.

It looks like I just described the software review process in a nutshell, and I very much did! But I feel it is important to point out that nothing of this has happened yet with these patches in a proper or substantial way.

In a shred of constructivism during the Mobile BoF, Markus Göllnitz offered himself to do this on behalf of the original author. I am looking forward for these steps to happen, and will collaborate with Markus on it.

I deep down hope that this blog post also serves as a cautionary tale about how wanting to rock the boat instead of rowing together may stall initiatives, and eventually poison relationships.

Andreas Gabriel Berbescu has reported several root privilege escalation vulnerabilities in various NetworkManager VPN plugins. If the VPN plugin is installed, then an unprivileged user can escalate to root by loading a malicious VPN configuration file:

• (CVE-2026-91837) network-manager-iodine: Option confusion reaches iodine’s pre-drop root shell
• (CVE-2026-91838) network-manager-sstp profile data reaches root pppd pty shell
• (CVE-2026-91839) NetworkManager-fortisslvpn credential newline injection permits local root code execution
• (CVE-2026-91840) NetworkManager-vpnc: Top-level VPN username newline injection reaches a root password helper
• (CVE-2026-91841) NetworkManager-vpnc: Incomplete fix of CVE-2018-10900

While most obviously bad for multi-user systems, root privilege escalation is also a serious defense in depth problem for single user systems. You are vulnerable if you have the VPN plugin installed; it does not matter whether you actually use it or not.

These are not vulnerabilities in NetworkManager itself. The VPN plugins are each separate projects , with their own separate maintainers, hosted by GNOME rather than by freedesktop.org. The status of each project is a little different:

• The NetworkManager-vpnc and Network-Manager-fortisslvpn git repos have both been archived. Contributions are no longer accepted, and you should uninstall them immediately. NetworkManager-vpnc users should migrate to NetworkManager-libreswan, and NetworkManager-fortisslvpn users should migrate to NetworkManager-openconnect.
• network-manager-sstp is currently unmaintained, but it is not obsolete. If you are interested in SSTP, this project needs a new maintainer.
• network-manager-iodine is maintained, and the maintainer has created a merge request to resolve this issue.

For more information on NetworkManager VPN plugins, see Josephine’s VPN plugin overview and announcement .