Agreguesi i feed

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