Chapitre 6

La naissance de la v5

« Il faut des tonnes de trucs à revoir ! »

Dans ce chapitre

Le constat de la v4

La v4 est impressionnante. Plus de 101 000 lignes de code, 290 méthodes, un éditeur fonctionnel avec des dizaines de fonctionnalités. Mais David voit plus loin. Et il voit les problèmes.

Après des dizaines de sessions de développement, les limitations structurelles de la v4 deviennent évidentes :

Le rendu est uniquement statique
Le canvas se redessine à la demande, quand quelque chose change. Ça fonctionne pour des formes statiques, mais ça rend impossible l'affichage de GIF animés, de vidéos intégrées, ou d'animations fluides. Pour du contenu dynamique, il faudrait une boucle requestAnimationFrame — mais l'architecture n'a pas été prévue pour ça.
Les comportements sont codés en dur
Quand la souris entre sur un objet, le curseur change. Quand on clique, l'objet est sélectionné. Quand on drag, il se déplace. Tout ça est câblé directement dans le code. Si un développeur veut un comportement différent — par exemple, un clic qui ouvre un menu au lieu de sélectionner — il doit modifier le code source.
Les médias sont stockés en Base64 dans la RAM
Chaque image, chaque vidéo est convertie en chaîne Base64 et stockée directement dans les données du projet. Un fichier vidéo de 58 Mo se retrouve intégralement en mémoire. Avec plusieurs vidéos ou images haute résolution, la consommation mémoire explose.
L'API a grandi de manière organique
Certains noms de fonctions sont mal choisis, incohérents d'un module à l'autre. L'API a été construite fonctionnalité par fonctionnalité, sans plan global initial, et ça se voit dans les incohérences de nommage.
L'architecture monolithique de certains fichiers
Le fichier Core-InteractionManager.js fait plus de 8 000 lignes. Ui-Properties.js dépasse les 14 000 lignes. Le fichier Editor.html fait plus de 5 500 lignes. C'est trop gros, trop difficile à maintenir. David le dit lui-même : « Y'a des tonnes de trucs à revoir ! »

La décision

La v4 est un prototype extraordinaire. Un cahier des charges vivant. La preuve que le concept fonctionne. Mais pour aller plus loin — pour faire de VOH un produit professionnel, vendable, extensible — il faut reprendre les fondations. Ce n'est pas repartir de zéro. David insiste là-dessus :

« La v4 sert de cahier des charges, et de base. Beaucoup de code sera réutilisé. Ce n'est pas une reprise à zéro totale mais une refonte. »

La v5 garde tout ce qui marche. Les algorithmes, les concepts, la logique métier. Mais elle repose sur une architecture nouvelle, pensée dès le départ pour supporter ce que la v4 ne pouvait pas faire.

Il faut être clair : au moment où ces lignes sont écrites, rien n'est encore figé. La v5 est un chantier exploratoire. David a des idées fortes sur la direction, mais il cherche, il teste, il s'interroge. Les « trois piliers » décrits ci-dessous sont des intentions de conception, pas des implémentations terminées. C'est une vision en construction.

Les trois piliers envisagés pour la v5

La refonte s'articule autour de trois innovations fondamentales — du moins, c'est le plan :

Le moteur de règles JSON (Rule Engine)
Au lieu de comportements codés en dur, tout est configurable. Les règles sont des fichiers JSON qui définissent : « quand tel événement se produit, faire telle action ». Le Core a ses règles par défaut (le comportement classique : clic = sélection, drag = déplacement). Mais un développeur peut les remplacer ou les étendre à volonté. Le prototype de l'EventMaker — un éditeur visuel de règles, style RPG Maker — a été créé en v4 comme preuve de concept. En v5, il devient une partie intégrante de l'architecture.
Le rendu hybride (Hybrid Render Engine)
Le moteur de rendu est statique par défaut (redessin à la demande), mais bascule automatiquement en mode dynamique (requestAnimationFrame) quand du contenu animé est présent. Pas de GIF sur le canvas ? Rendu statique, zéro consommation CPU au repos. Un GIF ou une vidéo sur un objet ? Le moteur active la boucle d'animation automatiquement, et la coupe quand l'animation s'arrête.
Les médias sur disque (FileManager)
Plus de data URI Base64 en RAM. Les médias (images, vidéos, sons) sont stockés sur disque dans le dossier du projet, et chargés à la demande avec un cache LRU (Least Recently Used). Un fichier vidéo de 58 Mo reste sur le disque. Seule une référence légère est gardée en mémoire. Le chargement se fait quand l'objet qui utilise le média est visible.

L'architecture en 7 couches (le plan)

La v4 avait 2 couches (Core + Editor). La v5 ambitionne de pousser la granularité beaucoup plus loin avec une architecture en 7 couches empilées :

