diff options
| author | srdusr <[email protected]> | 2025-11-07 14:04:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2025-11-07 14:04:00 +0200 |
| commit | ea78f94027ecd2c690904a6d7729e9e3cc190a20 (patch) | |
| tree | fe622c0cd12a2fe077501a26f0077c51d41b4209 /crates/core/src/manager/mod.rs | |
| parent | a8991f65602abc5ecee740c443c58fa96ecd15e1 (diff) | |
| download | srdwm-ea78f94027ecd2c690904a6d7729e9e3cc190a20.tar.gz srdwm-ea78f94027ecd2c690904a6d7729e9e3cc190a20.zip | |
Make tiling's master/stack ratio live, add settings readback everywhere
Investigated the "tiling needs a lot of work" report directly. The
MasterStackLayout algorithm itself was already correct; the real gap was
that dragging or resizing a tiled window did nothing durable (raw
geometry that the next arrange_workspace silently discarded), and
master_ratio/master_count had no live path at all (config-file only).
A resize-drag on the shared master/stack boundary now live-adjusts
TilingConfig::master_ratio and re-arranges the group immediately; srd set
master_ratio/master_count do the same for a keybind or script. Found and
fixed a real bug while building this: start_resize's own focus_window
call re-stacks its target in self.order before the ratio-drag decision
used to be made, silently misclassifying real master-column grabs.
Fixed by deciding ratio-drag status (and freezing the membership
snapshot it depends on) before that raise happens, applying
MasterStackLayout directly against the frozen snapshot rather than
re-deriving membership from the by-then-reordered live order. Live-
verified in a nested compositor, not just unit-tested.
Also closes the readback gaps flagged directly by the AGS peer session:
border_width/border_color/corner_radius/decoration_mode/gap_inner/
gap_outer/master_ratio/master_count were all live-settable via srd set
with no way to read the current value back, and pin_input had no
readback at all. SettingsResponse now reports all of them; a new
pinned_inputs query (srd pinned inputs) lists every currently pinned
pid/window.
Diffstat (limited to 'crates/core/src/manager/mod.rs')
| -rw-r--r-- | crates/core/src/manager/mod.rs | 24 |
1 files changed, 24 insertions, 0 deletions
diff --git a/crates/core/src/manager/mod.rs b/crates/core/src/manager/mod.rs index c9c77b2..e4ac1c2 100644 --- a/crates/core/src/manager/mod.rs +++ b/crates/core/src/manager/mod.rs @@ -49,6 +49,23 @@ struct ResizeState { start_x: i32, start_y: i32, orig: Rect, + /// `self.tiling.master_ratio` at the moment this resize started -- + /// unconditionally captured (cheap, one `f32` copy) even for a resize + /// that turns out not to touch it, the same way `orig` itself is + /// captured regardless of whether the drag ends up floating or tiled. + /// See `WindowManager::adjust_master_ratio_for_drag`'s own doc comment + /// for why a live tiling resize needs its own *starting* ratio, not + /// just the live one mutated in place tick by tick. + orig_master_ratio: f32, + /// `WindowManager::tiling_ratio_drag`'s result, decided once here, + /// *before* `start_resize` calls `focus_window` - `Some(membership)` + /// for a tiling master/stack ratio drag, `None` for an ordinary + /// (floating, or non-boundary-edge) resize. See that method's own doc + /// comment for why this has to be captured now rather than + /// re-derived later: focusing the target re-stacks it in `self.order`, + /// the exact list membership is read from, and re-deriving after that + /// point silently answers for the wrong window. + ratio_drag_ids: Option<Vec<WindowId>>, } /// The platform-independent core of srdwm: owns window/workspace/monitor @@ -80,6 +97,12 @@ pub struct WindowManager { /// ever learn) to a specific window. See `input_pin.rs`'s own doc /// comment. pin_input_requests: Vec<(i32, Option<WindowId>)>, + /// `pid`'s *actual current* pin state, as last reported by `Comp + /// State::set_virtual_pointer_pin` once it's genuinely applied -- + /// distinct from `pin_input_requests` above, which is a one-shot queue + /// drained and forgotten the moment the backend picks it up. See + /// `set_pinned_window`'s own doc comment. + pinned_windows: HashMap<i32, WindowId>, /// Same cross-boundary-request pattern, for fake (fully virtual, no /// real hardware) monitors - see `fake_monitor.rs`'s own doc comment /// and `crates/wayland/src/udev/virtual_heads.rs`'s module doc @@ -465,6 +488,7 @@ impl WindowManager { monitors: Vec::new(), output_position_requests: Vec::new(), pin_input_requests: Vec::new(), + pinned_windows: HashMap::new(), create_fake_monitor_requests: Vec::new(), remove_fake_monitor_requests: Vec::new(), output_enable_requests: Vec::new(), |