Give the canvas tools a rail of their own, and the column one width
Build and test / Desktop (Linux) (push) Failing after 1h14m38s
Build and test / Layer separation (push) Successful in 48s
🐳 Android image / Build and push (push) Successful in 16m30s
Build and test / android-image (push) Successful in 16m31s
Traceability / Requirement traces (push) Successful in 1m47s
Build and test / Android (aarch64) (push) Successful in 1h0m21s
Build and test / Desktop (Linux) (push) Failing after 1h14m38s
Build and test / Layer separation (push) Successful in 48s
🐳 Android image / Build and push (push) Successful in 16m30s
Build and test / android-image (push) Successful in 16m31s
Traceability / Requirement traces (push) Successful in 1m47s
Build and test / Android (aarch64) (push) Successful in 1h0m21s
Crop, Local and Repair were chips at the head of the develop column, sharing a row with the adjustment groups and told apart from them by the shape of their highlight. Three things followed from that, and only the last is cosmetic: the column closes, so the way out of a mode went away with the way in — hence the duplicate "Done Cropping" over the canvas; the chips are generated from the operation set, so the widest thing in the sidebar was a row nobody had chosen the contents of; and a mode and a filter are different kinds of state wearing one control. They are a fixed 60px rail down the left now, generated from a single table in toolrail.slint. A tool is one row of it plus a drawing plus a ViewMode variant; nothing in app.slint is touched to add one. What is left of the strip is the group filters, so it is GroupStrip. The column stops measuring itself. Every panel published a content-width and declared it as min-width, and the column took the largest — which spent the photograph's pixels on whatever happened to be widest, and moved the image sideways when switching tools swapped one set of panels for another. It is panel-width now, one number in style.yaml. That number is 360 and it is measured, not picked: the contents report a minimum of 344 in every mode, and they do not compress below it because a Text that does not elide reports the same minimum as preferred. 320 was tried and sliced Paste down the middle. The Flickable's viewport is floored at the layout's minimum rather than its preferred width for the same reason — content that is never told how much room it has cannot adapt to having less. Removing the eight content-width declarations repairs three comments an earlier edit had spliced sentences into. The raw histogram's note on keeping its hint short is rewritten rather than dropped: an over-long hint no longer widens the column, it pushes the column's minimum past the width it has and clips the panel, which makes that constraint sharper rather than obsolete. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
+15
-9
@@ -93,20 +93,26 @@ const MAX_DISPLAY_DIM: u32 = 2048;
|
||||
/// compact layout exactly as a tablet in portrait would.
|
||||
const EXPANDED_MIN_WIDTH: f32 = 820.0;
|
||||
|
||||
/// TRACES: FR-UI-2
|
||||
/// TRACES: FR-UI-1
|
||||
/// The largest share of the window the develop column may take.
|
||||
///
|
||||
/// The column sizes itself to the widest thing it holds — the generated mode
|
||||
/// strip, the Copy/Paste pair, the histogram's axis labels — so on a rich
|
||||
/// operation set it would otherwise keep growing. This is where that stops.
|
||||
/// The majority of the window stays with the photograph, which is what the
|
||||
/// column is there to serve.
|
||||
/// A policy, not a size. The column is a fixed `panel-width` (`style.yaml`),
|
||||
/// so on any window with room for it this does nothing at all — it bites only
|
||||
/// where 360px would be most of the screen, and what it says there is that the
|
||||
/// majority of the window stays with the photograph the column exists to
|
||||
/// serve.
|
||||
///
|
||||
/// It used to do more, because the column used to size itself to the widest
|
||||
/// thing it held and could therefore grow without limit on a rich operation
|
||||
/// set. It cannot any more; this is the remaining half of that guard, kept for
|
||||
/// the case the fixed width does not cover.
|
||||
const PANEL_MAX_FRACTION: f32 = 0.45;
|
||||
|
||||
/// The floor under that share, so a narrow window still gets a usable column
|
||||
/// rather than one squeezed below the width its own controls were drawn for.
|
||||
/// Matches the 280px the column asks for at minimum: below this the cap would
|
||||
/// be doing the clipping the cap exists to avoid.
|
||||
/// Under `panel-width` by design: between the two the column narrows from 360
|
||||
/// to 280 on a small window and stops, which is the range the sliders inside
|
||||
/// it stay accurate over.
|
||||
const PANEL_MIN_WIDTH: f32 = 280.0;
|
||||
|
||||
/// How long after the last change a draft frame is replaced by a sharp one.
|
||||
@@ -3231,7 +3237,7 @@ fn apply_layout_class(window: &AppWindow, width: f32, panels: &PanelChoices) {
|
||||
window.set_expanded(expanded);
|
||||
window.set_layout_class(if expanded { "expanded" } else { "compact" }.into());
|
||||
|
||||
// FR-UI-2: the ceiling on the develop column, computed here for the same
|
||||
// FR-UI-1: the ceiling on the develop column, computed here for the same
|
||||
// reason the class is — a width that both derives from and feeds the
|
||||
// layout is a binding loop in Slint.
|
||||
window.set_panel_max_width((width * PANEL_MAX_FRACTION).max(PANEL_MIN_WIDTH));
|
||||
|
||||
Reference in New Issue
Block a user