Tiling-Assistant: a Windows-style snap assist bolted onto GNOME

It extends GNOME's tiling rather than replacing it

Tiling Assistant is a GNOME Shell extension which adds a Windows-like snap assist to the GNOME desktop. It expands GNOME's 2 column tiling layout and adds many more features.

That framing is the important part. The extension is not a tiling window manager that replaces GNOME, and it is not a standalone tiling application. It takes the layout that GNOME already has, the two column arrangement, and adds snap assist behaviour on top of it, so that a window being dragged towards an edge offers the half screen, quarter screen or corner placement that a Windows user expects.

The feature list itself is not in the README. The README points at the wiki for a list of all features, and says you will find videos and explanations for each of them there. That is a deliberate division of labour, and it means the repository README is a starting point rather than the documentation.

The project is published under the ubuntu organisation on GitHub, and the author of the package is Leleat, who also maintains the extension's own identity, tiling-assistant@leleat-on-github, which is the name that appears in the extension directory and in the metadata file.

The audience is a GNOME user on a current release who has seen a tiling workflow elsewhere and wants it inside the desktop they already use, and the licence is the GNU General Public License, version 2 or later.

The compatibility table is the documentation that matters

A GNOME Shell extension lives inside the compositor and is tied to its internals, and this project is explicit about the consequences.

The metadata file lists all currently supported GNOME Shell versions. Generally, only the most recent GNOME Shell is supported. That means older releases may not include all features and bug fixes. The README then says you can look at the revisions of the wiki articles to find out when a feature was added, changed or improved, and that the changelog will show all changes in chronological order.

So there are three sources and they answer three different questions. The metadata says what your GNOME version can run at all. The wiki revision history says when a specific feature appeared, which is how you tell whether the feature you want is in the version you can install. The changelog says what changed between releases.

The table itself maps GNOME Shell releases to the last extension version that supports them, and it is not a simple offset.

| GNOME Shell | Tiling Assistant | |:-------------:|:-----------:| | 45 | 44 | | 44 | 43 | | 43 | 43 | | 42 | 36 | | 41 | 32 | | 40 | 32 | | 3.38 | 23 | | 3.36 | 23 |

Read the last three rows and the shape of the problem is obvious. GNOME 3.36 and 3.38 stopped at extension version 23, while the current releases are in the forties and fifties. The extension version is not a function of the GNOME version, it is a history of which features needed which shell internals.

The release history of the extension follows the same pattern, with v54 in February 2026, v55 in September 2026 and v56 in October 2026, and the last push to the repository on 2026-10-08.

Two ways to install, and one of them needs a shell reload

The installation section offers the usual two routes and is honest about the awkward parts of the manual one.

The first is the extension site, extensions.gnome.org, listed as extension 3733, tiling-assistant. That is the route for most people, because the site handles the version metadata and the updates.

The alternative is to download or clone the repository and run the build script with the -i flag, which builds and installs in one step. Two requirements are called out. You need gettext installed, which the build uses for the translations, and after a manual installation you need to reload GNOME Shell, for example by logging out.

That last point is the one that catches people. A shell extension is loaded into the running compositor process, so installing the files is not the same as having the extension active, and the difference shows up as the panel not appearing. The README's advice is to log out, which is blunt but reliable, and on a Wayland session it is also the only option, since the reload shortcut that existed on X11 is not available.

The README also mentions that the extension is on the AUR, but flags that this repository is maintained by a third party. That is a reasonable thing for it to say about itself, and it is worth repeating, because a packaging repository in somebody else's name is a different maintenance arrangement from the extension source you are actually reading.

The build itself is a shell script rather than an npm script, and the package.json reflects that with an empty scripts object. The JavaScript in the repository is the extension source, and the tooling around it is ESLint with the flat config, plus the gjs and gnome-shell type definitions from the girs project for type checking the GNOME APIs the extension calls.

Translating it means writing a .po file or opening an issue

The Translation section is short and unusually welcoming, and it is worth reading because it tells you something about how the project is run.

Translations are welcome. If you are already familiar with how it works, feel free to directly open a pull request with a YOUR_LANG.po file at translations/. And then the reassurance: don't worry, in case you don't know how to create a .po file, just open an issue and I'll set everything up. You'll only need a text editor and your language skills.

So there are two routes. The first is for somebody who already knows the gettext workflow, and it is the pull request with a .po file in the translations directory. The second is for everybody else, and the maintainer will create the translation file and hand back something to fill in.

That second route is unusual and it is the most useful thing on the page for a non-English user. The conventional way to localise an extension is to clone the repository, install gettext, run the extraction, and work in the resulting template, and the gettext requirement in the installation section is the same requirement. The issue route removes the setup step for anyone who cannot or does not want to do it.

The consequence for the project is that the translation catalogue and the translator community grow at a different rate from the code, and the wiki, which is where the features are documented, is also the place a translator needs to look to understand what the words mean.

Where the extension stops, and what the alternative is

The limitation is structural rather than a missing feature, and the README states it plainly: only the most recent GNOME Shell is generally supported, and older releases may not include all features and bug fixes.

That is the trade of running inside somebody else's compositor. The extension gets access to window management internals that a standalone application cannot have, and it pays for that with a coupling that breaks on every shell release. The compatibility table is the bill.

There is a second limitation implied by the design. Because the extension expands GNOME's two column tiling rather than replacing the window manager, the layout it operates on is GNOME's. A user who wants a scrolling layout, a keyboard driven workflow or a per-monitor tiling tree is asking for something this extension does not attempt, and the mismatch is not a missing feature so much as a different model of what a desktop should do.

The alternative approach is a dedicated tiling window manager, where tiling is the design centre rather than an extension of a floating desktop. The difference in approach is where the snapping and layout logic lives and what it is allowed to assume. A dedicated window manager owns the layout, so it can offer a consistent tiling model, and it is not affected when a desktop release changes its internals. The cost is that you leave the desktop, and with it the applications, the notifications and the settings that GNOME integrates.

The middle option is GNOME's own tiling without any extension. The extension exists precisely because that was not enough, but a user who only wants two columns and a sensible keyboard flow may find the built-in behaviour sufficient and avoid the shell compatibility treadmill entirely.

Editorial conclusion

Tiling-Assistant fits a GNOME user on a recent release who wants snap assist and a richer tiling layout without leaving the desktop, and who is comfortable installing a shell extension that changes how windows are placed. It does not fit a user on an older GNOME release expecting the same features, since the README says only the most recent GNOME Shell is generally supported, and it does not fit somebody who wants a tiling model designed for tiling from the start. Before you install, check the compatibility table for your GNOME Shell version, and read the wiki entry for the features you actually want, since the changelog and the wiki revisions are where the version boundaries are recorded.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. ubuntu/Tiling-Assistant on GitHub