One of the great annual trips we do with a bunch of friends is a train trip to Jakuszyce, a tiny stop in neighbouring Poland, and ride along the contour line through one of the most beautiful places in the Jizera Mountains. There's only one proper climb from Smedava to Knajpa, the rest is fast. A joyride. Catching up on our lives on the train and a joyride home is the best combo.

I tend to think of myself as a friend of repairs, of making things last. I have sadly had to retire our washing machine after a good 25 years. The dishwasher before that served us more than 15. A boiler and heater had to go this year after about 20. I had my previous car for 13 years and felt like I was bailing too soon, even though there were quite a few issues with it at the end. None of those things ever felt new to me by the end. They most certainly showed their age.

But the bike. The bike I ride every year on that trip, the one leaning against the wall in the shed right now - it still feels like my "new bike". I replaced the tires and brake pads last year and the thing screams. It is such a joy to ride. It feels current, alive, like something I just picked out. Until a friend sent me a photo his Google Photos app reminded him of. A very young version of myself is sitting on that exact bike. Fifteen years ago. Nothing has aged except me. Bikes just don't age like we do.

17 Jun 2026 12:00am GMT

Excited that Bobby has been accepted as a GNOME Circle app!

Who's Bobby?

Bobby is a viewer utility. It displays tables from SQLite files. The most deployed database format in the world. That's it.

Whilst hacking on the backend of Auroras I was missing an easy way to check my data tables. There are many database management tools, but they seemed too heavy for my use case.

GTK4 and Libadwaita

Releasing something smaller first also was a chance to refamiliarise myself with modern GNOME app development. It was my first serious project using Rust.

GTK is still the rock UI toolkit it has always been. Libadwaita makes it easy for your app to look beautiful and is a lot of fun to use.

The main challenge was hooking up the database backend to the ListModel required to be displayed by the new ColumnView. The struggle was worth it though as it enables Bobby to have lazy loading of rows, smooth scrolling, and a limited memory footprint.

After that using any other widget should be a breeze!

Future

I will keep the scope of the app small, but there are a few features I want to add in the future:

• Encrypted file support
• Updating values in place
• Search

Get Bobby on Flathub and always sanitise your database inputs!

17 Jun 2026 12:00am GMT

Almost exactly three years ago the Oceangate submarine implosion happened. The disaster came about when a billionaire called Stockton Rush created his own unclassified submarine to go sightseeing on the Titanic. Ignoring all advice from experts he created a "macgyveresque death trap" that eventually killed him and sadly also 4 innocent people. The whole thing was a massive display of stupidity and arrogance with unfortunate outcomes. We are not going to go into the actual event any deeper, but those interested can find lots of material online.

Instead we are going to look more deeply into one often overlooked points of Stockton Rush's character. Apparently he felt like he was something of a "new James T. Kirk" (link1 paywalled, link2). Liking Star Trek is not that unusual. I'm guessing that more than 99% of the readers of this blog are fellow Star Trek fans. The problem lies elsewhere, but to understand it we first have travel back in time.

A brief overview of the British navy during the Napoleonic wars (by a non-historian, so probably inaccurate)

The original concept for Star Trek was, approximately, The Adventures of Horatio Hornblower in Space! The Enterprise is basically a British warship sailing through the vast ocean of outer space. The command structure mirrors this, where you have a captain, navigator, ship's doctor and so on. The Next Generation leaned into this even further by having a first officer and so on. The original Star Trek never went into detail on how the main cast got to their current positions, just that there was an Starfleet Academy they went to.

In the Napoleonic era of Hornblower things were quite different. Anyone who wanted to become a captain pretty much had to be from the upper classes. They had to obtain a letter of recommendation so that they could join a vessel as a midshipman at the age of 13 or so. They were expected to be able seamen by this time and then spent the next six to seven years working on the ship rigging sails and doing all manner of random jobs. This went on for six to nine years depending on circumstances, after which the person could take a formal examination to become a lieutenant. The test was not trivial, many people could not pass even after trying multiple times.

A lieutenant then had to work successfully for several years before obtaining the rank of captain. Even that did not guarantee a commission. Some captains never commanded a ship simply because there were not enough of them to go around. All in all becoming a ship's captain was a long and difficult journey. In a surprisingly non-British turn of events it was not possible for aristocrats to sneak past the gates. Getting a midshipman position was obviously easier with connections, but the lieutenant's test was something they had to pass on their own.

All of this is to say that every captain of the time was an expert with decades of working experience on many different positions aboard the ship.

What does a captain actually do?

[Note: I have not fact checked this portion at all. Feel free to consider it fanfiction.]

The year is 1808 and we are aboard a British warship about to leave for a mission of great importance. The captain gives the order to set sail. Whistles are blown, bells are rung and sailors springs into action. Every single man, with one exception, is either doing manual labour or directly supervising their underlings. That exception is the captain, who seemingly stands around doing nothing (at least if you ask the crew). This is not so.

What he is doing is crucial. He is observing the state of the ship and her crew. This includes things like overall crew morale, any aberrations from normal operations that could cause problems, thinking of workflow improvements and so on. In a sense he has to sense the ship itself. This only works because of two things. First of all he has personal experience doing the exact work he is observing. If you have not personally "been there", you can't really know if a crew is working well or not. You need a "gut feeling" to be able to sense this. Secondly the captain does not have any manual labour so he can focus all of his mental energy on observing the ship's state. He is preparing for all the unexpected things that may occur in the future. This can only happen if your brain is free from menial tasks.

This is exactly what most books on business and project management advocate. It is a time tested way of improving your chances of success. A highly skilled commander can take an average team of people and lead them to victory. It is the basic plot of most military and sports movies.

Getting back to the present

Now take a typical modern day billionaire-via-inheritance and show them Star Trek at an impressionable age. Do they see the advantages of education, hard work and ethics? The foundation upon which Gene Roddenberry carefully built the show? Hell no! What they see is this (TNG screenshot used because TOS did not have a suitable maritime episode).

And then they think: "Wow! I want to be exactly like that! Parading around in a funny hat while everyone obeys my orders without question is my life's mission from now on. And I get to have sexy space sex with hot sexy space ladies of sex whenever I want. This appeals to me even more profoundly than Atlas Shrugged." Some of them might go on to watch Master and Commander and shed tears upon realizing that they cant publicly flog employees for failing to salute their superiors. Yet. Expect this to be made legal in Silicon Valley any day now.

