Open-source project
Schneegans/Burn-My-Windows avatar
Schneegans/Burn-My-Windows

Burn-My-Windows: GLSL Window Effects for GNOME Shell and KWin

🔥 Disintegrate your windows with style.

3,082 stars111 forksJavaScriptGPL-3.0

At a glance

What is it?
Burn-My-Windows adds shader-driven close and open animations to GNOME Shell 45+ and KWin. Here is how the extension is built, how to install it, and where it stops being the right tool.
Who is it for?
Adopt Burn-My-Windows if you run GNOME Shell 45 or newer (or KWin) and want window transitions implemented as GLSL shaders rather than a particle system. Skip it on GNOME 44 and older, where the main branch does not apply and you must switch to the gnome-3.36-44 branch, and skip it on desktops with no GNOME Shell or KWin component, which is why searches for a Cinnamon or a Windows 11 build have no matching artifact here.
Can I use it commercially?
Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly JavaScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What Burn-My-Windows Actually Replaces

GNOME Shell plays a short, fixed animation when a window closes or opens. Burn-My-Windows replaces that transition with a shader: the window is not faded out over a fixed duration, it is consumed by a fragment program that can disintegrate it, shatter it, beam it away, or melt it. The README frames the project as the successor to a joke request, saying the author was asked to "revive one of the most useless features of Linux desktop history: Setting windows on fire", and it is honest about the cost, calling the extension "much more hacky" than the Desktop Cube extension that preceded it.

The audience is narrow and specific. You need GNOME Shell or KWin, you need to be willing to install a shell extension, and you need to accept that window animations run inside the compositor process. This is not a theme, and it is not a wallpaper engine. It hooks the window lifecycle and draws into it. The README table lists the shipped catalogue, including Apparition, Aura Glow, Broken Glass, Doom, Energize A and B, Fire, Focus, Glide, Glitch, Hexagon, Incinerate, Matrix, Mushroom, Paint Brush and Pixelate. Several of these carry configuration notes: Broken Glass can be set so shards fly away from the mouse pointer position, and the Matrix effect's color is configurable.

How the Shader Pipeline and the Two Backends Fit Together

The repository layout tells most of the story. There is a top-level extension.js and prefs.js, a src/ directory of JavaScript modules, a resources/ directory holding the compiled gresource bundle, and a separate kwin/ directory for the KWin port. The topics list names gjs, GLSL and gnome-shell-extension, so the runtime is GJS, the JavaScript binding for GNOME, and the visual work is done in GLSL shaders shipped as resources.

The Makefile confirms the packaging model. Its ZIP_CONTENT variable bundles the JavaScript sources, the compiled translation files, resources/burn-my-windows.gresource, two GSettings schema files (org.gnome.shell.extensions.burn-my-windows.gschema.xml and the -profile variant), metadata.json and the LICENSE. The gresource file is the mechanism that gets shader sources and UI definitions into the extension without loose files on disk.

Two details matter for anyone evaluating it. First, the README states plainly that "the code in the main branch is for GNOME Shell 45+", with a gnome-3.36-44 branch for older versions. That is a hard compatibility boundary, not a soft one. Second, the KWin side lives in its own directory rather than being generated from the GNOME code, which means the two backends are maintained in parallel. A fix or a new effect on one side does not automatically appear on the other.

Installing Burn-My-Windows and Running a First Effect

The README points at extensions.gnome.org as the distribution channel for GNOME users, and the Makefile provides a local build path. The install recipe builds the zip and hands it to gnome-extensions, then tells you to restart the shell:

bash
make install

The Makefile's own output states: "Extension installed successfully! Now restart the Shell ('Alt'+'F2', then 'r')." That restart step is not optional on a Wayland session, where the Alt+F2 run dialog does not restart the compositor the same way. Log out and back in if the keybinding does nothing.

If you only want the archive, the zip target produces it without touching your session:

bash
make zip

The resulting file is named [email protected], following the NAME and DOMAIN variables at the top of the Makefile. To remove the extension again, the uninstall recipe calls gnome-extensions uninstall with the same identifier:

bash
make uninstall

After installation, effects are selected in the extension's preferences window, which is what prefs.js and the resources UI files build. Pick one effect, close a window, and watch the transition. If nothing changes, the shell is still running the old code.

The Compatibility Boundary Is the Main Limitation

The most consequential constraint is stated in a single line of the README: the main branch targets GNOME Shell 45 and newer. If you are on GNOME 44 or earlier, the code in this branch is not for you, and the project directs you to the gnome-3.36-44 branch instead. That branch is a separate line of development, so it will not carry the same effects or the same fixes at the same time.

