fidzu : gnome

## Bureaucracy

You may have noted that there wasn't a Foundation Update last week. This is because almost everything that has been happening at the Foundation lately falls under the banner of "bureaucracy" and/or "administration" and there isn't much to say about either of those topics publicly.

Also, last Friday was GNOME's 28th birthday and no one wants to hear about paper-shuffling on their birthday.

I'm sorry to say there isn't much to add this week, either. But I hope you did all take a moment to reflect on the nearly-three-decades-of-work that's gone into GNOME last week.

Happy Belated Birthday, Computer.

23 Aug 2025 3:48am GMT

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

GNOME Core Apps and Libraries

Glycin ↗

Sandboxed and extendable image loading and editing.

Sophie (she/her) announces

Glycin 2.0.beta.3 has been released. Among the important changes are fixes for thumbnailers not working in certain configurations, loading speed for JPEG XL having been dramatically improved, fixed sandbox rules that broke image loading on some systems, and fixed editing for some JPEG images saved in progressive mode.

GNOME Circle Apps and Libraries

Déjà Dup Backups ↗

A simple backup tool.

Michael Terry announces

Déjà Dup 49.beta was released! It just fixes a few small bugs and uses the new libadwaita shortcuts dialog.

But if you haven't tried the 49.x branch yet, it has a big UI refactor and adds file-manager-based restore for Restic backups.

Read more details and install instructions in the previous 49.alpha announcement. Thanks for any testing you can do before this reaches the masses!

Third Party Projects

Mir Sobhan announces

We forked the TWIG website and forged it into a "good first issue" tracker. It catches all GNOME-related projects on GitHub and GNOME GitLab to show issues labeled "good first issue" or "Newcomers." This can help newcomers find places to contribute including myself.

Website: https://ggfi.mirsobhan.ir Repo: https://gitlab.gnome.org/misano/goodfirstissue

Džeremi says

Chronograph gets a BIG new 4.0 update!

What is Chronograph?

Chronograph is an app for syncing lyrics, making them display like karaoke in supported players. It comes with a beautiful GTK4 + LibAdwaita interface and includes a built-in metadata editor, so you can manage your music library along with syncing lyrics. Default LRC files can be published to the large lyrics database LRClib.net, which is widely used by many open-source players to fetch lyrics. Until now, Chronograph supported only line-by-line lyrics, which was enough for most cases since standard LRC is the most common format. But times change…

Word-by-Word support!

Starting August 24th, Chronograph will gain support for Word-by-Word syncing. This feature uses the eLRC format (also known as LRC A2 or Enchanted LRC). In eLRC, each word has its own timestamp, allowing players that support it to animate lyrics word-by-word, giving you a true karaoke experience. And this is just the beginning: future updates will also bring support for TTML (Timed Text Markup Language).

Final notes

I hope you'll enjoy using the latest version of Chronograph, and together we can spread awareness of eLRC to the wider community. Sync lyrics of your loved songs! ♥️

Nathan Perlman announces

Rewaita - Give Adwaita some flavour

Hi there, a few weeks ago I released Rewaita, a spiritual successor to Gradience. With it, you can recolour GTK4/Adwaita apps to popular colour schemes. That's where the name comes from ~ Re(colour Ad)waita.

As of v1.0.4, released this week, you can create your own custom colour palettes if the ones we provide don't suit you, and you can also change the window controls to be either coloured or MacOS-styled.

You can find it on Flathub, but also in the AUR and NIXPKGS (the Nix Package is still under review).

Rewaita is also going through rapid development, so any help would be appreciated, or just leave us a star :). In particular, GTK3 and Cinnamon support are next up on the chopping block.

Miscellaneous

JumpLink says

ts-for-gir - TypeScript bindings for GObject Introspection

This week we've released a major improvement for GObject interface implementation: Virtual Interface Generation.

Instead of having to implement all methods of a GObject interface, developers can now only implement the virtual methods (vfunc_*). This matches the actual GObject-Introspection pattern and makes interface implementation much cleaner.

Before (implement all methods):

class CustomPaintable implements Gdk.Paintable {
  // Implement all methods manually
  get_current_image(): Gdk.Paintable { ... }
  get_flags(): Gdk.PaintableFlags { ... }
  get_intrinsic_width(): number { ... }
  // ... and many more
}

After (only virtual methods):

class CustomPaintable implements Gdk.Paintable.Interface {
  // Declare for TypeScript compatibility
  declare get_current_image: Gdk.Paintable["get_current_image"];
  declare get_flags: Gdk.Paintable["get_flags"];
  
  // Only implement virtual methods
  vfunc_get_current_image(): Gdk.Paintable { ... }
  vfunc_get_flags(): Gdk.PaintableFlags { ... }
}

We've created a comprehensive example: https://github.com/gjsify/ts-for-gir/tree/main/examples/virtual-interface-test

