Deux bugs remontés en test manuel sur l'éditeur de scène (Phase A,
commit f0070fa) :
1. Décalage visuel à l'ajout d'un objet de scène (personnage/décor) :
render_scene_object.py positionne son <img> en absolu (left/top/
width/height en px), pensé pour être un enfant DIRECT de
.playScreen.playScene en mode jouable. Dans scene_edit.html, la même
balise est nichée dans .canvasElementInner, lui-même déjà positionné
par .canvasElement — l'image se repositionnait donc EN PLUS depuis
#canvas (son ancêtre positionné le plus proche), en double du
décalage déjà appliqué par le conteneur. Corrigé par une règle CSS
scoped à l'éditeur (.canvasElementInner > img) qui neutralise le
positionnement propre de l'image et la fait simplement remplir son
conteneur.
2. "FOREIGN KEY constraint failed" à l'ajout d'un clip de Timeline sur
un objet de scène : _animation_clips.element_id portait une VRAIE
contrainte FK vers _screen_elements depuis la création de la table.
animation-timeline.js est réutilisé TEL QUEL entre les deux éditeurs
(voir le plan "Fondations d'une plateforme multi-éditeurs") et
n'opère aucune distinction — pour un jeu jeu_2d, element_id désigne
en réalité un id de _scene_objects, absent de _screen_elements, d'où
l'échec de l'INSERT sous PRAGMA foreign_keys=ON. ensure_animation_schema
reconstruit maintenant la table (une fois, migration automatique à la
volée comme le reste du schéma) sans cette contrainte FK — même
patron que trigger_element_id/cond_element_a dans ensure_flow_schema.py.
Comme la suppression en cascade reposait jusqu'ici sur cette FK, un
nettoyage manuel des clips a été ajouté à la suppression d'un élément
(delete_element.py) et d'un objet de scène (delete_scene_object.py).
Nouveaux tests (tests/test_scene_edit_view.py, +4 cas) : ajout d'un
clip de Timeline sur un objet de scène via la route, nettoyage des
clips à la suppression d'un objet de scène et d'un élément DOM. Suite
complète : 312 tests passent (aucune régression).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ajoute le positionnement absolu (pos_x/pos_y, réutilise left/top en %
déjà en place) et relatif (pos_x_relatif/pos_y_relatif, ajoute un delta
à la position actuelle plutôt que de l'écraser) comme nouvelles
propriétés de l'action "Modifier un élément".
Ajoute une nouvelle source de condition "collision" (aux côtés de
"objet"/"variable") : deux éléments (cond_element_a/cond_element_b,
ALTER TABLE sans contrainte FK, même patron que block_id/
trigger_custom_event_id) dont on compare les rectangles à l'écran via
getBoundingClientRect() côté client (elementsOverlap(), dans
conditions.js). Pas d'opérateur/valeur à choisir : le chevauchement EST
directement le booléen vrai/faux du nœud — le créateur relie le port
"Faux" pour "ne se touchent pas", exactement comme pour n'importe quelle
autre condition (design plus simple que réinterpréter égal/différent,
qui n'a pas de sens pour superieur/inferieur).
delete_element.py et flow_nodes_referencing_element.py nettoient
désormais aussi les nœuds de collision référençant un élément supprimé
(ou l'un de ses descendants), pour rester cohérents avec le nettoyage
déjà en place pour trigger_element_id/target_element_id.
Combiné à la Phase 3 (minuteur récurrent) et au déplacement au clavier,
ça couvre des jeux type casse-briques/Pong/ramasse-objets sans
construire un vrai moteur physique (pas de vélocité/accélération/
gravité continues, cadrage volontairement limité).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Depuis le dernier correctif, supprimer un élément supprime aussi en
silence tout nœud de la Logique de la scène qui le référence (déclencheur/
action, voir delete_element.py) - nécessaire pour éviter le plantage
"FOREIGN KEY constraint failed", mais l'utilisateur n'était jamais prévenu
qu'un bout de sa logique disparaissait en même temps.
Nouvelle route GET .../elements/<id>/delete-impact (element_delete_
impact.py) : calcule, sans rien supprimer, combien de nœuds de la Logique
de la scène référencent cet élément OU l'un de ses descendants (partage
element_descendant_ids.py avec delete_element.py, pour rester exactement
cohérent avec ce qui sera réellement supprimé).
Les deux boutons "supprimer" de screen_edit.html (élément sélectionné, et
onglet d'un widget Onglets) ouvrent maintenant une modale custom
(deleteConfirmModal, même famille que le sélecteur d'icônes) au lieu du
confirm() natif du navigateur : elle interroge cette route juste après
ouverture et affiche un avertissement dédié si le nombre remonté est non
nul, avant que l'utilisateur ne confirme quoi que ce soit - impossible à
faire avec confirm(), dont le texte est figé au moment du rendu de la
page. La confirmation soumet ensuite le formulaire normalement (via
requestSubmit(), intercepté par pjax.js comme n'importe quel autre
formulaire).
Ajoute deux tests pour la nouvelle route (impact nul, impact non nul sans
rien supprimer).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bug remonté : supprimer un élément plantait avec sqlite3.IntegrityError:
FOREIGN KEY constraint failed.
Cause : trigger_element_id/target_element_id (_flow_nodes, voir
ensure_flow_schema.py - un nœud "clic sur cet élément" ou "Modifier cet
élément"/"Activer cet onglet") et target_element_id (l'ancien système
_actions, conservé pour compatibilité) référencent _screen_elements(id)
SANS ON DELETE CASCADE - volontairement, un élément ne doit pas pouvoir
disparaître "par erreur" en cascade depuis un nœud de logique qu'on
modifie ailleurs. Mais ça veut dire que delete_element.py, qui ne
supprimait jusqu'ici que la ligne elle-même, faisait échouer PRAGMA
foreign_keys=ON (db/connection.py) dès qu'un nœud de logique existant
référençait encore l'élément.
Fix : delete_element.py nettoie maintenant ces références AVANT de
supprimer l'élément - pas seulement pour l'élément explicitement supprimé,
mais pour tous ses DESCENDANTS aussi (leur suppression est cascadée
automatiquement au niveau SQL via parent_id, sans repasser par ce
fichier, donc sans ce nettoyage si on ne le fait pas explicitement).
Ajoute tests/test_delete_element_referenced_by_flow.py (élément
référencé comme déclencheur, comme cible d'action, et cas d'un conteneur
supprimé dont un descendant est référencé).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
