• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

umputun / agterm / 33823636945
93%

Build:
DEFAULT BRANCH: master
Ran 04 Sep 2026 12:57AM UTC
Jobs 1
Files 120
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

04 Sep 2026 12:53AM UTC coverage: 97.28%. Remained the same
33823636945

push

github

web-flow
fix restored split layout and measure the split ratio below the titlebar (#542)

* fix: re-apply the split ratio when the safe-area inset changes

SwiftUI sizes a VSplitView's primary pane as content height plus the top safe-area
inset, while the stored splitRatio is a fraction of the full AppKit split height. A
session restored in the background lays out at a stale 1pt inset; when the real inset
arrives on reveal the divider is never re-applied, and the next window resize falls
back to SwiftUI's own even split of the content space.

Measured on a 432pt window: the primary goes 216 to 232 on a 1pt resize and capture()
persists 0.5358 in place of 0.5, moving the top pane's pty from 10 rows to 11. The same
reveal step grows the primary wrapper by 31pt, which is what #539 reports as a top pane
drawn under the compact titlebar.

layout() now records the inset each time it applies the ratio and re-arms when it
differs, so the divider is re-applied once the real inset lands.

Adds a UI test driving the restored-background case with stty size as the oracle, plus
hosted tests for the re-arm and its negative twin.

Related to #539

* fix: measure the split ratio below the titlebar and capture only on a drag

splitRatio was a fraction of the full AppKit split height, but SwiftUI lays the panes out
below the titlebar band, so an even ratio rendered uneven in compact mode: a fresh top/bottom
split persisted 0.5729 as its own even split, and session.resize 0.5 or the double-click reset
produced a visibly uneven result. The ratio is now a fraction of the pane area below the band,
top/bottom only, since a top inset does not touch width.

capture() also wrote on every didResizeSubviews, so layout-pass frames were persisted as if
they were the ratio: 0.074 right after a reveal, 1.0 while hidden, rejected only by
splitRatioMin. Only a divider drag is intent, so capture now requires an in-band press with the
button still down. A never-set ratio is seeded with splitRatio... (continued)

9657 of 9927 relevant lines covered (97.28%)

4110552.31 hits per line

Jobs
ID Job ID Ran Files Coverage
1 33823636945.1 04 Sep 2026 12:57AM UTC 120
97.28
GitHub Action Run
Source Files on build 33823636945
  • Tree
  • List 120
  • Changed 5
  • Source Changed 5
  • Coverage Changed 4
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #33823636945
  • 200d4827 on github
  • Prev Build on master (#33720298561)
  • Next Build on master (#33832364984)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc