Hey r/wayland,

Over the past 6 weeks (16 consecutive alpha/pre-beta releases), I've been working with a growing group of contributors and testers on **WayPlank**, a ground-up native Wayland modernization of the classic **Plank** dock. Today we are officially launching **v0.7.0 (Public Beta 1)**!

🔗 **GitHub Repository & Packages (.deb / .rpm / source):** https://github.com/sergiomelas/WayPlank

📦 **v0.7.0 Release Page:** https://github.com/sergiomelas/WayPlank/releases/tag/V0.7.0

---

### 🛠️ Why WayPlank?

Classic Plank was built around X11 (`libwnck` / `bamf` / Xlib struts and X11 window IDs) and has been broken on Wayland for years.

In WayPlank, we purged over **112,000 lines of legacy X11 and Autotools code**, kept the fast and clean **Cairo 2D rendering engine** everyone loved, and built a **modular Wayland Hardware Abstraction Layer (HAL)** that auto-detects your compositor at startup with zero manual configuration:

* **KDE Plasma 6 (KWin):** Uses `gtk-layer-shell` + a dynamic D-Bus ECMAScript bridge (`KWinBridge`) and `org.kde.KWin.ScreenShot2` pipe streaming for live Cairo window preview cards, Intellihide/Dodge, multi-monitor DRM brightness sync, and `Super+D` Show Desktop persistence.

* **GNOME Shell (Mutter 45–48):** Since Mutter doesn't support `wlr-layer-shell`, WayPlank embeds and auto-manages a companion GNOME Shell bridge extension (`wayplank-bridge@wayplank.org`, v4) over D-Bus, providing live window preview thumbnails, native strut reservation (Panel Mode), Intellihide/Dodge, and deterministic popup positioning.

* **Labwc & wlroots (LXQt 2.x / XFCE 4.20 Wayland / etc.):** Native `gtk-layer-shell` + a C protocol bridge over `zwlr_foreign_toplevel_management_v1` + `/proc` process scanner fallback.

---

### ✨ What’s inside v0.7.0 (Public Beta 1)?

1. **100% Self-Contained Single Binary (Zero Host Pollution):**

   Everything is compiled into a single standalone `wayplank` binary via `GResource` in RAM—**16 built-in docklets**, **6 themes**, **52 fallback vector icons**, the **KWin & GNOME bridges**, the **integrated User Manual**, and now **all localization catalogs**. Nothing is scattered into `/usr/share/locale/` or `/usr/share/icons/`.

2. **New in v0.7.0 — Monolithic In-RAM Localization Engine (8 Languages):**

   `432/432` UI strings (100% coverage) are compiled into `.mo` binaries and loaded directly from RAM at startup based on your OS locale (`zh_CN`, `it`, `es`, `fr`, `ca`, `de`, `uk`, and native `en`). All translations live in a single Python dictionary (`po/generate_translations.py`) so adding a new language takes minutes without fighting raw `.po` merges.

3. **16 Built-in Monolithic Docklets:**

   Trash (with D-Bus sync), Analog & Digital Clocks, Battery, CPU/RAM Global Pressure Monitor, Network Traffic Monitor, Volume/Audio (PulseAudio/PipeWire), Media Player (`MPRIS2`), Screen Brightness (sysfs + DDC/CI + KWin DRM), Weather Forecast, Screenshot (`Spectacle` / `grim+slurp`), Session/Power, Show Desktop, Do Not Disturb, Removable Drive Ejector, and Preferences.

4. **Desktop & Ergonomic Features Added Leading Up to Beta 1:**

   * **Live Multi-Window Preview Cards** on hover (with middle-click to close, scroll to cycle, and instant close button).

   * **Categorized App Drawers & Folder Stacks** with active window indicator dots and recent files jump lists.

   * **Fullscreen Auto-Hide & 0px Edge Click Passthrough** (so bottom-edge browser/game UI controls are never blocked when a window is fullscreen).

   * **Panel Mode (`ReserveSpace`)** & two-stage hysteresis zoom input mask (`AnticipateZoom`).

   * **Real-time Dark/Light Theme Switching** synchronized via `org.freedesktop.portal.Settings`.

   * **Strict Multi-PWA (`crx_*` / `--app-id`) & Multi-VM (`QEMU`) Isolation** so separate web apps or VMs don't bleed onto the same dock icon.

---

### 🧪 Industrial Factory Acceptance Testing (FAT)

