From 8110bb2773b6c841029a51eca7971f42a36f480c Mon Sep 17 00:00:00 2001 From: srdusr <99972264+srdusr@users.noreply.github.com> Date: Tue, 2 Apr 2024 00:58:00 +0200 Subject: Rewrite srdwm in Rust: working X11 and Wayland backends, Lua config The C++ prototype (moved to legacy-cpp/) was mostly a design skeleton: X11 and Windows backends were partially real, Wayland created the wlroots object graph but never wired a single event listener, macOS was stub except monitor enumeration, and the Lua engine's srd.bind() stored a key-combo string but never the actual closure. See docs/PRIOR_ART.md for the full audit. This replaces it with a Cargo workspace: - srdwm-core: platform-independent window/workspace/monitor state, a real master-stack tiling layout, and SmartPlacement grid/cascade/ snap-to-edge placement - fixing several bugs in the C++ version (hardcoded 2-column grid, cascade that never cascaded, snap-to-edge that always returned a fixed rect). 35 unit tests. - srdwm-config: the srd Lua API via mlua, implementing the surface docs/DEFAULTS.md always documented but the C++ engine never actually built (srd.window.close()/focus(direction), srd.workspace.next(), real keybinding closures, require("srd") support). 10 unit tests. - srdwm-x11: a real reparenting WM with a drawn title bar (buttons, drag, resize), verified live under Xephyr - frame placement and client offset match srdwm-core's computed geometry exactly, and the decoration renders correctly on screen. - srdwm-wayland: a from-scratch smithay compositor (the C++ version had nothing working to port from) - runs via the winit backend, tracks xdg-shell toplevels through the same WindowManager and hit-testing code X11 uses, verified to start/render/run without crashing. Decorations are solid-color (no text yet); see docs/IMPLEMENTATION_STATUS.md for exact scope. - srdwm-windows / srdwm-macos: structured, cfg-gated designs informed by komorebi/glazewm and yabai/AeroSpace respectively (see docs/PRIOR_ART.md), honestly marked as unbuilt/unverified since this sandbox has no Windows or macOS target. --- legacy-cpp/src/layouts/tiling_layout.cc | 38 +++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 legacy-cpp/src/layouts/tiling_layout.cc (limited to 'legacy-cpp/src/layouts/tiling_layout.cc') diff --git a/legacy-cpp/src/layouts/tiling_layout.cc b/legacy-cpp/src/layouts/tiling_layout.cc new file mode 100644 index 0000000..440c95a --- /dev/null +++ b/legacy-cpp/src/layouts/tiling_layout.cc @@ -0,0 +1,38 @@ +#include "tiling_layout.h" +#include + +TilingLayout::TilingLayout() { + // Constructor implementation +} + +TilingLayout::~TilingLayout() { + // Destructor implementation +} + +void TilingLayout::arrange_windows(const std::vector& windows, const Monitor& monitor) { + std::cout << "TilingLayout::arrange_windows called for monitor:" << std::endl; + std::cout << " Position: (" << monitor.x << ", " << monitor.y << "), Dimensions: (" << monitor.width << ", " << monitor.height << ")" << std::endl; + std::cout << " Number of windows: " << windows.size() << std::endl; + + // Basic placeholder tiling logic (e.g., splitting the screen vertically) + if (!windows.empty()) { + int window_width = monitor.width / windows.size(); + int current_x = monitor.x; + + for (size_t i = 0; i < windows.size(); ++i) { + SRDWindow* window = windows[i]; + // In a real implementation, you would calculate the desired + // position and size for the window based on the tiling algorithm + // and then call a method on the window object (which would + // internally use the platform backend) to apply these changes. + std::cout << " SRDWindow " << window->getId() << ": Placeholder position (" << current_x << ", " << monitor.y << "), size (" << window_width << ", " << monitor.height << ")" << std::endl; + + // Update the window's properties in the SRDWindow object + window->setPosition(current_x, monitor.y); + window->setDimensions(current_x, monitor.y, window_width, monitor.height); + + + current_x += window_width; + } + } +} -- cgit v1.2.3