The second limitation is structural. Window animations run inside the compositor, and the README describes the approach as hacky by the author's own admission. When a shader misbehaves, the symptom appears in the shell process, not in a sandboxed application. That is a different failure surface from a normal desktop application, and it is the reason the project ships a test suite and a checks workflow rather than relying on manual verification alone.

The third limitation is scope. There is no Cinnamon, MATE or XFCE backend in the repository layout, and no Windows build. Searches for those combinations return nothing this project can satisfy. The code targets GNOME Shell and KWin, and the top-level kwin/ directory is the only evidence of a second compositor.

Burn-My-Windows Against Compiz-Style Particle Effects

The obvious comparison is the original Compiz fire effect, and the README makes the distinction itself: the Fire effect is "implemented using a GLSL shader and not with a particle system like in the old days". That is a real architectural difference, not a marketing line. A particle system spawns and integrates many small objects per frame; a fragment shader evaluates a function per pixel. The shader approach scales with resolution rather than with particle count, and it produces a continuous deformation of the window surface rather than a cloud of sprites in front of it.

The trade-off runs the other way too. A particle system can be tuned by changing emitter parameters at runtime, and its behaviour is easy to reason about frame by frame. A shader effect is only as configurable as the uniforms the author exposed, which is why the README can list specific knobs for Broken Glass and Matrix but not for every effect. If you want to invent a new transition by tweaking parameters in a settings panel, this project gives you a fixed catalogue plus a few options. If you want to write the transition yourself, you are editing GLSL and rebuilding the gresource bundle.

Maintenance, Licence and the Cost of Upgrading

The last push to the repository was on 2026-09-23, and the most recent release is v48 from 2026-03-15, following v47 in 2025-08-25 and v46 in 2025-03-09. The release cadence is roughly aligned with GNOME's own cycle rather than with a fixed schedule, which is what you would expect from a shell extension: a new GNOME release can break the extension, and the version number here tracks the shell generation it supports.

That cadence defines your upgrade cost. Upgrading GNOME Shell means waiting for a matching Burn-My-Windows release, and the v48 release notes are the place to check whether your shell version is covered. The project also carries translation work through Weblate, so localized preference strings may lag behind the English source.

The licence is GPL-3.0 for the extension itself. The README's SPDX headers show a split: the README is CC-BY-4.0 and the Makefile is MIT, while the repository ships a LICENSES/ directory and a REUSE.toml for per-file compliance. If you intend to redistribute the extension inside a distribution image or a custom spin, the GPL-3.0 terms apply to the extension code, and the REUSE metadata is the authoritative map of which file carries which licence. This is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt Burn-My-Windows if you run GNOME Shell 45 or newer (or KWin) and want window transitions implemented as GLSL shaders rather than a particle system. Skip it on GNOME 44 and older, where the main branch does not apply and you must switch to the gnome-3.36-44 branch, and skip it on desktops with no GNOME Shell or KWin component, which is why searches for a Cinnamon or a Windows 11 build have no matching artifact here. Before installing, confirm your shell version against metadata.json and check that the effects you want are listed in the README table, since the extension ships a fixed catalogue rather than a general animation engine.

Frequently asked questions

How do I install Burn-My-Windows?

The README links to extensions.gnome.org, where the extension is distributed for GNOME users. For a local build, the Makefile provides make install, which creates the zip and runs gnome-extensions install with the --force flag before asking you to restart the shell.

What is Burn-My-Windows?

It is a GNOME Shell and KWin extension that replaces the standard window close and open animations with GLSL shader effects. The README lists effects such as Fire, Broken Glass, Doom, Matrix and Pixelate, and notes that the Fire effect uses a shader rather than a particle system.

How do I configure Burn-My-Windows?

Effects are selected and adjusted in the extension's preferences window, which is built from prefs.js and the UI files under resources/. The README notes that some effects expose their own options, such as Broken Glass using the mouse pointer position and Matrix having a configurable color.

Is there a Burn-My-Windows alternative for other desktops?

The repository only contains backends for GNOME Shell and KWin, with the KWin code in a separate kwin/ directory. There is no Cinnamon, MATE or Windows implementation in the layout, so a comparable effect on those desktops would come from a different project.

Official sources

  1. Issues
  2. License: GPL-3.0
  3. README
  4. Releases
  5. Schneegans/Burn-My-Windows on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/schneegans-burn-my-windows.svg)](https://hysenlabs.com/projects/schneegans-burn-my-windows)