Liking Kirk is not in any way a bad thing. Wanting to "be just like Kirk" is, because in the real world running a business like Kirk runs the Enterprise is a terrible way to do things. An example will illustrate this nicely. Let's imagine a random episode where the Enterprise has gotten into trouble. Eventually Kirk will call for Scotty and tell him: "You need to <babble> <babble> <babble>." Scotty will then reply with a varying level of scottish accent something like: "I cannae change the laws of physics, captain". Kirk will then say the same thing again, just more aggressively and in a close up shot. Scotty replies with "Well in that case I can get it done in sixty minutes." Kirk counters with: "You have five." And thus the problem is solved. Kirk gets a commendation for incredible valour under stress while Scotty, who did all of the actual work, is never mentioned.

In "Kirk style" management the Big Boss tells his underlings what to do. If they try to give any sort of feedback, the Boss ignores everything and just repeats his original orders again and again until the other party yields. The only reason underlings ever resist The Vision is that they are lazy and it is the job of the manager to put them in their place. This seems like a bit from a comedy show, but I have unfortunately worked under bosses like this. Either you try to talk at least some sense into them, fail, get labeled as a "not team player", watch the project crash and get blamed for the failure, or you try to do the impossible task given to you, fail watch the project crash and get blamed for the failure.

Another major problem with Kirk is that due to the way tv shows and movies need to be structured, he is actually an obsessive gambler. The stakes must always get higher and the ways to get out of trouble must become ever crazier. Kirk will break any and all laws and regulations he sees fit and then, once he has succeeded, no disciplinary action is taken. The ends justify the means. Idolising this sort of behaviour leads to thinking that wild one-in-a-million gambits will succeed at least 99 times out of a hundred. And even if it fails, you can get out of it by betting everything on an even bigger gamble. The real world does not work like that. Reality is not a story and you are not its hero. It does not owe you eternal, or even eventual, success. Had Stockton Rush survived his death trap, he would most likely have faced criminal charges and, if convicted, gone to jail.

The myth of the existence of the professional manager

Let's make one last detour in the 1800s and assume that the 7th Earl of Sidcup or some such really wants to get his idiot son instated as a captain. He and contacts the appropriate naval officers.

"My offspring needs to become a captain of a ship post haste!"

"Well first he has to become a midshipman and ..."

"Phah! None of that nonsense. It's way too slow and not becoming of my statute. Also my son is 35 years old so the post of a midshipman would be beneath him."

"I see. Well what sort of prior naval experience does he have?"

"None."

"Has he even ever been out to sea?"

"Not to my knowledge. But that does not matter. He is highly skilled in using the abacus excelius to compute annual budgets."

"By himself?"

"Of course not. That is what secretaries are for. He just gives them orders. That he can do. And that is all that matters. Same as in sailing."

This person is unlikely to get his wish with this line of reasoning. On the other hand in modern business life this is common. For example when startups get VC money, a common requirement is that they need to get a "proper manager" as a CEO. Typically this means the investor's friend, and more often than not an MBA.

Contrary to common belief, having an MBA does not make you incompetent at managing a technical company (though there is a strong positive correlation). It is entirely possible to be a good manager on a field you have no personal experience in. You just have to have a lot of humility, listen (actually, properly listen) to your employees and let the people with hands-on experience make the most technical, product and development decisions. In other words you have to be the enabler, not the maverick decision maker. People with these sorts of personality traits are rare and typically their career choices steer as far away from getting an MBA as possible.

The absolute worst thing happens if the CEO in question combines the (lack of) skills of an MBA with the attitude of Kirk. That leads to incompetent decisions based on willful ignorance, executed with the fury of an egomaniac who refuses to even entertain the notion that they might be wrong. Further, any person inside the organisation who dares to point out potential flaws in the plan will soon find themselves outside said organisation. Disagreement is treason. Treason shall not go unpunished.

In the 1800s the British navy could be said to be the best in the world. It seems plausible that one component of this success was the requirement that the officers running their ships had to have actual experience operating the ship. Not looking at other people operating it. Not pretending to read about operating it for a test. Actually doing it. If we look around how MBA wielding sociopath CEOs are enshittifying absolutely everything about the tech industry, bringing this requirement back into active use starts to feel awfully tempting.

Epilogue: Why doesn't everything immediately explode?

A reasonable counterpoint to everything written above would be that if managers truly are that bad, shouldn't all those companies be bankrupt by now? In an ideal world they would be, but there are opposing forces that keep them going.

The first one is that all corporations have inertia. If you took an established major company and actively started to mismanage it to death, it would still take years for things to eventually collapse.

The second one is a dirty little secret. Many employees care more about the product they work on than "corporate visions" that seem to stem from overuse of peyote. They don't blindly obey idiotic commands but instead try to make things silently work within the system. Basically this means that corporations thrive despite their mad kings, not because of them. I know several people who have worked in these kinds of organizations and this is not as rare of an occurrence as one might imagine.

I have also experienced it personally. Years ago I was at a company, whose CEO (who, to the best of my knowledge, did not have an MBA) wanted to change the company's product so that it would do a specific thing X. Everybody thought this was a horrible idea and tried to reason with him using solid business and technical reasons (which turned out to be 100% correct). That failed. Spectacularly. This lead to an eternal series of secret meetings. The participants were main developers and all managers except the CEO. The only item on the agenda was "How can we make the CEO think that we did what he ordered while doing the exact opposite".

Eventually we did succeed, but boy was that a surreal couple of weeks.

15 Jun 2026 7:29pm GMT

15 Jun 2026 2:23am GMT

15 Jun 2026 1:07am GMT

I occasionally see people go through great effort to do end-to-end testing of keyboard input latency. That is fantastic but it requires hardware and patience I don't, nor will ever, have.

Here is a much simpler way to get about 90% of the value. For example, everything but driver/interrupt handler latency and display link scanout/monitor visibility latency and of course your app side (but you could theoretically rig this up to do that too, inside your app). Not that those aren't important, but they definitely fall into the category of things I personally cannot control for you.

Keyspeed is a very simple GTK application which uses /dev/uinput to synthesize keypresses. Since it knows the time of provenance, it can compare that to when it gets the event back from compositor delivery.

Wrap all that data up in Sysprof capture marks, pull in some from the compositor (GNOME Shell/Mutter support this), tie in some callgraphs/flamegraphs, and you have a very good overview of what is going on during your keypress.

