Skip to content

The browser tab is a Repainter; Repainter's doc names every backend - #140

Merged
tannevaled merged 1 commit into
mainfrom
tab-repaint
Oct 10, 2026
Merged

tannevaled merged 1 commit into
mainfrom
tab-repaint

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor
  • Browser tab backend implements Repainter: Repaint (any goroutine) asks webcanvas v0.4.0 (RepaintAware, verified in headless Chrome there) for the next animation frame. Tree.RepaintWith/Repaint use atomics; tested under -race, internal/tab stays at 100%.
  • Doc fix: Repainter said "Implemented today by the macOS (Cocoa) back-end"; X11, Wayland, GTK and Win32 implement it too (compile-time assertions in open_*.go). Numbered and Placement really are Cocoa-only and keep their sentence.
  • README: the pattern for results from other goroutines: go-widgets/mvvm v0.14.0 Queue with Repaint as its wake, drained in the root container's SetBounds.

First user: the go-fileshare admin console. To be released as v0.88.0.

🤖 Generated with Claude Code

The tab backend could not be woken: a result arriving on a goroutine stayed
off the screen until the next click. It now implements Repainter through
webcanvas v0.4.0's RepaintWith -- the next animation frame redraws the tree.
Repainter's doc said macOS only; X11, Wayland, GTK, Win32 have it too. The
README shows the whole pattern: mvvm.Queue with Repaint as its wake, drained
in the root's SetBounds.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@tannevaled
tannevaled merged commit 0d8d604 into main Oct 10, 2026
28 checks passed
@tannevaled
tannevaled deleted the tab-repaint branch October 10, 2026 20:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant