About LEF Desktop

LEF started as a tech preview. A way to show what the Waxed Display Server could actually do in practice, not just in theory. But somewhere along the way it became more than a demo. It became a real desktop environment that could genuinely compete with what's already out there. And more importantly, it became a statement.

The Linux desktop space has settled into some comfortable ruts. GNOME keeps trimming features because they know best. KDE piles on options because more is more. The Wayland crowd has spent years turning the display layer into a political battleground where every feature needs a security justification and a three-year debate. LEF exists to say: there can be a different path. Wayland should not be the inevitable future of Linux desktops. We can do better.

The name

LEF. Take the letters K, D, E and shift each one forward in the alphabet. You get L, E, F. Draw your own conclusions about whether that's a jab at the established order or just a coincidence.

But there's more to it. K becomes L. D becomes E. E becomes F. Each letter moves forward by exactly one position. Not backward. Not sideways. Forward. In every direction that matters, LEF is a step ahead. A single alphabetic leap upward across the board. If you wanted to be charitable, you could read it as a quiet statement of intent: this isn't just another desktop environment, it's the next one.

And "lef" also means courage in Dutch, which felt appropriate for a project attempting to do what this one does.

Plugins, lots and lots of plugins

Early in development, it became clear that building LEF as a monolithic desktop would be a mistake. Sure, it would show off the technology fine. But it wouldn't be extensible. Nobody could take it and build their own alternative without essentially rewriting everything. That seemed like a missed opportunity.

So LEF is essentially a scenegraph. Plugins place objects on that scenegraph according to the API that Waxed exposes. To unpack that a bit: Waxed tells the outside world what it can do, things like "I can give you a surface to draw on." A plugin registers a hook to handle that API call. When an application wants a window, Waxed asks the plugin "how do you want to handle this?" and the plugin does the work. The complete flow, from application to window to screen, flows through these hooks.

But maybe you think differently. Maybe you want API calls that Waxed didn't define by default. Maybe you want to remove calls you don't want to support. All of that is possible from within LEF, and therefore from within every LEF plugin. You can add new API hooks to Waxed and implement them yourself. You can remove ones you don't like. The flexibility is extreme.

There are limits, though. Some functionality sits in a weird middle ground between Waxed, LEF, and individual plugins. Virtual desktops are the main example. I intentionally decided that switching between virtual desktops is a core Waxed feature that you cannot override. The reason is purely technical: if virtual desktops were managed by a plugin, you couldn't have virtual desktop 1 be LEF and virtual desktop 2 be a completely different desktop plugin. But if virtual desktops live in the Waxed core, that becomes fairly straightforward. A virtual desktop plugin in LEF, then, is more about the graphical presentation of desktops, like a pager or workspace switcher, and less about the bookkeeping.

More plugins

The Linux desktop world has long had a fragmented mess around on-screen displays. Volume changes. Brightness adjustments. Notification popups. Every desktop environment reinvents these. Waxed advertises functions for all of them. Within LEF, there's a plugin that registers support for those calls and shows you a nice visual style. If you don't like the visuals, you swap the plugin. The API stays the same.

Hardware acceleration, Vulkan

I've told people before that adding Vulkan to an existing compositor is madness. It serves no real benefit for the amount of work involved. But starting from scratch? Different story.

Vulkan provides features that are genuinely helpful for desktop development. Descriptor indexing. Better threading. More control over memory. Why shouldn't game technology serve your desktop interface and make it pretty? I didn't want the flat surfaces and resize hiccups that so many projects have dealt with. It's time for beautiful UI to become the standard on Linux desktops. We have the tech. Use it.

Vulkan support these days is mature and widely adopted. Even on Linux, across various hardware vendors, the support is surprisingly up to date. Seemed like a no-brainer to just commit and go Vulkan-only. The threading model alone might change how UI toolkits work under Linux, though I need to experiment more with that later.

Why not OpenGL or OpenGL ES?

I did briefly consider these. Much of what LEF needs has been possible in OpenGL for years, if not a decade or more. And in terms of hardware support, it would open things up significantly. OpenGL ES would let Waxed and LEF run on ten-plus-year-old hardware. That looked interesting.