Run it like this (but remember to chmod back when you're done less you have attack surface available).

$ sudo chmod 660 /dev/uinput
$ git clone https://gitlab.gnome.org/chergert/keypress
$ sudo dnf install sysprof-devel libinput-devel gtk4-devel
$ make
$ sysprof-cli --gtk --gnome-shell capture.syscap -- ./keyspeed
$ sysprof capture.syscap

Currently, this only shows you keypress send to receive in GTK, but if someone cared enough, you could make it take the next GtkFrameTimings and use that to get the presentation time. I don't need that for what I'm doing, so it doesn't.

If you go to the marks section, you can dive in to a specific keypress/release cycle. Zoom in on just that section, switch back to callgraph/flamegraph profiler and see what was going on.

Pretty simple, no special hardware needed.

You can see how long it took, where time was spent, and more importantly, how much time was empty between things that matter.

13 Jun 2026 9:47am GMT

Greetings from Planet Peanut!

Since there's a whole new generation of GNOME contributors active right now, I'll do a short reintroduction: Hello, I'm Hylke!

I was a design contributor in the late 2.X, early 3.X days. Mainly icons and theming. I've attended many GUADECs.

I'm also the developer of SparkleShare, a Git-based file sync app. Once a much used tool by the Design Team to collaborate on mockups, now in need for some love and care.

After many years just lurking I'm happy to be officially back as a GNOME Foundation member now that Bobby has joined Circle.

New plan

I lost my job this year due to the big tech layoffs. Also dealing with burnout, it made me realise I need to go back to working on things that matter to me.

I would love to contribute design full-time.

If you like my work and want to support me, I'm trying to gather enough small monthly sponsors to support me with a basic income. Every little helps.

My focus for 2026:

• Supply a stream of icons to the Linux ecosystem by designing at least one app icon a week. Developers can request free icons.
• Reboot SparkleShare. Finish the rewrite in Rust and redesign the interface with GTK4 and libadwaita.
• Launch a FOSS design service. Make a plan for sustainably assist FOSS communities with product design work.

I will post frequent updates here and on the Fediverse.

Good to be back!

13 Jun 2026 12:00am GMT

Update on what happened across the GNOME project in the week from June 5 to June 12.

GNOME Foundation

marimaj reports

The GNOME Foundation has selected the first recipients who will receive funding through its new Fellowship program, and is delighted to announce that Peter Eisenmann and Sophie Herold will begin work as our first Fellows in July.

Sophie and Peter are both long-running GNOME contributors, with many significant contributions as members of the GNOME community. Sophie is known as developer of apps, libraries, and websites, including Loupe, Pika Backup, Glycin, and welcome.gnome.org. Peter is a long-standing Nautilus maintainer (officially known as the Files app), as well as an experienced contributor to platform libraries, including GTK and GLib.

Full announcement: https://blogs.gnome.org/foundation/2026/06/11/announcing-our-first-fellows/

Miscellaneous

Philipp Sauberzweig reports

I'm excited to share with you that I'll be joining the Sovereign Tech Agency as a fellow for the GNOME Design Team starting in July. Check out the announcement and the full cohort of fellows in the official blogpost.

During my two-year fellowship, I will support GNOME maintainers and developers with design feedback and reviews, create mockups, and coordinate efforts to standardize design patterns. My focus will be on increasing the visibility of design work, improving documentation, tools, and templates, and supporting the onboarding of new contributors.

I'm looking forward to meeting many of you (again) at GUADEC and I'll post more about my activities soon. I'm currently wrapping up projects from my previous job and taking some time off. See you all back in July.

GNOME Core Apps and Libraries

Maps ↗

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

mlundblad reports

Maps now shows departures (and arrivals) for public transit stops/stations (when data is available in Transitous)

GNOME Circle Apps and Libraries

Tuba ↗

Browse the Fediverse.

GeopJr 🏳️‍⚧️🏳️‍🌈 says

This week, Tuba was ported to Android, opening up exciting new opportunities, as we get closer to the next release!

Third Party Projects

Jiri Eischmann reports

Meshy 26.06 has been released. It's the first stable release of MeshCore client for Linux written in Python, GTK 4, and libadwaita.

It has a feature parity with the official client, but provides native look & feel striving for the best possible integration with the Linux desktop, primarily GNOME.

You can install stable releases of Meshy from Flathub or developoment releases from the app's flatpak repo.

Stable releases are planned at a rate of once per month.

Anton Isaiev announces

RustConn 0.16 Released

RustConn just turned one year old, and 0.16 is out. Thank you to everyone who uses it and files reports - that feedback shapes every release.

The biggest change this cycle is the move to IronRDP 0.15: bulk compression for lower bandwidth on slow links, slow-path rendering (XRDP and older Windows no longer show a blank screen), and better compatibility with GNOME Remote Desktop. Huge thanks to the IronRDP project and to all the open projects RustConn builds on for its connections.

Other highlights, all requested by users:

• Connections with notes now show a small badge in the sidebar, so you can see at a glance which entries have documentation (search also takes into account the content of notes).
• Snap packaging caught up with the Flatpak build.
• A lot of macOS fixes (Keychain, SSH password auth, tray).
• A new Windows / WSL2 setup guide.
• Plus many small GNOME HIG refinements across the settings dialog and sidebar.

Homepage: https://github.com/totoshko88/RustConn Flathub: https://flathub.org/apps/io.github.totoshko88.RustConn

austin says

Gelly 1.6 was released this week. Gelly is a Jellyfin and Subsonic/Navidrome compatible player using GNOME technologies. The last month has seen an uptick in development and contributions, with a few major features added:

• Gapless playback
• UI polish, including a new compact mode
• NFC card support with the companion gelly-nfc project
• Favorites
• Internationalization

Gelly needs help with translations! Please see the README for details. Thanks to all that have already contributed!

https://flathub.org/en/apps/io.m51.Gelly

Ans Ibrahim announces

Memento, the movie and tv tracking app, got updates this week with version 1.3.0:

• Backup and Restore functionality was implemented
• Import from Ticketbooth is supported
• Import for Movary plays and watchlist is supported
• Users can add plays without date

Fractal ↗

Matrix messaging app for GNOME written in Rust.

Kévin Commaille reports

Fractal 14 has landed and is packed with lots of small changes, that make for an even better experience. Here is a quick reminder of the changes since Fractal 13:

• Call rooms are identified with a camera icon in the sidebar and show a banner to warn that other users might not read messages in these rooms.
• Calls are rendered in the timeline and incoming calls trigger a notification. We still don't support calls, but at least now you know when someone is calling and can open another client to answer.
• While we still support signing in via SSO, we have dropped support for identity providers, to simplify our code and a have a closer experience to signing in with OAuth 2.0.
• The sidebar room filter has been improved: Enter goes to first room result, and there's an empty state when no results match the term.
• The performance of the room list has also been improved, it should be mostly noticeable for accounts that have joined a lot of rooms.
• Informative events (Unable to decrypt, server notices…) are now styled differently to reflect their special nature and differentiate them from regular text messages that anyone can send.
• Sending files & location is properly disabled while editing/replying, as it doesn't work anyway.

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

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

This version is available right now on Flathub.

This cycle, we were lucky enough to get a higher than usual number of new contributors. Most of the changes listed above come from them. If you want to join the gang, you can start by fixing one of our newcomers issues. We are always looking for new members!

Shell Extensions

Carlos Jiménez reports

New version of Gnome Football extension, now with a calendar panel integration: https://github.com/carlosjdelgado/GnomeFootball/releases/tag/v2.0.0

Arnis (kem-a) announces

Kiwi (is not Apple) brings a bit of macOS feel to GNOME without getting in the way of the desktop you already use. The idea is to help people coming from macOS settle into Linux and feel at home on GNOME right away. It is fairly feature-rich and modular: macOS-style window control buttons, window controls and titles in the top panel for maximized apps, battery percentage when you are getting low, and a calendar moved to the right with notifications tucked into Quick Settings, accent colored menu entries, among others. The restyling is deliberately minimal, so it plays nice with default Adwaita theme and the rest of your setup.

The latest update v1.7.0 improves the dynamic blur implementation (of course, there is blur) to the top panel, dash via Dash to Dock, and the Overview background, and adds a smoother, slowed workspace switch transition.

Install it from GNOME Extensions or get it from GitHub

Just Perfection says

A new rule has been added to the EGO review guidelines to prevent GNOME Shell extensions from including unnecessary keys in metadata.json.

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!

12 Jun 2026 8:33pm GMT

From white-boarding my ideas on a Google Doc, to writing a formal design document in Crosswords, my ability to communicate technical ideas clearly is being put to the test.

Writing documentation is critical to guide others' understanding of the code and choices made on a particular codebase. Especially when several developers are introduced to the system, a way to reference material leads to more preparedness to contribute to the codebase.

I wrote a design document introducing the concepts I would like to implement towards creating a way to generate a dynamic grid. Critique is welcome.

Standard libipuz crosswords currently rely on using an existing dictionary to fill a static box of X length x Y width. However, the implementation of vocab puzzles goes against this logic and instead generates a new grid of N length x M width based on a list of 0 <= W <= 30 words of 1 <= L <= 25 characters long.

I reconsidered the idea of using a GArray to store unplaced words because I want something idempotent. To avoid unwanted time complexity bloat, the backend should not carry the memory of unplaced words. Instead, the frontend will compare the generated grid against the original list to manage words that couldn't be placed.

Integrating this new feature will be a fascinating technical challenge.

I created a new IpuzVocab class which inherits from IpuzCrossword. I learned how GNOME manages its developer documentation by writing a file myself to introduce this class. Writing this document made me think about the whole picture: how vocab puzzles handle grids, clues, and guesses, comparing it to standard crossword puzzles. I wrote the support to display a vocab puzzle in light and dark mode, with my next goal to integrate them via gi-docgen.

11 Jun 2026 8:49pm GMT

The GNOME Foundation has selected the first recipients who will receive funding through its new Fellowship program, and is delighted to announce that Peter Eisenmann and Sophie Herold will begin work as our first Fellows in July.

Sophie and Peter are both long-running GNOME contributors, with many significant contributions as members of the GNOME community. Sophie is known as developer of apps, libraries, and websites, including Loupe, Pika Backup, Glycin, and welcome.gnome.org. Peter is a long-standing Nautilus maintainer (officially known as the Files app), as well as an experienced contributor to platform libraries, including GTK and GLib.

Both Fellows will spend time working to enhance the long-term sustainability and health of the GNOME project. Sophie will be working to establish a new RFC process for GNOME, which will enhance our project-level governance. She will also be working on more maintainable and secure libraries through Rust adoption. Peter will work to modernize many aspects of the Files app, including thumbnailing, user directory localization, and the use of modern GNOME platform conventions.

Congratulations to Peter and Sophie - we're genuinely excited to see what you'll achieve as our first Fellows, and proud to be supporting your work.

We'd also like to take this opportunity to thank everyone who submitted applications to the first round of the Fellowship. We received some genuinely excellent proposals, and would strongly encourage unsuccessful applicants to apply again in future rounds.

Peter and Sophie's work is made possible by the generosity of GNOME's supporters. If you'd like to help fund future rounds and support contributors like them, please consider donating.

11 Jun 2026 8:49am GMT

Terry Godier wrote a beautiful essay "The Boring Internet". The internet isn't dying, he argues, just the commercial veneer glued on top of it is. Underneath all the engagement metrics and algorithmic feeds, there's still an older, slower, more federated web. One built on protocols nobody owns. RSS feeds still work (thank you, Aaron), people can set up websites and blogs.

Lets start a webring in 2026

Don't worry, I haven't pushed too many pixels and gone a little cuckoo. But it's a fun exercise to remind what the web once was. We'll silently skip over the fact that I actually started using gopher first, but even web surfing didn't begin on a search engine back in the day. It was web rings, later followed by index sites.

Start

Not long ago I posted about designing app icons for 3rd party GNOME app developers. The post generated quite some buzz and some old and new faces started showing up to help with the backlog. So obviously I'd like to take you on a webring tour of all the designers responsible for making the GNOME app ecosystem a little less awkward to browse on Flathub.

Let me introduce you to Brage. He's been around for a couple of years now, helping to tame the flames of the reddit community, helping with the GNOME Circle project to improve the quality of GNOME apps in the wild, creating illustrations for initial states in apps, authoring some noteworthy apps himself. So thank you, Brage, welcome to the 90s!

Next Up: Brage Fuglseth

10 Jun 2026 12:00am GMT

Linux App Summit 2026 Social Media Retrospective

This is my personal retrospective post - there will likely be some version of this that will go out to various stakeholders.

I want to start off by giving huge praise to our organizing team that worked really hard this year in putting this event together. Couldn't ask for a better team to work with. Our organizing team is a mix of KDE and GNOME people.

This post will focus on the outreach, fundraising, and social media campaign since that was the bulk of the work I did for LAS this year.

Linux App Summit (LAS) for those who don't know is a conference organized around the goal of encouraging developing apps on the Linux platform. With
the advent of technologies like Flatpak, we had the technology to be able to ship apps directly to users instead of through the distros. Opening
an opportunity for a bi-directional relationship between app developers and the users of their apps.

This year marks the 10th year I've been involved in organizing LAS and its previous incarnation, LAS GNOME. LAS is organized jointly by GNOME and KDE who help fund and promote the conference jointly. It is a showcase of how we can unite and do impactful things.

I was not able to attend this year due to other commitments. I hope other who did attend will weigh in and let us know how it was in-person.

Let's get to it!

Challenging Myself

I wanted to challenge myself this year and really bring in the kind of engagement that I could be proud of. I've not really had the kind of time I wanted to work on this and it was time to really focus and see what could be done with a proper plan. The goal I wanted to take myself is driving awareness and growing attendance on what our app ecosystem is doing.

What does that entail?

Improving our social media game

The underlying problem I have identified is that Linux and apps was not getting into the headspace of developers. It still felt that this conference was unknown even in our own spaces. We need to break out of Mastodon and start exploring different platforms and content.

In previous years, we were using Buffer since it was free but it was really difficult and unwieldy. We could only schedule 3 days in advance and at times the posts would just drop. We needed to first change the tools we used to really improve our engagement with the world.

With help from the sysadmins at the GNOME Foundation (thank you, GF and Andrea Veri and Bart!), we were able to install Mixpost a self-host social media platform. The two great things about Mixpost is 1) analytics of the posts and social media platforms we were active on and not so active on 2) have a workspace around all our social media accounts and have a team of people working in it with an editorial flow and content calendar. This allowed us to share the workload of posting among many members. For instance, when I wasn't around, Aryan Kaushik was able to take it over and post. Mixpost is now also being used for various GNOME's accounts as well. The software continues to improve and hopefully they'll get around to single-signon support.