Zone (1 couche)
Le conteneur de premier niveau. C'est le rectangle visible dans lequel tout se passe. Il gère son propre fond, sa propre grille, sa bordure, et surtout le viewport — le scroll et le zoom qui permettent de naviguer dans un espace de travail plus grand que la fenêtre.
Canvas (5 couches)
À l'intérieur d'une zone, un ou plusieurs canvas. Chaque canvas est composé de 5 couches HTML canvas empilées : 1. Background couleur — la couleur de fond du canvas. 2. Background image — une image de fond par-dessus. 3. Grid — la grille avec snap pour l'alignement. 4. Objects — les objets graphiques eux-mêmes. 5. Overlay — les poignées, les ancres, le rectangle de sélection souris.
UI (1 couche)
L'interface HTML au-dessus de tout : les contrôles InterfaceBuilder (boutons, sliders, inputs) qui flottent au-dessus du canvas. Chaque canevas est indépendant avec son propre état. Sélectionner des objets dans un canvas ne change pas la sélection dans un autre. Un seul canvas peut être édité à la fois.

Le système de projet type RPG Maker

La v5 prévoit un vrai système de fichiers projet, inspiré de RPG Maker. Le concept : quand l'utilisateur crée un projet, VOH crée un dossier structuré sur le disque :

MonProjet/
├── MonProjet.voh           — fichier projet (JSON)
├── index.html              — page d'entrée (générée par VOH)
├── core/
│   └── voh-core.min.js     — Core protégé (copié par VOH)
├── scripts/
│   └── main.js             — script principal
├── Images/
├── Vidéos/
├── Sons/
├── Fichiers/
├── Auto-Save/
│   └── autosave-index.json
└── Paramètres/
    └── config.json

Le Core est copié dans chaque projet — comme RPG Maker copie le runtime dans chaque jeu. Le projet est 100% autonome, portable, autosuffisant.

Neutralinojs : les premiers tests concrets

Un des premiers tests concrets de la v5 : compiler l'application web en exécutable Windows avec Neutralinojs. Un double-clic sur le .exe et l'application se lance, sans navigateur visible, sans installation. Ça fonctionne.

Le choix de Neutralinojs plutôt qu'Electron est stratégique : l'exécutable fait quelques mégaoctets au lieu de plus de 100 Mo. C'est léger, rapide, et ça utilise le WebView natif de l'OS.

David a aussi exploré Tauri comme alternative. Tauri est encore plus léger (3-5 Mo), son backend est en Rust, et il est sous licence MIT — totalement gratuit pour un usage commercial. Le choix définitif entre Neutralinojs et Tauri n'est pas encore arrêté.

La protection du code source

Une des frustrations d'Editors Factory était l'impossibilité de protéger le code source. Le module PureBasic était distribué en clair, n'importe qui pouvait le lire et le copier.

La v5 prévoit de résoudre ce problème. Le plan : minifier et obfusquer le Core via Vite, pour produire un voh-core.min.js illisible. Le code source resterait exclusivement chez David. Les utilisateurs recevraient soit un .exe packagé, soit un SDK avec le Core protégé.

Ce n'est pas une protection parfaite — en web, rien ne l'est — mais c'est suffisant pour décourager la copie opportuniste.

F5 = nouvelle fenêtre

Un des concepts les plus élégants de la v5 : quand l'utilisateur appuie sur F5 dans l'éditeur de code, VOH sauvegarde le projet puis ouvre une deuxième fenêtre Neutralinojs qui charge le projet comme un programme autonome.

Plus de new Function() hasardeux dans un iframe. Le programme tourne isolé dans sa propre fenêtre, exactement comme l'EXE final. Fermer la fenêtre ou cliquer Stop ramène à l'éditeur.

L'approche API-first

David et Claude choisissent une approche de développement inhabituelle pour la v5 : API-first.

Au lieu de commencer par l'éditeur visuel (l'interface avec les panneaux, les menus, le canvas interactif), ils commencent par le Core et son API. Un éditeur de code (CodeMirror) permet d'écrire et d'exécuter des scripts qui manipulent l'API directement. L'idée est de s'assurer que le moteur fonctionne parfaitement avant de construire l'interface par-dessus. Si l'API est solide, l'éditeur visuel suivra naturellement.

Les premiers pas sont modestes mais concrets : 15 scripts d'exemple, une documentation HTML, et une version 0.13.00. Les zones sont le premier module testé (multi-zone, création, suppression, switch entre zones). C'est à peu près tout pour l'instant. Les canvas, les objets, et tout le reste — c'est encore devant.

Le renommage

Avec la refonte, David envisage de renommer le projet. « Visual Objects Handler » ne lui semble plus assez représentatif de ce que le logiciel est devenu. Il propose « Editors Factory — Visual Objects Handler », puis « Editors Factory: VOH », puis revient à VOH tout court. La discussion reste ouverte. Comme David le dit :

« Le nom viendra naturellement quand le projet sera plus avancé et que la vision complète sera concrète. »

En attendant, VOH fait le job.

