Migrer de JBR vers Tao

Dans ce tutoriel, vous faites passer une application Nucleus existante du backend AWT (decorated-window-jbr ou decorated-window-jni) au backend Tao (decorated-window-tao). Les API DecoratedWindow et TitleBar sont identiques sur les deux backends : le changement se résume à un remplacement de dépendance et à un flag de backend. Le reste du tutoriel couvre les intégrations à retester ensuite.

Avant de commencer

• Une application existante qui tourne sur NucleusBackend.Awt, avec decorated-window-jbr ou decorated-window-jni.
• JDK 17 ou version ultérieure.
• Connaître le concept de backend : une application Nucleus n'embarque qu'un seul module de runtime de fenêtre, et NucleusBackend le sélectionne.

Remplacer la dépendance

Remplacez le runtime de fenêtre AWT par decorated-window-tao. Le point d'entrée nucleus.nucleus-application ne change pas.

dependencies {
    implementation("dev.nucleusframework:nucleus.nucleus-application:2.0.7")
    implementation("dev.nucleusframework:nucleus.decorated-window-jbr:2.0.7")
}

dependencies {
    implementation("dev.nucleusframework:nucleus.nucleus-application:2.0.7")
    implementation("dev.nucleusframework:nucleus.decorated-window-tao:2.0.7")
}

Basculer le flag de backend

Passez backend = NucleusBackend.Tao à nucleusApplication. Le contenu de la fenêtre reste identique.

nucleusApplication {
    DecoratedWindow(onCloseRequest = ::exitApplication, title = "MyApp") {
        TitleBar { state -> /* … */ }
        MyContent()
    }
}

nucleusApplication(backend = NucleusBackend.Tao) {
    DecoratedWindow(onCloseRequest = ::exitApplication, title = "MyApp") {
        TitleBar { state -> /* … */ }
        MyContent()
    }
}

Retester les intégrations système

Les API ci-dessus sont stables d'un backend à l'autre, mais les chemins d'exécution en dessous changent. Retestez chacun de ces points après le basculement :

• Drag-and-drop. Les données arrivent sous forme de TaoDragAndDropPayload au lieu d'un TransferHandler AWT. Réécrivez tout handler qui lit des données de transfert AWT.
• Deep links. Enregistrez-les avec onDeepLink { uri -> … } comme avant : l'API de rappel ne change pas, seul le pont derrière diffère (TaoDeepLinkBridge sur Tao).
• Dialogues fichier. Tao n'a pas d'AWT : tout appel direct à JFileChooser cesse de fonctionner. Passez à une bibliothèque de dialogues fichier native comme FileKit — voir Dialogues fichier natifs, qui fonctionne sur les deux backends.
• Vues natives. Les instances Canvas AWT embarquées ne fonctionnent plus sous Tao. Le SwingPanel de Compose Desktop cesse lui aussi de fonctionner et fait planter l'app au runtime, car Tao ne crée jamais la hiérarchie de fenêtre AWT/Swing dont il a besoin. Embarquez du contenu natif avec NativeView.
• Placement de fenêtre sur Linux. Les compositeurs Wayland peuvent ignorer les positions absolues. Voir Wayland.
• Flux multi-fenêtres. Rien ne change : un seul bloc nucleusApplication { } avec un appel DecoratedWindow par fenêtre, chacune exposant son propre NucleusWindow.

Comparer les backends

Décider de garder JBR

Restez sur le backend AWT quand votre application :

• embarque un module basé sur Swing,
• embarque un Canvas AWT que vous n'avez pas encore porté vers NativeView, ou
• dépend d'une bibliothèque qui a besoin de ComposeWindow directement.

Nucleus 2.0 publie decorated-window-jbr, decorated-window-jni et decorated-window-tao depuis la même version : vous pouvez donc différer le basculement et figer le backend par build avec NucleusBackend.Awt ou NucleusBackend.Tao.

Et ensuite

• Backends — comment NucleusBackend sélectionne le runtime de fenêtre.
• Decorated window — les API DecoratedWindow et TitleBar sur Tao.
• Dialogues fichier natifs — des sélecteurs de fichiers qui fonctionnent sans AWT.
• Wayland — placement de fenêtre et comportement des compositeurs sous Linux.