VTE

• Little back-and-forth on what we can do to improve a11y further with VTE. Prototype’d a way to extract hyperlinks and provide them into AccessibleText, however that is not the right place.

  We really need an implementation of the at-spi hyperlink API in GTK so that VteTerminal may implement it.

• Merged a number of a11y fixes provided by Lukáš Tyrychtr which fix some of my original a11y implementation to follow the at-spi expectations better.

  Also added one of my own to fix a potential uint underrun when describing runs thanks to long to uint conversion.

Ptyxis

• Got a report of a bit of undesirable behavior when closing a window where close-able tabs are closed before showing the the special close dialog.

  It’s all more complex than I wish it was, because there are multiple ways we can enter that flow. Additionally, the asynchronous nature of closing tabs makes that state a bit “split brain” as it exists now. We may want to implement a “session” object to manage this stuff all in one place going forward.

• When showing multiple tabs the “visual bell” background did not cover the entire headerbar. Quick CSS fix that.

• Sebastian Wick needed a terminal with the Terminal Intents implemented so I took a crack at implementing that in Ptyxis. That allowed forward-progress on implementing the GLib side of things.

  Doing so found a couple of things we want to address in the upcoming FreeDesktop terminal intent “standard” and thankfully they’ve been moving that forward (including the Ptyxis-side).

Libpeas

• libpeas distro packaging was failing on the testsuite for Lua due to LGI not supporting girepository-2.0. Libpeas 2.x doesn’t use girepository at runtime, so this is relegated to the testsuite.

  For now, I’ve just disabled the Lua tests since they can’t possibly work due to that girepository usage.

  Some months back I provided patches for LGI to support girepository-2.0 but the project seems unmaintained and therefore hard for anyone to really say “yes merge this”.

  You can find some more information from Victoria Lacroix at https://www.vtrlx.ca/posts/2025/lgi-fork/

Builder

• They don’t get much testing during development so we had a small build regression on i686.

• Spent a bunch of time on what will hopefully become Builder 50. This is a major rewrite on top of Foundry, Foundry-Gtk, and what will become Foundry-Adw in the 1.1 release of Foundry.

  It is hard to describe how remarkably small this will make Builder as a project compared to previous versions. So much complexity in the Builder code-base was in response to all the async/finish flows required to keep things smooth. But now that we have libdex and libfoundry, it’s just so easy to implement that sort of magic.

Libdex

• Sebastian Wick had some great ideas on integrating libdex with gdbus-codegen. Discussed a few different ways we could go forward to make something ergonomic. It would be nice to implement both consuming as proxies and providing as skeletons with futures.

Libpanel

• I noticed that the bottom corner buttons in Builder were not aligning with the external rounded corners of the window. That was fallout from a previous cleanup so fixed that up before release.

Template-GLib

• Thanks to early testing by distributors we found an issue in the testsuite which was exercising GObject Introspection integration. It broke on 32-bit because the gsize parameters are different and I never implemented auto-casting of integers of different sizes.

  So if you did a call like GLib.utf8_substring(str, i64(3), i64(-1)) and were on 32-bit that would fail since the offset / length parameters are glong which is sized differently.

  The quick fix that will still allow for errors to propagate was to implement auto up/down casting of numbers so long as they will fit in the destination type. Otherwise, you’ll fail the cast operation and errors propagate as necessary.

  This fix landed shortly before 3.38.0 but was tested on numerous architectures before release.

Foundry

• Learned that even command-line tools get appdata now days so I went ahead and implemented that for the foundry CLI tool.

• We now dynamically link foundry binary. Originally I had plans to statically link it so that we can send it to a remote system and run it as a bridge. Since we aren’t there yet anyway, it doesn’t make sense to enforce that and/or make distributions patch it out.

• FoundryBuildManager got a :busy property which makes it much easier to implement UI like Builder has where you show a build button or a stop button based on status.

  It also got a new stop() method/ GAction for that too. This is a lot harder than it looks because you need to plumb through a cancellable to all of the build pipeline API which is going to be awaiting the first future of [cancellable, some_op] .

  Was extremely happy to see it work on the first try which means I’ve done something right in the libdex design.

• Once I did the above, adding a rebuild action and method was quite easy. We have all the necessary plumbing to either call an action or await a method future and get the same result.

