Architecture

Une app Nucleus, c'est une pile de quatre couches bien comprises. Chacune fait un seul boulot, et chacune est remplaçable depuis la couche du dessus.

L'essentiel

• L'app repose sur Compose UI, des view-models et de la logique métier Kotlin pure.
• Nucleus 2.0 est la couche desktop native — 30+ modules runtime plus le plugin Gradle.
• Compose Multiplatform est le runtime UI accéléré GPU (Skia, état réactif, hot reload).
• Kotlin Multiplatform laisse partager les modules avec Android, iOS et web.
• Tout ça tourne sur JDK 17+, JBR ou GraalVM Native Image — choisis le runtime dont on a besoin.

Les couches

Haut — le application

Compose UI, view-models, la logique métier. Du Kotlin pur. Si on veut partager avec Android et iOS, c'est cette couche qu'on met sous un source set commonMain KMP.

// Kotlin pur — tourne sur toutes les plateformes que Compose cible.
class CounterViewModel {
    var count by mutableStateOf(0)
        private set
    fun increment() { count++ }
}

Couche desktop native — Nucleus 2.0

Plus de 30 modules runtime, groupés par intention :

• Intégration OS — Decorated Window (backend Tao), notifications, system tray, menus dock & launcher, dark-mode detector, hotkeys globaux, media control, couleur système.
• Performance — GraalVM Native Image, cache AOT (JDK 25+), energy manager, HTTP / SSL natif.
• Distribution — 16 formats de packaging, signing + notarisation, auto-update, deep links, auto-launch, actions CI réutilisables.

Tous optionnels. Tous Kotlin. Tirés à la carte via les dépendances Gradle — voir Modules.

Le plugin Gradle (dev.nucleusframework) est la moitié build-time de cette couche. Il choisit les formats, câble GraalVM, injecte les métadonnées de reachability, génère nucleus-app.properties pour que core-runtime.NucleusApp connaisse l'identité de le app, et orchestre le signing.

Fondation — Compose Multiplatform

UI accélérée GPU, typée, réactive. Pas un port du Compose mobile avec un layout étiré — un vrai renderer desktop sur Skia, avec hot reload, Compose Resources, et un modèle d'événements pointeur / clavier unifié.

Nucleus ne remplace pas Compose. Il s'y branche : chaque DecoratedWindow est un @Composable, chaque module Nucleus qui touche à l'UI (isSystemInDarkMode(), systemAccentColor(), NativeMenuBar, …) en est un aussi.

Fondation — Kotlin Multiplatform

Modules partagés, coroutines, StateFlow, kotlinx.serialization, Ktor. La même stack KMP qu'on utilise déjà pour Android et iOS. Les modules runtime Nucleus sont JVM-only, mais les couches au-dessus restent multiplatform.

Runtime — JDK 17+, JetBrains Runtime, ou GraalVM Native Image

Trois démarrages :

• OpenJDK 17+ — compatibilité maximale. Marche avec la decorated window backée JNI sur les JDK standard.
• JetBrains Runtime (JBR) — même forme qu'OpenJDK avec des APIs de décoration custom en plus. Par défaut pour le DecoratedWindow basé AWT.
• GraalVM Native Image — compilation AOT en monde fermé. Binaire autonome, démarrage à froid en ~50 ms, sans JRE embarquée.

Le switch DSL fait une ligne — voir Runtimes.

Comment une frame se produit

Quand l'utilisateur clique un bouton :

1. L'OS (ou la couche Rust Tao) émet un événement.
2. Le module de backend (decorated-window-tao ou une variante AWT) le traduit en PointerEvent Compose.
3. Compose recompose, demande à Skia de dessiner les couches affectées, et rend la surface GPU au backend.
4. Le backend swappe les buffers via le compositeur de l'OS (Wayland, DWM, Quartz).

Le code reste en Kotlin tout le long.

Et ensuite ?

• Runtimes — choisir GraalVM Native Image plutôt que JVM + cache AOT.
• Backends — AWT vs Tao sous le DecoratedWindow.
• Modules — comment les 30+ modules runtime se composent.