HWDE

HackerOS Wayland Desktop Environment.

HWDE - HackerOS Wayland Desktop Environment

HWDE is the native desktop environment for HackerOS, a Linux distribution aimed at daily use, gaming, cybersecurity work, development, and privacy-conscious users.

This is the SolidJS + Rust/Tauri v2 + Smithay rewrite of the original React prototype. The visual design is intentionally unchanged for this milestone — only the implementation moved.

Layout

HWDE-Project/
├── source-code/
│   ├── frontend/         SolidJS + TypeScript shell UI (Vite)
│   └── backend/
│       └── src-tauri/    Rust/Tauri v2 backend -> binary: starthwde
├── compositor/           Smithay 0.7 Wayland/XWayland compositor -> binary: comphwde
├── hwde-ipc/              Shared IPC protocol crate used by both binaries
├── config/                .desktop / session / distro packaging files
├── images/                Source art (logo, default wallpaper) - see images/README.md
├── Cargo.toml             Cargo workspace
└── Makefile               `make build`, `make shell`, `make compositor`, `make install`, ...

Building

make build          # everything, release mode
make shell           # just starthwde (frontend + Tauri backend)
make compositor       # just comphwde
make dev              # run the shell windowed, no compositor (fastest inner loop)
sudo make install     # install binaries + session file + default wallpaper

Requirements: Rust >= 1.80 (via rustup — the crates.io ecosystem has moved to the 2024 edition; distro-packaged Rust on Debian/Ubuntu stable is often too old), Node.js >= 20, and the usual Tauri v2 Linux dependencies (libwebkit2gtk-4.1-dev, libgtk-3-dev, librsvg2-dev, ...) plus Wayland compositor dependencies (libwayland-dev, libxkbcommon-dev, libinput-dev, libgbm-dev, libseat-dev).

This project was assembled in a sandboxed environment whose Rust toolchain (1.75) was too old to fully cargo check starthwde and comphwde against current crates.io dependency versions (which now require the 2024 edition). The SolidJS frontend was fully installed, type-checked, and built successfully. The shared hwde-ipc crate was compiled successfully. Please run cargo check --workspace on a machine with Rust >= 1.80 before your first real build and file issues for anything that needs adjusting — the code follows Smithay's own reference compositor (anvil) patterns closely, but Smithay's API does shift between point releases.

starthwde usage

starthwde              full graphical session - meant to be launched by
                        SDDM (see config/session/hwde.desktop) or from a
                        TTY. Spawns and supervises comphwde.
starthwde dev           runs the shell as an ordinary windowed app. No
                        compositor is spawned; some system integration
                        (real wallpaper via comphwde, external app
                        launching) is unavailable in this mode.
starthwde app <name>     launches a single HWDE app (e.g. `settings`,
                        `clipboard`, `about`, `emoji`) with no shell chrome.

comphwde <-> starthwde integration

starthwde and comphwde talk over a small NDJSON protocol on a Unix socket (see hwde-ipc/). Today this is used for:

• starthwde spawning comphwde and waiting for it to become ready.
• The shell asking the compositor to launch an external application (launch_external_app Tauri command -> IpcRequest::LaunchApp) as a normal Wayland/XWayland client of the session.
• Session shutdown.

Wallpaper

HWDE manages exactly one piece of desktop configuration today: the wallpaper. Both starthwde (for the webview background) and comphwde (for the real compositor background) default to:

/usr/share/wallpapers/HackerOS-Wallpapers/Wallpaper23.png

images/wallpapers/Wallpaper23.png in this repo is a placeholder - swap it for the real HackerOS artwork; make install copies it into place.

Known scope / next steps

This milestone deliberately keeps the compositor small so it's reviewable and buildable incrementally, per the project's own roadmap:

• Only the windowed (winit) backend is implemented. A DRM/udev/libseat backend for driving real hardware from a bare TTY is the next major piece of work.
• No layer-shell, server-side decorations, or wlr clipboard/data-device protocol yet.
• XWayland windows are mapped into the desktop, but interactive move/resize via the X11 protocol isn't implemented yet.
• The in-shell "external apps" registry is intentionally minimal for now (launch_external_app takes a raw command); richer app management (rules, workspaces-per-app, etc.) is future work, as discussed.