Qt et keal-view s'accordent sur plus de choses qu'ils n'en discordent : tous deux mettent devant vous un arbre de widgets retenu, tous deux le mettent en page plutôt que de le positionner, et tous deux dessinent leurs propres contrôles au lieu de les demander à la plateforme. La différence est ce qu'est un widget — un objet de longue vie qu'on modifie chez Qt, une description reconstruite depuis l'état ici.
| Qt | keal-view |
|---|---|
QLabel("Hi") | label("Salut") |
QPushButton + connect(…) | button("Go", { -> … }) |
QVBoxLayout / QHBoxLayout | column([…]) / row([…]) |
setStretch / stretch factor | .grows() et .shares() |
QWidget::paintEvent + QPainter | custom({ p -> … }) |
QDockWidget | Dock, leaf et split |
qApp->setStyleSheet(…) | useTheme(lightTheme()) |
Un widget Qt tient de l'état, donc il faut bien que quelque chose lui dise que le modèle a changé — c'est à ça que sert un signal. Ici l'arbre est jeté et refait depuis l'état, donc le gestionnaire d'un bouton écrit une Cell et l'image suivante est déjà juste. Il n'y a pas de connect, et rien à déconnecter.
Les mises en page de Qt négocient : un widget a un minimum, un préféré et un maximum, et le moteur trouve un compromis. Ici il y a un axe de flexbox et aucune compression — ce qui ne rentre pas est découpé. C'est un choix délibéré : une mise en page qui compresse en silence ne casse que sur les petites fenêtres, l'endroit où personne ne regarde.
tools/build.sh votre.keal compile le backend une fois et remet le fichier objet à keal build. Il n'y a pas de générateur de code dans la boucle, ni de description d'interface à garder synchronisée avec le code qui s'en sert.