Let the develop column ask how wide it needs to be

The column was 280px, a number chosen for a tablet, with 380px bolted on
later for a desktop. Both were guesses at how much room the widest row
inside needs, and a guess is what cannot work here: the mode strip is one
chip per attribute the *operation set declares*, so the row is generated
and no constant in app.slint can track it.

When the guess came up short the failure was not a tidy clip. The
Flickable inside the column never had its `viewport-width` set, so the
viewport took its content's preferred width, and a viewport wider than
its Flickable is *centred* in it — the same rule the note on the seam's
`x: 0` already records a few lines below. So the column lost half of each
edge rather than one of them: "HISTOGRAM" read "ISTOGRAM", "Straighten"
read "aighten", Copy sat centred while Paste ran off the far side. It
looked like a rendering fault and it was an alignment one.

So the column asks instead of guessing. Every panel that can appear in it
— image, histogram, geometry, settings transfer, masks, repairs, adjust,
history — now publishes a `content-width`: how wide it has to be before
it starts clipping itself, read off its own layout rather than asserted.
Each declares that as its `min-width` too, and that is what makes the
aggregation automatic: `column` is a layout, so it already reports the
largest minimum among its children, and it does so for the panels that
come and go with the mode as well, which live inside `if`s and cannot be
named from outside. Grep `content-width` in ui/dr-ui/ui to see every
panel with a say in the answer. The mode strip is named explicitly only
because it is pinned outside that layout, so nothing else measures it.

There is no floor left. A floor is one more guess and the panels state
their own minimums now. The only thing still above the measurement is
`panel-max-width`, which is not a size but a policy — a column may not
take the window from the photograph it exists to serve — and it comes
from Rust beside `layout-class` because a width read from `root.width`
inside the layout that `root.width` depends on is a binding loop.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ui/dr-ui/ui/app.slint