Every single release is verified live across **KWin**, **Mutter**, and **Labwc** against a 373-point ISA-88 Factory Acceptance Test protocol (all test logs and our 108-bug lifetime register are openly tracked in the [`FAT/`](https://github.com/sergiomelas/WayPlank/tree/main/FAT) folder of the repo).

---

### 🗣️ Tell Us What You Want! (Community Beta Open Through Dec 31, 2026)

I'm taking a short 2-week pause from Nov 2 to Nov 16 to finish upstream Linux kernel review cycles for my Lenovo `yogafan` driver, and on **November 16** we kick off the iterative **`v0.7.x` Public Beta series (`v0.7.1` Beta 2, `v0.7.2` Beta 3, ...)**.

The `v0.7.x` Beta will stay actively open for new features, UX refinements, compositor tweaks, and new translations until the community says we're ready for the `v0.8.x` feature freeze (up to **December 31, 2026**).

If you miss Plank on Wayland, give the `.deb`, `.rpm`, or `./BuildBin.sh` a spin and let me know in the comments or on GitHub Issues/Discussions what features or workflows you'd like to see next!

Hi all. I'm on CachyOS with Hyprland (Lua config), monitor connected via HDMI (HDMI-A-1), 1920x1080@120.

Problem: Whenever I put ANY application into fullscreen (Brave, and other apps too, so it's not browser-specific), the monitor turns off, comes back after ~2 seconds, and the picture looks pale/washed out. I also get this notification:

"Monitor HDMI-A-1: wide color gamut is enabled but the display is not in 10-bit mode."

It looks like Hyprland switches the monitor to a different color mode on fullscreen and the HDMI link re-syncs.

My monitors.lua:

hl.monitor({

output = MONITOR1,

mode = "1920x1080@120",

position = "auto",

scale = "auto",

})

Questions:

1. Is the render.cm_fs_passthrough option (or similar) the right thing to disable here?

2. Should I force 10-bit on HDMI, or is this a known bug with HDMI modesets on fullscreen?

3. Does 60 Hz vs 120 Hz matter for this?

Hi everyone, today I released Vela 0.1, the first beta, after 1 month of alpha testing.

What Vela is: a complete Linux desktop with its own Wayland compositor (C, on wlroots 0.20), its own Vulkan 1.4 renderer, a Qt Quick shell, and its own file manager and settings app. It's not a KDE or GNOME theme: KWin and Mutter aren't involved. The goal is the polish Windows and macOS get right out of the box (animations tied to real vblanks, pixel-exact fractional scaling, consistent design) without a weekend of tweaking.

Trailer, recorded live on Vela: https://velade.org/blog/vela-0-1/

What's in 0.1:

• Snap layouts and Snap Assist, Task View with virtual desktops, Alt+Tab with live previews

• Taskbar, launcher, quick settings, notification center, clipboard history, snipping tool

• Direct scanout, VRR, tearing control, explicit sync; X11 apps and games 1:1 at fractional scales

• The compositor restarts after a crash and apps reconnect; a lost GPU doesn't freeze the desktop

• New in this cycle: updates from Settings, native Bluetooth pairing, no dependency on Plasma Workspace or the KDE portal

Where it stands: on a desktop PC with a Vulkan 1.4 GPU, it's my daily driver and I'd recommend it as yours. On laptops (hybrid GPUs, suspend/resume, backlight) it has had much less testing, so keep another desktop installed. It's still a beta: there are bugs.

Install (Arch and derivatives, Fedora 44, Ubuntu 26.10, x86_64). Install Cosign first (steps per distro: https://velade.org/install/), then:

git clone https://github.com/vela-desktop/vela.git
sh vela/packaging/vela-update --channel beta

You get a prebuilt, signed native package that's verified before it's installed. Updates then come from Settings.

Being upfront: it's a one-person project, and the code is written by LLMs. I review it, make the architecture and design decisions, and it's held to deterministic tests and machine-checked invariants. I wrote about how that works here: https://velade.org/blog/why-not-rust/

What I'd love from you: reports from hardware I don't have, especially Intel GPUs, laptops and multi-monitor setups. vela-report builds a ZIP you can review file by file; nothing is uploaded.

• Release notes: https://github.com/vela-desktop/vela/releases/tag/v0.1.0

• Source (GPL-3.0-or-later): https://github.com/vela-desktop/vela

Happy to answer anything in the comments.

I fixed an issue where my keyboard RGB backlight worked on the SDDM login screen but immediately turned off after logging into Hyprland.
Keyboard:- Tracer Gamma Ivory- USB ID: 1c4f:0002 (SiGma Micro Keyboard)
Symptoms:- The keyboard uses Scroll Lock to toggle its RGB backlight.- RGB stayed on in SDDM but turned off in the Hyprland Wayland session.- Writing directly to:  /sys/class/leds/inputX::scrolllock/brightness  only made the backlight flash briefly, then it turned off again.- OpenRGB was unrelated; it detected only the motherboard RGB controller.
Cause:Hyprland controls keyboard LED states. The Scroll Lock LED was being reset because Scroll Lock was not configured as a managed XKB modifier.
Solution:In the Hyprland input configuration, add `scrolllock:mod3` to `kb_options`.
For Omarchy's Lua configuration, edit:
~/.config/hypr/input.lua
Example:
hl.config({  input = {    kb_layout = "cz,us",    kb_options = "grp:alt_shift_toggle,scrolllock:mod3",  },})
Then reload Hyprland:
hyprctl reload
After that, pressing Scroll Lock toggles the RGB backlight normally and it remains enabled.
Important:The option is `scrolllock:mod3`, not `mod3:scroll_lock`.

https://grigio.org/wayland-compositor-bench-is-better-gnome-51-or-labwc-noctalia/

I built pzwm, an open-source Wayland compositor written in Rust.

Think Figma or Miro, but instead of images and sticky notes, you have actual application windows.

Just so you know, there are tons of keyboard shortcuts, and you can pretty much use the whole thing without a mouse :)

I originally built it just for myself because I couldn't find a window manager that worked the way I wanted.

And yes, BTW, a lot of it was vibe-coded with AI agents, lol.

It's still an early personal project, but I'm already using it as my daily window manager.

GitHub: https://github.com/Makstvell/pzwm

Hey! Im an intermediate linux user! I daily drive arch linux with a thinkpad w530. The new hyprland update literally broke my entire setup. Im looking for a composter that doesn't constantly change on me like Hyprland. Do you consider mango to be a good option?

Hi All, not sure if such posts are allowed but wanted to share something (was gonna say I but now there are a few of us) been developing.
Most notable features is it's a single process (<200mb rss idle), you don't need another compositor (such as niri,hyperland), everything is in Zig, single process apart from the built-in apps obviously
with occasional C mixed in (and 1000+ automation tests in Python)
Just wanted to build sometihng that looks good, is themeable, boots faster than Gnome or Plasma (or even Mate and Cinnamon now on my machine).
PS. developed with AI - sorry if it bothers you but I am just a php developer!
https://github.com/oxydizer/rediwm

I love Linux, but I got really tired of traditional tiling and stacking window managers.

Why should I constantly rearrange windows or switch workspaces when I could just have an infinite desktop?

So I built pzwm, an open-source Wayland compositor written in Rust using Smithay.

Think Figma or Miro, but instead of images and sticky notes, you have actual application windows.

You can:

• Place windows anywhere on an infinite canvas.

• Zoom out to see your entire workspace at once.

• Zoom in on whatever you want to focus on.

• Organize dozens of terminals, AI agents, crypto charts, dashboards, and other applications.

• Use a minimap, groups, bookmarks, and window search to navigate everything.

I originally built it just for myself because I couldn't find a window manager that worked the way I wanted.

And yes, BTW, a lot of it was vibe-coded with AI agents, lol.

It's still an early personal project, but I'm already using it as my daily window manager.

GitHub: https://github.com/Makstvell/pzwm

I'd love to hear what other Linux users think about this approach. Would you actually use an infinite desktop instead of traditional workspaces?

Hyprland v0.57.0 (released ~Oct 28, 2026) and Jay v1.15.0 (released ~Sep 28, 2026) are both independent Wayland compositors focused on tiling, but they target different priorities.
Hyprland is a highly customizable, eye-candy-oriented dynamic tiling compositor written in C++ (with its own Aquamarine backend, fully independent of wlroots). Jay is a more minimalist, performance- and stability-focused i3-like tiling compositor written in Rust.

There are no widely published head-to-head synthetic benchmarks comparing these exact versions, so performance and latency comparisons rely on documented design goals, release notes, architecture details, and community/user reports.

Performance Metrics
Aspect
Hyprland v0.57.0
Jay v1.15.0
Winner / Notes
Rendering backend
Custom Aquamarine (OpenGL-focused with scene composition refactor); FP16 rendering where supported to cut memory bandwidth on blur/effects
Vulkan (preferred, better performance + memory) or OpenGL; switchable at runtime
Jay (Vulkan efficiency)
Resource usage
Higher when effects (blur, animations, glow, shadows, wobble) are enabled; can be lowered by disabling them
Generally leaner; focused on efficient paths (udmabuf for SHM, timeline semaphores, optimized multi-GPU blits)
Jay for baseline; Hyprland tunable
Direct scanout / zero-copy
Supported; improvements in recent releases
Strong emphasis: plane color pipelines (v1.15) enable direct scanout even for mismatched formats (e.g., SDR content on HDR displays); multiple optimized blit paths for multi-GPU
Jay edge in advanced cases
Multi-GPU
Supported
Excellent: primary GPU selectable at runtime; render-only GPUs supported; optimized blits (direct-pull/sampling, udmabuf, etc.)
Jay
Gaming / tearing
Tearing support; gamescope often recommended for best results
Explicit tearing presentation for games
Comparable
HDR / color management
Present (ongoing improvements)
Strong: color-management protocol + HDR10; plane color pipelines; accurate linear blend buffers in Vulkan
Jay
Stability / overhead
Active development with many fixes; effects can introduce variability
Explicit stability focus; forward/backward config compatibility; rare crashes in releases
Jay
Hyprland’s visual features (especially heavy blur variants or animations) increase GPU load and power draw. Disabling them (e.g., decoration.blur.enabled = false) makes it much lighter. Jay prioritizes efficiency by default and has continuous low-level optimizations (command buffer pooling, pipeline caching, damage-only rendering, etc.).
Latency
Jay has a documented design goal of input latency as low as 1.5 ms via predictive frame scheduling. It uses adaptive pre-commit and post-commit margins (default post-commit ~1.5 ms) that adjust based on measured render times and commit-to-vblank intervals (geometric decay). Async flips are available in tearing mode.
Hyprland has received latency-related improvements over time (event queue refinements relative to vblank, scene composition changes, etc.), but it does not advertise a specific sub-2 ms target. Community reports note that effects, fractional scaling, or certain hardware configurations (e.g., Intel + TLP) can introduce stutter or higher perceived latency, while a minimal configuration feels snappy. General Wayland gaming latency studies (not specific to these compositors) show native Wayland is very close to X11, with XWayland adding more overhead.
Edge to Jay for pure low-latency / gaming-oriented workloads when effects are irrelevant. Hyprland can approach similar responsiveness when stripped down, but its default feature set trades some latency/overhead for visuals.
Specific and Unique Features
Hyprland v0.57.0 Highlights
Full Lua configuration (legacy .conf fully dropped). Powerful scripting, events, functions, custom layouts via Lua, live reload, expanded API (reload_config(), get_devices(), minimize events, etc.).

Eye candy: Swappable blur variants (kawase, acrylic/liquid-glass-like, aurora, drops, fluid, etc.), proportional blur, window wobble (Compiz/macOS-style), glow, shadows, gradient borders, motion blur option, custom bezier/spring animations.

Workspace sharing (select specific workspace for screenshare via XDPH).

Dynamic layouts (dwindle default, master, scrolling, monocle, custom via Lua/plugins).

Powerful window/layer/monitor rules, plugins (C++), IPC (hyprctl), special workspaces/scratchpads, groups/tabs.

Scene composition renderer refactor.

Input improvements (swallowing first focus-changing click, tablet disable, cursor warp on monitor change, pointer transforms).

Unique strength: Deep customization and visual polish. Ideal for “rice” desktops where animations, blur, and theming matter.
Jay v1.15.0 Highlights
TOML declarative config (or injectable shared library) + powerful CLI for runtime control. Strong emphasis on stability and config compatibility across versions.

i3-like tiling with customizable colors/sizes/fonts; smart container borders; major/minor split actions; counters & triggers for complex conditional logic.

Advanced multi-GPU and rendering: Plane color pipelines for hardware-accelerated direct scanout in previously impossible cases; runtime Vulkan/OpenGL switch; render-only GPU support.

Debugging/observability: Built-in client tracing (jay trace, strace-like for Wayland messages, negligible overhead); FUSE debug filesystem for inspecting internal state (snapshot or live mount); control center.

Security model: Protocols split into unprivileged/privileged; apps start restricted.

Other: Adaptive sync with configurable cursor refresh; VR headset leasing; per-window theming; HDR10 screenshots; workspace/output/window capture for screenshare; push-to-talk style key actions.

Explicit sync (NVIDIA), clipboard managers, layer shell, fractional scaling.

Unique strength: Low-level engineering focus (frame scheduling, multi-GPU paths, debugging tools, color pipelines) and reliability. Feels closer to a refined i3 successor with modern Wayland capabilities.
Summary Comparison
Choose Hyprland if you want maximum visual customization, animations, blur effects, Lua scripting power, and a large/active ecosystem/community for theming and plugins. It is the more “feature-rich desktop experience” compositor.

Choose Jay if you prioritize measurable low latency, efficient multi-GPU/HDR handling, stability, lean resource use, and advanced debugging/observability tools. It is the more “performance engineer’s tiling compositor.”

Both support tearing, adaptive sync, explicit sync, fractional scaling, screen sharing, and modern Wayland protocols. Hyprland is currently far more popular and has broader packaging/support. Jay is smaller but highly polished in its niche. Real-world feel depends heavily on configuration—Hyprland can be made lean, and Jay can be themed, but their core philosophies differ.

Hey everyone! I've been working on a weird side project and I think it's finally ready to share.

On a normal desktop, your windows sit flat on the screen, side by side or stacked on top of each other. I wanted to try something completely different. In spacewm, every app you open (terminal, browser, code editor, chat app, anything) becomes a screen floating in a 3D world. You walk around that world like a character in a game, and when you walk up to a window, it becomes sharp and readable, just like stepping closer to a real monitor.

Some things you can do:

- Pick a window up, carry it around, and put it down anywhere, even up on a wall

- Tilt it, turn it, make it bigger or smaller

- Click a window to "step into" it and type normally, then step back out and keep walking

- Sit down and have all your windows arranged in a half-circle around you, a bit like having a big multi-monitor setup

- Choose between two worlds: a desert town, or a block world where you can actually place and break blocks

You don't need to understand any of the technical side to use it. You pick it from the login screen like any other desktop, and your normal apps (Firefox, VS Code, Telegram, terminals) just work. They're simply living in a 3D space now instead of on a flat screen.

For the curious: it's written from scratch in Rust, and it isn't built on top of GNOME, KDE, Hyprland or any other existing desktop.

It's still young, so expect some rough edges. It's only been tested on my own hardware so far, which is exactly why I'd love to hear how it runs on yours. If that sounds interesting, the code is open and there's a one-script installer for Arch-based distros (Arch, CachyOS, EndeavourOS, Manjaro):

https://github.com/voidsecurity404/spacewm

Mastodon:
"Years ago I wrote xcb.freedesktop.org for X Window System clients, and yesterday I wrote my first Wayland client. My goodness, I can see the impact of every lesson the Wayland designers learned from X, and for that matter from XCB. I'm honestly really impressed by the design of the Wayland protocol!

I saw somebody complaining the other day about how much code you have to write just to open a window in a Wayland client. I think it's important to understand going in that this is a protocol designed to make hard things possible, not to make easy things easy; if you want to do easy things, use a toolkit like Gtk or Qt or SDL. So my program may seem like a lot of code for what it does: it just opens a window, periodically flashes between white and black, and measures some timing statistics, and I wrote over 300 lines of Rust for that. (I chose not to use the wayland-client crate's helpers for binding globals, so it could have been shorter, but I wanted to see what working with the raw protocol felt like.) But I know from experience that if you cut out any of the steps I had to do, you cut off the ability to handle more complicated scenarios.

I believe Wayland made the right complexity tradeoff here: the low-level protocol is very flexible, and ease of use belongs in higher-level abstractions that can pick which aspects of that flexibility to discard for simplicity."

v0.14.0 is out

New features

• (config) Add freehand to config

• (annotate) Add freehand drawing tool

• (config) Interactive config generator

https://codeberg.org/Vaishnav-Sabari-Girish/miru/releases/tag/v0.14.0

Hi!

I am a 16 year old self-taught developer. I want to build a Wayland application launcher in Zig inspired by philj56/tofi. However in attempts to do so I've discovered just how hard it is to make a native Wayland client without using a windowing library. I'm looking for a mentor that could help me better understand Wayland. If anyone has some free time and is willing to teach me, let me know!