With the ability to actually have metrics, the next step is to actually take goals for each of the social media accounts we had and see if we could meet them. Below is a table of the targets I took and the results from February 2026 - May 2026. Instagram was actually started in the beginning of May.

Social Media	Start Count	Target Count	Result
Mastodon	596	796	926
LinkedIn	534	700	619
BlueSky	0	100	39
YouTube	1420	N/A	1610
Instagram	0	N/A	42

Overall, I think we did ok! The high count for Mastodon was because of the great work of the GNOME and KDE accounts on mastodon boosting our posts and helping promoting them before, during, and after LAS. I noticed doing things like polls on mastodon got a lot of attention without needing boosts from the other accounts.

We had decent engagement on LinkedIn. Certainly better than in the past. The trick though is that LinkedIn requires a different lens when you post. Since it is mostly focus on B2B and B2C type of messaging you need to write them differently. I didn't do it this time because writing social media posts is hard and takes a lot of time and thought.

I didn't take any goals for YouTube since we did not conceive that we would create content targeted for YouTube. In a spur of the moment, I did a 'podcast style' conversation between Matthias Clasen and myself talking about LAS. That gave us about 354 views. Which was encouraging and gives us some idea how organic content on YouTube would be received.

Bluesky was a new account for us. So we started with zero. We gained 39 followers. That might not seem like a lot given the time frame but BlueSky is an interesting platform when it comes to engagement. You can get quite a bit of engagement even if the follower count is low. I think given more time on the platform we'll be able to make that 100+ if we keep posting content. I think hashtags matter here and playing with the right kind of hashtag and content matters. Bluesky is also was a great experiment when you didn't have big accounts like GNOME and KDE boosting you.

