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.

23 Sep 2026 6:02am GMT

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!

23 Sep 2026 12:00am GMT

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.

21 Sep 2026 8:40am GMT

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

20 Sep 2026 12:00am GMT

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!

18 Sep 2026 7:11pm GMT

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.

18 Sep 2026 12:00am GMT

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

17 Sep 2026 4:36pm GMT

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.

17 Sep 2026 3:26pm GMT

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

17 Sep 2026 1:33pm GMT

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.

17 Sep 2026 12:00am GMT

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.

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!

16 Sep 2026 9:00pm GMT

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.

16 Sep 2026 12:00am GMT

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.

15 Sep 2026 8:05pm GMT

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.

15 Sep 2026 4:26pm GMT

15 Sep 2026 8:00am GMT

¡Hola!

36 hours of travel, multiple buses that didn't want me, one unexpectedly early morning, a trip to Porto, a lot of GNOME, and an unreasonable amount of coffee. That's GUADEC 2026 for me. For more details, read on!

Usually, I churn these out in about a week after the conference, but this time it took a bit longer due to extreme workload, another conference just after GUADEC, and the travel chaos.

Let's start :)

Unlike last year, I went easy on myself and didn't delve into giving a talk each day of the conference.

My main talk on Open Forms BoF on GNOME Foundation Internships - Unrecorded 😅

The main talk was on Day 1 of the conference, which was quite exhausting, not due to the talk but because I had to wake up on time. I had the pleasure of sharing my journey developing open forms and why it exists.

Attending GUADEC was much easier this year. If you haven't been following my blogs, then last year was quite a rollercoaster with travel and visa issues. You can read last year's rant at https://aryank.in/posts/2025-09-06-guadec-2025-experience/ , but now I finally have a 2-year visa, so no more pain for some time :D

Anyway, let's proceed with the blog :D

The touchdown

Due to a lack of flights to A Coruña, I had to take connecting flights through other cities to reach my destination (as I believe most did as well).

All in all, it was about 36 hours of travel to reach A Coruña. From Bareilly to Delhi, then to Qatar, then to Barcelona, and finally to A Coruña.

Phew, if it wasn't the excitement of attending GUADEC, I might have surrendered midway.

In Qatar, I found two of my good friends waiting for their connecting flights as well. Turns out, we had the same layover and connecting flights onwards. Seeing the struggles Aaditya went through for previous additions of GUADEC in securing his visa, I was insanely happy that he succeeded this time!

Having the company of Aaditya and Sailesh, we made a quick exit at Barcelona to visit La Sagrada Familia before catching our connecting flight to A Coruña.

It was a super short visit, and we couldn't even go inside the basilica. Nevertheless, seeing it from the outside was still breathtaking. Can you say you travelled to Spain and didn't see La Sagrada Familia?

The pre-conference party

I was looking forward to attending it, but the long journey, combined with the exhaustion from travel, made it quite challenging to muster the energy for the party. Also, my hotel was way too far from the venue, making it even more inconvenient to attend.

Not to mention, I was famished, and any longer without food and I would have turned into a hangry mess.

So unfortunately, I had to skip the pre-conference party and head straight to find some food.

But but but, even though the hotel was far, it was at the perfect spot possible. Close to the attractions, the market, the beach, everything. Thanks, Canonical!

The first day of the conference

My first day is always a shocker. And my journey with the bus in the EU has always given me pain at least once, haha. When I boarded, just like last year, I was again denied entry, as on the UDC line you can't tap your bank card, which wasn't the case with the airport bus, and the only bills I had were 100 EUR (Thanks to my chosen forex service :( ).

Thankfully, a student paid for my bus fare even without asking (kindness is still alive, people).

As soon as I boarded, I downloaded the A Coruña public transport app so that I could pay myself for future rides.

This actually portrays how poor my planning was this year. Every year, I spend at least a month knowing everything about the city, this year, I hardly spent a day, didn't even check what to visit :) Lesson learned for next time! Kudos to the GUADEC team, as the website clearly mentioned the public transport and other logistics, which I overlooked.

After reaching the venue, I spent 10 minutes wondering where the conference was. The map link on the website was for the university, but not the exact building. Eventually, I found another attendee who guided me to the right location.

Upon entering, I met Anisa, Kristi, Asmit, Deepesha and so many more familiar faces. I had a fun time asking everyone to guess my name to figure out who actually cares :) Joking on that part, I'm terrible with names and faces myself, but it's always fun to make things awkward lol.

We started with the conference welcome session, where, of course, I didn't hear any of it properly, being too busy catching up with everyone around.

I then had to quickly rush for Aaditya's session. Which was full of energy and insights, as always. GNOME Nepal has been doing amazing!

Following his session was mine! Again, the first talk I hadn't prepared at least 100 times. But I believe it was one of my finest yet! Lesson learned again, too much preparation sometimes makes the talk boring, uncertainty makes it lively and engaging.

Following which, was Sailesh's session, which was equally engaging and informative.

The day went on with multitudes of sessions and amazing talks as GUADEC usually does.

Then, Felipe asked me, if I'd like to join him for the community update at the end of the first day, and of course I said yes.

From being an intern in 2022 to now being a part of the Internship committee and presenting at the community update, it has been an incredible journey. The growth, learning, and experiences I've had along the way are truly priceless.

If you want to watch - the community update

The second day of the conference

While staying at the conference, we rarely get the time for sightseeing, so I did what my brain can not fathom... I woke up early :) And that was so worth it, went on a super early morning trip to the Tower of Hercules. Thankfully, I did a bit of searching on the bus and learned that you can go to the top, and so I did! And no pictures, no stories or whatever I say can justify the visual bliss I received. I just fell in love with A Coruña right there. But I had a conference waiting for me, so on we go.

The highlight talks for me were "When Porting Isn't Enough: Rewriting a Python GTK2 Application for GTK4", "GNOME Internationalization: accessibility for all over the world!" and "Session Save/Restore"

The one that particularly piqued my interest was the Internationalisation talk. It was fascinating to see how GNOME is making efforts to ensure accessibility and usability for people all over the world, and how what phrases we think are simple or sufficient in our context can be completely different in other languages and cultures. Always insightful and eye-opening!

Then, just before the lightning talks, we had "The Future of Boxes" session by Felipe. Having discussed it with him in the past, and having had the pleasure of being one of the people who got to test it before the official release (and annoy Felipe with nitpicks), it was fascinating to see the improvements and new features being showcased.

Boxes looks really promising with the new features and improvements, and I can't wait for the stable release.

Then we had the intern lightning talks, where several interns shared their projects and experiences. It was inspiring to see the fresh perspectives and innovative ideas brought forward by the new members of the community.

The third day of the conference

As you can guess by now, it was great as well!

The highlights? Those were the super longggggg AGM, but also the engaging discussions and the sense of community that made it all worthwhile. Followed by State of the Shell, a must-watch ALWAYS!

And we ended the day with a great conference dinner.

Instead of taking the bus to the dinner venue, I walked. This is something I learned at last year's GUADEC: if you really want to experience the city and its atmosphere, walking is the best way to do it. You find monuments not listed anywhere, hidden gems in the streets, and get a true feel of the local life.

The food was amazing, the company was great, and the atmosphere was just perfect.

The highlight? Drinking Queimada. The traditional Galician drink was both fun to watch being made and delicious to taste. The funniest bit was seeing people who have experience with alcohol still being afraid just from the extremely potent smell. It felt like I could get intoxicated just via that aroma alone.

But the taste? It was pretty amazing! Although I was offered another glass, I had to refuse. Remember, kids (me being one too) drink responsibly!

I thought that this was it, that's the end of the day, but it wasn't. Me, Felipe, Alan, Tobias, Jakub Steiner, and a few others decided to walk to Maria Pita Square to watch football. Now, I was an imposter there, as I had no clue what was going on in the match. But the vibe is what made it fun!

We then had a good discussion on Indian currency notes, where I handed Felipe some to take back home. I never thought my own country's currency could spark such interest and conversation among international friends. For me, they are pretty boring hehe.

The BoFs

Being a GNOME GSoC'22 Intern, and now a part of the GNOME Internship Committee, I had my third and final talk (kind of), the GNOME Internship Committee Meetup, where we discussed the future of the program, the challenges we face, and how we can improve it.

As it was Sunday, the bus service was heavily disrupted, a bus denied me again, citing that they won't drop me in the city, only at the airport. So, I had to walk to the venue, my legs gave out after it, and I was partially drowning in sweat by the time I reached (not a great sight). But I had to be there! Thanks to a pizza party earlier that day, sessions were delayed, and I could relax somewhat before the discussions began.

I was continuously on chat with Felipe, ranting about the bus situation and my struggle to reach the venue on time.

Thanks, Felipe, for organising it and inviting me to be a part of it. It was great to see the progress we have made and the plans we have for the future.

The same day, we also made plans to watch the World Cup Final at Maria Pita Square. Due to bad network and an insanely packed area, we couldn't find each other, but man, what a time to organise GUADEC. Even though I was again an imposter there, I was there more for the vibe.

When the match went into overtime with the score still being 0-0, I left for my hotel, as I had no clue who could win, and a city with disappointed fans packed in one area is not something I would vibe with :)

But I'm so gladddd that Spain won! I was in my room when my college friend Shreyash motivated me to go out again and not waste it, so I did. And I have to say, that was soooo gooodddddd, all the crazy fans, the vibe, the sounds, people using horns to play songs and rhythms. IT WAS BLISS IN NOISE.

The Final BoF Day

After attending the BoFs, as per Emmanuel's recommendation, I went and visited the Aquarium, making sure to go at the time when they offer food to the Seals.

Thank you, Emmanuel, for the inspiration, as otherwise, an aquarium would have been pretty down the list. Watching the Arctic shore, the spectacular underground water tank and a real warship I spotted in the Arctic would make it forever memorable (the Aquarium was on the shore, so you could see the ocean).

The Porto tour

As this year the day trip was self-organised, I took a detour and went to Porto. It was a short trip at best, and quite draining for my wallet, but totally worth it for the experience and the memories made.

I absolutely loved and hated their topography. The steep hills and narrow streets made each spot a marvel to click pictures, explore and absorb, but navigating those same hills made my legs ache and my stamina tested.

Coffee Conference

I am going to call GUADEC the "Coffee Conference" because of all the amazing coffee experiences I get there. Last year, after discussions with Federico, I learned a lot and bought a Bialetti Moka Pot. And, it was such an amazing investment. Not only that, I asked him jokingly to bring me beans from his area next year.

This year, Federico actually brought me some beans, and it was such a treat. The aroma, the taste, everything was just perfect. It felt like a little piece of Mexico had come to my home.

Just like last year, this year's splurge was a grinder. Federico recommended multiple times that grinding at home is a completely different experience. So, I went ahead and bought one. Although it was a heavy splurge, it was totally worth it for the experience and the quality of coffee it produces.

I used to get pre-ground, as there isn't any grinding facility nearby, and as they were in bean form, that was sufficient reason for me to finally drop the hammer.

Meeting people

At last, I met many new people and got to learn a lot. Made new friends, got to meet people I look up to and many more.

And I really missed Aarti and Sri :( I wish they both were there.

The Return

During return, I again got to meet Sailesh, Aaditya and Federico :D I wanted to bring some good white wine to India, as Spain had some really nice one, so I took Federico's help in picking one from Duty Free, and I'm gald I did, got to learn so much about picking the right one, and it was all so much. Btw, it tasted awesome, so thanks again :)

Another special thing that happened was that just a day after I landed back in India, I had my college graduation. I got to regroup with my old friends, receive my degree, and, well... clicked a lot of pictures :P But this was one of those moments that will keep it memorable for me.

The End

When I attended GNOME Asia Summit as a GSoC intern in 2022, I never imagined I'd return a few years later as part of the Internship Committee and present at the community update. Looking back, that's probably what I'll remember most about GUADEC 2026, not any particular session, but how much this community has changed my life.

Thanks to all the people for making the event so great. I would also like to thank Ubuntu CDA for sponsoring the trip :)

I hope I used it to the fullest and made the most of it. :D

14 Sep 2026 3:37pm GMT