The painter seam

go-widgets/painter defines the one interface every widget draws through:

type Painter interface {
	FillRect(r Rect, c RGBA)
	StrokeRect(r Rect, c RGBA, lineW int)
	FillRoundRect(r Rect, radius int, c RGBA)
	StrokeRoundRect(r Rect, radius int, c RGBA, lineW int)
	PutPixel(x, y int, c RGBA)
	Text(x, y int, s string, ink RGBA)
	Size() (w, h int)
}

The set is small on purpose: every back-end must implement all of it, and a terminal grid cannot round a corner or vary a stroke width. So the contract says what happens when it cannot — StrokeRect’s width is a hint a cell grid ignores, and FillRoundRect falls back to a square fill there.

Optional capabilities

What not every surface can do is not in the base interface. A widget that needs it type-asserts, and draws something sensible when the answer is no:

if c, ok := p.(painter.Clipper); ok {
	c.PushClip(bounds)
	defer c.PopClip()
}

The two painters

The buffer stays the caller’s. A PixelPainter only translates primitives into writes, so the same []byte can be handed to a window back-end, a <canvas> or an image encoder without a copy in between.

Trying it

The repository’s own demos draw the same three widgets through both painters:

go run ./cmd/wui-demo --out demo.png     # pixels, written as a PNG
go run ./cmd/tui-demo --theme dark       # cells, written as ANSI to stdout

and go-widgets.github.io/painter shows the pixel painter in a browser.