The media partners we had 9to5Linux, Tuxdigital, It's FOSS, and Linux Magazine all helped in this regard by using their accounts boost our posts in these other platforms and give us visibility. Thank you to our media partners for helping out and we hope we can work with them closer next year. I'll like to engage with them further to see how we can help each other out including contributing content. Another idea is to reach out to the speakers of these talks and get them to write some articles that could be contributed based on their talks.

Finally, Instagram. This is an untapped gold mine. I was skimming through the platform looking for GNOME/KDE/Linux desktop type posts to see how well content did. Saw one young lady, who showed off her GNOME desktop with some caption and it gave her 130k views. It was about 10 seconds long. That was impressive. I posted a short video talking about Linux App Summit, and while I got about 130 views - the analytics said most stopped watching after 9 seconds of the 4 minute video I posted. That hurt my pride. I resolved to do better and get better engagement with a 10-15 second video that packed more information and visually more stimulating. As of now the LAS account is still gaining followers despite not posting for 2 weeks. Once again, the media partners helped by liking my posts while the other accounts lay idle.

Working with YouTube Influencers

One other aspects of my plan on boosting the visibility of LAS was to start working with influencers on various platforms. I made a few attempts with a few I knew but was only able to get on one podcast - Tux Digital. Michael Tunnell was kind enough to invite Aleix Pol and myself on his show. For an hour and half, we answered questions and did some bantering. We even went in some organic directions that was fun! I know I had fun, I hope Aleix did too. The exposure was pretty good with approximately 8k+ views for that episode that was 90 minutes. The feedback to the video was very positive with many resolving to attend the conference. Unfortunately, I didn't set up utm links so that I know where people came from.

Through social media and influencers, we hoped to break out of our media ecosystem and branch out to platforms that developers and Linux enthusiasts hang out and consume content. Meeting where developers are needs to be something we will need to focus on going forward.

Results

The in-person conference was a success, we had 110 people at the conference, the venue capacity was 100. We had 156 people who registered for the conference, this is about a 71% conversion rate. The industry average for free in-person events is 50%. For LAS, this is unprecedented because we usually had a much worse turnover rate historically. At one point, a few years ago I had started looking into doing registration fees to give people some reason to go and not ghost the conference.

For online this year, we had about 50 online registrations but it's hard to gauge anything about online participation since we freely published the YouTube link on social media.

The results for the conference for online had the following results on YouTube:

	2025	2026
Day 1 Views	922	1.7k
Day 2 Views	485	1.5k

The above numbers show views within the 24 hour period of each day. These are really good numbers where we've more than doubled our viewership on one of the two days compared to last year. Ostensibly, it shows that our social media did build awareness.

Here is the (still increasing) numbers as of now on Youtube:

First Day: 2k views
Second day: 2.7k views

The videos are currently being broken up into individual talks. But the individual talks as of now are averaging about 300 views or so with the top one being 900+ views for Lennart's keynote.

The aggregate views for all the 13 individual talk videos posted so far is 4.9k. If we combined that with the combined 2k and 2.7k views, we can simplistically (mathematically speaking) would be 9.6k. Interestingly enough, that is not a big difference from the 8k views of Tux Digital podcast that Aleix and I were on. 😀

