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:
@@ -187,6 +187,55 @@ lengths:
|
||||
Floor on button width, so a one-word label is still a comfortable
|
||||
target and a row of buttons has an even rhythm.
|
||||
|
||||
_develop:
|
||||
section: the develop view's two fixed columns
|
||||
note: |
|
||||
Both are *mandated* sizes rather than measured ones, which is the
|
||||
opposite of how the rest of this interface is laid out, and the reason
|
||||
is that these two flank the photograph. Everything else may grow to fit
|
||||
its contents; a column beside the image cannot, because the pixels it
|
||||
takes come out of the picture and a control gaining a word is not a
|
||||
reason to give the photograph less room.
|
||||
|
||||
What that costs is that a panel wider than the number below clips, and
|
||||
the Flickables inside it are what make the overflow reachable. That is
|
||||
the trade being made deliberately: a control you may have to scroll to
|
||||
is worse than one you can see, and a photograph that changes size when
|
||||
you switch tools is worse than both.
|
||||
|
||||
rail-width:
|
||||
value: 60
|
||||
doc: |
|
||||
The tool rail down the left of the develop view. Wide enough for a 20px
|
||||
icon over a `text-sm` label at the longest name in the table, and narrow
|
||||
enough to stay a rail rather than becoming a third panel.
|
||||
rail-entry-height:
|
||||
value: 54
|
||||
doc: |
|
||||
One tool in that rail. Over `touch-target`, because unlike the controls
|
||||
inside a panel these are not crowding anything — the rail holds four
|
||||
entries on a screen with room for a dozen.
|
||||
|
||||
panel-width:
|
||||
value: 360
|
||||
doc: |
|
||||
The develop column on the other side. One number for tablet and desktop
|
||||
alike, replacing the 280 the first was drawn for and the 380 the second
|
||||
was — the alternative is a column that changes width with the window,
|
||||
which is a photograph that changes size when you resize by a pixel.
|
||||
|
||||
**Measured, not chosen.** The column's contents report a minimum width of
|
||||
344 in every mode — photo, local and repair alike — and below that they
|
||||
do not compress, they clip: a `Text` that does not elide reports the same
|
||||
minimum as preferred, and most of this column is text. 320 was tried
|
||||
first and sliced "Paste" down the middle. So this is that floor plus
|
||||
enough not to be sitting on it.
|
||||
|
||||
To re-measure after changing a panel, bind a `Text` in `app.slint` to
|
||||
`column.min-width` and read it off the running app; there is no way to
|
||||
get the number out of the layout engine short of asking it.
|
||||
|
||||
|
||||
swatch:
|
||||
value: 12
|
||||
note: |
|
||||
|
||||
Reference in New Issue
Block a user