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.
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.
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.
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
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.
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.
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.
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
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!
I’ve been using Fedora Silverblue on my desktop and laptop for the past, what, five years?
Silverblue is Fedora’s main atomic variant, a spiritual counterpart to Fedora Workstation.
I also make niri, a scrollable-tiling Wayland compositor.
In other words, a core system component that you cannot properly test from inside a container or VM—you really want it directly on the host.
So, why would I choose an… immutable distro?
How does that even work?
Fedora Silverblue makes a frequent occurrence in my niri release notes screenshots.
Atomic distributions have been slowly rising in popularity.
Their main selling point is reliability: upgrades work by swapping the old system for the new one in one go across a reboot, rather than modifying the files in-place.
Package conflicts and other errors are caught at the time of assembling the new version (in a separate folder), and therefore cannot break your running system.
And if a successful update turns out buggy, atomic distros let you simply reboot back into the old version and keep using it as if nothing happened.
This “being able to reboot back” thing becomes even cooler once you realize that it works even across major distro upgrades!
When the next Fedora Beta rolls around, I can just rebase my system on top of it to kick the tires, and if anything is broken, I can simply reboot back to stable Fedora (and then undo the rebase).
This is like learning about source code version control.
A big weight off your mind any time you want to mess around with your OS.
You can just go back.
But, you may ask.
What if I develop these operating system binaries?
Aren’t atomic distros immutable and all, how do I test my work?
Turns out, this is not a problem at all!
In fact, the same tech that lets you go back after an update can also let you freely tinker with your host system and safely go back after a reboot.
I’d say that thanks to this ability, atomic distributions provide even more benefit for system component developers than for others, given that they’re constantly testing changes that may break their install.
So, let me show you how I do compositor development on Fedora Silverblue.
We’ll start with toolbox where most of the work happens, then proceed to the fun stuff.
On your immutable host system, you need a place where you can install the development environment.
Fedora Silverblue comes pre-installed with Toolbox, which provides just that—a terminal in a normal, mutable Fedora where you can sudo dnf install to your heart’s content.
Under the hood, it’s just a podman container with a whole range of things auto-mounted from the host: the Wayland socket, networking, devices, D-Bus, and everything else needed for apps to “just work” as much as possible from inside the container.
You can even interact with it through podman commands:
┌ ~
└─ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6ceccce5581e registry.fedoraproject.org/fedora-toolbox:44 toolbox --log-lev... 2 months ago Up 41 minutes fedora-toolbox-44
Most of your development work happens here.
Install all the libraries, compilers, editors, LSPs, debuggers, and the rest of the kitchen sink.
Since all of this resides inside the same container, it can all talk to each other and work together.
One slightly annoying detail is that since your fully-configured editor is inside the toolbox, you can’t use it to edit files accessible only on the host (e.g. configs in /etc—the system inside the toolbox has its own files there), but that is honestly a fairly minor problem in practice.
Fedora Silverblue comes with nano, which works, and if editing host-only files is a frequent occurrence for you, you can always rpm-ostree install a more featureful editor.
Another annoying problem is that currently, toolbox prevents SIGHUP from reaching apps, so if you run your favorite editor then close the terminal window, it will happily keep running in the background (along with all its rust-analyzers and such, eating several gigabytes of RAM).
So, running things in a toolbox works perfectly well for most development.
CLI tools will run fine, GUI apps will run fine, you can build and install libraries inside the toolbox and test them on apps inside the same toolbox.
Even with Wayland compositors, most of them can run as a window (gnome-shell --nested, or simply sway or niri), which is enough to test the majority of the code base.
Moreover, since ~2023, toolbox exposes everything necessary to run compositors on a TTY directly.
You can switch to a different VT with CtrlAltF3, toolbox enter, then start a compositor, and it will work as is.
This way you can test different input devices directly (trackpad, tablet, touchscreen), test monitor and GPU handling, do proper performance profiling, and so on.
Just remember to install a terminal and some GUI apps inside the toolbox because launching the host ones into a toolbox compositor is a bit annoying.
While toolbox is somewhat Fedora-specific, for everything else there’s distrobox.
It’s a separate project, but by and large has the same idea—let you easily install different distros as podman containers with automatic host integration.
I mainly use it to build or test things on Arch, but I imagine most of what I wrote above works just as well with distrobox.
What if this isn’t enough, though?
Say, you’re working on a component like NetworkManager or systemd that must run on the host system.
Or, you want to be able to log in to a test build of your compositor along with the rest of the full desktop session.
Let’s look at an easy way to do that.
Run sudo ostree admin unlock, also known as rpm-ostree usroverlay.12
This will mount a mutable overlay filesystem over /usr for you to play around in.
The overlay will last until the next reboot, at which point you’ll be back to a clean working system.
Now you can simply sudo cp your development build into /usr/bin and restart the service you’re testing.
This also works with libraries.
Say, you want to test your changes in GTK against apps installed on the host.3
Build it inside the toolbox, then copy the binaries to the (unlocked) host, and there you have it.
Binary compatibility is generally not a concern since Silverblue updates daily and very closely matches the regular Fedora that you build against inside the toolbox.
sudo cp is not a proper substitute for installing though, and you cannot use it as easily for many projects.
So let’s get some proper tooling on the host.
Contrary to an apparently widespread belief, you can install packages on the host in Silverblue.
This is called layering and is a perfectly normal and supported operation, primarily useful for adding system components such as terminals, window managers, or GPU drivers.
Running rpm-ostree install alacritty will cause rpm-ostree to install, or layer, this package on top of the base Silverblue image every time it updates.
After a reboot, you’ll have Fedora with Alacritty, as if you installed it on a regular, non-atomic system.
If the change is sufficiently non-invasive, running sudo rpm-ostree apply-live lets you skip the reboot and have a newly installed program available right away.4
When should you layer (as opposed to installing in a toolbox)?
Layering is more annoying and slower, and misses the benefit of throwing away a toolbox to start fresh.
So, I limit layering to programs that must run on the host, and tools that I frequently need on the host.
Here’s my list of layered packages that’s been more or less unchanged for several Fedora releases:
Terminals (must run on the host to access the full host filesystem5): alacritty, foot, gnome-console. My preferred shell: fish. Tool I frequently need: tmux.
Services and tools that I want to run without a toolbox: syncthing, distrobox, netconsole-service, trash-cli, htop, fastfetch, lm_sensors, rocminfo.
edid-asus and the initramfs-overlay provide the EDID for one of my monitors after AMDGPU broke it back in kernel 4.19.6
Along with these, I layer several development tools: gdb, strace, perf, sysprof.
These frequently come in handy whenever I need to debug or profile programs running on the host (or do full-system profiling in case of Sysprof).
What is dnf, a regular Fedora package manager, doing on an immutable Silverblue host system?
By itself, it’s not very useful indeed, since it can’t modify /usr.
(Though, it can dnf copr enable, which is convenient. rpm-ostree copr when?)
Where dnf on the host shines, however, is when you combine it with sudo ostree admin unlock.
After unlocking, you can install whatever you need in the moment with dnf.
This is much faster than rpm-ostree, never requires a reboot, and in fact a reboot makes it all clean up and go away, since it was all in a transient /usr overlayfs.
Example workflows:
dnf debuginfo-install to debug/profile something on the host with symbols, report crashes, etc.
dnf install some host-only program to test it. Follow up with rpm-ostree install if you decide to keep it.
dnf builddep gtk4, then build and sudo ninja install GTK 4 right on the host to test it against host apps. If anything breaks, just reboot, and you’re back to a clean working state.
Unlocking + layering dnf is a very powerful development workflow to the point where I’d almost want dnf included in Silverblue by default.
Unfortunately, this workflow is also unobvious enough that the dnf maintainers accidentally prevented it from working some time ago (thankfully, quickly corrected).
I understand the UX concern about having dnf visibly available when it cannot work outside this specific workflow, but perhaps Silverblue could just hide it somehow unless the host is unlocked, or rename the dnf binary?
Generally to put something persistently on the host, you’d just layer it with rpm-ostree install.
However, sometimes what you want is a temporary change that also happens to persist across reboots.
This sounds weird, but consider testing a kernel build.
You want it to be temporary and easy to roll back, but you kinda have to reboot into the new kernel.
And you also don’t want to spend extra time building and layering .rpms.
For this situation, ostree admin unlock comes with a --hotfix flag.
It’ll persist the temporary overlay across reboots, and will only reset itself once you explicitly make some change with rpm-ostree.
Note that you never lose the ability to reboot into the previous, working system.
So, this is what my development workflow looks like.
Most work happens in one kitchen-sink toolbox that I (like to but am not required to) reinstall every Fedora release to keep cruft from building up. This includes building and running niri on a TTY.
After finishing a change, I unlock the host with sudo ostree admin unlock, copy over the niri binary, and re-log in to test it in my real session. This will automatically reset upon a reboot.
When working on a long-running branch, I’ll build a work-in-progress niri .rpm and layer it with rpm-ostree install to persist the new version across reboots.
I use dnf install on the host when I want to throwaway-test something host-specific and have it automatically reset upon a reboot.
Over time I made a few small quality-of-life tweaks to smooth out some rough edges in this workflow.
For example, toolbox enter is a mouthful and always drops me into bash.
Enter t, a script in my ~/.local/bin/, always available in $PATH:
and it’ll run in the toolbox.
(I understand distrobox handles .desktop files automatically.)
Note that I use toolbox run but route the command through bash.
This is necessary to get all environment variables like $DEBUGINFOD_URLS that distros keep stubbornly putting in /etc/profile.d/ scripts, which of course don’t get sourced without a bash -i.
Another quality-of-life improvement was binding a separate hotkey to spawning a terminal directly in the toolbox.
I actually noticed that most of the time, when I open a terminal, I want to be in the toolbox, so now my SuperT spawns the toolbox Alacritty, while the less convenient SuperShiftT spawns the host Alacritty.
Furthermore, at some point I got tired of waiting for the…
┌ ~
└─ hyperfine -w 3 --shell=none 'true' 't true'
Benchmark 1: true
Time (mean ± σ): 411.9 µs ± 35.8 µs [User: 248.9 µs, System: 111.3 µs]
Range (min … max): 374.1 µs … 1147.6 µs 5794 runs
Benchmark 2: t true
Time (mean ± σ): 257.8 ms ± 2.0 ms [User: 3.0 ms, System: 6.1 ms]
Range (min … max): 255.2 ms … 260.5 ms 11 runs
Summary
true ran
625.92 ± 54.60 times faster than t true
…extra 250 ms for toolbox run, and wrote a script that keeps Alacritty running as a daemon inside (and outside) the toolbox, making opening a new terminal window always instant.
As a bonus, this happens to fix the SIGHUP problem that I mentioned above: since Alacritty runs directly inside the toolbox, closing its window will properly close the terminal app running inside.
(Eventually I went even further and made a tiny service for fun that runs inside the toolbox, listens to a socket, and runs the command it receives. I only use it in .desktop files though instead of t to avoid the 250 ms delay.7)
I quite like my Silverblue setup.
It very much works, and with the tools that it has, it lets me do anything that I might need.
Silverblue is not without its problems however, so I’ve been thinking about what parts of the experience I find important, and how well other distributions currently satisfy them.
1. The ability to reboot to a previous, working system.
Most new atomic/immutable distros can do this since it’s the main value proposition.
It’s also possible on NixOS.
On traditional distros I think you can get something close with btrfs snapshots, but it requires a complex setup.
A/B updates tie closely into this, where rather than mutating the running system, an update is prepared in a separate folder, then atomically swapped with the previous system version (which remains available to boot into should something go awry).
2. Anti-hysteresis.
The host system always stays clean, packages don’t build up over time.
On a normal distro, a few months is enough for you to scarcely have any idea about all the random one-off packages you installed and forgot about, especially various development tooling and build dependencies not to mention the texlive-full installation.
They use up disk space and time during system updates, sometimes cause conflicts and other annoying issues.
Config migrations build up, and your system gradually drifts away from a clean well-tested upstream state.
Immutable distros solve this by not letting you install stuff on the host, and every updated rebuild of the host system starts from a fresh state, so there’s no accumulation of junk.
NixOS and Silverblue do let you add (layer) packages, so they can build up, but:
they make it sufficiently annoying, making you prefer non-host environments such as toolbox for one-off packages;
even with layered packages, the system is rebuilt from a fresh state every update.
Technically, you could use toolbox for everything even on a normal Fedora Workstation, but this requires discipline and doesn’t save you from config migrations, SELinux labeling changes, etc.
3. The ability to easily install things on the host.
This is the part where many newer immutable distros fail to provide a good experience.
I need to install programs on the host, whether it’s because I want some host desktop components, or to test my own compositor, or whatever.
Often, I want to install something on the host quickly.
For distros such as Universal Blue spins and other bootc-based systems, the suggested way to include components on the host is making your own downstream spin.
But this works only for long-term packages: I don’t want to spend time editing and kicking off a full system build just to test some new terminal or notification daemon, not to mention the whole question of how to keep such a custom system always up to date with its base distro.
Compare this with rpm-ostree install on Silverblue: one command, slow but tolerable, and the OS remains automatically updated with no extra setup.
Some systems are even more limited, like GNOME OS which is based on the Freedesktop SDK.
The selection of tools and libraries available in the Freedesktop SDK is (intentionally) much more limited compared to most distros, so in many cases you’ll find yourself having to go and build whatever you need from source.
If that happens to be something big and complex like Qt (to try a hot new Quickshell-based desktop): good luck; I hope you didn’t have plans for the weekend.
A common suggestion for these OSes is systemd-sysext that lets you build an image and overlay it over /usr.
Florian Müllner gave a talk at the 2025 GUADEC showing a nice workflow for using sysexts for Mutter and GNOME Shell development and testing on immutable distros.
It’s also possible to enforce system version compatibility checks in sysexts.
A system like GNOME OS could build and ship a collection of sysexts version-locked to the runtime they were built against, and automatically updated together with the rest of the system using systemd-sysupdate, resulting in an experience similar to layered packages.
(In fact, GNOME OS does have that, just the selection of sysexts is fairly small.)
Some software can be packaged into self-contained sysexts that work on most distros.
The Flatcar sysext-bakery is one repository of such sysexts.
What’s wrong then?
Well, the main limitation of sysexts is that they are meant for tools without dependencies.
They do not do any dependency resolution or support any dependencies other than, optionally, the base OS itself.
Back to my example, while it’s possible to build and ship sysexts for Qt apps that bundle Qt itself, all of those sysexts will carry their own copies of Qt.
Even worse, since they are mounted into the same filesystem tree, conflicting files (say, different-version Qt binaries) will get mounted only from one of the sysexts, whichever one happens to mount last.
So sysexts aren’t a complete replacement for packages (nor are they intended to be).
4. The ability to make transient changes to the host.
While I don’t immediately see why you couldn’t put a writable overlay on any regular distro like what ostree admin unlock does, I haven’t seen anyone doing it, or any simple “no thinking necessary” tools for it.1
Perhaps it’s too easy to mess up outside immutable systems?
It’s worth noting that some paths like /etc aren’t usually covered by immutability and overlays, so you still need to be a bit careful.
All in all, Silverblue appears to be a sweet spot between offering immutable/atomic guarantees with plenty of useful tooling bundled in, while also being a normal Fedora with a wide package selection available for both persistent layering and quick transient installation.
I appreciate the QA and other behind-the-scenes work that goes into my ability to install Silverblue and be reasonably sure that it will work, and keep working, with all of my hardware, and that I won’t have to hunt for packages to get a working bluetooth or what have you.
My Silverblue installs are the longest I’ve kept any single distro, and I have no urge to reinstall because my host system remains clean and I know exactly what it comprises.
My issues with Silverblue mostly boil down to some rough edges and slowness of rpm-ostree, and some less than ideal Flatpak repository defaults.
Having to do most of the work in a container is somewhat annoying at times, especially when dealing with nested containerization or VMs.
But I’m not sure there’s a better way fundamentally, without trading host system robustness.
For the few things that do require it, I can always unlock the host.
I hope this post sheds some light on immutable system workflows and perhaps inspires you to try one.
I’d also love to hear your feedback and suggestions!
Did I miss something?
Is there a better way of doing things?
A new system that solves all problems and makes everything better?
Please reach out to me on Mastodon or by email, linked at the bottom of the page!
I’m told the modern alternative is systemd-sysext merge --mutable=ephemeral, which works across all distros and not just Silverblue. Haven’t tried it myself yet! ↩︎↩︎
I didn’t quite realize this before, but rpm-ostree usroverlay seems to literally exec ostree admin unlock:
┌ ~
└─ rpm-ostree usroverlay -h
Usage:
ostree admin unlock [OPTION…]
Make the current deployment mutable (as a hotfix or development)
(...)
┌ ~
└─ rpm-ostree usroverlay --version
libostree:
Version: '2025.4'
Git: 99a03a7bb8caa774668222a0caace3b7e734042e
(...)
Which is, uhh, not a lot of apps come to think of it. Nautilus, Ptyxis, Software, System Monitor, Settings, xdg-desktop-portal-gnome dialogs—the rest come as Flatpaks on Silverblue. How to test your GTK changes against those Flatpak apps? Uhhhhhh ↩︎
For years, it’s been rpm-ostree ex apply-live, where ex stood for experimental. I guess I’ve been procrastinating on this blogpost long enough that it had time to graduate to non-experimental rpm-ostree apply-live. ↩︎
The Ptyxis terminal can work properly on the host even when installed as a Flatpak. It does this by spawning a small binary on the host (through a host-run permission) that does all command spawning and PTY communication, while the Ptyxis GUI remains inside Flatpak. This is a clever workaround, but requires a sandbox hole and very careful engineering, and arguably runs somewhat at odds with the point of Flatpak. ↩︎
Since writing that example, I replaced that monitor and finally got rid of the custom initramfs.
This is faster because without overrides, Silverblue directly uses an initramfs built on Fedora servers, and I think it also works better with secure boot?
Either way, I wanted to leave it in as an example that you can customize the initramfs on Silverblue if needed. ↩︎
See for yourself:
┌ ~
└─ hyperfine -w 3 --shell=none 't true' 'true' 'tb true'
Benchmark 1: t true
Time (mean ± σ): 259.5 ms ± 3.6 ms [User: 2.9 ms, System: 6.2 ms]
Range (min … max): 255.7 ms … 266.6 ms 11 runs
Benchmark 2: true
Time (mean ± σ): 408.7 µs ± 34.2 µs [User: 248.6 µs, System: 107.1 µs]
Range (min … max): 370.2 µs … 1152.8 µs 6665 runs
Benchmark 3: tb true
Time (mean ± σ): 462.8 µs ± 41.7 µs [User: 264.2 µs, System: 135.6 µs]
Range (min … max): 399.2 µs … 786.4 µs 6688 runs
Summary
true ran
1.13 ± 0.14 times faster than tb true
635.00 ± 53.80 times faster than t true
Up too early. Dropped H. into XJTAG before her epic Asian
trip. Lovely to meet up with John Hall and catch up after a couple of
decades.
Tried to pack, and gather together things for the Church's Men's
walking weekend.
Published the next strip: Ejecting a do-er, "if in
doubt, kick them out!"; cancellation based on un-proven
allegation seems to be the spirit of the age:
Do not let the AI to remove the fun part from software development.
We shouldn't allow gen AI to write software just because it "can".
First, we must ask if it "should" do it, and even then, we should ask
if we want to delegate the fun part, the thinking, the writing,
the learning.
Remember what's important, journey before destination, we are the
Code:
Open Source maintainers are dealing with a lot of new reports and
pressure to "fix" the project due to generative AI.
We need to find a way of stopping this and get back to something
maintainable before all maintainers get burned out and look for a job
in a farm:
100% secure software doesn't exists, so there will be always a
possible CVE there. As Spaf said in 1989:
The only truly secure system is one that is powered off, cast in a
block of concrete and sealed in a lead-lined room with armed guards
- and even then I have my doubts.
Fixing bugs, adds new bugs, and if you need to fix something quick,
the probability of new bugs will be higher. Do not forget about the
First Law of Programming:
If it works, don't touch it
The amount of CVE reports is lowering the CVE credibility and
quality, so if everything is a "high" security issue, we can't
prioritize now and these reports are not different from random
issues in github. Do not listen to The Boy Who Cried Wolf
Stable software is sable because it doesn't change too much. It's
something that we are willing to loose trying to reach the
impossible of 100% secure software?
The actual problem
There's a lot of money in AI tech right now, and everyone is trying to
make the best gen AI tool or just pretend that their tool is the best.
In relation with the software analysis and writing, targeting the
open source is the obvious strategy.
It's interesting to scrap every line of code, patch, pull request,
issue and discussion around software to train your model, so AI
scrappers are DDoSing open source projects infrastructure.
To promote their tools or themselves, Security Researches are
using AI to target any project, reporting High security
vulnerabilities, with the only goal of getting a CVE number to say
how good they are.
This second point is affecting maintainers, because now you are
receiving a lot of poor quality security reports, that are generated
with AI and that looks plausible and are hard to read. You need to
spend a lot of time to check if there's an actual wolf there or if
it's again this boy that's tricking me.
This is burning the energy of maintainers, that instead of doing
something productive are wasting their limited time talking with a
Stocatic Parrot.
Do not let the AI Bros to use classic manipulation techniques on you!
A lot of open source projects are maintained by volunteers that do the
work with passion and love. And even if it's the job that paid your
bills, the maintainer can feel the pressure. When someone put a
lot of love in something and work on it during years, it's part of his
identity, so attacking the software is like attacking the person
behind it.
This is nothing new, and a lot of people take advantage of this
emotional link to manipulate the maintainer to do something that he
do not want to do.
AI bros are using these techniques, do not let them to manipulate you
and define your project agenda.
Here's a (not complete) list of known manipulation techniques that you
can detect (and disarm!) in your daily community work:
Flooding the queue. Just create so many new issues that the
actual maintainers can't deal with it. You feel responsible for the
project and feel bad because your TO-DO list is growing.
This software is not secure (doesn't do what I want), I will use
this other one instead that's better. The classic, "GNOME doesn't
allow me to change this specific preference, I'll use KDE from now
on".
This software is low quality, it doesn't follow the (my random)
quality standards. Direct attack to the maintainer self-esteem.
Gaslighting software development. LLM are expert at this and
people that uses it just copy the tactic. When the maintainer
detects something weird and just tries to blame the other person
for reporting nonsense and wasting all people time, it starts to
invent new arguments and ignore the previous interaction.
So, take it easy, and remember the best clause in almost any software
project, THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
PROGRAM IS WITH YOU:
No. Anyone old enough could remember how insecure old software was. Do
you remember windows 98? Do you remember the internet when everything
was http (without that little s at the end), when people use ftp
to logging into their server and modify the php code directly on
production?
It's true that today we have more dependency on technology, but it's
also true that everything is more secure, we have more and better
cryptography, we have different levels of isolation, virtual
environments, containers, virtual machines...
But we have the feeling that since AI can analyse all the software and
look for vulnerabilities, we are doomed, because any stupid kid can
hack my over engineered GNU/Linux machine!
First, that's not true, you need to know about security to get
something useful from any AI tool. But even if it was true, what can
you do about it? We need to be practical and find a balance between
risk and usefulness, so do not overestimate the risk just because
everyone is talking about it right now.
But even then, the security paranoia is not good for anyone. Software
is inherently buggy, people write software and makes mistakes, so a
possible vulnerability appears. In theory, these bugs are fixed when
discovered, so it's always recommended to update to the latest
version, because almost all known bugs will be fixed.
But it's also known that new versions comes with new functionality and
code, and that means new "unknown" bugs or different behavior. That's
a headache, so that's why the stable and Long Term Support are popular
distributions, because "if it works, don't touch it".
Stable packages just get the fixes, not new features, but fixes are
also code changes, so there's always a possibility to break something,
even with a patch update.
The stable software has a lot of value, do not let the AI security
paranoia destroy that, and convert everything in a rolling release
with the latest and greatest (and possibly broken) software. Sometimes
it's better to keep using something old, with known
vulnerabilities that you can mitigate, than use the latest with
unknown new vulnerabilities that you can't do anything about.
I will fight AI with AI
Please, do not do that. What I was trying to argue during this long
post is not a technical problem. The current burnout problem in open
source is a social problem, you can't fix it with a new layer of
probabilistic tokens.
Community reaction against AI. The current industry push for
the usage of AI everywhere is affecting a lot of people, and as a
reaction a lot of people are directly fighting back. Using gen AI
just sends the message that you do not care enough to do it
yourself, and destroy the trust on the project.
It doesn't worth it. Even if the AI works (that it doesn't) it
doesn't worth it. Writing code is easier than reviewing, you learn
and grow with every new line of code that you write, delegating
the fun part and personal growth part to an AI will make you work
more miserable and you will be a junior forever.
It doesn't create community. Think about it, it's hard to get
someone involved in a software project, but who will want to read
or improve the code produced by a gen AI? The only future
collaborator will be another AI.
Take it easy
Just remember, you can always say no, there's no hurry, and there's no
need to work on something that you don't want just because other
people consider that important.
Free Source is something done by people, for people. The software is
important, but the community around it is sometimes more important. We
use Free source not because it's technically better (that it is), but
because we trust who, how and why are writing it.
Remember why are you doing this, do not remove the Fun part, continue
with the Just for Fun mood.
Up much too early, train into London. Met up with
some interesting folk from HCL. Pod-cast recording, lunch
re-recording a second take; interesting perspectives, fun
people.
I love adaptive interfaces and technology that blends in more than the average human. I’ve spent literally years tinkering with ‘frecency’ ordered lists, bought a meural screen and have recently been glorying in the fantastic GNOME Adaptive Brightness.
On that last point, whilst GNOME already has Automatic Screen Brightness, and it is a good feature, dmy3k’s extension goes further on the specific machines with cool hardware: steadier behaviour with changing light, smoother transitions and brightness curves you can tune. One of the things I’ve been exploring with extensions recently is ’this feature, only more so’ and adaptive brightness is a good example.
Living far from the equator, evenings happen. The room goes grey, the window stops being a useful light source and GNOME is still cheerfully in light mode because I told it to be bright at the time one takes screenshots. Night Light is already doing its bit by then. The display has warmed up, which is nice, but the rest of the interface lacks the level of ‘darque’ required. I wanted the normal GNOME appearance preference to follow the day as well: light while it still feels like day, dark once the evening has properly arrived. Users of other operating systems may be aware of this feature, but for the purposes of this blog post let us pretend that everything below is entirely unique.
So I hacked up Sunset Appearance, a small GNOME Shell extension for GNOME Shell 45 to 50. At civil dusk it writes the same setting GNOME Settings uses:
My dad was an aviator, so I got to hear a lot of exciting words growing up, such as ‘civil twilight’, which always makes me think of Romeo and Juliet. Sunset turns out to be a surprisingly slippery concept, and very longitudinally mediated. In London in summer there can be plenty of useful light after the sun has dipped below the horizon, and the desktop does not need to go ‘darque’ the moment the sun touches the skyline. Nautical and astronomical twilight are too late for an interface preference, and in some places at some times of year they can fail to happen in the normal way at all.
Civil twilight is when the centre of the sun is 6 degrees below the horizon and when it really does feel like the world has changed character.
Location is awkward too, because civil dawn and dusk need latitude, longitude and date. There’s some interesting fallback logic to infrequently get a coarse location (good enough for a city) and then fall back to cached data if available as Night Light already needs much the same information. Frequent readers will remember my concerns over London, Ontario being above London, England in many search boxes so there is no virtue in making the user type London into another small box. If neither source has usable coordinates, nothing changes.
Manual override behaviour is another thing that avoids annoyance. If the extension sets dark mode at dusk and I then change GNOME back to light mode, I meant that. After any override, it waits until the next scheduled dawn or dusk transition before touching the setting again.
Solar time code has an unreasonable number of edges for something everyone thinks they intuitively understand. Keeping with my aggressive policy on internationalisation the tests keep London as the ordinary case, then poke at time zones, date line longitudes, DST changes, Antarctic stations, Arctic towns, awkward offsets such as Lord Howe and Chatham and cases where civil dawn or dusk may not exist at all. My time reading brr and pretending to be in New Zealand to solve work bugs was not poorly spent.
Right now Sunset Appearance can be built from source. At some point I may choose to distribute it more widely, or even see if someone has already solved my problem better.
Not the best film ever, but in today's Hollywood landscape it's a rare breath of fresh air. Kane Parsons takes the internet meme concept he started on YouTube and actually makes a feature-length film that's doing great at the box office.
The mood is great. That unsettling stillness of these generic liminal spaces. For something that builds a feeling / mood, the flick would benefit from a butcher in the editing room. I'd probably still not give it the extra star, but this really isn't the kind of movie that needs the extra 20 minutes.
Biggest entertainment was definitely watching my son freak out in the third act. :)
libdex 1.2 is still in pre-alpha phase but it is also far enough along that it is worth talking about the direction: libdex is growing from a library of future and fiber helpers into a more complete concurrency toolkit.
The most important 1.2 theme is that applications can now describe not just what work should happen concurrently, but how that work should be bounded and owned. DexLimiter lets a workload run with a fixed concurrency budget, with dex_limiter_run() handling the common fiber case by acquiring a permit before work starts and releasing it after the fiber completes. For larger workflows, DexTaskGroup gives related futures a structured scope that can be closed, awaited, or cancelled as one unit.
That combination makes cleanup much easier to reason about when a workflow has many moving pieces. A loader can start many subtasks, keep only a useful number active at once, and return a single future representing the whole operation. If the window closes, the project changes, or the operation times out, the group gives the application one place to cleanly shut the work down.
There is also a new DexThreadPool for the cases that are not naturally fiber-shaped. Fibers and schedulers are still the right fit for cooperative async work, but many applications need to integrate blocking libraries, database clients, filesystem helpers, or other foreign code. A fixed pool of reusable OS threads, dex_thread_pool_submit(), and asynchronous dex_thread_pool_close() give that integration story a bounded queue and an explicit shutdown path.
Deadlines are another practical piece of the same story. The new timeout wrappers, including dex_future_with_timeout_seconds() and dex_future_with_deadline(), turn time limits into ordinary future composition. Instead of open-coded timeout state spread across an application, a future can resolve normally, reject normally, or reject with DEX_ERROR_TIMED_OUT when the deadline wins.
On the I/O side, 1.2 continues filling in the operations that make responsiveness easier to preserve. dex_aio_open() and dex_aio_close() matter because even operations that look small can stall when they touch the kernel, storage, or network-backed filesystems. Keeping those calls in libdex’s file-descriptor AIO model makes it easier to keep them off the UI thread, using io_uring where it is available and the fallback AIO backend elsewhere.
The broader GIO coverage is intentionally less surprising, but still important. More app launching, GFile, stream, socket, resolver, proxy, TLS, DTLS, permission, subprocess, and Unix-facing APIs now have future-first wrappers. That is the kind of coverage people should expect from libdex over time: not every wrapper needs a release headline, but each one reduces the pressure to leave the future model for common GNOME application work.
This first blog post marks the opening of the internationalization blog! The i18n team will use it to share news and projects on the current plans. Don’t forget to subscribe!
The i18n team has seen some changes recently, at the beginning of 2026 and we thought it was necessary to publicly announce this change and introduce ourselves a bit.
Before all, we want to greet and deeply thank all internationalization coordinators that participated in the project so far and made GNOME what is is now. We are a global software community of volunteers, leading the free software ecosystem and are accessible in many languages. With this, we cover almost everyone on Earth. Thank you very much Andre, Alexandre, Claude, Daniel, Gábor, Gil, Mario, Piotr, Petr, Kjartan and all the others. Without you this wouldn’t have been possible.
What is internationalization?
Internationalization, or i18n for short, is the act of ensuring software or documentation can be used in other languages, countries, and cultures. This means designing and developing applications in a way that removes barriers to localization, making it possible to adapt them without requiring significant engineering changes.
In practice, this involves separating user-facing text from the source code, so it can be translated easily, and ensuring that the software correctly handles different character sets and writing systems, including right-to-left scripts. It also means being mindful of cultural conventions such as date and time formats, number formatting, currencies, and units of measurement.
Internationalization goes beyond text. It includes accommodating differences in sorting rules (collation), keyboard input methods, plural forms, and even layout considerations, as translated text can vary significantly in length. Developers must also ensure that their software supports Unicode and uses libraries or frameworks that simplify handling these variations.
For the GNOME community, internationalization is a collaborative effort between developers, designers, and translators. By preparing software properly, the i18n team enables localization contributors to focus on producing high-quality translations, ensuring that GNOME is accessible and welcoming to users all around the world.
A new team
The team has reborn with new faces: Anders Jonsson, Rafael Fontenelle and Guillaume Bernard, respectively coordinators of the Swedish, Brazilian Portuguese and French team. Let’s introduce ourselves a bit…
Rafael (@rafaelff) is coordinator of the GNOME Brazilian Portuguese Team for more than 13 years after a short but intense period of contribution as translator. Besides GNOME, he contributes to the translation of Python Docs, R language, Fedora, TranslationProject (GNU projects, etc.) and others. Also maintains some packages in Arch Linux’s AUR.
Anders (@ajonsson) is coordinator of the GNOME Swedish Team for over 10 years, translator in the Swedish branch of the Translation Project, and a member of the GIMP Team with a focus on internationalization questions and testing.
Guillaume (@gbernard) is coordinator of the GNOME French Team since this year after 14 years of contributions, first as a translator, reviewer and after a few years, he has been involved in submitting team’s translations. He is the maintainer of GNOME Damnes Lies, our translation platform since 2020. He took this responsibility after years of dedication from Claude. Thank you again for this mentorship!
Nine months ago, I had to field quite a few angry comments from folks who told me they intended to drop their GNOME Foundation memberships in the wake of confusing and opaque board behaviour. I say to you now what I told each of them back in September:
Stay and fight.
The GNOME Foundation saw a much needed — and long overdue — changing of the guard back in August of 2025. In the past 12 months, the Foundation has finally made the improvements it should have been making over the past decade:
2025-05-09 – GNOME’s infra team had its first management review — it was spotless.
2025-05-16 – Foundation Reports begin in earnest as a first small step toward a transparent GNOME Foundation. We begin the hunt for a new Treasurer.
2025-05-23 – We started a Foundation Handbook to match handbook.gnome.org. (This has since migrated to a wiki.) We started moving all the Foundation’s documents into a central location. Project management began at the Foundation for the first time ever.
2025-05-28 – The Foundation publicly acknowledged that attacks on our Matrix servers, using illegal images, constitute crimes.
2025-06-06 – Both donate.gnome.org and (later) fellowship.gnome.org are pitched and accepted by the board. We brought on Deepa Venkatraman as Treasurer. Bart Piotrowski set up vault.gnome.org for passwords.
2025-06-14 – Andrea Veri completed the transition to donated AWS resources for GNOME infra.
2025-06-20 – donate.gnome.org is released, thanks to the hard work of Bart, Sam Hewitt, and Jakub Steiner.
2025-06-26 – The “Donate Less” campaign begins, in anticipation of the outbound program that would become fellowship.gnome.org.
2025-07-05 – The concept of fellowship.gnome.org goes public. Work on the corresponding donate.gnome.org shell notification starts. We tightened fiscal controls. We added redundancy to all our financial, legal, and operational processes. We interviewed a pipeline of candidates and selected Ignacy Kuchciński to complete the work under the Digital Wellbeing grant.
2025-07-12 – We invited postmarketOS to the Advisory Board.
2025-07-21 – We started stabilizing the GNOME Foundation’s finances for the long term by redefining the Board Reserve and taking a hard look at balancing year-on-year (annual recurring) revenue and expenses. We added the first-ever redundant signatories on bank accounts.
2025-08-08 – We created a shared online space for Advisory Board members to collaborate.
2025-09-12 – Deepa’s budget process is “the best the Foundation has ever had,” according to multiple directors.
2025-10-10 – Digital Wellbeing is delivered. The Foundation gets a much-needed credit card policy.
2025-10-24 – A new Finance Advisor arrives. (An important role at a 501c3.)
2025-11-28 – The budget is balanced. More importantly, the budget report contains the commitment to balancing recurring expenses and recurring revenue, continuously.
2025-12-19 – Deepa joins as a full director and remains Treasurer.
2026-01-09 – A new automated accounts payable and accounts receivable system is installed.
2026-03-20 – Financial reporting moves from quarterly to monthly.
2026-04-17 – The Fellowship Program begins! Users’ donations come full-circle: a percentage of every donation now goes directly to developers.
2026-05-15 – Finances are on-target. The Foundation opens a position for Finance Director.
2026-05-29 – Four old finance platforms are retired as the finances of the Foundation are automated and simplified. The Foundation introduces a Concern Escalation Policy: if members feel that directors or staff are abusing their positions with policy violations, illegal activity, discrimination, or conflicted behaviour, they’re provided the reassurance that they can blow the whistle without risk of retaliation.
That’s a lot for one little nonprofit. But this is the beginning of GNOME Foundation 2.0, not the end. The work must continue and there is still plenty to be done.
If you let your membership expire in recent years, get it back. If you are thinking of leaving, don’t. And if you are thinking of running for board elections, run.
The GNOME Foundation is the healthiest it’s ever been. It’s reducing costs and focusing on its actual mission: GNOME. The excellence demanded of GNOME hackers is now demanded of the Foundation, too. You can be a part of continuing that trajectory.
Development of a new text editor or Integrated Development Environment (IDE)
based on the libgedit.
Code maintenance.
Training.
Support.
Creation of Long-Term Support (LTS) versions.
Developer Experience (DX) guidance.
[…] Come with your own ideas to collaborate with the gedit project.
Target audience
Operating System / Linux distributions: for your installed-by-default text
editor.
GTK-based desktop environments: to maintain a text editor or IDE, and to
adhere to your Human Interface Guidelines (HIG).
Scientific sector: to build developer tools.
Education sector: to build easy-to-learn developer tools.
New programming languages / development platforms: you're designing and
implementing a new programming language, and you need developer tools for
your users.
Older programming languages users: you're a big organization and you have a
lot of legacy code. You want better developer tools to be more productive.
Markup or domain-specific languages: to better promote your language, you
would like first-class support for it.
The libgedit shared libraries
gedit is not just a general-purpose text editor application, there is a
“libgedit” underneath!
A lot of gedit features are implemented as re-usable code, as a set of shared
libraries. So new apps - text editors and IDEs alike - can be built on top.
There is an ongoing effort from the gedit project to make more code re-usable.
An example of an IDE based on the libgedit is
Enter TeX.
The libgedit currently targets GTK 3. If you want to develop with
GTK 4, there is the
GtkSourceView
library (but it doesn't contain all the libgedit features). Another
possibility is to first port the libgedit to GTK 4.
The plugin system
gedit has a powerful plugin system mechanism, to extend the application. You
can leverage it for prototyping additional features, or as the final solution
that requires less efforts than creating a new specialized text editor.
You can also combine the best of both approaches:
First implement a feature that is based on libgedit.
Then wrap your feature in a gedit plugin so it can readily be used.
Finally, as an option, create a custom text editor app, re-using the same
implementation of your feature(s), integrating everything well together.
Other developer tools
The text editor part is essential, it is the central feature of an IDE. But
other developer tools can be developed as well.
For instance,
Devhelp
can be used for browsing and searching API documentation. Almost all its code
is re-usable; like for gedit, there is a libdevhelp toolkit under the hood.
Advice to not start from scratch
A little advice: please don't create a new text editor or IDE from scratch,
base your work on existing, high-level libraries like the libgedit. Even if it
looks simple on paper, developing a feature-full text editor is a lot
of work.
Use the libgedit from your preferred programming language
libgedit and GTK can be used from a wide range of programming languages, and
the support for additional languages can be implemented too. This is thanks to
GObject Introspection. See the list of
language bindings
for the GTK project.
Open-source or proprietary software
libgedit and GTK are licensed under the
GNU Lesser General Public License
(LGPL), which allows to develop proprietary software on top.
gedit plugins need to be distributed as free/libre software, under
the GPL license.
Who to collaborate with
Sébastien Wilmet,
the current maintainer and main developer of gedit and libgedit.
You? If you're or work for a consultancy company specialized in
GNOME, GLib or GTK, and want to be part of this project, don't hesitate to
get in touch!
Papers 50.2 and 49.7 were released this week with a (unusually high) number of bug fixes. Notably, several fractional scaling issues should be fixed thanks to the work of balooii, including both performance and display issues.
The upcoming version of Libadwaita now supports binding properties to CSS Classes and vice versa, making it easier to dynamically toggle CSS classes on widgets. This will be available in the upcoming GNOME release.
We published a blog post with update from the Circle Committee. We are addressing our current review backlog, our new AI policy, new handling of submission issues, earlier reminders about outdated runtimes on Flathub, and new benefits for Circle projects.
A new version of Exercise Timer was released! This is a quality-of-life update for this simple app for high intensity interval training. Most notably, the training page has been updated with a custom progress indicator. Minor updates include an Undo option for deleted trainings and an update to the latest GNOME runtime.
Get Exercise Timer from Flathub: https://flathub.org/en/apps/xyz.safeworlds.hiit
If you find any issues or regressions compared to the current System Monitor app, please report them in the Resources issue tracker. The potential inclusion into Core is tracked under App Organization. Distributions are encouraged to package the app and report any issues they foresee with a possible transition to Resources.
Congrats and big thanks to nokyan for writing and maintaining this app!
This week I released Java-GI 1.0.0-RC1. As the version number suggests, this is the first step towards a “stable” release. With multiple cool apps already on Flathub, like Speed of Sound and Subsound, and several more in active development, I figured it’s time for backward compatibility and API stability.
Notable improvements in this release are:
Support for non-UTF8-encoded filenames
Specialized exception types (deriving from GErrorException)
Improved Windows support
Bug fixes around memory management, class instantiation and nullability annotations.
Always wanted to build a GNOME app, using your Java (or other JVM language) skills? Give Java-GI a try!
Nucleus version 3 is released! Nucleus is a periodic table app.
This update brings a theoretical indicator to Ununennium, as well as some updated properties for Ununennium. French and Italian translations were added and the app was updated to the GNOME 50 runtime as well.
I want to thank everyone who opened a request or sponsored the project. All this time, the main features I shipped came from user requests. The most important ones: broadcast, a keyboard passthrough mode that disables the app shortcuts so they go straight to the remote desktop, Windows scripts, and a wizard for an easy start with predefined custom commands. I use all of this every day and it genuinely makes life simpler - which was the whole idea behind the project.
Gitte, a simple Git client for GNOME built with GTK4, libadwaita and Relm4, just got its 0.5.0 release! 🎉
The headline feature this time is commit and tag signing. Gitte now supports GPG, X.509 and SSH signing, validates signatures right in the commit log, and ships a dedicated “Signing status” window that walks you through setting everything up. Encrypted signing keys are handled via a new gitte-askpass helper, and every relevant dialog (commit, merge, revert, create tag, …) gets a per-action override switch so you can decide whether to sign on a case-by-case basis. The default respects the repository configuration.
On top of that, the commit message, revert and create tag dialogs were overhauled, dialogs now carry descriptive subtitles for better discoverability, and there’s a new Ctrl+O / Cmd+O shortcut to open a repository. Under the hood Gitte moved to the new git2 API, switched from polling to IO-event-based refreshes, and gained a Cornish translation (thanks to Flynn Peck!).
Welcome to another update about everything that’s been happening at the GNOME Foundation. As has become my custom, this post covers a two week period, this time from 18 May until today, 29 May. As usual the Foundation continues to be busy, with events, infra, governance, and accounting activities all happening simultaneously. Read on for more information!
Events
Linux App Summit (LAS) 2026 was held in Berlin over the 16-17 May weekend. I’ve heard quite a few reports now, and everyone seemed extremely positive about the event. Kristi wrote a nice summary if you want more details.
The GNOME Foundation had two team members on the ground helping with running the event, which we co-organize with KDE. I’d like to take this opportunity to give a big thank you to the event’s sponsors: openSUSE, Tuxedo, Nextcould and Codethink. This event wouldn’t be possible without your support.
In addition to LAS, work is continuing on arrangements for GUADEC 2026. The deadline for travel sponsorship applications has now passed, and the Travel Committee has met to decide who will be funded. Notifications will be going out soon.
Board Elections
The process is officially underway for this year’s Board elections. Terms on our Board of Directors are two years in length, and each year half the board seats are open for election. This year we have five seats being contested.
The 2026 election has a slightly different schedule to previous years. In the past, there was no gap between the candidacy period, in which people can announce their intention to run, and the voting period. This meant that there was little opportunity for last-minute candidates to participate in discussion prior to voting taking place.
To address this, we’ve added a one week discussion period to the schedule, which will run between 8 and 15 June, between the candidacy and voting periods. This will hopefully give us opportunity to have more structured and inclusive debate amongst the candidates. We are still figuring out what that might look like, so if people have ideas or want to help, let me know in the comments.
GNOME Fellowship
We are currently in the very final stages of confirming and announcing the successful candidates for the inaugural round of the Foundation’s Fellowship program. Expect an announcement very soon.
Got a Concern?
Last week we introduced a new policy for handling of concerns about the Foundation, which is now part of the project handbook.
The new policy covers how to report concerns about people who are working for the Foundation, either in a paid or voluntary capacity. It also covers more general concerns about the Foundation.
The main goals of the policy are to:
have a documented reporting procedure for those who have concerns relating to the Foundation
clarify how concerns will be responded to
provide reassurance for those reporting concerns, including that concern reports are welcome, are taken seriously, and will never result in retaliation
We hope that this policy will make it clear how you can inform us of a concern if you have one. We also want to emphasise that we want to hear concerns, so we can address them. Please do use the new reporting procedure.
Finance/Accounting
Work has continued on the finance and accounting operation over the past two weeks. Highlights include:
Our transition to a monthly rather than quarterly close reached a significant milestone this week, with the completion of our April finance reports within three weeks of the previous month end. This is probably the fastest ever turnaround for our finance operation, and is a huge win for us in being able to effectively manage our finances.
Following input from the board, corrections have now been sent to the accountants for our audit and annual tax filing.
Finally, as I mentioned in my last update, we are in the process of retiring a number of finance platforms as we consolidate and streamline our operation. This week saw another platform retired, which brings the total number of eliminated platforms to four.
Infrastructure
Our infrastructure experienced a DDoS attack last weekend, which Bart and Andrea have been dealing with. Thankfully it seems that services weren’t too badly affected, and we’ve already improved our protection against similar attacks in the future.
We want to share some updates and future plans from the GNOME Circle Committee with you. The Circle Committee is responsible for reviewing and accepting apps and other components into GNOME Circle as well as maintaining the review criteria.
The biggest issue for us, and for maintainers who submitted apps, has been the considerable backlog of unreviewed apps. There are cases where apps have been waiting for feedback for years. We are very sorry for those who have been affected by this. We are trying to finally address this issue now.
AI Policy
As a precaution, we have adopted the AI policy that already applies to GNOME Shell extensions. With the rise of low-quality machine-generated software, there is a risk that GNOME Circle could be overwhelmed by new submissions of this nature, further clogging the review queue.
This policy is a starting point, and for now, it will only be enforced on new submissions. We are open to receiving feedback on the AI policy from existing Circle maintainers. In a quick survey, 62% of Circle maintainers reported not using LLMs at all, 34% reported using them for small questions or snippets, and only 3% are taking larger parts of code from them. No maintainer selected the option for no longer writing code themselves.
Meanwhile, Flathub has also tightened their AI policy. Since GNOME Circle apps are usually expected to be published on Flathub, this policy indirectly applies as well.
Closing New Submissions
To make sure that we are focusing on submissions that haven’t been addressed for a long time, we will stop accepting new submissions for now. We will reopen submissions when we have made a considerable dent in our backlog.
New Handling of Issues
This is mostly a technical detail, but from now on, we will close issues that are awaiting feedback from the maintainer. When providing an answer, maintainers should just reopen the issue. This gives us a better overview of which issues are awaiting further processing by us.
Early Reminder About the Use of Outdated SDKs
Every GNOME release cycle, we spend a considerable amount of time on getting GNOME Circle apps to update their SDK on Flathub before the SDK becomes unmaintained. To avoid this in the future, we will try something new: We will remind maintainers much earlier that they are using an outdated SDK – months before it reaches EOL, rather than just a few weeks. This means apps using the GNOME 49 SDK will soon be part of an automatically generated reminder issue. To get the reminder, please make sure that you have provided a GNOME GitLab account in your project’s .doap file.
Growing Benefits
We are steadily growing the benefits for GNOME Circle apps and their maintainers. Among the benefits that were added are:
Having a student work on your project for Google Summer of Code or Outreachy.
Of course, all contributors and maintainers of GNOME Circle projects are still eligible for GNOME Foundation membership. You can check our full list of benefits.
Call for Reviewers
We are in constant need of more reviewers in the Circle Committee. If you have already reached out to us, and we haven’t gotten back to you, please give it another shot. You can find us in #circle:gnome.org.
Here are the noteworthy news about the
gedit
and
Enter TeX
text editors. (Some sections are a bit technical).
A single package for gedit and its core plugins
Before, users needed to remember to install the
gedit-plugins package
in order to benefit from additional plugins such as Word Completion
or Bookmarks.
Now, all core - or “official” - plugins are part of the
main gedit module.
So, Word Completion, Bookmarks and others have been copied
into the gedit module, and gedit-plugins is now empty/archived.
Note that there are also third-party plugins which are available in
other repositories.
The re-implementation of document loading continues
It's now a recurrent topic. Progress has been made, but more work is necessary
to fully replace the GtkSourceFileLoader internals.
This time, here is a general description of the methodologies used along with
the current state of affairs, without entering into too much technical
details. If you're an experienced developer, it'll most probably ring a bell
to you :-)
The typical “divide and conquer” methodology is followed: the problem is
divided into several smaller ones. The sub-problems are solved individually,
providing utility functions and small classes. Then things are built on top,
with several layers, gradually solving bigger and bigger problems.
It all looks nice, except that an iterative process is also needed, to revise
the solutions already built because of unforeseen problems (it happens all the
time in computer science).
The current progress status is that some utilities need to be
reworked in order to be a better fit for the above components, and also to fix
a couple of unforeseen problems. Thankfully it's not a “back to the drawing
board” situation, as the utilities that lie at the bottom layers don't need
any change.
For the curious reader, here are the two unforeseen problems encountered:
iconv() can output nul bytes even for UTF-8 as the target
charset. Embedded nuls are not valid UTF-8 according to
g_utf8_validate(). So an additional pass of validation is
necessary, to escape invalid UTF-8 bytes.
With the new implementation, at most two copies of the whole file
content needs to be present in memory. I stumbled across a corner case where
three copies would be necessary, so it needs to be fixed. The three copies
were: (1) the content containing a single chunk (or at least a big chunk) of
invalid bytes, (2) the invalid chunk escaped, and (3) the content as
inserted into the GtkTextBuffer.
It's just a matter of escaping the invalid bytes directly / at a different
place.
(Note that this is a concern only for the work-in-progress branch; current
stable versions of gedit doesn't suffer from that issue).
Enter TeX goodness
The Projects feature has been re-implemented in a better way (mostly
under-the-hood changes).
The module is again on GNOME Damned Lies, so there are many translation
updates. Thank you, all translators around the globe! In the past I
contributed to the French translation, and I directly saw that GNOME
translation teams do very high quality work. So, thanks again :) !
Other stuff
As usual there are some other work items fixed or where progress has been
made. Among others:
The comment/uncomment actions have been fine-tuned.
A prototype has been created in order to improve the main “sandwich” menu in
gedit.
Code re-use and Business-to-Business opportunities
There is a lot of potential with the libgedit modules (or also with
GtkSourceView for GTK 4), to grow the project into something like the
GStreamer multimedia project (but at a smaller scale) where there is a lot of
B2B
activity with consultancy companies helping to create new products for other
businesses.
Especially with libgedit-tepl, the name “Text editor product line” means that
it's possible to create other text editors or IDEs products (more easily).
An example that I have in mind is Arduino and its specialized IDE. But there
are new programming languages or development platforms that pop up regularly,
so there are opportunities to collaborate with them and develop great
developer tools for them.
I'll talk about it more in the future, but if you read this and are interested
to develop such a business model for gedit and/or GtkSourceView,
talk to me!
Back in March, I started to tackle this MR for GNOME Crosswords. It allowed me to learn a lot about navigating the codebase, adhere to naming conventions, and collaborating with others involved in Crosswords.
Crosswords Editor features a section for users to input metadata, such as author name, puzzle URL, and date. Originally, the MR was to convert and store the user’s manually typed date to ISO8601. This means storing the entered date in the form YYYY-MM-DD, while the user just needs to type in a date using the GDate struct.
Upon code review, the scope expanded to move from manual typing to selecting a date on a drop-down GTK calendar widget. I was able to implement this concept by following the architecture of an existing widget (edit-shapebg.c/h/blp) which placed shapes on the crossword puzzle. Then I connected the new calendar widget to the metadata so the chosen date from the now drop-down calendar will be stored in ISO8601 format yet display respective to the locale of the person using g_date_strftime.
Project Start
With the start of GSoC, I have spent a lot of time this week reading, white-boarding, and began setting up some structure to adding vocab-style crosswords to the libipuz library.
The basic constraints and workflow that I mapped are:
A user can input up to 30 words (strings), with a 25 character capacity.
Upon hitting enter or a button to generate, a Depth-First Search (DFS) algorithm starts to piece the words together on a blank grid. The algorithm can backtrack to tear apart words and rearrange them until a valid graph is formed
I’m going with DFS at the moment to prioritize the longest-to-shortest word seeding the graph in order to increase possibilities of connections
Every time the user generates the graph, it will be treated like its own isolated creation, recalculating the layout from scratch to allow for cleaner undo/redo states and easier addition/deletion of words
I don’t want words being placed right next to each other unless it was intentional for a 2+ word answer, which each word would be separated by thick lines
Words should only connect through intersections
The frontend does not mutate the grid but will be able to pass actions to the backend and return a new state
For instance: say a user starts off their grid by typing “CAT” and then “DOG.” These words don’t have common characters, so they cannot be connected. However, instead of erasing the user’s desire to incorporate “DOG,” the string gets tucked away and saved in a GArray
Now our user types and enters “CADET.” The UI takes our list and passes it to the algorithm to start chewing on and deal onto the board anew. This time, allowing for “CAT,” “DOG,” and “CADET” to appear, without the user having to retype “DOG”
I went back and forth with myself on how to represent the puzzle’s state in memory and disk. To write a custom GObject, or not.
The Argument Against: Standard IpuzCrossword objects have a handle on grids and JSON saving, and one could write a new function that takes an array of strings and return a standard IpuzCrossword.
The Argument For: Revisiting the “CAT,” “DOG,” and “CADET” conundrum; say an educator is creating a puzzle for his/her/their class, and they have just one word out of 20 that don’t connect to current existing possibilities of intersecting words. If they save their puzzle, it transforms to a standard IpuzCrossword, and the floating word are permanently abandoned.
At the current moment, I want the puzzle to be its own vocab-style workspace. Therefore this would allow for the floating word to instead sit in the sidebar and wait for further instruction for a future inserted word that works, or to get deleted.
Of course, as I gain more insight about the library, states, and optimization within the codebase, this approach is subject to refinement.
With the release of 4.23.1, GTK’s renderer will come with a new feature that we’ve called snapping.
How does it work?
Snapping is enabled by calling gtk_snapshot_set_snap(). If enabled, it will slightly adjust the placement of rectangles when drawing so that they align with the pixel grid and don’t cover half a pixel.
Content drawn with GTK is scaled automatically by the desktop’s scale factor. But with the arrival of native fractional scaling, it is no longer possible to know if content is aligned to the pixel grid.
While that is usually not a problem, there are a few cases where it is:
Sprite grids
Gameeky is a learning game that plays on a grid. Unfortunately, on a fractionally scaled machine, it can end up looking like this:
Once those sprites are snapped to the pixel grid by rounding to the nearest pixel, the same image looks like this
Sharp images
Often Applications want to display images in a way that matches the pixels of the image 1:1 with pixels of the monitor. This is a challenge on a fractionally scaled display. Not only is it important to get the scale factor right, it’s also important to align the pixels correctly, or they will appear slightly blurry.
The use case is not just image viewers that want to offer a 1:1 zoom factor, but all applications that redirect drawing, from game emulators to viewers like Boxes or Connections.
Hardware optimizations
And finally, there are optimizations like graphics offload that rely on content being aligned to the pixel grid or the hardware cannot optimize them. So it is important to snap content to the pixel grid for those cases.
Why don’t we just always snap to the grid?
There is one big problem with automatic snapping: smoothness. Because snapping only works on full pixels, doing slow animations causes content to jump from one pixel to the next. And that causes jitter.
The main situation where one can see this is smooth scrolling, like in this example:
Summary
The next GTK release will offer a new way to tame the effects of fractional scaling. Please try it out and let us know how it works!
While working on my GSoC project (rewriting the Pitivi timeline in Rust), I ran into an issue getting precise UI ticks that map to the
absolute nanosecond timestamps of the video frames. Initially I hardcoded NTSC fractional math (24000/1001) to calculate the boundaries of frames.
This led to issues with truncated timestamps, and had a glaring issue with other framerates (like 30fps). I needed a more robust solution that could handle any framerate and provide accurate tick positions.
I assumed that I could extract the framerate directly from ges::Timeline, however there is no direct getter in the Rust bindings. After some digging, I discovered that the framerate is actually stored in the gst::Caps of the timeline's video stream as a gst::Fraction.
My Approach
The steps I used:
Enumerate the timeline tracks (timeline.tracks())
Filter for the video track (checking ges::TrackType::VIDEO)
Read the track's restriction_caps
Extract the gst::Fraction
My helper
I wrote a helper function to extract the framerate from the timeline:
pub fn get_fps(&self, timeline: &ges::Timeline) -> Option<(i128, i128)> {
timeline
.tracks()
.into_iter()
.find(|track| track.track_type().contains(ges::TrackType::VIDEO))
.and_then(|track| {
let caps = track.restriction_caps().or_else(|| track.caps())?;
let structure = caps.structure(0)?;
let fps = structure.get::<gst::Fraction>("framerate").ok()?;
// Extract the safe numerator and denominator
Some((fps.numer() as i128, fps.denom() as i128))
})
}
// ... inside the timeline injection logic:
if let Some((fps_num, fps_denom)) = self.get_fps(timeline) {
self.fps_num.set(fps_num.max(1) as i32);
self.fps_denom.set(fps_denom.max(1) as i32);
} else {
// Default to 23.976 if we can't find a valid framerate caps
self.fps_num.set(24_000);
self.fps_denom.set(1_001);
}
I make some assumptions here, such as only one video track existing, and that the framerate is always present in the caps. This solution made the tick spacing and labels line up with the timeline’s actual frame boundaries at any framerate.
I do not always want to know what time it is. This is a slightly awkward position for someone who keeps making clocks, but there we are. Quite often the useful answer is not 17:42. It is “quarter to six”, “nearly lunch” or “you should probably start thinking about leaving”. The precise time is useful when catching trains, baking things and joining calls; the rest of the time it can be a bit much.
So I have been working on fuzzy time for a while. The first version I made was for the Pebble, which remains one of those devices that makes later technology feel slightly ashamed of itself. A small always-on screen, good battery life, physical buttons and just enough personality. It’s not tokyoflash after all.
The Android version is quite a funny object internally. It is a Watch Face Format v2 face, so the APK has no app code:
android:hasCode="false"
The face itself is declarative XML. Since writing thirty-six thousand lines of watch face XML by hand would be a cry for help, there is a generator which writes the cases out from the same fuzzy time rules. For every hour and every five-minute bucket it emits the condition, text and separate interactive and ambient versions.
That sounds excessive until you look at the details; and then it still sounds excessive. There are lots of pernickety things that give this the correct GB locale to my ears. “Five Past Midnight” is a real phrase. 23:58 should say “Midnight”, and if the date is visible it should be tomorrow’s date. 11:58 should say “Noon”. “O’Clock” wants different spacing and weight from “Twenty-five To”. Ambient mode wants smaller, quieter text. A round watch face leaves less room than you think it does. The watch face has a few small choices rather than a settings cathedral: warm white, cool white, soft green, dim amber; system font or Arvo; optional radial complication slots above and below the text. The range complications are deliberately arcs around the edge rather than little widgets in the middle. They can show useful things, but they should not make the face stop being mostly words and calm black space.
The GNOME version is the same idea on a different surface. It finds the existing clock label, listens to the same wall clock, respects the existing “show date” and “show weekday” settings, and changes the text. I have wanted to build something like this for years, partly because of Emmanuele Bassi’s word clock extension. That extension was great, but not quite the thing I wanted, so eventually I got around to making my own.
One of the few design decisions left that I helped on in main GNOME (which is much better now) is that the shutdown and logout dialogue only updates its timing every so often. It could update every second; the computer is quite capable of counting. But it’s much more pleasant when the number doesn’t twitch constantly while you are trying to decide whether you meant to press the button.
You can build both projects from source. I may choose to distribute them in a more structured fashion in future. The Android one is a minimal Wear OS watch face, and the GNOME one is a normal Shell extension that currently supports GNOME Shell 45 to 50.
Hello Everyone! I am Shivam, I am currently pursing my engineering in Electronics. I have been selected for GSoC 2026 for the port of GNOME-Gitg from GTK 3 to GTK 4. I am starting this blog in order to document my journey of porting Gitg. I have been contributing in GNOME from several months and in awe with the supportive and helpful nature of the community.
Project
As many of you probably know, Gitg is still using GTK3, which means it misses out on a lot of the improvements and features that came with GTK4. The main goal of this project is to port Gitg from GTK3 to GTK4 and then gradually modernize the application.
The scope of the project itself is quite large, and that’s honestly one of the most exciting parts for me. Working on this port will help me understand the application interacts with different libraries and components behind the scenes.
At the same time, I hope that this work will help the new contributors like me easier to get started contributing to the various GNOME projects
Conclusive Goal
The final goal of this project is to get Gitg building and running completely with GTK4 dependencies. At the moment, the application still fails to compile, which is expected since many GTK3 APIs are still present throughout the codebase.A separate GTK4 branch already exists where parts of the migration work have been started, and several components have already been adapted to GTK4. This project will continue building on top of that existing effort and gradually move the remaining parts of the application to the newer toolkit.
I would also like to sincerely thank the contributor(s) who have worked on the GTK4 porting work earlier. Their efforts created the foundation for this project, and I’ll be continuing from the work they have already done.
Thank You For Reading!
PS:- I would also like to thank Alberto Fanjul for mentoring me in this project and Felipe Borges for this time and support.