This shows both Gio.ListModel and Gdk.Paintable implementations using the new pattern.

Release: v4.0.0-beta.35 and v4.0.0-beta.36

Note: Last week we also released v4.0.0-beta.34 which introduced Advanced Variant Types by default, completing the gi.ts integration with enhanced TypeScript support for GLib.Variant.deepUnpack() and better type inference for GObject patterns.

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!

22 Aug 2025 12:00am GMT

At the Linux App Summit (LAS) in Albania three months ago, I gave a talk about testing in the xdg-desktop-portal project. There is a recording of the presentation, and the slides are available as well.

To give a quick summary of the work I did:

• Revamped the CI
• Reworked and improved the pytest based integration test harness
• Added integration tests for new portals
• Ported over all the existing GLib/C based integration tests
• Support ASAN for detecting memory leaks in the tests
• Made tests pretend to be either a host, Flatpak or Snap app

The hope I had is that this will result in:

• Fewer regressions
• Tests for new features and bug fixes
• More confidence in refactoring
• More activity in the project

While it's hard to get definite data on those points, at least some of it seems to have become reality. I have seen an increase in activity (there are other factors to this for sure), and a lot of PRs already come with tests without me even having to ask for it. Canonical is involved again, taking care of the Snap side of things. So far it seems like we didn't introduce any new regressions, but this usually shows after a new release. The experience of refactoring portals also became a lot better because there is a baseline level of confidence when the tests pass, as well as the possibility to easily bisect issues. Overall I'm already quite happy with the results.

Two weeks ago, Georges merged the last piece of what I talked about in the LAS presentation, so we're finally testing the code paths that are specific to host, Flatpak and Snap applications! I also continued a bit with improving the tests, and now they can be run with Valgrind, which is super slow and that's why we're not doing it in the CI, but it tends to find memory leaks which ASAN does not. With the existing tests, it found 9 small memory leaks.

If you want to improve the Flatpak story, come and contribute to xdg-desktop-portal. It's now easier than ever!

21 Aug 2025 11:00pm GMT

At the Linux App Summit (LAS) in Albania three months ago, I gave a talk about testing in the xdg-desktop-portal project. There is a recording of the presentation, and the slides are available as well.

To give a quick summary of the work I did:

• Revamped the CI
• Reworked and improved the pytest based integration test harness
• Added integration tests for new portals
• Ported over all the existing GLib/C based integration tests
• Support ASAN for detecting memory leaks in the tests
• Made tests pretend to be either a host, Flatpak or Snap app

The hope I had is that this will result in:

• Fewer regressions
• Tests for new features and bug fixes
• More confidence in refactoring
• More activity in the project

While it's hard to get definite data on those points, at least some of it seems to have become reality. I have seen an increase in activity (there are other factors to this for sure), and a lot of PRs already come with tests without me even having to ask for it. Canonical is involved again, taking care of the Snap side of things. So far it seems like we didn't introduce any new regressions, but this usually shows after a new release. The experience of refactoring portals also became a lot better because there is a baseline level of confidence when the tests pass, as well as the possibility to easily bisect issues. Overall I'm already quite happy with the results.

Two weeks ago, Georges merged the last piece of what I talked about in the LAS presentation, so we're finally testing the code paths that are specific to host, Flatpak and Snap applications! I also continued a bit with improving the tests, and now they can be run with Valgrind, which is super slow and that's why we're not doing it in the CI, but it tends to find memory leaks which ASAN does not. With the existing tests, it found 9 small memory leaks.

If you want to improve the Flatpak story, come and contribute to xdg-desktop-portal. It's now easier than ever!

21 Aug 2025 9:00pm GMT

If you have spent any time around HID devices under Linux (for example if you are an avid mouse, touchpad or keyboard user) then you may have noticed that your single physical device actually shows up as multiple device nodes (for free! and nothing happens for free these days!). If you haven't noticed this, run libinput record and you may be part of the lucky roughly 50% who get free extra event nodes.

The pattern is always the same. Assuming you have a device named FooBar ExceptionalDog 2000 AI[1] what you will see are multiple devices

/dev/input/event0: FooBar ExceptionalDog 2000 AI Mouse
/dev/input/event1: FooBar ExceptionalDog 2000 AI Keybard 
/dev/input/event2: FooBar ExceptionalDog 2000 AI Consumer Control 

The Mouse/Keyboard/Consumer Control/... suffixes are a quirk of the kernel's HID implementation which splits out a device based on the Application Collection. [2]

A HID report descriptor may use collections to group things together. A "Physical Collection" indicates "these things are (on) the same physical thingy". A "Logical Collection" indicates "these things belong together". And you can of course nest these things near-indefinitely so e.g. a logical collection inside a physical collection is a common thing.

