Planet GNOME

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:

org.gnome.desktop.interface color-scheme = 'prefer-dark'

At civil dawn it sets it back to:

org.gnome.desktop.interface color-scheme = 'default'

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.

static DexFuture * load_many_files (GPtrArray *files) { g_autoptr(DexTaskGroup) group = dex_task_group_new (0); g_autoptr(DexLimiter) limiter = dex_limiter_new (8); for (guint i = 0; i < files->len; i++) { GFile *file = g_ptr_array_index (files, i); dex_task_group_add (group, dex_limiter_run (limiter, NULL, 0, load_one_file, g_object_ref (file), g_object_unref)); } return dex_future_with_timeout_seconds (dex_task_group_close (group), 10); }

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-05 – First corporate sponsor.
• 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.

There has never been a more meaningful time to join the GNOME Foundation board.

 

This article is also available in the B2B Services section on the gedit website.

Several business-to-business services are possible around gedit:

• Development of a new plugin.
• 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 is in turn based on the very flexible GTK graphical toolkit.

GTK 3 or GTK 4

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!

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:

https://blogs.gnome.org/gtk/files/2026/04/jitter.webm 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 current versions are Fuzzy Time GB, a Wear OS watch face, and Fuzzy Clock GB, a GNOME Shell extension.

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.