Leave the adjust panel somewhere to scroll from
🐳 Android image / Build and push (push) Successful in 3s
Build and test / android-image (push) Successful in 3s
Build and test / Desktop (Linux) (push) Successful in 19m8s
Build and test / Layer separation (push) Successful in 35s
Traceability / Requirement traces (push) Successful in 29s
Build and test / Android (aarch64) (push) Failing after 9m0s
🐳 Android image / Build and push (push) Successful in 3s
Build and test / android-image (push) Successful in 3s
Build and test / Desktop (Linux) (push) Successful in 19m8s
Build and test / Layer separation (push) Successful in 35s
Traceability / Requirement traces (push) Successful in 29s
Build and test / Android (aarch64) (push) Failing after 9m0s
A strip down the right-hand edge of the panel that no control reaches, so there is always somewhere to put a thumb that means "scroll" and nothing else. This is the other half of the slider arbitration. A `SliderTrack` stands the Flickable down the moment a finger touches it, which is what makes dragging an adjustment reliable — and the price is that the track can no longer be dragged past. What was left to scroll from was the ~20px band of label between one control and the next, which on a panel that is mostly tracks means aiming rather than reaching. Reserving the space outright is the honest version of what had been left to chance. Padding rather than a spacer element, and that is what makes it work: the strip is inside the Flickable but no child is laid out into it, so nothing puts a TouchArea over it. A press there reaches the Flickable directly, with no arbitration to lose. A full touch target wide (FR-UI-3). A gutter too narrow to hit confidently would be the problem it was added to fix, in a smaller space. It costs the tracks about 44px of a 280px column, which leaves travel enough that the readout still moves a step per pixel at the precisions the descriptors ask for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -728,6 +728,31 @@ export component AdjustPanel inherits Rectangle {
|
|||||||
spacing: 0px;
|
spacing: 0px;
|
||||||
alignment: start;
|
alignment: start;
|
||||||
|
|
||||||
|
// **The scroll gutter.**
|
||||||
|
//
|
||||||
|
// A strip down the right-hand edge that no control reaches, so
|
||||||
|
// there is always somewhere to put a thumb that means "scroll"
|
||||||
|
// and nothing else.
|
||||||
|
//
|
||||||
|
// It exists because of the arbitration in `SliderTrack`: a
|
||||||
|
// track stands the Flickable down as soon as a finger touches
|
||||||
|
// it, which is what makes dragging a slider reliable, and the
|
||||||
|
// cost is that the track can no longer be used to scroll past.
|
||||||
|
// The rows either side of a track were the only remaining
|
||||||
|
// purchase, and on a panel that is mostly tracks that came to
|
||||||
|
// aiming at a 20px band between controls. Reserving the space
|
||||||
|
// outright is the honest version of what was left to chance.
|
||||||
|
//
|
||||||
|
// Padding rather than a spacer element, and that is what makes
|
||||||
|
// it work: the strip is inside the Flickable but no child is
|
||||||
|
// laid out into it, so nothing puts a TouchArea over it. A
|
||||||
|
// press there reaches the Flickable directly, with no
|
||||||
|
// arbitration to lose.
|
||||||
|
//
|
||||||
|
// A full touch target wide (FR-UI-3), because a gutter too
|
||||||
|
// narrow to hit confidently is the problem it was added to fix.
|
||||||
|
padding-right: Theme.touch-target;
|
||||||
|
|
||||||
// One iteration per row, but only a group's *first* row draws
|
// One iteration per row, but only a group's *first* row draws
|
||||||
// anything — and it draws the whole group. Every other row
|
// anything — and it draws the whole group. Every other row
|
||||||
// renders nothing at all.
|
// renders nothing at all.
|
||||||
|
|||||||
Reference in New Issue
Block a user