In regards, to the people who attended Linux App Summit, 16 people filled out the surveys and by in-large most of the people who attended heard about LAS through word of mouth and not so much through social media. So, that's an interesting data point. I expect that is because of people like Lorenz Wildberg (thank you!) who did on the ground outreach.

Interestingly, enough our online views were quite good compared to say SCALE which peaked at 7.1k views for one talk but in general the average views was less than the average views than at LAS. Our subject matter is increasingly important.

Also to be clear, views do not translate to people.

Looking towards 2027, we'll want to increase our in-person attendance while doubling our online views. Something we will be focusing on when we organize for next year.

Next Steps

Our organizing team will be posting relevant individual talks on social media once all the individual videos have been posted. I hope you all share those with everyone.

Secondly, we would love to add more people to our organizing team. Specifically, in order to really build out our outreach we need a lot more people to help network and reach out to developers from different communities and different platforms. This way we can start building relationships with other desktop projects, app developers, game developers, designers not just from Linux but from other platforms as well. For that we need a small army of advocates.

Thanks

I wanted to add the social media work is a team effort and that I would like to thank Aryan Kaushik and Aniqa Khokar for helping write posts and editing them. As well, I would like to thank Caroline Henriksen for doing all the images and themes on social media!

09 Jun 2026 11:18pm GMT

Gom is a very old object mapper I wrote to bridge GObject to SQLite. It made a lot of assumptions about the world based on when it was prototyped.

The past couple years had me using it again for the documentation search in Manuals. Typically, I would have just built Manuals to parse all the XML files on disk and hold them in memory. That's how both Devhelp and Builder always did things. Once we started supporting Flatpak SDKs that was no longer realistic. You could have numerous SDKs all with copies of the overlapping data and it just became easier to have a query model.

One of the more performance critical limitations was the locking model. When gom-1.0 was written, it was not common for distributions to compile SQLite with locking support. So you just created a single thread and did your work over there.

Bolting fulltext search and many other missing features onto the old ABI just wasn't realistic. Especially when I've wanted to make the thing properly async for years. One of my other projects, Libdex is just right over there and perfect for this sort of problem.

The landscape changed and so do our horizons.

A new informed ABI

In the years after Gom was prototyped, I worked at a commercial database company and learned a great deal about implementing the internals of both that database and more traditional RDBMS. That left a certain cringe on my mouth whenever looking at my code predating it. Knowing how things get done inside the database allows for building better APIs to interact with it.

This time everything is async. Queries are modeled like you do with a compiler. Lowered into the back-end specific implementation. There can be an entity map and real transactions which allows you to read back the same instance despite which query inflated it.

The Center

Your early stage objects are the GomRepository, GomDriver, and GomRegistry.

The registry describes the entities that can exist within the repository. This is handy because it allows us to pre-compile information into a model that is both immutable and fast at runtime. Compare that to methods like g_object_class_list_properties() which is a performance bottleneck of its own.

The driver is very obvious. It is our abstraction layer for the database engines. Currently we have support for SQLite and PostgreSQL.

The repository is the center of the center. It is how you query, insert, update, delete, transact, and more. It is likely your application instance owns one of these unless of course you use Gom as your file format in which case you'll have one per "document".

Two Access Models

This new version of Gom can support either the entity mapping you're used to or; optionally, raw access to relations/projections via the GomCursor.

As the cursor moves through the resulting rows you will have access to all the projections requested in the query. Though it holds enough information to allow you to gom_cursor_materialize() the row into an GomEntity subclass.

If you want a snapshot of that cursor row without materializing, you can use GomRecord which can also conveniently be used in GListModel for integration into GTK applications.

Most of the time, you'll use materialization. And even then it is likely to happen through automated collections rather than with a cursor directly. More on that later.

Sessions

As I mentioned, there was no concept of transactions previously.

In this iteration we have GomSession. It is your standard identity-map layer with transaction-scoping. If you perform multiple queries for the same record, the session will ensure you get the same instance back. That is essential when you do local mutations on an instance and what to see that reflected in followup queries.

Additionally, it makes it nice to have multiple views of an object with an editor or listview and needing them to stay in sync.

Relationship Modeling

Support for relationships was adhoc previously. We had some functions named in ways that made you think you could, but I assure you, they were not well tested.

This time around you can model your GomEntity with 1:1, 1:M, M:M, inverse, self-referencing, all while handling proper delete rules. Combing this with the session support mentioned previously is crucial.

So now you should be able to show related models easily in GtkListView while keeping the paginated-and-lazy model beneath it transactional.

Migrations

In the previous version migrations were dynamic, but largely controlled by Gom itself. Very inflexible.

This time around we have things broken down into Migrator and Migration.

You can use built-in implementations like the EntityMigrator or implement your own. CustomMigrator makes that easy. Especially since you can inject your own migrations at just the right point.

Internally, libgom-2 can snapshot your GomRegistry at specific versions based on the provided metadata. Then it performs a diff between two versions of the registry to determine what migration work must be done.

You can just as easily use a SqlMigration with custom SQL scripts. This stuff is all highly composable now to get exactly what you need.

Live List Models

I've written many ways to get live SQLite results into GTK over the past two decades. I think one of the first was a GtkTreeModel implementation for GTK 2 which could do it. With that in mind, it was still rather annoying when making Manuals so I set off to make that convenient.

We have GomRecordListModel, GomEntityListModel, GomRelatedListModel, GomQueryModel all of which have practical uses based on application needs.

But in short, most of those are lazy and support transaction-backed stable identities for entities. Very useful when you have a list of items and an editor loaded in another frame, both of which must reflect the same data.

Expression Trees

This time around I implemented proper expression trees. They model the query, relations, and projections in a manner that allows the driver to lower into a query much more accurately.

You can model things like function-calls cleanly all of which required writing manual SQL before. If you did anything outside of what gom could generate previously, it became madness to maintain.

Vectors

This version of libgom embeds the vec1 extension for SQLite. That means we can store vectors in your records and query them. GomVector makes that easier to manage as a property within your application entity.

I can think of a few things this will be useful for, maybe you can too.

Profiling

This version of libgom has profiling support with another project of mine, Sysprof. The whole library emits profiler marks about what is going on so that it is easy for you to figure out why something might be slow in your application.

Since we've already done the integration of Sysprof into GLib/GObject, GTK, Pango, Libdex, and GNOME Shell/Mutter you can very quickly get an idea with details of what is going on in your application. Click record, select the problem area, zoom, and it is often pretty clear. You can have flamegraphs, callgraphs, and timing marks all in one place.

Local First with Sync Coordination

