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.

New version on the Microsoft Store

gedit 50.0 is now also available on Windows .

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 !

Ongoing Work

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

About Me

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.

I made another weird side project while unemployed. In fact I’ve wanted it for a while but once I learned that “Rebonjour” is the word for “hello again” I just had to finish the library.

librebonjour is an asynchronous DNS-SD and mDNS client library for GLib applications. Or, more practically, it is a small GObject API over the two local service-discovery providers you are likely to find on a Linux system: Avahi and systemd-resolved.

It does not link against either of them. It only talks to them over D-Bus.

The reason for that is mostly boring, which is usually where the useful things are. Applications should not need to care if a machine has Avahi running, or if it is using systemd-resolved for mDNS. They should be able to discover a service, resolve it, maybe advertise something, and get on with whatever they were actually trying to do.

So RebonjourClient selects a backend internally. If org.freedesktop.Avahi is available on the system bus, it uses Avahi. If not, it falls back to systemd-resolved’s org.freedesktop.resolve1 API. If neither is around, availability checks fail like you would expect.

The public API stays the same either way.

What It Does

There are three common things I wanted to make pleasant.

First, one-shot discovery. Ask for the service types in local , ask for instances of something like _ipp._tcp , then resolve one of those instances into addresses and TXT metadata.

Second, browser-style discovery. A RebonjourBrowser owns a stable GListModel of RebonjourService objects. That fits nicely into GTK code because the model object can stay the same while the contents change underneath it.

Third, registration. You can describe a local service with RebonjourServiceDescription , register it, and keep the returned RebonjourRegistration alive for as long as the service should be advertised.

Resolving a service gives you a RebonjourResolvedService . That contains the SRV result, TXT data, priority, weight, and a model of RebonjourEndpoint objects. The endpoints hold the GSocketAddress you would actually use to connect.

Why Two Backends

Avahi is the nicer backend for browsing. Its D-Bus API gives you long-lived browser objects and emits signals when services appear and disappear. That maps very naturally to GListModel changes.

systemd-resolved is different. It has useful DNS-SD and mDNS operations over D-Bus, but the browsing side is lookup-based. That means you can ask what is there, but you do not get the same live add/remove signal stream that Avahi provides.

I did not want applications to have to care about that distinction unless they really want to. So the browser has auto-refresh and refresh-interval properties. With Avahi, auto-refresh is effectively harmless because the model is already live. With systemd-resolved, it starts an internal refresh loop and updates the model for you.

It is not magic. It is just putting the backend-shaped unpleasantness in one place so application code can stay boring.

Asynchronous with libdex

The whole thing is built on libdex . Anything that might touch D-Bus or the network returns a DexFuture .

That means construction, availability checks, service-type lookup, instance lookup, resolving, registration, browser refresh, and unregistering are all future-based. If you are already writing fiber-style code with libdex, the API fits into that directly:

g_autoptr(RebonjourClient) client = NULL;
g_autoptr(GListModel) services = NULL;
g_autoptr(GError) error = NULL;

if (!(client = dex_await_object (rebonjour_client_new (), &error)))
  g_error ("%s", error->message);

services = dex_await_object (rebonjour_client_lookup_instances (client,
                                                                0,
                                                                "_ipp._tcp",
                                                                NULL,
                                                                REBONJOUR_LOOKUP_FLAGS_NONE),
                             &error);

The 0 there means any interface. Passing NULL for the domain uses local . The common case should not require looking up interface indexes which I’m pretty sure most people reading this have never even done before.

Advertising

Advertising is where things get more system-policy-oriented.

With Avahi, registration goes through Avahi’s D-Bus API. With systemd-resolved, registration uses RegisterService and UnregisterService , which are polkit-protected. Also, resolved needs full mDNS enabled with MulticastDNS=yes ; MulticastDNS=resolve is enough to browse and resolve, but not enough to respond as a service.

So librebonjour can expose one API for registration, but it cannot make host policy disappear. Applications still need to handle authorization failure, missing mDNS responder support, sandbox boundaries, or whatever policy the system administrator has decided is appropriate.

That seems like the right way to demarcate things. The library should hide the provider mechanics, not the permissions of the platform.

Why

Mostly because I wanted this to exist.

DNS-SD is handy. Local-network service discovery is still useful. But using it from a GLib application means either caring too much about the provider or writing just enough glue that every application gets to have its own slightly different version of the same code.

And even worse is having to bundle things to build projects like Avahi for Flatpak when you only use the library which calls into D-Bus anyway.

This is not a grand platform initiative. It is not something I am employed to maintain. So you know, use wisely.

• Early interview & job offer for a support role, catch up with Anna, sync with Dave, catch up with a partner, 1:1 with Naomi.
• Sync with Thorsten, Skyler, Pedro, poked at slides.
• Dave, Emily, Jake, Pete & Eli arrived - played in the garden somewhat, enjoyed company, tried to cook a meal; caught up happily after a decade+ gap. Bed early.

Update on what happened across the GNOME project in the week from May 15 to May 22.

Third Party Projects

Alexander Vanhee reports

Last Saturday, Bazaar was updated to 0.8.0 with the ability to install .flatpak bundles. We created a fancy new dialog so people can better understand what happens when they install one. We also added the ability to remove app caches directly from within the sizes dialog and reworked the app install animations.

Feel free to leave your feedback on the GitHub repo !

Luiggi R. Cardoso says

Draft v1.3 has been released!

You know those text snippets you need to save, that quick idea you want to write down, or a link you need to hold onto but don’t want to open a heavy app for? This is Draft.

This new version brings:

• Estonian and Brazilian Portuguese Translations (thanks to our community!).
• Keyboard shortcuts for formatting options.
• Under-the-hood performance fixes and minimal spellchecking support.

Download it on Flathub | Contribute on GitLab | Help with Translations

Bilal Elmoussaoui reports

I have released a new version of gobject-linter . The release includes:

• Parse custom types using g_type_register_static directly
• Add a new unused vfuncs rule
• Add a new missing_g_begin_decls rule
• Generate fixes for g_object_virtual_methods_chain_up , missing_autoptr_cleanup
• gi_missing_since rule now validates that enum members don’t include inlined Since: annotations
• Improvements to various existing rules

francescocaracciolo says

Newelle 1.4.0 Released! Newelle (AI Assistant and Agent for Gnome) has received a new major update!

🔗 Added Interfaces: alternative way external applications can interact with Newelle! Featuring Telegram support, APIs, WebUI and more!

👷 Support for directly download pre-compiled binaries for llama.cpp instead of compiling

🔐 Better Command permissions

💬 Better Prompt Editing

📝 Better Font rendering and customization

Get it on Flathub: https://flathub.org/it/apps/io.github.qwersyk.Newelle

Wladimir Palant reports

Gnome Commander 2.0 has been released! Many changes:

• Rewritten in Rust, with better performance and stability.
• Added embedded terminal to display output of commands run in Gnome Commander.
• Redesigned Quick Search can now be used to filter the file list as well.
• Far better search performance and many more improvements to the Search dialog.
• Consistent handling of file encodings in the internal viewer along with lots of other improvements.
• Improved accessibility of the application, screen readers should be able to recognize the context everywhere now.
• More tab state is being restored on restart – selected file, column sizes and ordering, hidden columns.
• Tons of fixed bugs and more .

Anil reports

Codd 0.5.0 has been released!

Since the first Flathub release, several new features and improvements have been added:

• Secure password storage using the system keyring
• SQL script generation for tables
• A Table Inspector for inspecting columns, data types, defaults, constraints, indexes, foreign keys and triggers
• Additional table action options

Spanish translations have also been added recently, thanks to fvtronics.

Codd is a lightweight PostgreSQL client for GNOME, available on Flathub. Feedback, bug reports, and feature ideas from PostgreSQL users are very welcome.

Get it on Flathub or check out the source code .

Gitte ↗

A simple Git GUI for GNOME

Christian announces

🎉 Gitte 0.4.0 released!

Gitte is a GTK4/libadwaita Git interface for the GNOME desktop, written in Rust.

This version introduces a mainline concept: you can now mark a branch as your project’s mainline and use it as a reference for merged-checks, filtering, and a brand-new “Sync with mainline” action that rebases your branch and fast-forwards it in one step. The commit log also gained a filter to only show commits not yet in the mainline.

Working with changes got more flexible: you can now revert commits straight from Gitte, partially stage untracked files, toggle an additive selection mode in the changed files list, and ignore whitespace in diffs. Staging and unstaging are now available via context menu, Enter, and double-click, and you can create a branch directly from any commit in the log.

The UI received a lot of polish. The push and pull dialogs are now visually distinguishable and show their targets in tooltips, “ahead/behind” is rendered as text instead of arrows, popovers no longer claim unnecessary width, and several diff styling glitches are gone. Checking out a branch now creates a detached HEAD, with switching as a separate, explicit action.

This release also brings a long list of fixes around macOS shutdown and keyboard shortcuts, keyboard navigation, files without trailing newlines, now respects fetch.prune = true in the pull dialog, and various small papercuts.

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

Fractal ↗

Matrix messaging app for GNOME written in Rust.

Kévin Commaille reports

Here comes Fractal 14.rc. This release candidate comes with a fair amount of quality of life improvements:

• The sidebar room filter has been improved: Enter goes to first room result, and there’s an empty state when no results match the term.
• The performance of the room list has also been improved, it should be mostly noticeable for accounts that have joined a lot of rooms.
• Informative events ( Unable to decrypt , server notices…) are now styled differently to reflect their special nature and differentiate them from regular text messages that anyone can send.
• Calls are rendered in the timeline and incoming calls trigger a notification. We still don’t support calls, but at least now you know when someone is calling and can open another client to answer.

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

It is available to install via Flathub Beta, see the instructions in our README .

As the version implies, it should be mostly stable and we expect to only include minor improvements until the release of Fractal 14.

If you want to join the fun, you can try to fix one of our newcomers issues . We are always looking for new contributors!

Miscellaneous

Damned Lies ↗

The internal application to manage localization of GNOME & friends modules

Guillaume Bernard says

GNOME Damned Lies has received a few improvements this week! Focusing on the issues identified for the next GNOME 51 release, we implemented the auto-closing feature for translations pushed through a merge request. This way, a background job regularly checks the status of the merge request (GitLab instances and Github.com are supported) to auto-close workflows.

We also updated the look and feel of the vertimus workflows to use more native Boostrap base style and removed the custom CSS that was used to render the action history, easing the maintenance.

In addition to that, we added support for Codeberg.org projects. Only direct pushes are supported at this time, because we need to implement the plugin to open/check merge requests on Forgejo software. We are on our way to also support Freedesktop’s GitLab instance soon.

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!