Every operating system has a window manager. Most people just never realize they’re using one. On Linux, you get to choose — and that choice changes everything.
Let’s start with the basics
A window manager is exactly what it sounds like — software that manages your windows. It decides how they appear on screen, how they move, how they stack, how they animate, what happens when you switch between them.
That’s it. That’s the definition.
But here’s what most people don’t realize: every operating system has one. Windows has one. macOS has one. Your phone has one. The difference is that on Windows and macOS, you never get to touch it. It’s baked in, locked down, invisible. On Linux, it’s just another piece of software you can swap out.
How Windows and Mac handle it
Windows — Desktop Window Manager
On Windows, it’s called Desktop Window Manager, or DWM. You’ve probably never heard that name, and that’s entirely intentional.
DWM was introduced with Windows Vista in 2006 — a complete rethinking of how Windows drew things on screen. Before Vista, every application drew directly to the display buffer. If a window was covered by another and then revealed, Windows had to ask the app to redraw itself. It was messy, slow, and caused those visual tearing artifacts you might remember from the XP era.
DWM changed this by giving every application its own offscreen buffer. Each app draws into its own private space, and DWM composites everything into one final image using your GPU. This is what enabled Windows Aero — the glass-like transparency, the live taskbar thumbnails, the smooth window animations that felt futuristic in 2006.
You’re a user of the environment, not the owner of it.
macOS — Quartz Compositor
Apple’s equivalent is called Quartz Compositor, and it’s been at the heart of macOS since the very first release in 2001. Where Windows built compositing on top of an existing system, Apple designed it in from the start — a complete departure from the old QuickDraw system that powered classic Mac OS.
The idea is elegant: every app renders its window contents into a bitmap. Quartz acts as what Apple itself calls a “visual mixing board” — it takes every window’s bitmap, applies transparency, shadows, positioning, and blends them into one final frame. The famous Genie effect when you minimize a window to the Dock? That’s Quartz. The blur behind notification panels? Quartz.
The fun fact: Quartz 2D internally uses the PDF format as its drawing model. Every shape, every glyph, every vector graphic on a Mac is technically described in the same format as a PDF document. This is why macOS has always had flawless font rendering — it’s been running a PDF engine under the hood for over two decades.
Apple doesn’t let you touch any of this. The WindowServer process — which is Quartz — is one of the most protected processes on macOS. You can’t kill it, can’t modify its behavior, can’t even inspect it properly without disabling System Integrity Protection.
💡
In 2014 Apple integrated Metal into Quartz. By macOS Mojave 2018,
OpenGL was deprecated entirely. On Apple Silicon, Quartz is tied into
unified memory — CPU and GPU share the same pool. The compositor and
your apps run closer together than on any other mainstream platform.
Different cage. Cleaner bars.
Linux is different
On Linux, the window manager is just a program. You can install it, remove it, replace it, configure it down to individual pixel behavior. This is both the most liberating and most overwhelming thing about the Linux desktop.
Because Linux separates the window manager from everything else, a whole ecosystem of options exists. And if you’re new to Linux, you usually don’t start with a bare window manager — you start with a Desktop Environment (DE), which bundles a window manager together with a file manager, a settings app, a taskbar, system utilities, and a coherent visual theme.
The major ones: KDE Plasma, GNOME, XFCE, Cinnamon. Each was built by real people with real philosophies.
KDE was founded in 1996 by Matthias Ettrich, a CS student at the University of Tübingen, Germany. He was 23 years old. He looked at the Linux desktop — scattered, inconsistent, hostile — and wrote a mailing list post saying “we can do better.” That post started one of the longest-running open source projects in history.
GNOME came a year later, started by Miguel de Icaza — a Mexican developer who grew up where proprietary software was inaccessible. Open source was his only path into high-level technology. GNOME was his response to KDE’s dependency on Qt, which at the time wasn’t fully free. He built it on GTK — the toolkit written for GIMP.
The one I find myself thinking about most is Ettrich. A 23-year-old student, frustrated with the state of something, writing a public post saying “we can do better” — and then actually doing it. That’s a specific kind of engineer mentality. The ego that sees a problem and can’t leave it alone.
The DE rabbit hole — my honest takes
KDE — too much of everything
KDE was my first. And on paper, it’s impressive — it has more customization options than any other desktop environment. Themes, widgets, color schemes, animations, panel layouts. You can make it look like anything.
The problem is that “you can make it look like anything” and “it looks good” are two very different things.
The KDE theme ecosystem felt fragmented — powerful, but inconsistent. Thousands of options, no coherence between them. You mix a window decoration from one creator, an icon pack from another, a color scheme from a third — and the result looks like a patchwork quilt. I was never fully comfortable running community-made customization scripts I hadn’t inspected myself. Installing things through a GUI storefront always felt harder to trust than editing my own config files.
You’re customizing inside someone else’s boundaries. The walls just have more paint. I could change the appearance of the system more easily than its underlying behavior.
And here’s the thing — technically, I could have made KDE look exactly like my current Hyprland setup. But doing that means editing files you’re not supposed to touch, files the GUI overwrites every time you change a setting. After every major KDE update, half of it breaks. You’d be fighting the system constantly.
GNOME — cleaner, but still not mine
GNOME is the opposite philosophy. Minimal options, opinionated defaults, clean out of the box. And honestly — out of the box, it looked genuinely good. The rounded corners were actually rounded, unlike KDE’s sharper default aesthetic. The color schemes were coherent. The spacing felt considered.
But then I started wanting more.
I wanted blur in the terminal. I wanted to jiggle the cursor to make it larger when I lost it on screen. I wanted system-wide transparency I could actually control. GNOME had simply decided these were not user-accessible decisions.
GNOME extensions existed, but they broke with every major update — a well-documented, well-complained-about problem in that community. I went back to KDE a second time, this time with the engineer’s mentality properly engaged. Not “how do I make this look right” but “how does this actually work.” I got into config files, started version-controlling my dotfiles, learned Vim properly. The ego that refused to let a broken install beat me was now the same ego that refused to stay on the surface of things.
But I still felt like I was fighting the system rather than working with it.
Hyprland — where everything made sense
By this point, it was getting late. Not philosophically late — practically late. Real development was being compromised. Projects were sitting untouched. I was spending hours configuring instead of building.
I could have gone further with KDE or GNOME. But that path required just knowing — memorizing workarounds, tracking which extensions still worked, accumulating tribal knowledge about a system I didn’t fundamentally control. It didn’t require solving. And the distinction mattered to me.
Hyprland is not a desktop environment. It’s a Wayland compositor — which means it handles both window management and rendering directly. No DE on top. No GUI settings panel. Just a config file.
-- open terminal
hl.bind("SUPER + Return", function()
hl.dispatch(hl.dsp.exec("kitty"))
end)Open it in Neovim. Change a line. Save. Done. There’s no abstraction between me and what the system does. Every behavior — window animations, workspace switching, keybindings, window rules, monitor layout — is a line in a text file that I wrote. I know what every line does because I put it there.
There is no settings panel to blame when something breaks. There is only you, your config, and the truth.
The bounce
One of the first things I did after getting Hyprland stable was customize the workspace switching animation. Hyprland lets you define animation curves using bezier functions — mathematical curves that control how animations accelerate and decelerate.
I spent two hours watching a video on bezier curves. I didn’t become an expert. But I learned enough to understand what I was tweaking. I came out with a bounce animation that triggers every time I switch workspaces — quite noticeable, deliberately so. I didn’t pick it from a list. I built the curve myself, adjusting numbers until it felt exactly right.
hl.config({
animations = {
bezier = "myBounce, 0.05, 0.9, 0.1, 1.05",
animation = "workspaces, 1, 5, myBounce, slide"
}
})That’s a small thing. But it’s entirely mine.
The night before differential equations
Hyprland 0.55 dropped a major update. And this wasn’t a minor version bump — it was a fundamental change to the entire config system.
For four years, Hyprland had used its own custom syntax called hyprlang. It was simple: key = value. But as Hyprland grew, the syntax got increasingly ugly:
windowrule = immediate yes, border_size 4, class:^(app)$, title:^(sus)$In 0.55, Vaxry replaced the entire thing with Lua:
hl.windowrule({ class = "app", title = "sus" }, {
immediate = true,
border_size = 4,
})Structured. Readable. Programmable. A proper scripting language instead of a custom format. The right call. But it broke my entire config — every window rule, every animation, every keybind.
Timing: the night before my differential equations final. Entire config broken. Pulled up a 5-6 hour Lua course. Rewrote everything from scratch in 4+ hours. By the time I was done I checked end4-dotfiles — an update was already there. Someone had already done the migration. I don’t regret rewriting it myself.
I could have copied someone else’s migration, but rewriting it myself forced me to actually understand the system. I know Lua now. I understand my config at a level I didn’t before.
The only thing I actually regretted was looking at the clock and realizing I’d spent 12+ hours on my computer and my differential equations revision still wasn’t done. The exam was in the morning. The config was perfect. My maths was not.
The break was the lesson. Again.
The bigger idea
There’s a culture around Arch Linux and setups like mine that looks from the outside like pure ego — “I use Arch btw,” the tiling WM screenshots, the terminal-everything aesthetic. And some of it is ego, I won’t pretend otherwise.
But there’s something real underneath it. The same mindset you see in low-level programmers who insist on understanding every layer of the stack, right down to the metal. The ones who live by the idea that to make an apple pie from scratch, you must first create the universe. It’s not practical. It’s a philosophy. You should know what you’re standing on.
A window manager is just software. But choosing one — configuring it, breaking it, fixing it, making it yours — forces you to understand how your computer actually works. What renders your windows. What handles your inputs. What decides how animations behave.
Windows and macOS make that invisible because invisibility is comfortable. Linux makes it visible because visibility is powerful.
Linux doesn’t guarantee ownership. It just makes it possible.
The moment you understand what a window manager is and realize you’ve been using one your whole life without knowing it — something shifts. You start asking what else is invisible. What else has been decided for you. What else you could own if you chose to.
That question, more than any specific tool or setup, is what Linux actually teaches you.
Running Hyprland on Arch Linux on an Acer Predator Helios Neo 16. Yes, it was a bad idea. No, I don’t regret it.