Le manuel zenit
Créez en Zig des interfaces de bureau macOS réellement natives. zenit réunit fenêtres, rendu GPU, texte, méthodes de saisie et accessibilité dans un modèle d'UI clair ; ce manuel vous mène de votre première fenêtre à une application de production maintenable.
const std = @import("std");
const ui = @import("ui");
const App = @import("zenit_app").App;
fn mountUi(cx: *ui.Cx, _: *ui.Scope) anyerror!*ui.Node {
return ui.text(cx, "Hello, zenit!", .{
.font_size = cx.tokens.font_size.xxxl,
.color = cx.tokens.color.fg_primary,
});
}
pub fn main() !void {
var gpa = std.heap.GeneralPurposeAllocator(.{}){};
defer _ = gpa.deinit();
const app = try App.init(gpa.allocator(), .{
.window = .{ .title = "Hello" },
});
defer app.deinit();
try app.runWith(mountUi);
}Parcours d'apprentissage
Parcourez-le une fois, dans l'ordre — environ 45 minutes — et vous aurez tout le modèle mental pour créer des applications zenit en autonomie.
L'architecture que vous utilisez
Les applications ne dépendent que de la couche publique stable ; zenit gère la plateforme et le rendu.
zenit.attach(dep, exe) ajoute exactement deux imports de module à votre exécutable — ui et zenit_app — puis compile les ponts natifs et lie les frameworks système. Les modules internes ne figurent pas du tout dans votre graphe de build : ce n’est pas « évitez », c’est « impossible ».Plus qu'un ensemble d'API
Ces trois capacités traversent le runtime, la pile texte et l'outillage — chacune appuyée par une démo exécutable et des preuves en fenêtre réelle.
Trois principes
Suivez-les et votre code restera clair pendant que zenit évolue encore rapidement.
Utilisez ui.*, ui.<group>.* et zenit_app.App — n’allez jamais piocher dans les répertoires internes.
L'état persistant vit dans des Signals ou un état lié ; dérivez avec Memo, gérez les effets de bord avec Effect.
Couleurs, typographie, espacements et rayons viennent du thème ; si vous devez sortir de l’échelle, dites-le avec ui.arb.