• A last minute API was added to create a producer from a consumer PTY fd. Hopefully using this new nomenclature is not so confusing for people used to ancient PTY terminology which I know is extremely confusing to begin with. But we gotta move past those antiquated terms (which I wont repeat here) as they are both morally wrong and technically inaccurate.

• The FoundryFileManager can now automatically discover content-type when provided a filename. This vastly simplifies API usage when you have one-or-the-other to get a symbolic icon. Since we override many icons from the system, that is just a necessary abstraction.

• FoundrySearchResult got an :icon property which means it’s basically usable to search UI now. Though there are not many FoundrySearchProvider s yet as they will land for 1.1.

• A new context.file-manager-show GAction is provided which allows you to pass a uri as a "s" -typed GVariant . I feel stupid for not doing this a decade ago in Builder and quite frankly, it should probably just exist in GTK.

• Libpanel/Builder has this nice “Action Muxer” API for years now and that is exported in Foundry too so we can use it in libfoundry-gtk and libfoundry-adw. It’s extremely handy when the built-in action support in GTK is not enough.

• Foundry has a SQLite database of extended attributes on URIs when the underlying file-system does not support extended attributes. I made a little boo-boo there so made that to actually work.

• Talked to dmalcom about supporting SARIF in Foundry for GNOME 50. They (the GCC project) would really like to see more consumers of it and Foundry is an obvious place to put that.

  It doesn’t look terribly difficult and it should allow us to drop the whole “regex parsing of PTY content” if done right.

Foundry-Gtk

• Fixed palette parsing and color application to VteTerminal.

• Imported all the Ptyxis terminal palettes which can now be represented as a FoundryTerminalPaletteSet and FoundryTerminalPalette .

  Ultimately, what this means is if you link against libfoundry and libfoundry-gtk you could functionally create your own Ptyxis replacement in very little code (assuming you don’t use an agent on the host OS like Ptyxis does).

  Just use the FoundrySdk as your container abstraction (which you can query using FoundrySdkManager ) and FoundryTerminal with FoundryTerminalPaletteSet .

• You can now list/find available palettes with a GListModel API in the form of foundry_terminal_list_palette_sets() and foundry_terminal_find_palette_set() . Each set has an easy light/dark property you can use based on your needs.

• The file-search plugin now properly implements the load() vfunc for search results so you can implement preview/opening in apps.

Foundry-Adw

• A ton of work on the workspace, page, and panel APIs for 1.1. I’m really trying to find a way to re-use this across a number of applications such as Builder, Drafting, Sysprof, and more.

Releases

• gnome-text-editor 49.0

• gtksourceview 5.18.0

• sysprof 49.0

• gnome-builder 49.0

• ptyxis 49.0

• libdex 1.0.0

• foundry 1.0.0

• libpanel 1.10.2

• template-glib 3.38.0

• d-spy 49.0 (thanks to Jordan for the 49.1 w/ CI fixed)

• gom 0.5.4

• libpeas 2.2.0

• manuals 49.0

Other

• Team coffee hour, shared some battle wounds of trying to use AI for a pahole wrapper which fixed all my class structs to be cacheline aligned. Was just faster to write the damn code.

Misc news about the gedit text editor, mid-September edition! (Some sections are a bit technical).

Next version will be released when Ready

