La costura del painter

go-widgets/painter define la única interfaz a través de la cual dibuja cada widget:

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)
}

El conjunto es pequeño a propósito: cada backend debe implementarlo entero, y una cuadrícula de terminal no puede redondear una esquina ni variar el grosor de un trazo. Por eso el contrato dice qué ocurre cuando no puede: el grosor de StrokeRect es una indicación que una cuadrícula de celdas ignora, y FillRoundRect recurre allí a un relleno cuadrado.

Capacidades opcionales

Lo que no todas las superficies pueden hacer no está en la interfaz base. Un widget que lo necesita hace una aserción de tipo, y dibuja algo razonable cuando la respuesta es no:

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

Los dos painters

El búfer sigue perteneciendo al llamante. Un PixelPainter solo traduce primitivas en escrituras, de modo que el mismo []byte puede entregarse a un backend de ventana, a un <canvas> o a un codificador de imágenes sin ninguna copia intermedia.

Probarlo

Las demos del propio repositorio dibujan los mismos tres widgets a través de ambos 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

y go-widgets.github.io/painter muestra el painter de píxeles en un navegador.