An "Application Collection" is a high-level abstractions to group something together so it can be detected by software. The "something" is defined by the HID usage for this collection. For example, you'll never guess what this device might be based on the hid-recorder output:

# 0x05, 0x01,                    // Usage Page (Generic Desktop)              0
# 0x09, 0x06,                    // Usage (Keyboard)                          2
# 0xa1, 0x01,                    // Collection (Application)                  4
...
# 0xc0,                          // End Collection                            74

Yep, it's a keyboard. Pop the champagne[3] and hooray, you deserve it.

The kernel, ever eager to help, takes top-level application collections (i.e. those not inside another collection) and applies a usage-specific suffix to the device. For the above Generic Desktop/Keyboard usage you get "Keyboard", the other ones currently supported are "Keypad" and "Mouse" as well as the slightly more niche "System Control", "Consumer Control" and "Wireless Radio Control" and "System Multi Axis". In the Digitizer usage page we have "Stylus", "Pen", "Touchscreen" and "Touchpad". Any other Application Collection is currently unsuffixed (though see [2] again, e.g. the hid-uclogic driver uses "Touch Strip" and other suffixes).

This suffix is necessary because the kernel also splits out the data sent within each collection as separate evdev event node. Since HID is (mostly) hidden from userspace this makes it much easier for userspace to identify different devices because you can look at a event node and say "well, it has buttons and x/y, so must be a mouse" (this is exactly what udev does when applying the various ID_INPUT properties, with varying levels of success).

The side effect of this however is that your device may show up as multiple devices and most of those extra devices will never send events. Sometimes that is due to the device supporting multiple modes (e.g. a touchpad may by default emulate a mouse for backwards compatibility but once the kernel toggles it to touchpad mode the mouse feature is mute). Sometimes it's just laziness when vendors re-use the same firmware and leave unused bits in place.

It's largely a cosmetic problem only, e.g. libinput treats every event node as individual device and if there is a device that never sends events it won't affect the other event nodes. It can cause user confusion though: "why does my laptop say there's a mouse?" and in some cases it can cause functional degradation - the two I can immediately recall are udev detecting the mouse node of a touchpad as pointing stick (because i2c mice aren't a thing), hence the pointing stick configuration may show up in unexpected places. And fake mouse devices prevent features like "disable touchpad if a mouse is plugged in" from working correctly. At the moment we don't have a good solution for detecting these fake devices - short of shipping giant databases with product-specific entries we cannot easily detect which device is fake. After all, a Keyboard node on a gaming mouse may only send events if the user configured the firmware to send keyboard events, and the same is true for a Mouse node on a gaming keyboard.

So for now, the only solution to those is a per-user udev rule to ignore a device. If we ever figure out a better fix, expect to find a gloating blog post in this very space.

[1] input device naming is typically bonkers, so I'm just sticking with precedence here
[2] if there's a custom kernel driver this may not apply and there are quirks to change this so this isn't true for all devices
[3] or sparkling wine, let's not be regionist here

20 Aug 2025 1:12am GMT

Hi!

This month I've spent quite some time working on vali, a C library and code generator for the Varlink IPC protocol. It was formerly named "varlinkgen", but the new name is shorter and more accurate (the library can be used without the code generator). I've fixed a bunch of bugs, updated the service implementation to use non-blocking IO, added some tests and support for continued calls (which are Varlink's way to emit events from a service). I've also written a patch to port the kanshi output configuration tool to vali.

Speaking of kanshi, I've released version 1.8. A new kanshictl status command shows the current mode, and wildcard patterns are now supported to match outputs. I want to finish up relative output positioning for the next release, but some tricky usability issues need to be sorted out first.

Support for toplevel capture in xdg-desktop-portal-wlr has been merged. This was the last missing piece to be able to share an individual window from Web browsers. libdisplay-info v0.3 has been released with support for many new CTA data blocks and groundwork for DisplayID v2. José Expósito has sent libdrm and drm_info patches to add user-space support for the special "faux" bus used in cases where a device isn't backed by hardware (up until now, the platform bus was abused).

The Goguma mobile IRC client now displays a small bubble when someone else mentions you, making these easier to spot at a glance:

Jean THOMAS has added a new option to choose between the in-app Web view and an external browser when opening links. Hubert Hirtz has tweaked the login forms to play better with the autofill feature some password managers provide.

I've released go-imap v2 beta 6, with support for SPECIAL-USE and CHILDREN thanks to Dejan Štrbac and legacy RECENT thanks to fox.cpp. I'd like to eventually ship v2, but there are still some rough edges that I'd like to smooth out. I now realize it's been more than 2 years since the first v2 alpha release, maybe I should listen a bit more to my bio teacher who used to repeat "perfect is the enemy of good".

Anyways, that's all for now, see you next month!

16 Aug 2025 10:00pm GMT