One of my personal motivations for this is around building a native sync protocol for applications I'm building. I wrote numerous SQLite-based sync protocols for the now defunct catch.com before they were acquired by apple. That means I know multiple wrong ways to do it.

This time around, I want to put it right in the data-mapper at the point where you have the most insight. So libgom has the right abstractions in place to build that. The GomSyncCoordinator manages the process and GomSyncTransport is the abstraction-point for service integration.

You work with GomDelta at this layer. The application can provide you with a GomMergePolicy to help make decisions which allow for contextually doing the right thing.

This part is still very new. I'm still building the other side of it but landing the shape early allows me to mock and test things comprehensively before committing to the ABI.

My goal is building a practical, robust, and correct implementation for personal local first features.

A small personal note: as I wrote in my recent update from France, I am no longer employed by Red Hat. Work like this is currently self-funded, out of pocket, while my family and I settle into a new chapter. If you find it useful, a note of encouragement or a contribution means a lot right now. It helps make it possible to keep improving the free software infrastructure many of us rely on.

09 Jun 2026 7:48pm GMT

Many GNOME projects have adopted a policy banning all contributions generated by LLMs. This policy was originally developed by Sophie for Loupe, but is now used in many other notable places:

This project does not allow contributions generated by large languages models (LLMs) and chatbots. This ban includes, but is not limited to, tools like ChatGPT, Claude, Copilot, DeepSeek, and Devin AI. We are taking these steps as precaution due to the potential negative influence of AI generated content on quality, as well as likely copyright violations.

This ban of AI generated content applies to all parts of the projects, including, but not limited to, code, documentation, issues, and artworks. An exception applies for purely translating texts for issues and comments to English.

AI tools can be used to answer questions and find information. However, we encourage contributors to avoid them in favor of using existing documentation and our chats and forums. Since AI generated information is frequently misleading or false, we cannot supply support on anything referencing AI output.

I won't attempt to argue that you should allow use of AI for writing code. If you wish to ban LLM-generated code, fine. That's probably inadvisable, but I am not going to object.

But this policy is far stricter than that. Notably, it strictly prohibits AI-generated content in issue reports (except to translate text). Don't do this! Prohibiting bug reports is stupid and just makes your software worse. Please make sure your project's AI policy allows for at least AI-generated static analysis results and AI-generated vulnerability reports. Otherwise, you prohibit entirely unobjectionable problem reports.

It's hard to imagine what could possibly be the value of prohibiting valid bug reports. AI-generated static analysis works well: the AI is able to think about your code, follow execution paths, and automatically discard most false positives to avoid bothering you with them, and the quality of reports is generally pretty high. They are far from perfect, but the same is true of humans.

Here is a typical example of an AI-generated static analysis finding:

2. Resource leak in update_credentials_cb on gnutls_credentials_set failure

  File: tls/gnutls/gtlsconnection-gnutls.c:169-172

  When gnutls_credentials_set() fails, the function returns without calling g_gnutls_certificate_credentials_unref(credentials). The credentials was either freshly allocated or ref-bumped, so it leaks.

Pasting this into an issue report clearly violates the ban on AI-generated content. And yet, why would you not want to receive a clear and concrete bug report for memory leak?

I understand not all maintainers are fond of AI, but is your dislike really so extreme that you would choose to ignore valid problems and intentionally make your software worse? If not, then your AI policy should thoughtfully consider how to handle AI-generated content in issue reports. Certainly do not adopt a policy that outright bans all AI-generated content in issue reports.

As an issue reporter, you could theoretically take the problem found by the AI and rephrase all the words, then claim that it is no longer AI-generated content because it is rewritten. This is a waste of time and usually results in a lower-quality, less-detailed result, but you could plausibly do that. Or, if you want to go above and beyond, you could just jump ahead to creating a merge request. But realistically, if your project does not allow any use of AI in issue reports, it's more likely that either (a) you won't receive the issue report in the first place, or (b) you won't receive such issue reports from experienced developers who read and respect your policy, while users who do not read your policy will continue to submit them.

What about security vulnerability reports? Since the start of this year, I have reviewed well over 100 vulnerability reports that I strongly suspect were generated by AI. To reach the "over 100" claim, I sadly only considered vulnerability reports submitted during a particularly heavy four week period, so this is an extremely loose lower bound. Suffice to say, I have seen a lot of them. The quality varies dramatically. Vulnerability reports are now often better or worse than before: better because an experienced human working with a good AI is able to find vulnerabilities that would have surely gone unnoticed without AI, and worse because an inexperienced human with a bad AI might create some pretty terrible issue reports, a significant proportion of which are just outright spam. Low-quality reports remain a problem, but nowadays most AI-generated issue reports are quite good.

Maintainers do not need to tolerate spammy vulnerability reports. If an issue report is bad, of course go ahead and close it. If it's really bad, then I sometimes don't even bother replying. But banning good vulnerability reports solely because some portion of the report was generated by AI is unacceptable. AI-assisted vulnerability reports are the new industry standard, and this is not likely to change. Prohibiting issue reports reduces the quality and safety of your software, punishing your users. This is too extreme.

08 Jun 2026 9:30pm GMT

One of the many nice language features in Python are keyword arguments. They make some types of APIs concise and readable. Like so:

Unfortunately C does not have keyword arguments and, by extension, neither does C++. Adding them as a language feature would take 15-20 years of effort, most of which would consist of trying to convince people via email that such a feature is important and should be added.

There have been attempts to implement this via macros and template magic (link), but they have not seen widespread usage probably because they are using macros and template magic. However it turns out that with modern language features you can fake keyword arguments fairly convincingly. Like so:

The add_argument method takes a single argument which is a struct. The extra curly braces inside the parentheses boil down to "whatever the underlying argument is, construct it in place with these parameters". The dotted names are designated initializers, so those fields get the specified value whereas other fields get their default values.

And there you go, keyword arguments in C++. You just have to squint a bit and pretend not to see the extra curly braces.

08 Jun 2026 12:09pm GMT

As in previous years, This Week in GNOME and this entire month are dedicated to the joys and struggles of all two-spirit, lesbian, gay, bi, trans, queer, inter, pan, asexual, aromantic, and non-binary people. We celebrate the invaluable work and life of all 2SLGBTQIA+ contributors and users, across all backgrounds and experiences.

Attempts to divide queer communities are not stopping. Fundamental human rights, hard-won over decades of struggle, are still under attack.

But we are here and we are not going anywhere. The GNOME community stands with queer people, now and always.

Together we are stronger.

GNOME Core Apps and Libraries

File Previewer ↗

A previewer companion for GNOME Files.

