go-widgets

Ein Widget-Baum, von Go gezeichnet, auf jeder Oberfläche, die Go erreicht. Ein natives Fenster unter X11, Wayland, macOS und Windows; ein <canvas> in einem Browser-Tab; ein Terminal; eine Android-APK. Keine C-Toolchain, keine Webview, kein System-Widget-Satz: Jedes Modul baut mit CGO_ENABLED=0, und jedes Pixel zeichnet das Toolkit.

w, err := window.Open(window.Config{Title: "Hello"})
if err != nil {
	return err
}
defer w.Close()

box := toolkit.NewVBox()
box.Append(toolkit.NewLabel("Hello from go-widgets"))
box.Append(toolkit.NewButton("Click me", func() { /* ... */ }))
return w.Run(box) // an X11 or Wayland window, an NSWindow, a Win32 window

Das ist cmd/windowdemo, gekürzt. Dieselbe box in einem Browser, einem Terminal oder einem PNG gezeichnet ist derselbe Code mit einer anderen Oberfläche darunter.

Warum ein Toolkit alles zeichnet

Ein Widget, das den plattformeigenen Button aufruft, ist so portabel wie die am wenigsten fähige Plattform, auf die es zielt, und sieht auf jeder anders aus. go-widgets geht den umgekehrten Weg: Das Draw eines Widgets spricht immer nur mit einem painter.Painter, einer Handvoll Primitive (ein Rechteck füllen, eines umranden, ein Pixel setzen, Text zeichnen). Ob aus diesen Aufrufen RGBA-Pixel oder Terminalzellen werden, ist Sache des Back-Ends, nicht des Widgets.

Was das kostet, wird offen gesagt: standardmäßig kein natives Aussehen und keine Barrierefreiheit geschenkt – das Toolkit veröffentlicht seinen eigenen Barrierefreiheitsbaum an jede Plattform. Was es dafür bekommt, ist ein einziger Widget-Satz, einmal getestet, mit demselben Verhalten überall, und ein Binary, das sich von jeder Maschine aus für jede dieser Plattformen cross-kompilieren lässt.

Wie es weitergeht

Lizenz

BSD-3-Clause.