mirror of
https://github.com/aphrody-labs/wordcraft.git
synced 2026-10-14 03:29:04 +00:00
* Rulers: table column and row markers; indents in a cell measured from it (#700) With the caret in a table, the rulers show the table, as Word's do: - The horizontal ruler marks the column borders of the caret's row (past the table's left edge); the vertical ruler marks the bottom of each of the table's rows on the page. Each marker has the resize pointer, a tooltip and a name for screen readers. - Dragging a marker drags that border exactly like a drag on the page (#600): a dashed guide, Escape cancels, one undo step on release through `table.resizeDrag`. On the horizontal ruler only the column left of the border changes and the columns right of it move along, so the table's width changes (Word's ruler); a row marker sets the row's height. The markers follow any drag of the table's borders, on the ruler or on the page. - In a cell, the indent markers and tabs are measured from the cell's text area (its box less its margins); they were placed as if the paragraph started at the page's margin. - Layout: `cell_margins` (a cell's own margins, else the table's, else Word's), so the ruler uses what the layout does. - UI: crates/ui-egui/src/table_ruler.rs; table_resize.rs starts a drag from a ruler marker (`grab`) and tells the ruler where a dragged border is (`moved`), sharing that computation with the dashed guide. - Tests: layout (cell_margins matches where each cell's text starts); kittest with real pointer events: a column marker drag (the marker follows, one undo step, the columns right of it keep their widths), a row marker drag, and an 18 pt drag of the left-indent marker in a cell indenting the paragraph 18 pt. Progress docs updated: ui-parity (rulers 70% -> 85%), gaps (the ruler's column markers are off the list), target-app-parity, ROADMAP. No new commands or labels (the tooltips reuse "Table Column Width" and "Table Row Height"). `cargo xtask ci` passes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Rulers: Shift works the other way round on the ruler; row markers beside a vertical merge Checked against Word (2019, Windows): on the ruler a column marker drag changes only the column on its left and the columns right of it move along (as before), and with Shift the neighbour makes up the difference, so the table keeps its width; on the page Shift does the opposite. The ruler now follows that: `ResizeDrag::plan` takes the Shift key and flips it for a drag started on a ruler marker. Since #669 a vertically merged cell's box spans all its rows, so a row marker took the merge's bottom when the merge was the row's leftmost cell. The marker now sits on the row's shortest box. (`Placed::Cell` patterns take `..` for #669's new field.) - Test (kittest, real pointer events): a Shift drag of a column marker on the ruler gives the neighbour's width to the column on the left and keeps the table's width. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Tables: Ctrl, Alt, left-edge and selected-cells border drags (#711) Word's border drags that #600 left out: - Ctrl while dragging a column border: the columns right of it share the change in proportion to their widths, so the table keeps its width (none narrower than the minimum). Ctrl wins over Shift; on the table's right edge only the last column changes. - The table's left edge can be dragged, from just outside it: the table's indent moves and the first column makes up the difference, so the other borders stay. A centred or right-aligned table becomes left-aligned where the edge was dropped; a floating table moves its horizontal offset. The horizontal ruler has a marker on it too. - Alt while dragging a column border: the horizontal ruler shows each column's width as it is going to be. - With the selection across two or more cells, dragging one of their column borders (in one of their rows) moves it only in their rows; the grid gets a line for the new border and the cells' spans follow. A border of a cell merged down past the selection moves in the whole column. Text selected within one cell isn't a cell selection (it can't be told from one selected cell yet), so it moves the whole column. - Engine: `Share` (who makes up a column border's move), `Edge::Column(0)`, `ResizeTarget::limit_to_selection`/`only`/ `planned_x`, `Plan::indent_by`/`cells`; `table.resizeDrag` takes `"ctrl"`. `plan` still takes a bool for Shift. Each drag is one command and one undo step. - UI: table_resize.rs (keys, a guide down the rows that move, `measuring`), table_ruler.rs (left-edge marker, `widths`). - Tests: engine (Ctrl in proportion and at the minimum; the left edge, also of a centred table; selected cells' rows only, with the grid and spans; a merged cell past the selection); kittest with real pointer events (a Ctrl drag, the left edge and its ruler marker, Alt's widths mid-drag). Progress docs updated: ui-parity (tables on the page 80% -> 90%), target-app-parity, ROADMAP. No new commands or labels. `cargo xtask ci` passes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Tables: a centred or right-aligned table keeps its alignment when its left edge is dragged Checked against Word (2019, Windows): dragging the left edge of a centred table widens the first column by the whole drag and the table stays centred (each side moves half); a right-aligned table keeps its right edge and grows to the left. Only a left-aligned table's indent moves. #711 made such a table left-aligned where the edge was dropped; now `move_left_edge` leaves a centred or right-aligned table's alignment and indent alone and says whether it moved anything, and the drop-point correction runs only then. The ruler's Shift (from #710) now goes through `share`: on a ruler marker Shift makes the neighbour take up the change, without it only the column on the left changes. - Tests: the left-edge test checks the centred table (first column +20 pt, the others unchanged, still centred) and a right-aligned one (only the left edge moves); a kittest Shift drag on the ruler. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: rabis <340973947+rabis7575@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com>