Aller au contenu

Comment un widget atteint l'écran

Un widget dessine à travers un painter ; le painter décide si cela devient des pixels ou des cellules de terminal ; un back-end présente le résultat.

Trois couches, et chacune ne connaît que celle du dessous :

toolkit widget tree          Button, Table, Agenda, VBox ...  (or a skin.Object)
        │  Draw(p painter.Painter, theme *Theme)
        ▼
painter.Painter              FillRect, StrokeRect, Text, PutPixel, ...
        │
        ├─ PixelPainter  → an RGBA []byte   → window, browser canvas, PNG, Android
        └─ CellPainter   → a grid of cells  → a terminal, as 24-bit ANSI

Un widget n’apprend jamais quel painter on lui a remis. Un back-end n’apprend jamais quels widgets ont dessiné. C’est toute la raison pour laquelle un même arbre de widgets peut s’afficher dans une fenêtre native, un navigateur et un terminal sans une ligne de code conditionnel.

La jonction du painterles primitives, les capacités optionnelles, les deux painters
La boîte à outilsle jeu de widgets, les thèmes, les mises en page, le texte et l’accessibilité
Skinsdécrire les parties et les états d’un widget par des données plutôt qu’en Go

Créée le par tannevaled

Modifiée le par tannevaled