But I decided against it for a simple reason: OpenGL development seems to have died. Vulkan development, on the other hand, is very lively. By now there are tons of online resources, tutorials, examples. Sorry to the old hardware, but you're not supported. Vulkan 1.2 would be the bare minimum, though currently 1.3 is required.

Some things that will be controversial

LEF will do things that Wayland proponents consider heresy.

Global pointer coordinates. Session state saving so applications remember where they were when you closed them. These aren't hard problems. The fact that Wayland has spent years debating them instead of just implementing them is absurd. Wayland should end its existence. It has caused enough political nonsense and stifled enough innovation with its ideological motivations. Just implement the features. It's not that hard.

Also controversial: no sandboxed packaging formats

LEF will not support Flatpak, Snap, or AppImage. Many recent decisions in the Linux ecosystem have been driven by these formats, and they've led to some questionable choices like the XDG Desktop specifications. The result is intentional layering of complexity in the name of "security" while in reality it's just a nightmare to use.

LEF will use a different approach. Maybe at a later point sandboxed applications will be supported. For now, LEF will not pick security over sensible logic. First priority is getting things working properly without being artificially limited.

LEF isn't against sandboxing in principle. But the current implementations are horrible, so they're rejected. Instead, LEF will use standard Linux .desktop files to determine how permissions should be handled. Small, focused applications that do one thing. The existing mime-preferences logic, a Linux standard for decades, can then be used to tweak those to desktop-specific implementations.

Theming, but with shaders

Like everything else, theming is a plugin too. But you'll have a hard time finding images. In LEF, nearly the entire desktop is built out of shaders.

We made this choice with one goal: make the best use of the GPU and animate the hell out of everything. We want a beautiful desktop, and in a next-level setting like LEF, it makes sense to use shaders. Why draw flat rectangles when your GPU can do so much more?

The theming engine isn't that complicated. Effectively it has a list of properties where a shader needs to apply. A surface defines the shader that needs to apply to it, along with all its static rules. A window, which technically inherits from a surface, adds window controls on top of that shader. But it also defines sub-shaders for window actions. Close button hover state? Shader. Minimize animation? Shader. The whole thing is composable and GPU-accelerated from the ground up.

SVG, QOI, and leaving PNG behind

The Linux desktop has been stuck in old technology for decades. Not because those choices were wrong at the time, they weren't. But UI interfaces and icons have been stuck in PNG, with some SVG, for a very long time. Thumbnails are stuck in PNG. These formats aren't bad. They're just in need of an update.

LEF will break tradition. Its tools will exclusively use newer and better formats by default. A file manager generating thumbnails should opt for QOI. Like PNG, it's lossless. Unlike PNG, it's vastly more performant while maintaining similar file sizes. Decoding speed matters when you're scrolling through thousands of images.

Icons should be done in SVG, or another vector format, with an efficient decoder and rasterizer. The technology exists. It has existed for years, and even more so recently. Here too, it's time to start using it.

AI-built

LEF wouldn't exist without AI. GLM models, specifically. Started with 4.6, moved to 4.7, now on GLM 5. This isn't a talking point. It's the reason the project exists at all.

One developer building a desktop environment from scratch is absurd on its face. The scope is too large by orders of magnitude. There's window management, input handling, rendering, IPC, configuration systems, panel widgets, notification protocols, and about a thousand other things that all need to work together. But AI handles the implementation grunt work, and suddenly "absurd" becomes "hard but possible."

To be completely clear about what this looks like in practice: I'm not generating code blind and shipping whatever comes out. I still steer the whole thing. I still debug. I still have to understand what's being built well enough to catch mistakes. The AI implements ideas, explores approaches I might not have considered, iterates quickly when something doesn't work. I direct. It executes. The back-and-forth is where the actual progress happens.

A call to fellow desktop developers

KDE. GNOME. XFCE. Hyprland. COSMIC. Sway. Cinnamon. Mate. Budgie. All of you.

You could technically all be Waxed plugins. You could have many core features simply built in instead of reinventing them. VSync, VRR, multi-monitor handling, input processing. All of that could be shared infrastructure instead of duplicated effort across a dozen projects.

Let's stop the insane fragmentation that Wayland brings and join together in Waxed.

You can do it. I can't.

Check out the code on GitHub or browse the available plugins to see what LEF can do.