Multi-zone, multi-canvas, multi-page

La v5 est pensée dès le départ pour être multi-tout :

C'est la philosophie d'Editors Factory en PureBasic, mais poussée beaucoup plus loin. Editors Factory ne permettait qu'un seul canvas. La v5 vise à n'avoir aucune limite.

Le principe architectural est « zéro singleton, tout en instances ». Chaque instance de VisualObjectsHandler est autonome : ses objets, sa sélection, son historique, ses pages, sa grille, ses connexions, son rendu lui appartiennent. Aucune dépendance implicite à des variables globales.

La couche PureBasic : un pont, pas un abandon

Malgré la migration vers le web, David ne veut pas abandonner PureBasic. La v5 prévoit un pont bidirectionnel (PB Bridge) qui permet d'intégrer VOH dans un programme PureBasic via WebViewGadget.

PureBasic envoie des commandes à VOH via WebViewExecuteScript(). VOH renvoie les événements et données à PureBasic via BindWebViewCallback().

Ce ne serait plus la couche principale — Neutralinojs ou Tauri la remplacerait pour l'exécutable desktop. Mais pour les développeurs PureBasic qui voudraient intégrer VOH dans leurs programmes, le pont serait là.

Le système de docking VS2010

L'interface de la v5 est bâtie sur un système de panneaux dockables inspiré de Visual Studio 2010. C'est un chantier en soi.

Au départ, David demande simplement de pouvoir réorganiser les panneaux par glisser-déposer. Claude explore les bibliothèques existantes : GoldenLayout (la plus complète), Dockview, Lumino (JupyterLab), dock-spawn-ts. Toutes sont analysées pour leurs forces et faiblesses.

La décision est prise de coder le système de docking from scratch, adapté aux besoins spécifiques de VOH. La maquette résultante est impressionnante : panneaux détachables en fenêtres flottantes, split horizontal et vertical, onglets, redimensionnement par drag des bordures, boussole de docking (les flèches qui apparaissent quand on drag un panneau pour indiquer où il va s'ancrer). Mais le plus remarquable, c'est le theme editor qui accompagne le système de docking. Un éditeur visuel complet avec 239 variables CSS éditables en temps réel. Chaque section (panneaux, onglets, splitters, boussole de docking, fenêtres flottantes) a son propre aperçu interactif. Des lignes SVG connectent chaque propriété CSS à l'élément visuel correspondant dans le preview.

La maquette de docking est un projet dans le projet. Elle est suffisamment autonome pour être distribuée séparément, nettoyée de toute référence à VOH. David la teste, l'approuve, et elle devient le squelette de l'interface v5.

Les scripts et leur gestion

L'éditeur de code de la v5 ne se contente pas d'un simple champ de texte. C'est un vrai système de gestion de scripts. 15 scripts d'exemple sont fournis, organisés en 9 dossiers thématiques. Chaque script est un fichier .js stocké sur le disque dans le dossier script/ du projet. L'utilisateur peut créer, renommer, dupliquer et supprimer des scripts depuis un panneau dédié dans le dock.

Le panneau Scripts affiche l'arborescence des dossiers à gauche, et l'éditeur CodeMirror 5 à droite. Un clic sur un script le charge dans l'éditeur. L'exécution se fait par le bouton Play ou par un raccourci clavier.

Le CodeMirror 5 a été choisi plutôt que le CodeMirror 6 (plus moderne) pour une raison pratique : CodeMirror 6 nécessite un bundler (Rollup, Vite, Webpack) pour fonctionner, ce qui n'est pas compatible avec l'architecture Neutralinojs sans système de build. CodeMirror 5 se charge en un seul fichier JS et un CSS — c'est tout. L'auto-sauvegarde fonctionne sur deux niveaux : un timer de 30 secondes pour la sauvegarde périodique, et une sauvegarde automatique à chaque fermeture de l'application. Le contenu de l'éditeur est capturé avant chaque sauvegarde pour s'assurer que le script actif est toujours à jour.

La documentation HTML avec 50 thèmes

La documentation API de la v5 est une page HTML autonome, navigable et complète. Chaque module (Zone, Canvas, Objects...) a sa propre section avec des cartes pour chaque méthode API : signature, paramètres, valeur de retour, exemples de code.

La particularité : 50 thèmes de coloration syntaxique pour les blocs de code, sélectionnables en temps réel via un menu déroulant. De « Monokai » à « Solarized » en passant par des thèmes personnalisés, l'utilisateur choisit celui qui lui convient. La page Zone seule contient plus de 40 sous-liens et 29 cartes API.

Le document de conception en 4 fichiers

Le document de conception de la v5 est un monstre de plus de 2 300 lignes, découpé en 4 fichiers texte pour faciliter la lecture et les mises à jour :

Ce document est vivant — il est mis à jour à chaque décision importante. Il sert de référence partagée entre David et Claude, un contrat technique qui évolue avec le projet.