@@ -225,6 +225,14 @@ component InfoPanel inherits Rectangle {
     in property <string> exposure;
     in property <string> dimensions;
 
+    /// TRACES: FR-UI-2
+    /// How wide this panel has to be before it starts clipping itself. The
+    /// develop column is the largest of these and nothing else; publishing it
+    /// as `min-width` too is what makes the enclosing layout aggregate them
+    /// without this panel having to be referenced by name.
+    out property <length> content-width: panel.preferred-width;
+    min-width: root.content-width;
+
     background: transparent;
     height: panel.preferred-height;
 
@@ -986,6 +994,22 @@ export component AppWindow inherits Window {
     in property <bool> expanded: true;
     in property <string> layout-class: "expanded";
 
+    /// TRACES: FR-UI-2
+    /// The most the develop column may take, in logical pixels.
+    ///
+    /// Set from Rust beside `layout-class` and for the same reason: the column
+    /// sizes itself to its contents, and a ceiling read from `root.width`
+    /// inside the layout that `root.width` depends on is the binding loop the
+    /// note above describes.
+    ///
+    /// A ceiling and not a width. The column asks for what it needs and this
+    /// only says when the answer has stopped being reasonable — a photograph
+    /// with a third of a window left to show itself in is not a develop view.
+    /// The default is generous because the first frame is drawn before any
+    /// resize has been reported, and a column briefly too wide is a far
+    /// smaller fault than one briefly clipped.
+    in property <length> panel-max-width: 520px;
+
     // --- local adjustments (FR-DEV-3) ---------------------------------------
 
     /// The false-coloured region map, drawn over the photograph.
@@ -2494,24 +2518,56 @@ in property <bool> panel-visible: true;
                 // depends on `panel-visible`, which derives from the window
                 // width, which the layout then influences. Slint flags it, and
                 // it can panic at runtime.
-                Rectangle {
+                develop-column := Rectangle {
                     // TRACES: FR-UI-2
-                    // 280px was chosen for a tablet, where the column is a
-                    // large fraction of the screen and every pixel of it is
-                    // taken from the photograph. On a desktop window it is
-                    // simply too narrow: the mode strip alone is two modes,
-                    // a separator, "All", and one chip per attribute the
-                    // operation set declares, which is more words than 280px
-                    // holds — so it scrolled sideways, and a control you have
-                    // to pan to reach is one you do not know is there.
+                    // **As wide as what it holds.**
                     //
-                    // Driven off `layout-class` rather than `root.width`
+                    // It was 280px, chosen for a tablet where the column is a
+                    // large fraction of the screen and every pixel of it is
+                    // taken from the photograph. That was too narrow on a
+                    // desktop, so a second number — 380px — was added for the
+                    // expanded class. Both were guesses at how much room the
+                    // widest row in this column needs, and a guess is exactly
+                    // what cannot be right here: the mode strip is two modes, a
+                    // separator, "All", and one chip per attribute the
+                    // operation set *declares*, so the row is generated and no
+                    // constant in this file can track it. When the guess came
+                    // up short the strip scrolled sideways, and a control you
+                    // have to pan to reach is one you do not know is there.
+                    //
+                    // **So the column asks instead.** Every panel that can
+                    // appear in it publishes a `content-width` — how wide it
+                    // has to be before it clips itself — and also declares that
+                    // as its `min-width`. The `min-width` is what makes this
+                    // aggregate on its own: `column` below is a layout, so it
+                    // already reports the largest minimum among its children,
+                    // and it does so for the panels that come and go with the
+                    // mode as well, which sit inside `if`s and cannot be named
+                    // from out here. Grep `content-width` in this directory to
+                    // see every panel that has a say.
+                    //
+                    // The mode strip is named explicitly only because it is
+                    // pinned *outside* that layout, so nothing else would
+                    // measure it.
+                    //
+                    // There is no floor. A floor is another guess, and the
+                    // panels state their own minimums now. The one thing left
+                    // over the measurement is `panel-max-width` — not a size
+                    // but a policy, that a column may not take the window from
+                    // the photograph it exists to serve — and past that the
+                    // Flickables inside are the fallback, as they have always
+                    // been. It comes from Rust rather than from `root.width`
                     // because reading the window width inside the layout that
                     // sets it is the binding loop the comment on `expanded`
-                    // above describes. Rust already classifies the window; this
-                    // just spends the extra width where there is some.
+                    // above describes; Rust already measures the window for
+                    // `layout-class`, so this is one more thing said in the
+                    // same breath.
+                    property <length> content-width: max(
+                        develop-strip.content-width,
+                        column.preferred-width,
+                    );
                     width: root.panel-visible
-                        ? (root.layout-class == "expanded" ? 380px : 280px)
+                        ? min(root.panel-max-width, self.content-width)
                         : 0px;
                     visible: root.panel-visible;
                     background: Theme.surface;
@@ -2538,7 +2594,7 @@ in property <bool> panel-visible: true;
                     // would both sit at its origin and overlap. The strip is pinned by
                     // being outside the Flickable rather than by any coordinate.
                     VerticalLayout {
-                        ModeStrip {
+                        develop-strip := ModeStrip {
                             enabled: root.adjust-enabled;
                             mode: root.view-mode;
                             tabs: root.adjust-tabs;
@@ -2549,6 +2605,26 @@ in property <bool> panel-visible: true;
 
                         Flickable {
                             viewport-height: column.preferred-height;
+                            // **And the width, or the column is drawn centred
+                            // over its own edges.**
+                            //
+                            // Unset, a Flickable's viewport takes its content's
+                            // preferred width, and a viewport wider than the
+                            // Flickable is *centred* in it — the same rule the
+                            // note on the seam's `x: 0` below records. So a
+                            // column narrower than what it held did not clip
+                            // the right-hand side and keep the left, it lost
+                            // half of each: "HISTOGRAM" read "ISTOGRAM",
+                            // "Straighten" read "aighten", and Paste ran off
+                            // the far side. It looked like a rendering fault
+                            // and it was an alignment one.
+                            //
+                            // Floored at the Flickable's own width so the
+                            // ordinary case — a column sized to fit, which is
+                            // now every case the cap does not bite — puts the
+                            // content at x: 0 and stretches it, rather than
+                            // leaving it preferred-width and adrift.
+                            viewport-width: max(self.width, column.preferred-width);
                             interactive: !adjust.slider-dragging;
 
                             // **What the column holds is the mode's answer.**