Desktop Cube: a Compiz style 3D workspace cube for GNOME Shell

A nostalgia project with a stated lineage

The origin story is short and specific. When the author started using Linux more than a decade ago, it was because of the 3D desktop cube of Compiz. Even if that was a pretty useless feature, it is still missed today. So a similar effect was created for GNOME Shell.

The framing matters for how you judge the code. This is not a productivity tool that happens to look 3D. It is a re-creation of a specific visual effect from a specific era of the Linux desktop, and the project description says plainly that the point is to indulge in nostalgia with useless 3D effects. Knowing that saves you from reading it as an attempt to build a better workspace switcher.

The audience is therefore GNOME users on Linux who remember Compiz, plus anyone who wants a showpiece effect. It also fits alongside other nostalgic extensions the author points to, such as Compiz windows effects and Burn My Windows.

The project is not archived and the last push was on 2026-10-10, with three tagged releases in 2026 alone: Desktop Cube 35 on 2026-10-10, Desktop Cube 34 on 2026-09-23, and Desktop Cube 33 on 2026-05-28. A change log for previous releases is kept in the repository at docs/changelog.md, which is where you would look to see what a specific version changed.

The cube is a workspace model, not just a transition effect

Most of the features listed are variations on one idea: workspaces arranged as the faces of a cube, with a camera you can move around them.

The 3D overview arranges the workspaces in the overview in a cube-like fashion. The cube also appears when you switch workspaces with touch gestures or keyboard shortcuts. Three separate input paths rotate it: click and drag anywhere on the desktop, click and drag the panel, which the project notes is useful with maximized windows, and click and drag the overview background.

The geometry has a small twist. If you rotate the cube up or down, the 3D effect becomes more intense, described in the feature list as exploding the cube on vertical rotations.

The cube is also not rigid. The extension supports any number of workspaces, so in the project's own words it is actually not a cube most of the time. And you can drag windows directly to adjacent workspaces, including from within the overview, which turns the cube into a spatial file manager rather than just a transition.

Background panoramas complete the effect: you can select an image used as a 360 degree skybox, so the cube appears to rotate inside a panoramic scene. The documentation notes that entering the app drawer unfolds the cube, and that transitions between the desktop, the overview and the app drawer are smooth.

Two limits come from GNOME Shell, not from the extension

The limitations section names two known issues, and both trace back to GNOME Shell rather than to the code in this repository.

The first is no wrap-around. In GNOME Shell it is not possible to change from the last to the first workspace, and the extension does not change this. On a cube that means you can rotate around to see the workspaces, but the shell will not let you roll straight from the last one into the first. Rotating the cube past the end does not become a shortcut for cycling workspaces.

The second is bad multi-monitor support on X11. On X11, GNOME Shell uses the same projection and view matrices for all monitors. The extension can modify these matrices so that the projection centre of the virtual camera sits in front of the current monitor, but the cube looks somewhat sheared on setups with multiple monitors if the cube is shown on all monitors.

That second limitation has a practical consequence. The extension can compensate for the camera position, but it cannot compensate for the shell sharing one projection across displays, so the geometry is visibly wrong in a configuration that is common on desktops with two monitors. Under Wayland the shared-matrix problem does not apply in the same way, which makes the multi-monitor experience different between the two display protocols.

Issues are tracked on the project's GitHub issue tracker, which is where anything beyond these two is reported.

Installing it: three routes, and one version caveat that decides everything

There are three installation routes, and the project describes the first as the easiest. You can install from extensions.gnome.org, download a stable release from GitHub, or clone the latest version directly with git.

The version caveat comes first, though, because it determines whether any of those routes will work. The code in the main branch is for GNOME Shell 45 and newer. For older GNOME versions, the project points you at the gnome-40-41 or gnome-42-44 branches respectively.

That is the single most important line in the installation documentation for anyone running an LTS distribution. A user on GNOME 42 who installs the release from extensions.gnome.org and finds nothing happening has a version mismatch, not a broken extension.

If you prefer to build from the repository, the Makefile carries the recipes. The install target builds the zip and installs it:

gnome-extensions install "$(ZIP_NAME)" --force

and the uninstall target removes it by its full identifier:

gnome-extensions uninstall "$(NAME)@$(DOMAIN)"