Peter Eisenmann reports

The last few weeks have been busy for sushi, the previewer companion for nautilus. Not only did Corey Berla's GTK4 port finally land, but on top of that Tau Gärtli, Nokse and myself have made several modernizations. The major changes are:

• Dark mode support
• GTK4, libadwaita, glycin and (initial) Blueprint usage
• Rework layout of several previewers
• Nicer floating toolbars
• Modernize code to use EcmaScript modules
• Cleaned up deprecated function usages

You can test these changes in GNOME OS or by installing sushi and nautilus from the gnome-nightly Flatpak repository.

Greetings from GPN in Karlsruhe!

GJS ↗

Use the GNOME platform libraries in your JavaScript programs. GJS powers GNOME Shell, Polari, GNOME Documents, and many other apps.

JumpLink announces

I'm currently working on a TypeScript framework for GJS called gjsify, and it has just hit a new milestone: the TypeScript compiler (v6.x) now runs directly inside GJS, so Node.js is no longer needed to run tsc. Just install gjsify and invoke it with gjsify tsc. Beyond tsc, there are other handy commands too, like gjsify install as a drop-in replacement for npm install, all running natively in GJS.

Third Party Projects

Mikhail Kostin says

Vinyl v1.4.0 has been released! There is a lot of changes since v1.3.2. Over the course of a month, I tried to do as much work as possible on the functionality and accessibility of the player. I also want to say with confidence that Vinyl is the first GNOME music player with the ability to read lyrics directly from an ID3v2 tag.

Here is the list of changes that the app has undergone:

• Added opportunity to synced parse lyrics directly from ID3v2 tag
• Added a lot of shortcuts, for playback and UI
• Added functionality for a more detailed scan of covers (Ability to read covers separately for each track)
• Added a button to open the current directory for the playing track
• Added search by audio extension
• Added tooltips
• Changed track sorting, tracks are now sorted first by folder location rather than by tags
• The player has been localized into many languages ​​including German, Hindi, Czech, Slovak, Kazakh, Uzbek, Polish and Swedish

Today you can see the new version of the Vinyl on Flathub

balooii reports

First release of Contributor Atlas!

Contributor Atlas is a set of interactive visualizations that bring a project's contributor history to life. It's aimed at projects with a long legacy of contributors.

I built it for GIMP and its ecosystem, with nearly 30 years of contributors to explore, but the graphs are generic - you might find it useful for your own project too.

Explore the live GIMP dataset at the link below. I hope you find it as interesting as I do! https://contributor-atlas-4dab97.pages.gitlab.gnome.org

You can find the project at https://gitlab.gnome.org/balooii/contributor-atlas

mohfy says

This week i've released v2.0.0 of Quizbite, Quizbite is an educational app that let you create quizzes with multiple choice questions, play them and share them with your friends!

You can also export the quiz to PDF, where you can print the quiz if you want to study offline.

In version 2.0.0 we've added search for quizzes, added ability to review mistakes after taking the quiz, ability to edit a quiz after creation, and some fixes.

Get Quizbite on Flathub: https://flathub.org/en/apps/dev.mohfy.quizbite

Gitte ↗

A simple Git GUI for GNOME

Christian says

Gitte, a simple Git client for GNOME built with GTK4, libadwaita and Relm4, just got its 0.6.0 release! 🎉

The headline feature this time is per-file stash operations: you can now apply, pop or drop individual files from a stash via handy context-menu entries, and stash only the files you've selected in the working copy view, instead of always stashing everything.

Commit messages also got a lot more interactive. URLs are turned into clickable links, #<id> and !<id> mentions are linkified for known forges, and authors and committers show up as mailto: links. After pushing to a known forge, Gitte now offers a "New merge / pull request" link button so you can jump straight to creating one.

There are new shortcuts to hide untracked files (Ctrl+Shift+H) and to toggle untracked directories without recursing into them, and the staged/unstaged sections in split view are now collapsible, with an option to reverse their order.

Under the hood the working copy view got a performance overhaul: Gitte can now browse the Linux kernel repository with 10k changed files with ease.

Gitte also resolves includeIf blocks when reading the Git configuration now. On top of that come colored pills in the branch info box, a pointer cursor on selectable diff lines, and the usual pile of smaller UI refinements and fixes.

And there's good news for BSD folks: Gitte is now available in the FreeBSD ports tree, so you can install it via pkg install deskutils/gitte.

Get it on Flathub, for macOS or have a look at the Code.

Miscellaneous

GNOME OS ↗

The GNOME operating system, development and testing platform

Felicitas Pojtinger says

The documentation for contributing to GNOME Build Metadata (the project which builds things such as GNOME OS, the GNOME Flatpak runtimes and GNOME OCI images) got a big overhaul! If you ever wanted to build your own version of GNOME OS, want to make changes to your running GNOME OS system or fix a bug you've found somewhere, or if you're just curious and want to learn more about how BuildStream, systemd-sysupdate/sysext or the Flatpak runtimes work, now is a great time to try it out! The new CONTRIBUTING.md document is a good place to start: https://gitlab.gnome.org/GNOME/gnome-build-meta/-/blob/master/CONTRIBUTING.md

Damned Lies ↗

The internal application to manage localization of GNOME & friends modules

Guillaume Bernard announces

A few changes for Damned Lies arrived this week! Our translation platform has received two external contributions, and we have very cool new features:

• @kristjan.esperanto added a dark theme to Damned Lies. You now have the possibility to switch between dark and light themes, or use the auto-mode that will follow your browser and desktop default theme.

• @balooii implemented a feature to better reward contributors who work on a workflow. The current implementation of the commit action only mentions the author of the translation and the committer. With this change, all volunteers who worked on a translation workflow are mentioned in the commit message with Translated-by, Reviewed-by, and Contributed-by credits.

Then, we have a fix from another contributor, @codeurluce who started contributing with a newcomer feature to fix a glitch in the interface.

I also took the opportunity to work a bit on the Deneb theme that Damned Lies uses to enhance the contrast of the different buttons and elements. The gnome-boostrap-theme received a few updates that are now reflected in Damned Lies. As usual, if you find something odd, please report issues!

Finally, in the diff view (the one you see on vertimus workflows) between a file and a previous version of a PO file, you now see some of the non-printable characters, like newlines, tabs, or non break spaces. If you use some in your language you'd like to have, just ask!

This was a very intense week for Damned Lies, and if you'd like to plant a seed in the i18n ecosystem, please open an issue, contact us on the #i18n:gnome.org channel or ask for new features!

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!

06 Jun 2026 11:32am GMT