Win8DE: a Windows 8 style shell for Wayland compositors

What the author says the project is for

The README opens with a short description of the situation, and it is unusually direct about who the project is for. It is for people who enjoyed Windows 8 and miss its fluid animations but have since moved to Linux, and who cannot go back to Windows 8 because all the apps are non functional there, and who cannot install it on newer hardware.

The reply is a shell for Wayland window managers like Labwc and Hyprland. The components it lists are a wallpaper utility, a lock screen, a start menu, an OSD for volume and brightness, and a settings app for the wallpaper.

One omission is stated with a reason. There is no charms menu, because the author always thought it was useless. That is a small detail and a useful one, because it tells you the scope was decided by taste rather than by a checklist.

The repository is described as a windows 8 like de for linux, and the primary language is recorded as QML. The top level of the repository makes the component structure plain, with a directory per program: Win8Corner, Win8Lock, Win8OSD, Win8Running, Win8Settings, Win8Start and Win8Wall, alongside assets/, battery/, network/, tiles/ and list-windows/. The licence is GPL-2.0, the default branch is master, the last push was on 2026-04-03, and there are no GitHub releases.

The start menu, and how the live tiles work

The start menu is the component with the most features listed, and the list reads as a description of the Windows 8 behaviour being reproduced.

There is one command, Win8Start, to show or hide the start menu, and it can be bound to the super key of the compositor. The tiles support full drag and drop, with sizes small, medium, large and xlarge, configured graphically, and with a right click option. You can drag an app from the all-apps view into a tile, the app search works, and you can drag an app from the all-apps view to the bottom to hide the start screen and drop the icon anywhere the desktop supports it. Clicking the user icon opens the power menu, and there is a battery on-screen display built in.

The live tiles system is the part that makes this more than a screenshot of a start menu. It supports live tiles for tiles in the start menu, and the mechanism is a convention rather than a plugin API. You put the logic.py and or tile.qml in the config directory path .config/Win8Start/tiles/appname/tiles.qml || logic.py, and there is no need to install anything for it. The README explains the choice of Python as being due to its non compiled nature and the ease of programming, and notes that a QML file can function without a logic.py if you know how to make one, using the Qt documentation to understand it.

That design decision is the interesting part. A live tile is a small program that renders a widget and updates itself, and the template treats that program as a file you drop into a directory. The tile directory name is the app name, and the files inside are the tile's own code. There is no manifest, no registration step and no build, which means a tile can be written in QML alone or given logic in Python, and the cost of adding one is a directory.

The consequence is that the tile system is only as good as what people write for it, and the repository has a tiles/ directory at the top level, which suggests the bundled examples live there.

The OSD, the wallpaper and the lock screen

The on-screen display is split into two parts, which is worth understanding because it changes how it is started. There is a Win8OSD-server and a Win8OSD-client, and the server does not need to be autostarted. The client is what you invoke, with arguments for volume up, volume down, mute, display up and display down.

Win8OSD-client --volup voldown mute dispup dispdown

So the design is that the OSD appears on demand when something else asks for it, rather than sitting in the session waiting for events. That suits a compositor environment, where the volume and brightness keys are usually bound to the compositor's own actions, and where a permanent overlay would be in the way.

The wallpaper component is simpler. It is a simple image wallpaper that supports GIF, it is settable through the settings app, and the wallpaper gets blurred when the mouse is not over it, and the GIF also stops playing, so it does not consume CPU.

That last point is a genuine design decision rather than an accident. An animated wallpaper that keeps decoding frames while it is hidden is a real cost on a laptop, and a wallpaper utility that pauses itself when it is not being looked at is doing something a plain wallpaper setter cannot.

The lock screen is Windows 8 in style, with a wallpaper changeable by the settings app, a slide down and up animation, and a difference from the original: you do not need to click and drag, a click is enough.

The settings app covers the rest. It can change the wallpaper of all three graphical surfaces, the start menu, the wall and the lock screen, and it can change the accent colours and the background colours of the start screen and lock screen.

Building it, and the dependency list it assumes

This is a source build, not a package. The README gives two routes, and the dependencies are listed by distribution.

For Arch, the dependency list is a build toolchain and the Qt 6 stack: cmake, gcc, ninja, pkgconf, then qt6-base, qt6-declarative, qt6-wayland, plus layer-shell-qt, wayland, pam and glibc.

sudo pacman -S --needed - < dependencies.txt

The repository ships a dependencies.txt at the root for that command, along with a list-deps.sh script.

The build itself is a shell script.

./build.sh

It builds all the binaries and puts them in the build/bin folder, and you can use them in config files to autostart and bind to the system keys for brightness and volume with a local location. There is a caveat the README spells out: you cannot run the settings from the start screen, because it uses the system location, so you will have to run it from the built binary. That is a direct consequence of the design where each program can use its own config directory, and the settings app deliberately does not.

The install route runs the build and moves the binaries to /usr/local/bin/ so they are available systemwide, which the README says makes it easier to put them in configs and autostart.

./install.sh

And the reverse.

./uninstall.sh

It removes the binaries from /usr/local/bin/. There is no package recipe, no AUR entry and no flatpak manifest in the repository listing, so the install path is a git clone, a build and a copy.

Running it as a separate session, through a .desktop entry

The most useful idea in the README is the last one, and it is a workaround for a real limitation.

Because each program reads its own configuration directory, the way to keep Win8DE from disturbing your current setup is to give it a different configuration. The instruction is to create a copy of the config folder and paste it with a different name, like labwc2 or hypr2.

Then you find your compositor's config loading command and make a .desktop file for it. The README gives the shape of the entry.

[Desktop Entry]
Name=labwc-win8
Comment=A wayland stacking compositor
Exec=labwc -C /usr/share/labwc3
Icon=labwc
Type=Application
DesktopNames=labwc;wlroots

You paste it into /usr/local/share/wayland-sessions/, and at login you choose that session. The point of the DesktopNames key is that the session file declares which Wayland implementation it belongs to, so the display manager can group it correctly.

So the intended usage is: you already run a Wayland compositor, you want the Windows 8 shell on top of it for a session, you give it a separate configuration so nothing you had is touched, and you pick it from the login screen.

The repository layout backs this up. There is a Win8Corner/ directory, which is presumably the corner overlay, a Win8Running/ directory for the running applications view, a battery/ directory, a network/ directory, and a list-windows/ directory, so the set of programs is broader than the four features the introduction names.

Where Win8DE is the wrong tool

Three cases point elsewhere. The first is a user who wants a Windows 8 replacement as a complete desktop environment. Everything here is a shell that sits on top of a compositor, and the README names the compositors it targets, Labwc and Hyprland. If your problem is that you have no window manager at all, this does not solve it.

The second is a user on a distribution whose packages cannot supply the dependency list. The build wants Qt 6 declarative, Qt 6 Wayland, layer-shell-qt, pam and glibc, and the README only gives the Arch recipe. A Debian, Fedora or Arch derivative user will have to translate the package names, and the layer-shell-qt dependency in particular is not in every distribution's archive. The project is a source build with one documented packaging route, and that is a real barrier to adoption outside Arch.

The third is a user who wants the Windows 8 look and expects it to behave like Windows 8. The README is honest that the apps are non functional on the original, and this project is about the shell, not the applications. Anyone hoping for a Windows 8 compatibility layer will find a start menu and a lock screen and nothing else.

The alternative worth comparing is using the compositor's own shell, since a compositor can be configured to handle launching and wallpapers itself, and a tiling window manager's own key handling is designed to be bound to the same keys. The difference in approach is that those are integrated: the launcher's bindings, the bar, the wallpaper and the compositor's own animations are one system, tuned together. Win8DE is a set of separate programs that layer a Windows 8 skin over an existing session, and it uses the layer-shell protocol, which means it can draw panels and overlays above or below other surfaces.

The price of that separation is visible in the README's own caveat about the settings app needing to run from the built binary, and in the need to give the whole set a separate configuration directory and a separate session entry. For a user who wants the look and nothing else, that is a reasonable trade; for a user who wants a coherent desktop, the compositor's own shell is the better answer.

Editorial conclusion

Win8DE fits a Linux user on a Wayland compositor who misses the Windows 8 tile interface and wants it layered on top of a setup they already have. It does not fit a user who wants a complete desktop environment, because everything here assumes a compositor underneath, and it does not fit a distribution whose package manager cannot supply the listed Qt 6 and Wayland dependencies. Before you build it, read the dependency list and the build script, since the binaries are compiled rather than shipped, and remember that the settings app has to be run from the built binary because it uses the system location rather than the per-session config.

Frequently asked questions

Official sources

1. er-bharat/Win8DE on GitHub
2. Issues
3. License: GPL-2.0
4. README