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 est 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.