KDE developers just merged a subtle but noticeable change into KWin. Windows that once looked out of place on Plasma desktops will soon cast proper shadows. The update arrives with Plasma 6.8. And it targets those stubborn applications that draw neither their own shadows nor ask the compositor to do so.
Vlad Zahorodnii, a key KWin contributor, detailed the work in a blog post published today. He explained the split in how shadows appear. “Drop shadows are drawn either by the compositor or the application,” Zahorodnii wrote. GTK apps often handle shadows client-side. Qt apps typically request the compositor to draw both decoration and shadow. But some apps do neither. That leaves them square, flat and inconsistent.
Take Discord as the prime example. Under default settings in current Plasma, it shows sharp corners. No shadow falls around its frame. Titlebar buttons clash with Breeze styling. Zahorodnii shared side-by-side images. The left window looks alien. The right one, with the new server-side shadow enabled, gains rounded corners, an outline and a soft drop shadow. It blends. The close, maximize and minimize buttons still don’t match perfectly. Yet the overall effect pulls the app into the desktop environment rather than leaving it adrift.
This isn’t entirely new behavior. Users could force similar results in Plasma 6.7. They created a window rule for server-side decoration. Then they overrode the Breeze decoration to hide the titlebar. Zahorodnii outlined the exact steps for Visual Studio Code. The process worked but demanded manual tweaks for each app. Plasma 6.8 automates much of that friction.
A new window rule does the heavy lifting. Called “Window manager draws titlebar, frame, and shadows,” it replaces the older “No titlebar and frame” option. Select it for a specific application. KWin steps in. The compositor adds the shadow, frame and handles rounding where supported. KWin also applies the change automatically to X11 windows lacking both server-side decorations and client-side shadows. Wayland support stays more cautious. Sub-surfaces complicate matters there. Zahorodnii noted a dedicated protocol may be required before automatic handling extends to Wayland clients.
Decorations must opt in for full compatibility. They declare support in metadata. The format looks like this: “org.kde.kdecoration3” with styles array containing both “shadow” and “titled”. The decoration code then checks KDecoration3::Decoration::style() and adjusts visuals accordingly. Hide the titlebar. Draw only the shadow. Simple in theory. But not every third-party decoration implements it yet.
The change landed in KWin within the past day. Phoronix first reported the merge, highlighting its arrival in Plasma 6.8. Zahorodnii’s own post on his personal blog provides the technical depth and screenshots. He called it a quick update. “This is a small thing but I hope that people will find it useful for making their desktops look more eye-candy,” he added.
Consistency has long frustrated Linux desktop users. Electron-based apps in particular often ship with their own client-side decorations. They ignore system themes. They ignore system shadows. The result feels disjointed. GNOME’s Mutter compositor takes a stricter path and avoids server-side decorations entirely under Wayland. KDE has chosen the opposite direction. It expands compositor control where possible. This latest patch continues that philosophy.
Performance implications appear minimal. The feature reuses existing shadow rendering code in KWin. No new blur algorithms or heavy computation enters the picture. The gain comes from visual polish and reduced user configuration. Fewer manual rules. Fewer forum posts asking why one app looks different. For daily drivers who mix toolkits, the difference will register immediately.
Plasma 6.8 already packs other compositor changes. KWin dropped desktop OpenGL support earlier this month, shifting to OpenGL ES internally. The move supports older hardware while paving the way for future Vulkan work. Server-side shadows fit into the same broader effort to modernize and simplify the window management stack. But, unlike the OpenGL shift, this one carries immediate aesthetic payoff.
Adoption depends on decoration authors. Breeze already supports the new styles. Other popular themes will need updates to declare the “shadow” variant and respond to the style signal. Until then, users may see partial results with some themes. The window rule still functions. Full visual harmony requires both sides of the equation.
Zahorodnii hasn’t posted follow-up details since the merge. The Planet KDE aggregation picked up his blog entry within hours. Community reaction on X remains light so far. One Bulgarian-language post shared the Phoronix link. No major developer threads surfaced in the past 24 hours. That quiet often precedes broader discussion once Plasma 6.8 testing builds circulate.
The feature won’t transform the desktop. It won’t fix every theming mismatch. But it removes one persistent source of friction. Apps that previously required workarounds now receive shadows by default or with a single rule. For users who value a cohesive look, the change matters. It signals continued attention to detail in an area many projects treat as solved.
Plasma 6.8 remains months from final release. Features continue to land weekly. This one slipped in under the radar until Zahorodnii wrote it up. Expect more refinement before the beta cycle. Additional decorations may add support. Wayland discussions could produce a protocol extension. For now, the foundation exists. And the screenshots look promising.
WebProNews is an iEntry Publication