While the release of GNOME 49.0 was approaching (it's this week!), I came to the conclusion that it's best for gedit to wait more, and to follow the Debian way of releasing software: when it's Ready. "Ready" with an uppercase letter 'R'!

So the question is: what is not ready? Two main things:

• The rework of the file loading and saving: it is something that takes time, and I prefer to be sure that it'll be a solid solution.
• The question about the Python support for implementing plugins. Time will tell what is the answer.

Rework of the file loading and saving (next steps)

Work continues to refactor that part of the code, both in libgedit-gtksourceview and gedit.

I won't go into too much technical details this time. But what the previous developer (Ignacio Casal Quinteiro, aka nacho) wrote (in 2011) in a comment at the top of a class is "welcome to a really big headache."

And naturally, I want to improve the situation. For a long time this class was used as a black box, using only its interface. Time has come to change things! It takes time, but I already see the end of the tunnel and I have good hopes that the code will be better structured. I intend to write about it more once finished.

But I can reveal that there is already a visible improvement: loading a big file (e.g. 200 MB) is now super fast! Previously, it could take one minute to load such file, with a progress bar shown and a Cancel button. Now there is not enough time to even click on (or to see) the Cancel button! (I'm talking about local files, for remote files with a slow network connection, the progress bar is still useful).

To be continued...

If you appreciate the work that I do, you can send a thank-you donation . Your support is much appreciated! For years to come, it will be useful for the project.

Intro:

Hi everyone, it’s the end of GSoc! I had a great experience throughout this whole process. I’ve learned so much. This is essentially the ‘final report’ for GSoC, but not my final report for this project in general by a long shot. I still have so much more I want to do, but here is what I’ve done so far.

Project:

JSON, YAML, and/or XML emitting and parsing integration into Vala’s compiler.

Mentor:

I would like to thank Lorenz Wildberg for being my mentor for this project, as well as the Vala community .

Description:

The main objective of this project is to integrate direct syntax support for parsing and emitting JSON, XML, and/or YAML formats in Vala. This will cut back the boilerplate code, making it more user-friendly and efficient for developers working with these formatting languages.

What I’ve done:

Research

• I’ve done significant research in both JSON and YAML parsing and emitting in various languages like C#, Java, Rust and Python.
• Looked into how Vala currently handles JSON using JSON GLib classes, and I then modelled the C code after the examples I collected.
• Modelled the JSON module after other modules in the codegen, specifically, mainly after Dbus, Gvariant, GObject, and GTK.

Custom JSON Overrides and Attribute

• Created Vala syntax sugar specifically making a [JSON] attribute to do serialization.
• Built support for custom overrides as in mapping JSON keys to differently named fields/properties.
• Reduced boilerplate by generating C code behind the scenes.

Structs

• I’ve created both Vala functions to deserialize and serialize structs using JSON boxed functions.
• I created a Vala generate_struct_serialize_func function to create a C code function called _ % s_serialize_func to serialize fields.

• I then created a Vala function generate_struct_to_json to create a C code function called _json_ % s_serialize_mystruct to fully serialize the struct by using boxed serialize functions.
  

• I created a Vala generate_struct_deserialize_func function to create a C code function called _ % s_deserialize_func to deserialize fields.
• I then created a Vala function generate_struct_to_json to create a C code function called _json_ % s_deserialize_mystruct to fully deserialize the struct by using boxed deserialized functions.

GObjects

• I’ve created both Vala functions to deserialize and serialize GObjects using json_gobject_serialize and JSON generator.

• I then created a Vala function generate_gclass_to_json to create a C code function called _json_ % s_serialize_gobject_myclass to fully serialize GObjects.
  

• I created a Vala generate_gclass_from_json function to create a C code function called _json_ % s_deserialize_class to deserialize fields.

Non-GObjects

• I’ve done serializing of non-GObjects using JSON GLib’s builder functions.
• I then created a Vala function generate_class_to_json to create a C code function called _json_ % s_serialize_myclass to fully serialize non-objects that aren’t inheriting from Object or Json.Serializable.

Future Work:

Research

• Research still needs to be put into integrating XML and determining which library to use.
• The integration of YAML and other formatting languages not only JSON, YAML, or XML.

Custom Overrides and Attributes

• I want to create more specialized attributes for JSON that only do serialization or deserialization. Such as [JsonDeserialize] and [JsonSerialize] or something similar.
• [JSON] attribute needs to do both deserializing and serializing, and at the moment, the deserializing code has problems.
• XML, YAML, and other formating languages will follow very similar attribute patterns: [Yaml] , [ Xml ], [ Json ] .

Bugs

• unref c code functions are calling nulls, which shouldn’t be the cause. They need proper types going through.
• Deserializing prompts a redefinition that needs to be corrected.
• Overridden GObject properties need to have setters made to be able to get the values.

Links

• Here is the JSON module that has majority of the code.
• Here is the merge request .

It’s been another busy week for the GNOME Foundation. Here’s my attempt to summarise what’s been happening. As with my previous update, this update is for the whole organisation rather than just me personally. It’s also likely that I’ll have missed some things. Hopefully I’ve captured the highlights though!

GNOME.Asia 2025

GNOME.Asia 2025 is happening in Toyko, Japan, in December. I’m sure that this is going to be a fantastic event, and the call for papers has recently been extended to 1st October. If you have an idea for a talk and would like to participate, go submit a proposal!

Digital wellbeing

The Foundation has been funding development work on digital wellbeing features in GNOME for almost two years now. This work is funded by a grant that we received from Endless, which is now in its final stages. I spent some of this week reviewing the budget and discussing the timeline with Philip and Ignacy, who are currently working on the project.

There are a number of features which are currently in development which will hopefully be landed for GNOME 50, including session time limits for accounts that are managed with parental controls. We also have a modernized parental controls app which is also in the works.

For Future Summit

Kristi attended the For Future Summit in the United Arab Emirates last weekend, where she gave a talk about GNOME and had some exciting hallway conversations. There were some very interesting organisations at the event, who we are hoping to have follow-up conversations with soon.

Thank you to For Future Summit for funding Kristi’s attendance.

Flathub

We have a long-standing ambition to establish Flathub as an independent entity, so that it can do its own fundraising and spending. These plans have unfortunately suffered from delays. However, Rob has been working with Aleix from KDE on this recently, and they’ve made some positive progress this week, with lawyers being commissioned to provide some of the initial pieces that we need. I’m hopeful that this work can continue and we can finally get Flathub standing on its own feet.

Alongside this, Flathub infrastructure support continues to tick along. All of this Flathub support is being funded from our Endless grant, so many thanks to them for enabling it to happen.

Board regular meeting

The board had its first regular meeting of September this week (regular meetings are on the second and fourth Tuesday of the month). The Finance Committee have been working on the upcoming budget since the Board meeting, so this was a good opportunity for the Board to discuss the latest proposal.

This is the best budgeting process I’ve seen in my years on the board. Kudos to everyone who’s been involved.

GIMP support

The GIMP project’s grants program has been inching towards the finish line this week. It’s taken a while, but we’re almost there! It’ll be so exciting to see two developers being funded from their donation stream.

Routine paperwork

A fair chunk of the work done by the Foundation is not very exciting, but is important nonetheless. This week featured a few items of that type, relating to our trademarks and insurance. These got done.

Message ends

See you again next week. o/

• Up early, bid 'bye to M. sync & brainstorming with Dave, quick sync with Frank, prepared slides for TTT:
• Gave a Tea Time Training on threading:
  

Introduction

Python-BPF offers a new way to write eBPF programs entirely in Python, compiling them into real object files. This project is open-source and available on GitHub and PyPI . I wrote it alongside R41k0u .

Published Library with Future Plans

Python-BPF is a published Python library with plans for further development towards production-ready use.
You can pip install pythonbpf but it’s certainly not at all production ready and the code is hacky at best with more bugs than I could count. (This was a hackathon project afterall. We plan to fix it after we are done with the hackathon.)

The Old Way: Before Python-BPF

Before Python-BPF, writing eBPF programs in Python typically involved embedding C code within multiline strings, often using libraries like bcc . eBPF allows for small programs to run based on kernel events, similar to kernel modules.

Here’s an example of how it used to be:

from bcc import BPF
from bcc.utils import printb

# define BPF program
prog = """
int hello(void *ctx) {
 bpf_trace_printk("Hello, World!\\n");
 return 0;
}
"""

# load BPF program
b = BPF(text=prog)
b.attach_kprobe(event=b.get_syscall_fnname("clone"), fn_name="hello")

# header
print("%-18s %-16s %-6s %s" % ("TIME(s)", "COMM", "PID", "MESSAGE"))

# format output
while 1:
 try:
 (task, pid, cpu, flags, ts, msg) = b.trace_fields()
 except ValueError:
 continue
 except KeyboardInterrupt:
 exit()
 printb(b"%-18.9f %-16s %-6d %s" % (ts, task, pid, msg))

This approach, while functional, meant writing C code within Python, lacking support from modern Python development tools like linters.

Features of the Multiline C Program Approach

# load BPF program
b = BPF(text="""
#include <uapi/linux/ptrace.h>

BPF_HASH(last);

int do_trace(struct pt_regs *ctx) {
 u64 ts, *tsp, delta, key = 0;

 // attempt to read stored timestamp
 tsp = last.lookup(&key);
 if (tsp != NULL) {
 delta = bpf_ktime_get_ns() - *tsp;
 if (delta < 1000000000) {
 // output if time is less than 1 second
 bpf_trace_printk("%d\\n", delta / 1000000);
 }
 last.delete(&key);
 }

 // update stored timestamp
 ts = bpf_ktime_get_ns();
 last.update(&key, &ts);
 return 0;
}
""")

The multiline C program approach allowed for features like BPF MAPS (hashmap type), map lookup, update, and delete, BPF helper functions (e.g., bpf_ktime_get_ns , bpf_printk ), control flow, assignment, binary operations, sections, and tracepoints.

Similar Program in Reduced C

For production environments, eBPF programs are typically written in pure C, compiled by clang into a bpf target object file, and loaded into the kernel with tools like libbpf . This approach features map sections, license global variables, and section macros specifying tracepoints.

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#define u64 unsigned long long
#define u32 unsigned int

struct {
 __uint(type, BPF_MAP_TYPE_HASH);
 __uint(max_entries, 1);
 __type(key, u32);
 __type(value, u64);
} last SEC(".maps");

SEC("tracepoint/syscalls/sys_enter_execve")
int hello(struct pt_regs *ctx) {
 bpf_printk("Hello, World!\\n");
 return 0;
}

char LICENSE[] SEC("license") = "GPL";

Finally! Python-BPF

Python-BPF brings the true eBPF experience to Python by allowing the exact same functionality to be replaced by valid Python code. This is a significant improvement over multiline C strings, offering support from existing Python tools.

from pythonbpf import bpf, map, section, bpfglobal, compile
from ctypes import c_void_p, c_int64, c_int32, c_uint64
from pythonbpf.helpers import ktime
from pythonbpf.maps import HashMap

@bpf
@map
def last() -> HashMap:
 return HashMap(key_type=c_uint64, value_type=c_uint64, max_entries=1)

@bpf
@section("tracepoint/syscalls/sys_enter_execve")
def hello(ctx: c_void_p) -> c_int32:
 print("entered")
 return c_int32(0)

@bpf
@section("tracepoint/syscalls/sys_exit_execve")
def hello_again(ctx: c_void_p) -> c_int64:
 print("exited")
 key = 0
 last().update(key)
 ts = ktime()
 return c_int64(0)

@bpf
@bpfglobal
def LICENSE() -> str:
 return "GPL"

compile()

Python-BPF uses ctypes to preserve compatibility, employs decorators to separate the BPF program from other Python code, allows intuitive creation of global variables, and defines sections and tracepoints similar to its C counterpart. It also provides an interface to compile and run in the same file.

How it Works Under the Hood

1. Step 1: Generate AST The Python ast module is used to generate the Abstract Syntax Tree (AST).

2. Step 2: Emit LLVM IR llvmlite from Numba emits LLVM Intermediate Representation (IR) and debug information for specific parts like BPF MAPs. The .py file is converted into LLVM Intermediate Representation.

3. Step 3: Compile LLVM IR The .ll file, containing all code written under the @bpf decorator, is compiled using llc -march=bpf -O2 .

4. Step 4: Generate eBPF Object File The LLVM backend takes the IR and converts it into a bpf object file with eBPF bytecode, handling all optimizations.

   

Salient Features

Previous Python options for eBPF relied on bcc for compilation, which is not ideal for production use. The only two real options for production-quality eBPF programs were aya in Rust and Clang with kernel headers in C. Python-BPF introduces a third, new option, expanding the horizons for eBPF development.

It currently supports:

• Control flow
• Hash maps (with plans to add support for other map types)
• Binary operations
• Helper functions for map manipulation
• Kernel trace printing functions
• Timestamp helpers
• Global variables (implemented as maps internally with syntactical differences)

TL;DR

• Python-BPF allows writing eBPF programs directly in Python.
• This library compiles Python eBPF code into actual object files.
• Previously, eBPF programs in Python were written as C code strings.
• Python-BPF simplifies eBPF development with Python decorators.
• It offers a new option for production quality BPF programs in Python.
• The tool supports BPF maps, helper functions, and control flow, with plans to extend to completeness later.

Thanks for reading my poorly written blog :)

Those of you who follow the Toolbx project might have noticed something odd about our latest release that came out a month ago. The version number looked shorter than usual even though it only had relatively conservative and urgent bug-fixes, and no new enhancements.

If you were wondering about this, then, yes, you are right. Toolbx will continue to use these shorter version numbers from now on.

The following is a brief history of how the Toolbx version numbers evolved over time since the beginning of the project till this present moment.

Toolbx started out with a MAJOR.MINOR.MICRO versioning scheme. eg., 0.0.1, 0.0.2, etc.. Back then, the project was known as fedora-toolbox, was implemented in POSIX shell, and this versioning scheme was meant to indicate the nascent nature of the project and the ideas behind it.

To put it mildly, I had absolutely no idea what I was doing. I was so unsure that for several weeks or few months before the first Git commit in August 2018, it was literally a single file that implemented the fedora-toolbox(1) executable and a Dockerfile for the fedora-toolbox image on my laptop that I would email around to those who were interested.

A nano version was reserved for releases to address brown paper bag bugs or other critical issues, and for release candidates. eg., several releases between 0.0.98 and 0.1.0 used it to act as an extended set of release candidates for the dot-zero 0.1.0 release. More on that later.

After two years, in version 0.0.90 , Toolbx switched from the POSIX shell implementation to a Go implementation authored by Ondřej Míchal . The idea was to do a few more 0.0.9x releases to shake out as many bugs in the new code as possible, implement some of the bigger items on our list that had gotten ignored due to the Go rewrite, and follow it up with a dot-zero 0.1.0 release. That was in May 2020.

Things went according to plan until the beginning of 2021, when a combination of factors put a spanner in the works, and it became difficult to freeze development and roll out the dot-zero release. It was partly because we kept getting an endless stream of bugs and feature requests that had to be addressed; partly because real life and shifting priorities got in the way for the primary maintainers of the project; and partly because I was too tied to the sanctity of the first dot-zero release. This is how we ended up doing the extended set of release candidates with a nano version that I mentioned above.

Eventually, version 0.1.0 arrived in October 2024, and since then we have had three more releases — 0.1.1, 0.1.2 and 0.2. Today, the Toolbx project is seven years old, and some things have changed enough that it requires an update to the versioning scheme.

First, both Toolbx and the ideas that it implements are a lot more mature and widely adopted than they were at the beginning. So much so, that there are a few independent reimplementations of it. It’s time for the project to stop hiding behind a micro version.

Second, the practice of bundling and statically linking the Go dependencies sometimes makes it necessary to update the dependencies to address security bugs or other critical issues. It’s more convenient to do this as part of an upstream release than through downstream patches by distributors. So far, we have managed to avoid the need to do minimal releases targeting only specific issues for conservative downstream distributors, but the recent NVIDIAScape or CVE-2025-23266 and CVE-2025-23267 in the NVIDIA Container Toolkit gave me pause. We managed to escape this time too, but it’s clear that we need a plan to deal with these scenarios.

Hence, from now on, Toolbx releases will default to not having a micro version and use a MAJOR.MINOR versioning scheme. A micro version will be reserved for the same purposes that a nano version was reserved for until now — to address critical issues and for release candidates.

It’s easier to read and remember a shorter MAJOR.MINOR version than a longer one, and appropriately conveys the maturity of the project. When a micro version is needed, it will also be easier to read and remember than a longer one with a nano version. Being easy to read and remember is important for version numbers, because it separates them from Git commit hashes.

So, this is why the latest release is 0.2, not 0.1.3.

GNOME Kiosk is a separate Wayland compositor built on the same core components as GNOME Shell, such as Mutter.

While it does not provide a desktop UI, it is intended for kiosk and appliance use cases.

Originally designed to run a single application in fullscreen mode, recent development has expanded its scope toward more versatile window management and system integration.

Recent Releases Overview

47

• Support for Shell introspection API (in --unsafe-mode ).

48

• Initial support for configurable windows via window-config.ini .
• Added Shell Screenshot D-Bus API.

49

• Extended window configuration: set-on-monitor , set-window-type , window tags.
• Added support for remote sessions (Systemd).
• Fixes for GrabAccelerators, media keys, and compositor shortcut inhibition.

Window Configuration and Tagged Clients

One of the recent main areas of development has been window configuration .

• In GNOME 48, Kiosk gained initial support for configuring windows via a static configuration file ( window-config.ini ).
• In GNOME 49, this functionality was extended with additional options:
  • set-on-monitor : place windows on a specific monitor.
  • set-window-type : assign specific roles to windows (e.g. desktop , dock , splash ).
  • Matching based on Window tags : allow selection of windows based on toplevel tags, a new feature in Wayland protocols 1.43 .

Additionally, with the new ( in mutter from GNOME 49 ) gnome-service-client utility, toplevel windows tags can be assigned to clients at launch, making it possible to configure their behavior in Kiosk without modification to the client.

Example: configuring a tagged client in Kiosk

GNOME Kiosk searches for the window configuration file window-config.ini in the following locations:

• The base directory for user-specific application configuration usually $HOME/.config/gnome-kiosk/window-config.ini
• The system-wide list of directories for application data $XDG_DATA_DIRS This list usually includes:
  • /var/lib/flatpak/exports/share/gnome-kiosk/window-config.ini
  • /usr/local/share/gnome-kiosk/window-config.ini
  • /usr/share/gnome-kiosk/window-config.ini

Therefore, for a user configuration, edit $HOME/.config/gnome-kiosk/window-config.ini to read:

[all]
set-fullscreen=false
set-above=false

[desktop]
match-tag=desktop
set-window-type=desktop
set-fullscreen=true

With this configuration, GNOME Kiosk will treat any surface with the toplevel tag desktop as a „desktop“ type of window.

launching a tagged client

gnome-service-client -t desktop weston-simple-shm

This command starts the weston-simple-shm client and associates the tag desktop with its surface.

The end result is the weston-simple-shm window running as a background window placed at the bottom of the windows stack.

This combination makes it possible to build structured kiosk environments with different Wayland client used docks or desktop windows for implementing root menus.

Accessibility and Input

Several improvements have been made to input handling and accessibility:

• Fixes for GrabAccelerators support.
• Support for media keys in Systemd sessions.
• Ability to inhibit compositor shortcuts.
• Compatibility with screen reader usage.

Remote Sessions

As of GNOME 49, Kiosk supports remote sessions when run under Systemd. This allows kiosk sessions to be used not only on local displays but also in remote session contexts.

D-Bus APIs

Although GNOME Kiosk is a separate compositor, it implements selected D-Bus APIs also available in GNOME Shell for compatibility purposes. These include:

• Screenshot API (added in 48).
• Shell introspection when started with --unsafe-mode (added in 47).

This makes it possible to use existing GNOME testing and automation frameworks such as Ponytail and Dogtail with kiosk sessions.

These APIs allow automation scripts to inspect and interact with the user interface, enabling the creation of automated tests and demonstrations for kiosk application (using tools like GNOME ponytail and dogtail ).

GNOME Kiosk is the Wayland compositor used with the Wayland enabled version of Anaconda, the installer for Fedora (and Red Hat Enterprise Linux as well). The support for introspection and screenshots is used by anabot , the framework for automated testing of the installer.

Development Direction

Future development of GNOME Kiosk is expected to continue along the following lines:

• Configuration refinement : further improving flexibility of the window configuration system.
• Accessibility : ensuring kiosk sessions benefit from GNOME’s accessibility technologies.

The goal remains to provide a focused, reliable compositor for kiosk and appliance deployments, without implementing the full desktop UI features of GNOME Shell.

As time is approaching the release of GNOME 49, I thought I should probably put together a small recap post covering some of the new things in Maps.

Metro Station Symbols

The map style now supports showing localized symbols for rail- and metro stations (relying on places being tagged with reference to the networks' entry in Wikidata.

Highway Symbols in Place Details

The existing code for showing custom highways shields in the map view (based on code from the OpenStreetMap Americana project) has been extended to expose the necessary bits to use it more generally as icon surfaces in a GtkImage widget. So now custom shields are shown in place details when clicking on a road label.

Adwaita Shortcuts Dialog

The keyboard shortcuts help dialog was ported by Maximiliano to use AdwShortcutsDialog, improving adaptivity.

Showing OSM Account Avatars in OSM Account Dialog

If a user has set up OAuth for an OpenStreetMap account, and has set a personal profile picture in their OSM account this is now shown in place of the generic „face“ icon.

And speaking of editing points-of-interests, the edit dialog has been compacted a bit to better accomodate smaller screen sizes.

Softer Labels

Some smaller adjustments has also been made to the map style, such as using slightly softer color for the place labels for towns and cities rather than pitch black (or bright white for dark mode).

Marker Alignments

Thanks to work done by Corentin Noël for libshumate 1.5, the center point for map markers can now be adjusted.

This means the place markers in Maps can now actually point to the actually coordinate (e.g. having the “tip of the needle” at the actual location).

Updating the Highway Shields Defintions

And finally of the last changes before the release was updating the definition for custom highway shields from OpenStreetMap Americana. So now, among others we support shields for national and regional highways in Argentina.

And that's some of the highlights from the 49 release cycle!