The zip name and identifier come from variables near the top of the Makefile, where the extension name is desktop-cube and the domain is schneegans.github.com. So the installed identifier is [email protected]. The install recipe also prints the next step, which is to restart the Shell using Alt and F2 followed by r.

The build is a resource bundle, a schema and a translation catalogue

Looking at the Makefile shows how a GNOME Shell extension is actually packaged, which is useful if you want to understand the project rather than only run it.

The build collects JavaScript files, UI files, and resource files, then compiles the translation catalogue from the gettext .po files in the po directory into .mo files under locale. The content that goes into the extension zip is the JavaScript, the compiled locales, a gresource bundle, the GSettings schema named org.gnome.shell.extensions.desktop-cube.gschema.xml, metadata.json, the LICENSE, and stylesheet.css.

The schema is the configuration surface. A GNOME extension with settings cannot hardcode values, it needs a GSettings keyfile, and that file is both compiled into the zip and read by the preferences UI. The prefs.js file at the top of the tree is the settings panel, and extension.js is the entry point that GNOME Shell loads.

Translation is handled with standard gettext tooling. The pot target runs xgettext over the JavaScript files to generate po/desktop-cube.pot, with a package name and a copyright holder set. The project is hosted on Weblate for translations, and the documentation uses the tag for translators.

The repository also carries a LICENSES directory, a .reuse directory and a .clang-format file, so the project follows the REUSE conventions for per-file licence headers, and there is a scripts directory with a cloc script used for the line count badges shown in the project description.

Licensing is per file, and the code licence is not the documentation licence

The licence situation is worth reading carefully because the project uses the REUSE approach, where each file carries its own licence header.

The repository as a whole is recorded under GPL-3.0, with a LICENSE file and a LICENSES directory at the top level. But the headers tell a more precise story. The README file itself carries an SPDX header naming Simon Schneegans as the copyright holder and CC-BY-4.0 as the licence, which is a Creative Commons attribution licence appropriate for documentation. The Makefile carries its own header with SPDX-License-Identifier: MIT.

So the code, the documentation and the build files are not all under the same terms, and the project structure is designed to make that explicit rather than leaving it to a single root licence file. Anyone who wants to reuse the source code in a derived project needs to look at the per-file headers, not just the root licence, and anyone who wants to reuse the documentation or the images in docs/pics has a different, more permissive term to work with.

The point here is not legal advice but a practical reading instruction: the licence that applies to a given file is the one in its header, and the root GPL-3.0 applies to the code files that do not say otherwise.

The screenshots, the teaser video and the animated feature gifs are part of the documentation set rather than the code, and they carry their own terms under the same convention.

Comparing it with the Compiz behaviour it replaces

The honest comparison here is with the effect Desktop Cube is imitating, since the project describes itself as creating a similar effect for GNOME Shell, and points to other nostalgic extensions such as Compiz windows effects and Burn My Windows as things you might also like.

The difference in approach is architectural rather than cosmetic. Compiz was a separate compositing system that took over the window manager's rendering, which is why it could produce genuine 3D with depth, lighting and arbitrary effects on every window. Desktop Cube does not touch the compositor. It works inside GNOME Shell's own overview and workspace model, arranging existing workspaces around a virtual camera.

That constraint explains both what you get and what you do not. You get the cube, the rotation gestures, the panoramas and the window dragging without replacing your desktop environment, and the extension stays out of the way of everything else. What you give up is per-window 3D, and with it the wider effect ecosystem that came with a real compositor.

The other comparison worth making is between the Desktop Cube and the extensions it names as neighbours. Compiz windows effects and Burn My Windows are about window animations, whereas Desktop Cube is about workspace arrangement. They target different layers of the shell, so they are not competing choices in the same way, and the author lists them as further nostalgic extensions rather than as alternatives.

If your goal is genuinely three-dimensional windows rather than a three-dimensional workspace, a compositor based approach is the different route, and Desktop Cube will not get you there.

Editorial conclusion

Adopt Desktop Cube if you want the Compiz cube back on GNOME Shell and you are on GNOME 45 or newer, where the main branch applies. Skip it on X11 with several monitors, where the project documents the cube as sheared, and skip it if you need wrap-around between the last and first workspace, which the extension does not change. Verify first that your GNOME Shell version matches a supported branch, that the main branch covers 45 or newer while older shells need the gnome-40-41 or gnome-42-44 branches, and that the extension is available for your distribution.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Schneegans/Desktop-Cube on GitHub