f03ac26200928456a902a70e7c33b2f1e01ebfc3
189
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 williamandClaude Sonnet 5
|
1b24df9546 |
Éditeur à champs pour les variables Objet/Tableau (plus de JSON à taper)
L'édition en JSON brut (textarea) n'était pas adaptée à un public non développeur. Remplacée par un panneau "Configurer la valeur" (déplaçable/ redimensionnable/plein écran, comme les autres) avec une ligne par clé (Objet) ou par élément (Tableau) : un champ Clé (Objet seulement), un type (Texte/Nombre/Oui-Non) et une valeur en texte libre — le JSON est reconstruit automatiquement au clic sur "OK", jamais tapé à la main. Un seul panneau partagé (#varValuePanel) pour toutes les variables : à l'ouverture (openVarValuePanel(targetInputId, mode)), reconstruit une ligne par entrée déjà présente dans le JSON actuel de l'<input> ciblé — un objet/tableau imbriqué en valeur est préservé tel quel (JSON.stringify en texte opaque) plutôt que perdu, même si cette valeur précise n'est pas éditable via une ligne (portée volontairement limitée aux valeurs simples : suffisant pour une configuration ou une liste, sans la complexité d'un éditeur JSON récursif). - Barre "+ Créer une variable" : le champ de valeur devient en lecture seule pour Objet/Tableau, avec un bouton "🔧 Configurer" à côté. - Ligne d'une variable existante : la cellule Valeur montre un aperçu en lecture seule + le même bouton "🔧 Configurer" (au lieu du textarea JSON du commit précédent). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
aaf9954446 |
Variables globales Objet/Tableau, lisibles via un chemin dans les conditions et filtres
Deux nouveaux types de variable globale (db/constants.py) : "objet" et
"tableau" — valeur stockée en JSON (colonne TEXT existante), avec
validation à la création/modification (db/global_vars/
coerce_structured_value.py) : un JSON invalide retombe sur un défaut sûr
("{}"/"[]") plutôt que de corrompre silencieusement la variable pour
toutes ses lectures suivantes. apply_variable_action.py n'a besoin
d'aucun changement — "definir_texte" écrit déjà n'importe quelle chaîne
telle quelle.
Nouvelle résolution de chemin, partagée (screens/rendering/
filter_repeater_rows.py::_resolve_variable_path) : navigue dans la
valeur JSON d'une variable selon un chemin ".champ"/"[index]" chaînable
(ex. ".arme.degats", "[0].valeur") — ne lève jamais, renvoie None si le
JSON est invalide ou qu'un segment du chemin ne correspond à rien.
Branchée à deux endroits, qui lisaient déjà une variable globale :
- La valeur de comparaison {{$nom_variable}} (filtres de Répéteur ET
Condition de visibilité, qui partagent le même
_resolve_filter_value()) accepte maintenant un chemin optionnel :
{{$perso.nom}}, {{$scores[0]}}. Le sélecteur "Variable globale" du
panneau de propriétés (screen_edit.html, .filterValueVariable) gagne un
champ "Chemin optionnel" à côté du choix de variable — même regex
étendue côté JS (_VAR_REF_RE) que côté Python (_VAR_REF_PATTERN), pour
que la valeur round-trip correctement à la réouverture du panneau.
- La variable VÉRIFIÉE par une Condition de visibilité en mode "variable"
(choisie via un <select>, pas la syntaxe {{$...}}) gagne son propre
nouveau contrôle "Chemin dans la variable" (visibility_condition_
controls.py) — nécessaire pour comparer un champ d'un Objet ou un
élément d'un Tableau, pas seulement la variable entière.
game_dashboard.html (onglet Variables) : la valeur par défaut de la barre
de création devient un <textarea> (fonctionne aussi bien pour un JSON
multi-ligne qu'un scalaire court), et la cellule "Valeur" du tableau des
variables existantes devient un <textarea> quand le type est objet/
tableau.
4 nouveaux tests (tests/test_variable_object_array.py) : validation JSON
à la création, filtre de Répéteur avec chemin chaîné, condition de
visibilité avec accès par index de tableau, chemin invalide/absent sans
plantage.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
b21f56e364 |
Filtre de colonnes + panneau de détail d'une entrée (onglet Données)
Un objet avec beaucoup de champs rendait le tableau "Données enregistrées" illisible (toutes les colonnes serrées sur une ligne, valeurs tronquées) — deux ajouts pour compenser : 1) "🔧 Colonnes" : menu déroulant (une case à cocher par champ, toutes cochées par défaut) au-dessus du tableau — décocher un champ masque sa colonne (th + td, via [data-col]) sans reconstruire le tableau. Un seul menu ouvert à la fois, fermé au clic ailleurs sur la page. 2) 👁️ par ligne : ouvre un panneau de détail (déplaçable/redimensionnable/ plein écran par défaut, comme les autres) listant TOUS les champs de cette entrée, un par ligne, valeur complète non tronquée — reprend le style .rowDetailField/.rowDetailLabel/.rowDetailValue de l'ancienne modale Bulma de data_list.html (retirée, mais ce CSS ne dépendait pas du template et a été gardé). Un seul panneau PAR OBJET (pas par ligne) : son contenu est reconstruit à l'ouverture en lisant en direct la ligne du tableau déjà affiché (via [data-row-id] sur chaque <tr>) — reflète donc aussi une modification tout juste saisie mais pas encore "Enregistrer"ée, sans aller-retour serveur. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
943bf265de |
Panneaux flottants en plein écran par défaut, avec bouton pour en sortir
Chaque panneau (Nouvel objet, Modifier un objet, Ajouter un champ, Ajouter une entrée) s'ouvre désormais en plein écran par défaut (marge de 12px) plutôt qu'en petite fenêtre centrée — plus confortable dès qu'il y a plusieurs champs/entrées à voir en même temps. Un bouton ⛶ dans l'en-tête bascule vers/depuis la taille et la position précédentes (mémorisées le temps de la session, pas persistées), pour qui préfère un panneau plus petit à côté du reste du tableau de bord. makeFloatPanelFullscreenable(panel, toggleBtn) — générique, posée sur panel._fsToggle — appelée par les 4 familles de panneaux existantes. makeFloatPanelDraggable()/makeFloatPanelResizable() sortent d'abord proprement du plein écran si l'utilisateur interagit manuellement (glisser l'en-tête ou tirer le coin) : sans ça, bottom/right encore actifs en plein écran auraient repris la main sur la position/taille qu'on vient de poser. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
03db681022 |
Panneaux dédiés pour "Ajouter un champ"/"Ajouter une entrée"
La barre en ligne (tous les champs alignés horizontalement) devenait illisible au-delà d'une poignée de champs — un objet à 10 champs donnait une ligne de saisie qui débordait largement de l'écran. Remplacée par un simple bouton "+ Ajouter" qui ouvre un panneau dédié (déplaçable et redimensionnable, comme les autres) avec un formulaire VERTICAL — un champ par ligne, étiquette au-dessus, comme un formulaire normal — plutôt qu'entassé sur une seule ligne. Un panneau "Ajouter un champ" et un panneau "Ajouter une entrée" par objet, tous deux cachés par défaut. Réutilise makeFloatPanelDraggable()/makeFloatPanelResizable() (déjà génériques, voir commit précédent) — aucun nouveau mécanisme de glisser-déposer à écrire. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
0e390a679b |
Ajoute l'onglet "Données" au panneau objet, retire object_view.html
Suite de la demande : le panneau "Modifier un objet" (crayon ✏️, onglet Objets du tableau de bord) a maintenant 2 sous-onglets — "Champs" (déjà en place) et "Données", qui reprend data_list.html + data_form.html (retirés) : ajouter une entrée (une ligne compacte avec le bon type de champ par colonne — texte/nombre/case à cocher/date/relation, comme l'ancien formulaire), modifier/supprimer une entrée existante (tableau dense, cellules éditables en ligne, même principe que "Champs existants"). Sous-onglets scopés au panneau de LEUR objet (switchObjectPanelTab(), classes .objectPanelTabs/.objectPanelTabPanel distinctes de .builderTabs/ .builderTabPanel) — plusieurs objets ont chacun leurs propres sous-onglets indépendants sur la même page, sans jamais interférer avec les onglets du tableau de bord lui-même. routes/games/game_dashboard.py fournit maintenant, par objet : ses lignes (rows_by_definition), les libellés lisibles de ses champs relation (relation_labels_by_definition, pour l'affichage) et leurs options (relation_options_by_definition, pour les <select>), ainsi que referenced_by_definition (avertissement permanent si un autre objet a une relation vers celui-ci — repris de l'ancien object_view.py, affiché maintenant en continu plutôt qu'après une tentative de suppression échouée). data_form.py (partagé par data_new/data_edit), data_delete.py et object_delete.py redirigent maintenant vers le tableau de bord (?edit=<id>&subtab=data, +?blocked_row=<id> si la suppression d'une entrée est bloquée par une relation) au lieu de object_view/object_edit. Piège évité : de nombreux tests déduisent l'id d'un objet fraîchement créé du DERNIER SEGMENT du chemin dans le header Location d'une redirection (.../objects/<id>) — rediriger object_new directement vers le tableau de bord (chemin sans id) cassait donc 33 tests d'un coup. Fix : object_view.py reste en place, mais seulement comme redirecteur (plus de page rendue) — object_new redirige toujours vers lui (chemin qui se termine par l'id, donc les tests continuent de fonctionner), qui redirige à son tour vers le tableau de bord. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
b8dfdcb205 |
Corrige la nav pjax, panneau déplaçable/redimensionnable pour éditer un objet
1) Bug pjax trouvé : swapDocument() cherchait "header.topbar", qui n'a jamais existé (c'est un <nav>, pas un <header>) — la barre de navigation du jeu (ajoutée après pjax.js) n'était donc jamais mise à jour pendant une navigation pjax : absente en arrivant sur un jeu sans Ctrl+F5, et inversement laissée en place en revenant sur l'accueil où elle n'a rien à faire. Fix : tout ce qui est hors <main> mais doit changer d'une page à l'autre (topbar + barre du jeu) est regroupé dans un nouveau conteneur stable #pageChrome, que pjax.js remplace en bloc — plus fiable qu'un sélecteur qui ne correspondait à rien. CSS (flex:0 0 auto des layouts plein-écran) mis à jour en conséquence. 2) Renommages demandés : onglet/panneau "Écrans du jeu" -> "Écrants", "Éléments de jeu" -> "Templates" (tab, titre de panneau, bouton "+ Créer un template", état vide, infobulle, confirmation de suppression). 3) Le crayon ✏️ sur une ligne d'objet ouvre désormais un panneau déplaçable ET redimensionnable (nouveau coin de redimensionnement générique, .floatPanelResizeHandle) au lieu de naviguer vers object_edit.html (retirée) — un panneau par objet, pré-rendu et caché par défaut. Reprend telles quelles les fonctionnalités de l'ancienne page : renommer l'objet, ajouter un champ (ligne compacte), modifier/supprimer un champ existant (tableau dense déjà repris pour "Nouvel objet"), supprimer l'objet. Les routes de champs (object_field_ add/edit/delete) et object_edit lui-même redirigent maintenant vers le tableau de bord avec ?edit=<id>, pour rouvrir automatiquement le bon panneau après l'action plutôt que de le fermer silencieusement. makeFloatPanelDraggable()/makeFloatPanelResizable() généralisées pour être partagées entre "Nouvel objet" et les panneaux d'édition, plutôt que du code dupliqué par panneau. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
e1216e99d5 |
Rend le panneau "Nouvel objet" compact — lignes de tableau, pas des cartes
Chaque champ prenait une grosse carte (~250px de haut : libellés Bulma pleine taille, "Retirer ce champ" en texte) — inutilisable pour un objet à 10+ champs, ce qui est pourtant l'usage visé par ce panneau. Remplacé par une vraie ligne de tableau dense, sur le même principe que "Champs existants" dans object_edit.html (déjà compact et sobre dans le reste de l'outil) : une ligne = un champ, colonnes Nom/Type/Objet lié/Mini/Maxi/Obligatoire, action "Retirer" réduite à une icône. Les colonnes conditionnelles (Objet lié pour une relation, Mini/Maxi pour un nombre) restent TOUJOURS présentes — sans quoi les colonnes de lignes différentes ne s'aligneraient plus — seul leur contenu bascule entre le vrai champ de saisie et un espace réservé "—", au lieu de masquer toute la cellule comme avant. object_form.js adapté en conséquence : bounds désormais 2 cibles séparées (mini/maxi, chacune dans sa propre cellule) au lieu d'une seule enveloppe commune, et chaque bascule s'accompagne de celle de son espace réservé. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
d875557254 |
Fusionne les 4 pages de création dans le dashboard, retire le titre/BDD
Suite de la demande précédente : les 4 pages autrefois listées dans la barre de navigation n'existent plus en tant que pages séparées — tout vit désormais dans les onglets du tableau de bord (commit précédent) ou, pour la création d'un objet, dans un panneau déplaçable. - screens_list.html + sa route (screens_list) : supprimés (l'onglet "Écrans du jeu" du dashboard couvre déjà tout : créer, réordonner, éditer, supprimer). screen_new/screen_move/screen_delete redirigent maintenant vers le dashboard (tab=screens) au lieu de cette page. - element_types.html : supprimé, mais la route element_types est conservée (GET redirige vers le dashboard, POST — utilisé par la barre de création repliable de l'onglet "Éléments de jeu" — continue de fonctionner). element_type_edit/element_type_delete redirigent aussi vers le dashboard. - game_variables.html + sa route (game_variables) : supprimés (l'onglet "Variables" du dashboard couvre déjà tout). create_global_var/ global_var_edit/global_var_delete redirigent vers le dashboard (tab=variables) au lieu de cette page. - object_form.html : supprimé. La route object_new (POST) est conservée pour traiter la soumission du panneau — voir plus bas — mais ne rend plus de page pour un GET (redirige vers le dashboard). Nouveau panneau déplaçable "Nouvel objet" sur le dashboard (bouton "+ Nouvel objet" de l'onglet Objets) : réutilise .floatPanel/ .floatPanelHeader/.floatPanelBody (déjà utilisées dans l'éditeur d'écran) avec une nouvelle variante centrée (.floatPanel--center) et son propre glisser-déposer minimal (pas de position persistée, contrairement aux panneaux de l'éditeur d'écran — inutile pour un panneau ouvert ponctuellement). Contenu et script (object_form.js) repris tels quels de l'ancienne page. base.html : la barre de navigation du jeu n'a donc plus que 2 liens — "📊 Tableau de bord" (nouveau) et "▶️ Jouer" (toujours en dernier). game_dashboard.html : titre du jeu et chemin de la base de données retirés (redondants avec le nom déjà visible dans l'onglet du navigateur/la barre de nav). Les liens "crée-en un"/"gérer les variables" dans l'éditeur d'écran (screen_edit.html) pointent maintenant vers le dashboard avec le bon onglet (?tab=...), lu et appliqué au chargement de la page (switchDashTab() côté JS). 2 tests (test_screens_and_elements.py) mis à jour : ils vérifiaient le contenu des pages supprimées (element-types, screens) — adaptés pour vérifier la même chose sur le dashboard, qui porte maintenant cette information. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
65450a5719 |
Refait le dashboard en fenêtre à onglets avec de vrais tableaux
Le précédent dashboard (grille de cartes compactes) ne correspondait pas
à ce que l'utilisateur voulait : une seule fenêtre avec de vrais tableaux
de données (denses, colonnes nettes), un bouton "Créer" par catégorie
dans l'en-tête, et une navigation horizontale pour passer d'une catégorie
à l'autre.
Réutilise telles quelles .builderTabs/.builderTabBtn/.builderTabPanel
(déjà utilisées pour "Écran / Logique / Timeline" dans l'éditeur d'écran)
plutôt que d'inventer un 2e système d'onglets — même sensation partout
dans l'outil. Un onglet par catégorie (Écrans/Objets/Éléments de
jeu/Variables), chacun avec :
- un bouton "+ Créer" dans l'en-tête qui révèle une barre de création
compacte (repliée par défaut) — sauf pour les Objets, dont la
création (plusieurs champs typés) reste sur sa propre page dédiée,
trop complexe pour tenir dans une barre ;
- le VRAI tableau de gestion de cette catégorie (colonnes, actions),
repris tel quel de screens_list.html/element_types.html/
game_variables.html plutôt que réinventé en version appauvrie.
La page défile désormais normalement (retrait de body.objectEditBody/
content-objectEdit, pensés pour une hauteur figée avec défilement
interne) — une liste peut être longue, pas besoin d'un défilement séparé
par panneau ici.
routes/games/game_dashboard.py fournit en plus variable_types
(db.GLOBAL_VARIABLE_TYPES) pour la barre de création de variable.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
8f45169209 |
Retire le fil d'Ariane, centre/réordonne la barre de nav, refait le dashboard
Trois demandes distinctes de l'utilisateur, regroupées car elles touchent
toutes à la navigation d'un jeu :
1. Fil d'Ariane retiré (devenu redondant avec la barre de navigation du
jeu ajoutée au commit précédent) : bloc breadcrumb_wrap retiré de
base.html, et son override ({% block breadcrumb %}) retiré des 9
templates qui le définissaient encore. .breadcrumbBar (CSS) retiré,
y compris des règles flex:0 0 auto de body.objectEditBody/builderBody.
2. Liens de .gameNavBar centrés (justify-content:center).
3. "Jouer" déplacé en dernier lien (c'est une action à part — ouvre
l'aperçu jouable dans un nouvel onglet — pas un éditeur de plus comme
les 4 autres).
4. game_dashboard.html devient un vrai tableau de bord : une grille de
cartes (Écrans/Objets/Éléments de jeu/Variables), chacune listant les
entrées existantes avec un accès direct (clic = éditeur concerné) et
un lien "Gérer" vers la page dédiée pour créer/réorganiser. Remplace
l'ancien panneau "Créer" (redondant avec la barre de navigation
persistante) et la simple table "Objets définis". routes/games/
game_dashboard.py alimente maintenant aussi screen_list, element_types
(+ usage) et variables, en réutilisant list_screens/
list_element_types/element_type_usage_count/list_global_variables déjà
utilisés ailleurs.
Vérifié en rendant toutes les pages concernées via le client de test
Flask : barre de nav présente partout où un `game` est dans le contexte
(absente sur l'accueil), fil d'Ariane absent partout, ordre des liens
avec "Jouer" en dernier.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
de89115534 |
Ajoute une barre de navigation persistante entre les éditeurs d'un jeu
Jusqu'ici, les liens vers les différents éditeurs d'un jeu (Écrans, Éléments de jeu, Variables, Jouer, Objet) n'existaient que dans le panneau "Créer" du tableau de bord (game_dashboard.html) — changer d'éditeur obligeait à revenir sur cette page à chaque fois. base.html expose désormais une 2e barre (.gameNavBar), sous la barre "Forge Engine" et au-dessus du fil d'Ariane, reprenant ces mêmes 5 liens — visible sur TOUTE page qui met un `game` dans le contexte du template (déjà fait par chaque route pour le fil d'Ariane, donc aucun changement de route nécessaire), absente sur l'accueil (liste des jeux, pas de jeu courant). L'onglet correspondant à la section actuelle est mis en évidence via un simple préfixe sur request.path. static/style.css : nouvelle barre en ligne (contrairement à .navList/ .navRow, empilés verticalement dans le panneau "Créer" du tableau de bord, réutilisés tels quels ailleurs). Ajoutée aux règles flex:0 0 auto de body.objectEditBody/body.builderBody (mise en page plein-écran des éditeurs) aux côtés de .topbar/.breadcrumbBar, sans quoi elle aurait cassé la répartition de hauteur figée de ces pages. Vérifié en rendant plusieurs routes via le client de test Flask : barre absente sur l'accueil, présente partout ailleurs (tableau de bord, liste des écrans, éditeur d'écran normal ET d'écran-modèle, éléments de jeu, variables, nouvel objet). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
ffedb16d8a |
Inclut les écrans-modèles dans gameData.flows/animations
Cause du "la logique posée sur le modèle ne s'applique pas dans la scène" (persistant malgré les 2 commits précédents) : full_game_payload() appelait list_screens(slug) SANS include_templates=True — un écran-modèle (ex. "Modèle : mail content") n'apparaissait donc jamais dans gameData.flows ni gameData.animations côté client. findTriggerNode() cherche pourtant bien un déclencheur dans TOUTES les clés de gameData.flows — mais si l'écran-modèle n'y a même pas d'entrée, il n'y a rien à trouver, quelle que soit la justesse de cette recherche. Fix : les nœuds/fils de logique et les clips d'animation sont désormais lus pour TOUS les écrans (list_screens(slug, include_templates=True)), dans une boucle séparée de celle qui construit payload_screens — celle- ci continue de ne lister que les vrais écrans, pour ne jamais rendre un écran-modèle comme un <div class="playScreen"> à part entière (il n'est jamais affiché tel quel, seulement rechargé en direct à l'intérieur d'un élément qui l'utilise). Vérifié sur les vraies données du jeu de test : gameData.flows contient désormais bien l'écran 3 (le modèle "mail content"), avec son déclencheur "Au survol" et son action "Rendre visible" ; payload_screens ne contient toujours que l'écran réel (1). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
e653f95d37 |
Ouvre les onglets Logique/Animation dans l'éditeur d'un modèle réutilisable
Ces onglets ("Logique de la scène", "Timeline d'animation") étaient
masqués sur l'écran-modèle d'un élément de jeu réutilisable, avec un
commentaire expliquant pourquoi : à l'époque, ses enfants étaient COPIÉS
en base avec un NOUVEL id à chaque exemplaire posé
(instantiate_template_tree) — une logique/animation posée dans le
modèle référencerait donc des ids qui n'existent plus une fois
l'élément utilisé ailleurs.
Ce mécanisme a depuis été retiré (voir le commentaire dans
list_elements.py) : le contenu d'un élément de jeu réutilisable est
désormais TOUJOURS rechargé EN DIRECT depuis son écran-modèle à chaque
affichage, avec les MÊMES ids à chaque exemplaire. Combiné au commit
précédent (findTriggerNode/runFlowFrom/collectAnimationClips côté
play.html, qui exécutent maintenant correctement un déclencheur/une
animation posé dans un modèle, où qu'il soit utilisé), la restriction
de cette page n'avait donc plus lieu d'être — elle bloquait justement la
fonctionnalité que le commit précédent venait de rendre possible.
Les données nécessaires (flow_nodes/flow_edges/elements du modèle,
etc.) étaient déjà calculées sans condition par la route
(routes/screens/screen_edit.py) ; seul le template masquait les deux
onglets et leur contenu derrière {% if not screen.is_template %}.
switchBuilderTab() détecte déjà la présence des panneaux via
HAS_FLOW_PANEL/HAS_ANIM_PANEL (document.getElementById), donc aucun
changement JS n'était nécessaire.
Vérifié en rendant réellement /game/test/screens/3/edit (l'écran-modèle
"mail content") via le client de test Flask : les deux onglets sont
maintenant bien présents, et l'écran normal (id=1) n'est pas affecté.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
17c5e93d8d |
Fait fonctionner logique et animations d'un modèle réutilisable partout où il est posé
Jusqu'ici, la logique (déclencheurs Au clic/Au survol/Fin du survol) et
les animations posées dans l'éditeur de l'écran-MODÈLE d'un élément de
jeu réutilisable (ex. "mail content") sur SES PROPRES enfants ne
s'exécutaient jamais quand cet élément était simplement posé sur une
autre scène : findTriggerNode() cherchait bien le déclencheur dans tous
les écrans (modèles compris) mais runFlowFrom() n'exécutait ensuite le
graphe que dans l'écran RÉELLEMENT affiché — le nœud trouvé n'existait
pas dans ce graphe-là, donc rien ne se déclenchait, silencieusement.
Même limitation pour les animations, dont la timeline ne lisait que les
clips propres à l'écran affiché.
Logique (templates/play.html) :
- findTriggerNode() renvoie désormais { node, screenId } plutôt que
juste le nœud, pour transmettre l'écran D'ORIGINE du déclencheur (qui
peut être un écran-modèle).
- runFlowFrom(nodeId, flowScreenId) accepte un 2e paramètre optionnel
(par défaut l'écran affiché, comportement inchangé pour tout le
reste) pour exécuter le graphe dans le BON écran.
- bindClicks()/bindHoverTriggers() passent maintenant cet écran
d'origine à runFlowFrom(). runScreenShowTriggers() (déclencheur "À
l'affichage de l'écran") reste volontairement inchangé — hors scope,
ambiguïté sur plusieurs exemplaires d'un même modèle sur un écran.
Animations (screens/payload/full_game_payload.py, templates/play.html) :
- Le payload expose désormais element_types (element_type_id -> id de
son écran-modèle), via screens.list_element_types() déjà existant.
- collectAnimationClips(screenId) rassemble récursivement les clips de
l'écran affiché ET de tout écran-modèle utilisé par un de ses
éléments (garde anti-boucle, dédoublonnage par écran).
- applyAnimationClip() cible désormais TOUS les exemplaires d'un id
d'élément (querySelectorAll, plus querySelector) : un enfant de
modèle garde le même id à chaque exemplaire, y compris pour chaque
ligne d'un Répéteur utilisant ce modèle comme gabarit de ligne.
Limite connue, non corrigée ici (pas la demande) : une action "Modifier
un élément" ciblant un enfant de modèle reste, elle, scopée au premier
exemplaire trouvé dans le DOM (document.querySelector singulier dans
runActionNode/applyElementProperty) — sans impact pour un modèle posé
une seule fois par écran, comme dans le cas d'usage actuel.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
19d3810164 |
Calcule rendered_html pour CHAQUE élément, pas seulement le premier niveau
Cause racine réelle des 2 précédents correctifs (commits |
||
|
williamandClaude Sonnet 5
|
f016a81dc6 |
Résout {{champ}} en place au lieu de recréer le nœud (zéro flash, façon React)
L'utilisateur a raison de pointer que le vrai souci n'était pas un bug
isolé mais l'APPROCHE elle-même : detruire puis reconstruire un nœud du
DOM à chaque clic (même bien ciblé, comme depuis les 2 derniers commits)
cause toujours un flash visuel, puisque tout état transitoire du
sous-arbre (visibilité posée par "Modifier un élément", focus...) est
perdu et reconstruit à neuf. C'est ce qui donnait l'impression trompeuse
d'un "rechargement" — un comportement JS parfaitement normal quand on
manipule le DOM ainsi, mais évitable : c'est exactement le problème que
la réconciliation ciblée de React (ne patcher que ce qui a changé,
jamais recréer un nœud pour rien) résout côté framework.
applyOpenRowBindings() ne remplace donc plus JAMAIS le nœud de l'élément
ciblé (ex. "mail content") — il patche directement, en place :
- un nœud TEXTE contenant {{champ}} est coupé en 3 (texte avant, un
<span data-bind-field="champ">, texte après) LA PREMIÈRE FOIS
SEULEMENT ; toute ouverture suivante se contente de changer le
textContent de ce span — plus aucune reconstruction ensuite.
- un ATTRIBUT contenant {{champ}} (ex. href="{{link_real_url}}") voit
son gabarit d'origine mémorisé sur data-bind-attr-<nom> au premier
passage, pour être recalculé et réécrit directement à chaque fois
sans jamais reconstruire le nœud.
Plus aucun nœud n'étant détruit, la sauvegarde/restauration de l'état
visuel transitoire (ajoutée dans un commit précédent pour compenser
cette destruction) devient inutile et est retirée.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
5e4e226794 |
Corrige le filtre "élément le plus spécifique" (logique inversée)
Les deux commits précédents (ciblage des éléments imbriqués dans applyOpenRowBindings() et refreshRuntimeData()) n'avaient AUCUN effet visible, confirmé par l'utilisateur après redémarrage du serveur — cause trouvée : leur filtre "ne garder que les éléments les plus spécifiques" vérifiait l'inverse de ce qu'il fallait. Un CONTENEUR contient toujours le HTML de ses descendants dans son propre rendered_html — donc un ancêtre "a le marqueur/placeholder" quasi systématiquement dès qu'un descendant l'a. Le filtre précédent excluait un élément candidat si un de ses ANCÊTRES était candidat — ce qui, vu ce qui précède, ne gardait quasiment jamais que l'ancêtre RACINE de l'écran, reproduisant exactement le bug d'origine (tout l'écran régénéré) que ces commits visaient à corriger. Fix : inversion du sens du filtre — un candidat est désormais exclu si l'un de ses PROPRES DESCENDANTS est aussi candidat (le descendant sera déjà régénéré individuellement, inutile de régénérer aussi son ancêtre). Vérifié par une simulation Node.js reproduisant la structure réelle de l'écran de test (Répéteur niché sous 2 conteneurs, "mail content" sous 2 autres) : la nouvelle logique cible bien uniquement le Répéteur et "mail content", plus jamais le conteneur racine de l'écran. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
f4a7a7340e |
Cible aussi les éléments imbriqués dans refreshRuntimeData()
Même défaut que celui corrigé dans applyOpenRowBindings() (commit précédent), mais dans le second endroit qui régénère l'écran après un changement de donnée : refreshRuntimeData() ne pouvait régénérer que les éléments de PREMIER NIVEAU (seuls eux ont un data-el-id sur leur wrapper .playElement). Un Répéteur niché dans un conteneur — comme celui de cet écran — n'est jamais du premier niveau : c'est donc son ANCÊTRE de premier niveau qui portait le marqueur "repeaterItem" à l'intérieur et se faisait régénérer en entier à sa place, potentiellement l'écran complet (jauges, onglets compris) si l'écran n'a qu'un seul gros conteneur racine. C'était la cause réelle du "rechargement" toujours visible après le précédent correctif : celui-ci ne portait que sur applyOpenRowBindings(), pas sur cette 2e régénération déclenchée par "Modifier une donnée"/"Modifier une variable". Fix : même principe que le commit précédent — cible chaque élément marqué (repeaterItem/jaugeBar/visibilityGated) directement via son data-element-id, à n'importe quel niveau d'imbrication, en ne gardant que les plus "hauts" parmi les éléments marqués pour ne jamais régénérer un même nœud deux fois. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
20adfa4169 |
Ne régénère plus que l'élément concerné par "Ouvrir la ligne cliquée"
Cause du "rechargement" perçu par l'utilisateur (et du flash à vide sur
la ligne de Répéteur juste cliquée, visible sur une vidéo de repro) :
applyOpenRowBindings() ne pouvait cibler que les éléments de PREMIER
NIVEAU de l'écran (seuls eux ont un wrapper .playElement dans le DOM).
Sur cet écran, "mail content" est niché à 2 conteneurs de profondeur, et
le SEUL élément de premier niveau est le conteneur racine de tout
l'écran — donc chaque clic sur une ligne de Répéteur régénérait
littéralement tout l'écran (jauges, onglets, Répéteur compris) pour ne
mettre à jour qu'un seul panneau de détail, avec un flash à vide pendant
la reconstruction.
Fix : applyOpenRowBindings() cible maintenant directement, à n'importe
quel niveau d'imbrication, le(s) élément(s) qui portent réellement un
{{champ}} non résolu (repéré via document.querySelector
('[data-element-id=...]'), disponible sur CHAQUE élément rendu, pas
seulement les élément de premier niveau) — et seulement les plus "hauts"
parmi eux, pour ne jamais régénérer un même nœud deux fois. Seul "mail
content" est donc désormais remplacé (via replaceWith), sans toucher au
Répéteur ni au reste de l'écran. La sauvegarde/restauration de l'état
visuel transitoire (style, classes, dataset hors clickBound/hoverBound/
hoverTriggerBound) suit le même principe, appliquée au nœud remplacé et
à ses descendants.
Aucun aller-retour réseau n'a jamais eu lieu ici (refreshRuntimeData()
utilise déjà fetch/JSON, pas de navigation de page) — la sensation de
rechargement venait uniquement de la granularité du remplacement DOM,
pas d'un manque d'AJAX.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
5114372cc4 |
Réattache les gestionnaires de clic après "Ouvrir la ligne cliquée"
Root cause enfin identifiée grâce à un log console instrumenté par
l'utilisateur (indispensable — sans lui les précédents correctifs
visaient le mauvais chemin de code, refreshRuntimeData(), qui ne se
déclenchait même pas dans ce scénario) : l'action "Ouvrir la ligne
cliquée" (ouvrir_ligne) appelle applyOpenRowBindings() DIRECTEMENT,
sans jamais rappeler bindClicks() ensuite — contrairement à
refreshRuntimeData(), qui elle le fait déjà correctement.
Si l'écran a un Répéteur ET un panneau de détail (avec des {{champ}})
posés dans un même conteneur parent, applyOpenRowBindings() régénère
tout ce sous-arbre — Répéteur compris — pour résoudre les {{champ}} du
panneau. Les lignes du Répéteur héritent alors de nœuds DOM tout neufs,
sans le moindre écouteur de clic (le garde-fou anti-doublon de
bindClicks() repose sur dataset.clickBound, absent sur un nœud neuf,
mais bindClicks() lui-même n'était jamais rappelé pour les attacher).
Symptôme exact reproduit : le tout premier clic sur une ligne fonctionne
(gestionnaires posés au chargement de la page), plus AUCUN clic ne
répond ensuite sur AUCUNE ligne, sans erreur console — confirmé par un
log montrant runFlowFrom() jamais réinvoqué au clic suivant, et
manuellement réparé en rappelant bindClicks() à la main dans la
console.
Fix : bindClicks()/bindHoverTexts()/bindHoverTriggers() sont maintenant
rappelés juste après applyOpenRowBindings() dans le gestionnaire de
"Ouvrir la ligne cliquée", comme ils le sont déjà dans
refreshRuntimeData().
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
ca7daf9a31 |
Réattache toujours les gestionnaires de clic après un rafraîchissement de données
Test de diagnostic déterminant : après le blocage rapporté (plus aucune ligne de Répéteur ne répond après le tout premier clic), appeler manuellement bindClicks() dans la console suffisait à tout réparer — donc ni le DOM ni le graphe de logique n'étaient en cause, seule l'INVOCATION de bindClicks() manquait à un moment donné. Cause : refreshRuntimeData() faisait un retour anticipé silencieux (`if (!screenData || !screenDiv) return;`) qui sautait, avec lui, TOUT le reste de la fonction — y compris bindClicks(), bindHoverTexts() et bindHoverTriggers() — sans le moindre message d'erreur, laissant les éléments régénérés (Répéteur compris) sans aucun écouteur pour le reste de la partie. Fix : ce garde-fou ne protège plus désormais que le bloc de régénération du contenu de l'écran (qui a effectivement besoin de screenData/ screenDiv) ; les réattachements, eux, s'exécutent toujours ensuite, quoi qu'il arrive. Un try/catch autour de la régénération ajoute en prime un filet de sécurité : toute erreur inattendue s'y loggera clairement au lieu de bloquer silencieusement le reste, si jamais ce n'était pas l'unique cause. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
024da11934 |
Corrige le blocage des clics après le premier rafraîchissement de données
Régression introduite par le commit précédent (préservation de l'état
visuel transitoire dans applyOpenRowBindings) : la restauration du
dataset complet d'un nœud copiait aussi clickBound/hoverBound/
hoverTriggerBound — des indicateurs INTERNES au moteur (voir bindClicks/
bindHoverTexts/bindHoverTriggers), jamais un état posé par une action
"Modifier un élément". Un nœud tout juste régénéré se retrouvait donc
marqué "déjà lié" à tort, alors qu'aucun écouteur de clic n'y était
réellement rattaché : bindClicks() le voyait déjà "bound" et sautait
son rattachement, rendant l'élément silencieusement inerte pour le
reste de la partie.
Symptôme rapporté : dans un écran avec un Répéteur ET un panneau de
détail utilisant des {{champ}}, le premier clic sur une ligne fonctionne
(exécuté par les gestionnaires posés au chargement de la page), mais
plus aucun clic ne répond ensuite sur AUCUNE ligne — le Répéteur étant
regénéré dans le même sous-arbre que le panneau de détail (ancêtre
commun avec des {{champ}} non résolus), donc concerné par la même
restauration de dataset.
Fix : exclure ces trois clés internes de la sauvegarde/restauration —
seul l'état réellement transitoire (style inline, classes, data-toggle-*
posés par "Modifier un élément") doit survivre à la regénération.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
 w-vandal
|
4fc2b492b1 |
Merge pull request 'Dev' (#1) from dev into main
Reviewed-on: #1 |
||
|
williamandClaude Sonnet 5
|
438e561b45 |
Préserver l'état visuel transitoire lors du rafraîchissement des données
Cause réelle du bug rapporté ("clic sur une ligne = comme un rechargement,
impossible de cliquer sur une deuxième ligne") : applyOpenRowBindings()
regénère entièrement le sous-arbre d'un élément contenant des {{champ}}
(ex. "mail content") à partir de son HTML D'ORIGINE, tel que rendu par le
serveur — donc avec son style PAR DÉFAUT (ici "invisible" via le réglage
Disposition > Visibilité). Cette fonction est appelée après CHAQUE
rafraîchissement de données (refreshRuntimeData), y compris pour un
changement de donnée sans rapport avec ce panneau.
Or une action "Modifier un élément → Rendre visible" ne modifie JAMAIS la
base : c'est un changement DOM transitoire (style.visibility = ''). Quand
un clic sur une ligne de Répéteur déclenche EN PARALLÈLE "Ouvrir la ligne
cliquée" + "Rendre visible" + "Modifier une donnée", la branche
"Modifier une donnée" est asynchrone (aller-retour serveur) et termine
après les deux autres, synchrones. Son refreshRuntimeData() qui suit
regénère alors "mail content" depuis son état par défaut, écrasant le
"Rendre visible" qui venait tout juste d'être posé — le panneau redevient
invisible. Un second clic sur le MÊME mail "corrige" l'affichage car la
donnée est déjà à jour, donc la Condition ne redéclenche plus l'action de
modification, plus de refresh, plus d'écrasement ; mais ouvrir un AUTRE
mail reproduisait le même écrasement.
Fix : avant de remplacer wrapper.innerHTML, sauvegarder le style inline,
la classe et les data-* de chaque élément du sous-arbre, puis les
réappliquer juste après la regénération — la résolution des {{champ}}
reste correcte (c'est le but premier de la fonction) sans plus annuler
les changements posés par une action "Modifier un élément" au même clic.
Les trois actions du graphe (ouvrir la ligne, rendre visible, modifier la
donnée) restent connectées telles quelles, sans aucun retrait.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
96d017c21f |
Évite de rejouer les déclencheurs "affichage"/l'animation quand on est déjà sur l'écran ciblé
Bug remonté : cliquer sur une ligne de Répéteur "semblait recharger la page", et devenait impossible à recliquer une deuxième fois - alors que le graphe de logique voulu (modifier la donnée + rendre visible un détail + "Ouvrir la ligne cliquée") reste sur le MÊME écran que le Répéteur. Cause : showScreen() rejouait INCONDITIONNELLEMENT les déclencheurs "À l'affichage de l'écran" et relançait la timeline d'animation depuis le début à chaque appel - même quand l'écran cible est déjà celui affiché (le cas normal pour "Ouvrir la ligne cliquée" combinée à une action "Modifier un élément → Visibilité" sur le même clic, pensées pour fonctionner ensemble SUR le même écran qu'un Répéteur). Ça rejouait donc les animations d'entrée et pouvait faire repasser la visibilité à son état initial via un déclencheur "affichage", entrant en conflit avec l'action "Rendre visible" du même clic - d'où l'impression de rechargement, et le blocage : reflow/re-rendu qui se disputent avec l'état attendu. Fix : showScreen() ne fait plus rien du tout si l'écran ciblé est déjà celui affiché - aucun changement visuel à faire, donc aucune raison de rejouer son "premier affichage". Changer vers un écran DIFFÉRENT continue de tout rejouer normalement. Les trois actions du graphe restent déclenchées à chaque clic, sans plus se marcher dessus. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
b094342097 |
Ajoute "Ligne cliquée (Répéteur)" comme cible pour une Condition/action de la Logique de la scène
Problème remonté : un déclencheur "Au clic" posé sur un Répéteur exécute
le MÊME graphe pour n'importe quelle ligne cliquée - or une Condition
("Si is_opened est égal à Non") ou une action "Modifier une donnée" ne
pouvaient viser qu'une ligne FIXE, choisie à la création du nœud dans
l'éditeur. Impossible donc de dire "modifie le champ DE LA LIGNE QUE JE
VIENS DE CLIQUER", puisque cette ligne n'est justement jamais connue à
l'avance.
Nouvelle valeur sentinelle CLICKED_ROW_ID (-1, screens/flow/constants.py,
ne collisionne jamais avec un vrai id de ligne) proposée en tête de TOUTE
liste déroulante "Ligne concernée" (clause principale et clauses
supplémentaires d'un nœud Condition, cible d'une action "Modifier une
donnée") : "🖱️ Ligne cliquée (Répéteur)".
Résolution au moment de l'exécution, pas à la création du nœud :
- Condition (évaluée côté client) : readFieldValue() (play.html) résout
-1 en window.lastClickedRowId, déjà capturé par bindClicks() au clic sur
une ligne de Répéteur (déjà utilisé par "Ouvrir la ligne cliquée").
- Action "Modifier une donnée" (exécutée côté serveur) : le client envoie
clicked_row_id dans le corps de la requête POST ; flow_node_run_data.py
ne s'en sert que si le nœud vise justement CLICKED_ROW_ID, sinon la
ligne fixe stockée sur le nœud reste utilisée normalement.
Ajoute tests/test_flow_clicked_row.py (ligne cliquée seule modifiée,
absence de clic = no-op plutôt que plantage, non-régression d'une cible
fixe, présence de l'option dans l'éditeur).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
7d48445443 |
Ajoute "Variable globale" au sélecteur "Valeur fixe / Donnée d'un autre objet"
Le sélecteur de valeur de comparaison (tout contrôle "..._valeur" : filtre
du Répéteur, Donnée liée, condition de visibilité) proposait déjà une
valeur fixe ou le champ d'un AUTRE objet - manquait la possibilité de
comparer à une variable globale (voir db/global_vars/), qui change elle
aussi en cours de partie mais n'est rattachée à aucun objet précis.
Nouvelle syntaxe interne "{{$nom_variable}}" (le "$" la distingue sans
ambiguïté de "{{Objet.champ}}", qui attend toujours un point) :
_resolve_filter_value (filter_repeater_rows.py) va lire sa valeur actuelle
via db.get_global_variable, comme "{{Objet.champ}}" le fait déjà pour un
champ d'objet. Le panneau de propriétés gagne un troisième mode
"Variable globale" à côté de "Valeur fixe"/"Donnée d'un autre objet",
avec la liste déroulante des variables existantes.
Corrige au passage un bug latent découvert en testant bout en bout : un
Répéteur SANS modèle de ligne (texte brut avec {{champ}}) plantait en
mode jouable avec TypeError - render_repeater.py substitue lui aussi
directement les {{champ}} du ctx dans ce cas (repli), et ce ctx porte
aussi _forge_play_mode (un booléen, voir render_element_html.py) depuis
l'ajout de la condition de visibilité - déjà corrigé pour le chemin
générique (apply_ctx.py) mais pas pour ce chemin séparé.
Le sélecteur de champ pour insérer {{champ}} dans "Contenu" (demandé dans
le même message) existe déjà depuis un tour précédent (voir
insertFieldAtCursor()) - vérifié toujours fonctionnel.
Ajoute tests/test_filter_value_global_variable.py.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
6894c5fc95 |
Remplace le confirm() natif par une modale custom qui avertit des suppressions en cascade
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> |
||
|
williamandClaude Sonnet 5
|
1e86077e45 |
Corrige un plantage à la suppression d'un élément référencé par la Logique de la scène
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> |
||
|
williamandClaude Sonnet 5
|
4dc42a7f3b |
Corrige les réglages fantômes d'un exemplaire d'élément de jeu déjà posé
Bug remonté : la taille d'un Titre réglée à 18px dans le modèle affichait 21px "sur l'écran". Cause : un exemplaire posé AVANT le passage en mode "toujours lié au modèle" (tour précédent) avait été créé par l'ancien mécanisme instantiate_template_tree (retiré), qui copiait tout l'arbre en base - ces lignes copiées (l'ancien enfant "Titre", encore à 21px depuis avant le changement) ne sont plus jamais RENDUES (le contenu vient désormais toujours en direct du modèle, voir le tour précédent), mais restaient toujours sélectionnables dans l'arborescence de l'éditeur, avec leurs propres réglages jamais synchronisés. Cliquer dessus dans l'arbre affichait donc ses vieux réglages (21px) dans le panneau de propriétés, donnant l'impression trompeuse que le modèle (18px) n'était pas pris en compte - alors que le rendu réel utilisait déjà correctement 18px. Fix, dans list_elements.py : tout élément dont un ANCÊTRE a element_type_id réglé est maintenant exclu de la liste renvoyée à l'éditeur (arborescence, sélection, panneau de propriétés) - son contenu n'a plus aucune existence propre, seul l'écran-modèle fait foi. Les lignes elles-mêmes restent en base (pas de suppression, un simple filtre en lecture) mais ne sont plus jamais atteignables depuis l'éditeur. Ajoute un test de régression qui simule exactement ce scénario (ligne orpheline avec un ancien réglage figé) et vérifie qu'elle n'apparaît plus nulle part - ni dans le canevas, ni via une sélection directe par id. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
94f1414506 |
Corrige un bug important : le style de TOUT élément neuf était cassé depuis l'ajout de l'Ombre
Bug remonté ("toutes les propriétés ne sont pas prises en compte") : la
vraie cause n'avait rien à voir avec les éléments de jeu — le contrôle
"Ombre" (voir le tour précédent) a une valeur par défaut composite (un
dict Python, {"x":0,"y":4,...}, pas une chaîne CSS). default_style_for_
widget.py, qui fige les réglages "dont la valeur par défaut a un effet
visuel voulu dès la création" pour chaque widget neuf, n'excluait pas ce
nouveau type de contrôle — il écrivait donc ce dict TEL QUEL (repr Python)
dans le style de CHAQUE élément fraîchement créé depuis ce commit, quel
que soit son widget. Une valeur CSS invalide au milieu du style pouvait
donner l'impression que "plein de propriétés" ne s'appliquaient plus.
Deux correctifs :
1. default_style_for_widget.py exclut maintenant "shadow" du gel à la
création (même raisonnement déjà appliqué à "color" juste au-dessus :
la valeur par défaut n'est qu'une suggestion affichée dans le panneau,
pas un réglage neutre à figer - le neutre CSS est "pas d'ombre").
2. style_string.py ignore désormais toute valeur non scalaire (dict/liste)
au moment de construire l'attribut style - filet de sécurité pour les
éléments déjà créés AVANT ce correctif, qui portent encore ce dict figé
en base et continueraient sinon à s'afficher cassés.
Ajoute deux tests de régression dans test_shadow_controls.py (aucune ombre
au premier rendu d'un élément neuf ; un élément déjà corrompu avant ce
correctif continue de s'afficher normalement).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
e9a991ed13 |
Un exemplaire d'élément de jeu posé sur un écran reste maintenant lié à son modèle
Jusqu'ici, poser un élément de jeu depuis le catalogue ("Mes éléments de
jeu") copiait tout son arbre en base (instantiate_template_tree) : chaque
exemplaire devenait indépendant, y compris de son propre modèle - modifier
l'élément de jeu dans son éditeur n'avait plus aucun effet sur les
exemplaires déjà posés ailleurs.
Change ce comportement pour qu'un exemplaire reste TOUJOURS lié à son
modèle, sur le même principe déjà utilisé par un modèle de ligne de
Répéteur (jamais copié, rechargé en direct à chaque affichage - voir
_load_template_tree/_render_repeater) : add_element.py ne crée plus
qu'UNE SEULE ligne plate (avec sa position/taille propres à cet
exemplaire) au lieu de copier tout l'arbre, et render_element_html.py
recharge le contenu depuis l'écran-modèle à chaque rendu quand
element_type_id est réglé. Modifier l'élément de jeu dans son propre
éditeur met donc à jour tous ses exemplaires déjà posés, sur n'importe
quel écran (y compris ceux placés AVANT ce correctif, qui portaient déjà
element_type_id sur leur ligne de premier niveau), sans avoir à les
retoucher un par un.
Contrepartie assumée (discutée avec l'utilisateur avant ce changement) :
un exemplaire ne peut plus être personnalisé individuellement à
l'INTÉRIEUR (texte, couleur d'un enfant précis...) - seules sa position et
sa taille sur l'écran restent propres à chaque exemplaire. Pour changer le
contenu, il faut désormais passer par l'éditeur de l'élément de jeu
lui-même.
instantiate_template_tree.py, devenu inutilisé, est supprimé.
Ajoute tests/test_element_type_live_instances.py (mise à jour d'un
exemplaire déjà posé, propagation jusqu'à "Jouer", position toujours
indépendante par exemplaire) et met à jour un commentaire de test devenu
obsolète dans test_screens_and_elements.py.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
79fe04c6ac |
Corrige "database is locked" causé par une connexion SQLite qui fuit après un plantage
Bug remonté : suppression d'un élément échouant avec sqlite3.OperationalError: database is locked, exactement sur le conn.execute() de delete_element.py. La trace complète montrait que la connexion attendait puis lâchait après le timeout (10s) - pas une simple collision passagère entre deux requêtes (déjà gérée par WAL + busy_timeout, voir les commentaires existants de connect()), mais un verrou tenu bien plus longtemps : une connexion ouverte par une requête ANTÉRIEURE qui a planté, jamais fermée. Cause de fond : chaque fonction de db/ (~80 d'entre elles) ouvre sa propre connexion et est censée la fermer elle-même avant de rendre la main - si une exception survient entre l'ouverture et cette fermeture, le conn.close() prévu n'est jamais atteint. En mode debug (voir app.py), le débogueur Werkzeug garde la trace complète de l'erreur en mémoire pour l'inspection interactive, ce qui inclut la variable locale `conn` : empêchée d'être ramassée par le GC, elle ne libère jamais son verrou d'écriture SQLite - bloquant TOUTE écriture suivante jusqu'au redémarrage du serveur, même longtemps après l'erreur d'origine et sans lien apparent avec elle (d'où la confusion : l'erreur semble venir de l'action qui échoue, alors qu'elle est victime d'une fuite antérieure). Fix, dans db/connection.py, sans toucher aux ~80 fonctions existantes : connect() enregistre maintenant chaque connexion sur le contexte de la requête Flask en cours (flask.g, uniquement quand il y en a un - un appel direct hors requête, scripts/tests, n'est pas concerné) ; un teardown_request ferme toute connexion encore ouverte à la fin de CHAQUE requête, qu'elle ait réussi ou planté (garanti par Flask, contrairement à after_request). Fermer une connexion déjà fermée normalement ne fait rien, donc aucun changement de comportement pour le cas normal. Ajoute tests/test_db_connection_leak_safety_net.py, qui reproduit le scénario exact (connexion ouverte puis exception avant fermeture) et vérifie qu'une écriture suivante ne bloque plus - désactivé temporairement pour confirmer que le test échoue bien (et de la même façon) sans le fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
bda082bffd |
Ajoute une propriété "Ombre portée" (box-shadow), disponible sur tout widget
Nouveau groupe "Ombre" dans le panneau de propriétés, à côté de "Bordure" (même universalité — voir UNIVERSAL_CONTROLS) : décalage X/Y, flou, étendue, couleur et opacité, combinés en une seule valeur CSS box-shadow (couleur+opacité fusionnées en rgba(), un <input type="color"> seul ne portant pas de canal alpha). Décalages/flou/étendue tous à 0 = pas d'ombre, même convention que border-width à 0 = pas de bordure. Nouveau ctype "shadow" (c_shadow.py), suit exactement le même principe que le ctype "size" déjà existant (size_override_controls.py) : plusieurs entrées de formulaire pour un seul réglage, composées/décomposées dans save_element_controls.py et control_value.py plutôt que passées par le chemin générique clé->valeur. Ajoute tests/test_shadow_controls.py (présence dans le panneau, composition de la valeur CSS, aller-retour dans le formulaire, remise à zéro qui retire l'ombre). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
9c9e3c5379 |
Le sélecteur de champ apparaît maintenant sur tout nouveau widget d'un élément de jeu lié à un objet
Le tour précédent exigeait que CHAQUE widget règle sa propre "Donnée
liée" (_data_definition_id) pour voir apparaître le sélecteur de champ -
mais un élément de jeu ("Mail card"...) créé avec un "Objet lié" (voir
element_types.html, bound_definition_id) a précisément pour but d'éviter
ce réglage widget par widget : ses {{champ}} sont censés venir de CET
objet, fourni plus tard par le Répéteur qui l'utilisera comme modèle de
ligne. D'où le bug remonté : un nouveau Titre/Texte posé dans un tel
élément de jeu n'affichait jamais le sélecteur.
Ajoute get_element_type_by_template_screen(slug, screen_id), pour
retrouver depuis l'éditeur d'un écran-modèle l'entrée du catalogue (et
donc l'objet lié) dont il est la recette. screen_edit.py le calcule pour
le panneau de propriétés et le passe à controls_with_values(), qui
l'utilise comme repli pour le champ "Contenu" SEULEMENT si ce widget n'a
pas déjà sa propre "Donnée liée" réglée (priorité conservée au réglage le
plus spécifique).
Ajoute tests/test_element_type_bound_field_picker.py (apparition sans
réglage supplémentaire, absence sans objet lié, priorité à la "Donnée
liée" du widget si réglée).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
7e80ff952a |
Ajoute un sélecteur de champ pour insérer {{champ}} dans le Contenu
Une fois "Lier à un objet de données" réglé (widget Texte/Titre...),
propose maintenant les champs de CET objet en liste déroulante juste sous
le champ "Contenu", avec un bouton "+ Ajouter" qui insère "{{nom_du_champ}}"
à l'emplacement du curseur - plutôt que d'avoir à taper cette syntaxe à
la main sans savoir quels noms de champs existent réellement.
controls_with_values.py pose field_options sur le contrôle "content"
quand _data_definition_id est réglé (réutilise data_binding_options, déjà
calculé pour data_filtre_champ/data_filtre2_champ) ; insertFieldAtCursor()
(screen_edit.html) fait l'insertion via selectionStart/selectionEnd puis
déclenche un événement "input" pour que l'enregistrement automatique se
déclenche normalement, comme une saisie manuelle.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
baa3da1035 |
Corrige la comparaison booléenne : "Oui"/"Non" n'était pas reconnu comme valeur vraie/fausse
Bug remonté avec une "Mail card" (icône enveloppe fermée si is_opened
est à "Non", ouverte si "Oui") : les DEUX variantes s'affichaient (ou
aucune), selon la ligne.
Cause : _compare() (filter_repeater_rows.py, utilisé par la condition de
visibilité, le Répéteur et Donnée liée) ne reconnaissait "1"/"true"/"vrai"
comme valeur vraie pour un champ booléen — jamais "oui", pourtant le SEUL
vocabulaire que l'app affiche elle-même pour ce type de champ partout
ailleurs (voir data_list.html : "Oui" si vrai sinon "Non"). Une valeur de
comparaison fixe tapée "Oui" retombait donc silencieusement à "faux",
et comme l'opérateur et le champ étaient par ailleurs corrects, ça
donnait l'impression que la condition "ne voyait" rien : sur la ligne où
is_opened=faux, les DEUX cartes ("égal à Oui" et "égal à Non", toutes
deux évaluées comme "égal à faux") s'affichaient ensemble ; sur la ligne
où is_opened=vrai, aucune des deux.
Fix : "oui" ajouté à l'ensemble des valeurs reconnues comme vraies,
côté Python (_compare) ET côté JS (compareValues() dans play.html, qui
doit rester alignée — utilisée par les nœuds Condition de la Logique de
la scène), cette dernière au passage rendue insensible à la casse comme
son équivalent Python (elle ne l'était pas du tout).
Ajoute un test de régression dédié à ce cas précis.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
a28cc5881e |
Corrige la condition de visibilité : un widget "special_render" visible ne se rafraîchissait jamais en jeu
Bug remonté avec deux icônes (enveloppe fermée / ouverte) posées
directement sur l'écran, chacune conditionnée sur is_opened : après avoir
ouvert le mail (une action "Modifier une donnée"), les DEUX icônes
restaient affichées en même temps au lieu que l'ouverte remplace la fermée.
Cause : refreshRuntimeData() (play.html) ne réévalue, après une action,
que les éléments dont le HTML porte un marqueur ("visibilityGated"/
"repeaterItem"/"jaugeBar"). render_element_html() posait bien ce marqueur
quand un élément sous condition est actuellement visible - mais seulement
sur le chemin de rendu GÉNÉRIQUE (texte, titre, conteneur...), jamais sur
les 9 widgets "special_render" (Icône, Tableau, Superposition, Onglets,
Case à cocher, Liste déroulante, Groupe de champs, Répéteur, Jauge) - un
élément CACHÉ portait toujours son marqueur (via son placeholder), mais un
élément VISIBLE de ce type non. Résultat : l'icône "fermée", visible au
premier chargement, ne portait aucun marqueur et restait donc figée dans
son état d'origine après toute action suivante, pendant que l'icône
"ouverte" (cachée au départ, donc marquée) se mettait, elle, correctement
à jour - d'où les deux affichées ensemble.
Fix : les 9 branches special_render passent maintenant, elles aussi, par
_mark() comme le chemin générique.
Ajoute un test de régression dédié (icône visible sous condition = doit
porter le marqueur).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
ff01b3903c |
Corrige la condition de visibilité (mode "objet") à l'intérieur d'un Répéteur
Bug remonté : dans une "Mail card" (élément de jeu réutilisable, deux
icônes - enveloppe fermée/ouverte - conditionnées sur le champ is_opened
de l'objet Email) posée dans un Répéteur de données, rien ne s'affichait
jamais correctement.
Cause : is_element_visible() (mode "objet") allait toujours chercher en
base la ligne la plus récente de l'objet ciblé (convention "1 seule ligne
= état de partie", correcte pour une Jauge suivant un état de partie),
sans jamais tenir compte de la ligne EN COURS DE RENDU dans un Répéteur -
donc tous les exemplaires du même modèle de ligne évaluaient la MÊME
ligne (la plus récente de tout l'objet Email) au lieu de chacun la
sienne, et affichaient donc tous exactement le même résultat.
Fix : is_element_visible() reçoit maintenant le ctx de rendu (les
{{champ}} de la ligne en cours, déjà posés par render_repeater.py) et,
si le champ réglé s'y trouve, utilise directement cette valeur plutôt que
d'interroger la base - un exemplaire de Répéteur voit donc bien SA propre
ligne. Hors Répéteur, le comportement (ligne la plus récente de l'objet)
est inchangé.
Ajoute tests/test_visibility_condition.py (mode variable, mode objet hors
Répéteur, absence dans l'éditeur, et ce cas précis dans un Répéteur) -
cette fonctionnalité n'avait jusqu'ici aucun test persistant, seulement
des scripts ad-hoc jetés après vérification.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
11b08c8503 |
Éditeur de scène : le canevas remplit exactement l'espace disponible, plus de marges
Le calcul JS "object-fit:contain" du tour précédent gardait l'aspect-ratio
(Portrait/Paysage/Carré) au prix de marges vides sur les côtés dès que la
fenêtre n'avait pas exactement ce ratio - "prendre toute la place
disponible" et "garder l'aspect-ratio" sont deux exigences contradictoires
dans ce cas, et c'est la première qui doit l'emporter dans l'éditeur.
Le canevas (#canvas) remplit donc maintenant .canvasFrame à 100% x 100%,
sans plus tenir compte de l'aspect-ratio choisi dans l'éditeur - ce
réglage continue de s'appliquer normalement à l'aperçu jouable ("Jouer",
voir screen_set_aspect.py/play.html), qui reste la référence pour le
rendu final. Padding de .canvasFrame réduit au minimum. fitCanvasToFrame()
et son calcul en pixels n'ont plus lieu d'être - retirés entièrement.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
14deba943a |
Éditeur de scène : le canevas remplit vraiment tout l'espace disponible
Le calcul purement CSS du tour précédent (aspect-ratio + height:100% + max-width:100%, pour que le canevas garde ses proportions tout en tenant dans la zone visible) laissait en pratique le canevas bien plus petit que l'espace réellement disponible - le calcul de taille "auto" d'un élément non remplacé dans ce contexte flex n'est pas fiable. Remplacé par un calcul en JavaScript (fitCanvasToFrame()) : mesure la taille réelle de .canvasFrame et calcule la plus grande taille en pixels qui tient à la fois en largeur ET en hauteur pour l'aspect-ratio courant (l'équivalent d'un "object-fit:contain"), posée directement en style inline sur #canvas. Recalculé à l'ouverture de l'écran, au changement de format (Portrait/Paysage/Carré), au redimensionnement de la fenêtre, et à chaque rafraîchissement du panneau (#canvas étant recréé à chaque sélection d'élément, sa taille calculée était perdue à chaque fois). Sous 1300px (mise en page empilée), le style inline est explicitement effacé pour laisser la règle CSS de repli (pleine largeur, page qui défile normalement) reprendre la main. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
dae6da166e |
Éditeur de scène : supprime le fil d'Ariane, canevas remonté, défilement propre au canevas
Le fil d'Ariane disparaît entièrement sur cette page (breadcrumb_wrap vide) - le nom de l'écran est de toute façon déjà éditable juste au-dessus, dans le panneau "Éléments" (voir le tour précédent) - et .content-builder perd son padding par défaut hérité de .content, pour que le canevas commence le plus haut possible. Change aussi la façon dont le canevas est dimensionné : il était jusqu'ici contraint par la LARGEUR (width:100%), ce qui pouvait le rendre bien plus haut que la fenêtre pour un format Portrait - obligeant à défiler .builderCanvasArea (toolbar/onglets compris) pour voir le bas de l'écran. Il est maintenant contraint par la HAUTEUR disponible (height:100%, la largeur se déduisant de l'aspect-ratio), avec max-width:100% en secours si c'est la largeur qui manque en premier - l'écran entier reste donc visible sans défiler. Le défilement, s'il reste nécessaire (fenêtre très basse), se fait maintenant sur .canvasFrame lui-même, jamais sur .builderCanvasArea (repassé à overflow:hidden) : la barre d'onglets et la barre d'outils restent toujours fixes en haut. Ajoute le pendant pour le repli en page empilée (< 1300px, une seule colonne) : le "letterboxing" par hauteur suppose une chaîne de hauteurs définies qui n'existe plus une fois empilé - revient alors à un dimensionnement par largeur, cohérent avec une page qui défile normalement. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
ea9f91fc19 |
Éditeur de scène : Logique/Timeline en onglets plein écran, réglages d'écran déplacés dans le panneau Éléments
Remplace l'ancien panneau du bas rétractable/redimensionnable à la souris (Logique de la scène, Timeline d'animation) par un système d'onglets au centre de l'éditeur - Écran / Logique de la scène / Timeline d'animation - un seul visible à la fois, occupant systématiquement tout l'espace disponible (switchBuilderTab() dans screen_edit.html). Changer d'onglet équivaut à "fermer" celui qu'on quitte ; plus besoin d'une poignée de redimensionnement séparée puisque l'onglet actif prend déjà toute la place. Supprime au passage tout l'ancien mécanisme (toggleFlowPanel/ toggleAnimPanel, poignées flowResizeHandle/animResizeHandle, classe CSS .flowPanel) devenu inutile. Déplace aussi le renommage de l'écran, le bouton "Jouer depuis le début" et le choix du format d'aperçu (Portrait/Paysage/Carré) - jusqu'ici au-dessus du canevas - dans le panneau flottant "Éléments" (celui qui porte déjà ce nom, à gauche) : des réglages qu'on touche rarement une fois l'écran en construction, qui n'ont plus besoin de rester en permanence visibles au-dessus de la zone de travail. Corrige au passage un bug découvert pendant ce tour : sur la page "Nouvel objet" (2 colonnes), le bouton "+ Ajouter un champ" avait disparu - placé APRÈS la zone de liste à défilement (flex-grow:1) dans la colonne de droite, un flex-grow imprévisible dans ce contexte le poussait hors de vue. Déplacé avant la liste (statique, toujours visible), pattern déjà éprouvé ailleurs sur cette même page. Deux tests mis à jour pour refléter intentionnellement la nouvelle structure : la présence de "animTabPanel" (au lieu de l'ancien "animPanel"), et un marqueur plus précis pour distinguer le bloc de propriétés "Onglets" d'une simple occurrence du même texte dans une liste déroulante de la Logique de la scène (qui apparaît désormais plus tôt dans le document, cet éditeur de flow étant maintenant un onglet du centre plutôt qu'un panneau tout en bas de page). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
2051b375ac |
Passe toutes les pages restantes en deux colonnes (créer à gauche, contenu à droite)
Généralise le principe déjà utilisé pour le tableau de bord et l'édition
d'objet à toutes les pages restantes : liste des jeux, écrans, éléments de
jeu, variables, nouvel objet, formulaire de données, tableau des données
d'un objet - colonne de gauche pour créer/agir, colonne de droite pour ce
qui existe déjà, chaque colonne défilant pour son propre compte.
Pour un formulaire qui doit rester UN SEUL <form> à cheval sur les deux
colonnes (nouvel objet : nom à gauche, champs à droite ; formulaire de
données : bouton Enregistrer à gauche, champs à droite), nouvelle classe
.formPassthrough ("display:contents") : le <form> ne devient pas lui-même
une boîte dans la mise en page flex, seul .twoCol à l'intérieur compte.
Supprime au passage .content-page/.formScroll/body.pageBody (le gabarit à
une colonne introduit au tour précédent, plus utilisé nulle part) et
.list/.listRow/.listRowFlex/.rowTitle/.rowSub/.rowActions/.addBtn (les
cartes à deux lignes remplacées par les tableaux denses et la nav
compacte) - du CSS mort plutôt que deux systèmes qui se chevauchent.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
59247694d6 |
Applique le gabarit sobre/compact/sans défilement à toutes les pages hors éditeur
Généralise le principe déjà en place pour l'édition d'objet (la page n'occupe jamais plus que la hauteur de la fenêtre, seules ses zones internes défilent) à toutes les pages restantes : liste des jeux, tableau de bord d'un jeu, écrans, éléments de jeu, variables, nouvel objet, formulaire de données, tableau des données d'un objet. Seuls l'éditeur d'écran/d'élément et l'aperçu jouable restent en dehors (déjà exclus par leur propre gabarit plein écran, ou pas concernés). Nouveau gabarit générique à une colonne (body.pageBody + .content-page + .scrollArea) sur le même principe que .content-objectEdit, plus une variante .formScroll pour un formulaire long à défilement interne (liste de champs d'un nouvel objet, formulaire de données) tout en gardant les boutons d'action toujours visibles. Les listes/tableaux remplacés par le format dense .fieldsTable (déjà utilisé pour le tableau de bord) pour rester cohérent et afficher plus de lignes à l'écran. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
williamandClaude Sonnet 5
|
ac0f003663 |
Rend le tableau de bord du jeu plus compact, sobre et sans défilement de page
Réutilise le système déjà en place pour l'édition d'objet (body.objectEditBody
+ .content-objectEdit) : la page occupe exactement la hauteur de la fenêtre,
seules les deux colonnes défilent chacune de leur côté si besoin - plus la
page elle-même, qui ne doit jamais défiler.
Colonne de gauche ("Créer") : nouvelle nav à une ligne (.navRow/.navList,
icône + libellé, sous-titre en info-bulle) plutôt que des cartes à deux
lignes - plus dense, plus sobre.
Colonne de droite ("Objets définis") : remplace les cartes par le tableau
compact à en-tête collant déjà utilisé pour les champs d'un objet
(.fieldsTable) - format nettement plus adapté à beaucoup de lignes.
Réduit aussi le padding par défaut de .listRow/.dangerZone (encore utilisés
par la page Variables), dans le même esprit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
20ef86e039 |
Aligne le style du bouton "nouvel objet" sur les autres actions du tableau de bord
Remplace le bouton en pointillés ("+ Définir un nouvel objet") par une
entrée de liste identique aux autres actions (Écrans, Variables, Jouer...)
— plus cohérent visuellement, comme demandé après revue du rendu réel.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
11a2d397e8 |
Remplace la création inline de variable par une page de gestion dédiée, redesign du tableau de bord du jeu
Retrait de la création rapide de variable globale depuis le sélecteur de
la Condition de visibilité (bouton "+ Créer") : une variable globale est
désormais gérée comme un objet "jeu" à part entière, avec une vraie page
CRUD ("Variables", nouvelle entrée du menu de gauche) - création, édition
du type/valeur, suppression. Le nom reste volontairement immuable après
création (c'est par ce nom qu'une condition de visibilité ou une action
"Modifier une variable" la référence - la renommer casserait ces réglages
en silence), d'où db.update_global_variable qui ne touche que type/valeur.
Redesign du tableau de bord du jeu (game_dashboard.html) en deux
colonnes : à gauche tout ce qu'on peut créer (écrans, éléments de jeu,
variables, jouer, nouvel objet) plus les paramètres du jeu (renommer/
supprimer) ; à droite ce qui a déjà été créé (objets définis). Remplace
les cartes Bulma par le système de mise en page compact déjà défini dans
style.css (.twoCol/.listRow/.dangerZone/.addBtn) mais jamais utilisé
jusqu'ici - plus dense et cohérent avec le reste de l'éditeur.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
williamandClaude Sonnet 5
|
c04bc0b926 |
Ajoute la condition de visibilité et les variables globales
Nouveau panneau "Condition de visibilité" disponible dans les propriétés
de TOUT élément (widget) : permet de masquer un élément en mode jouable
selon deux moyens, au choix -
- une variable globale (nom + type + valeur, une seule par jeu, stockée
dans une nouvelle table _global_variables) ;
- le champ d'un objet de données existant (même convention "état de
partie" - une seule ligne - déjà utilisée par la Jauge).
Une variable ne servant à rien si elle ne peut jamais changer en cours de
partie, ajoute aussi une nouvelle action de flow "Modifier une variable
globale" (parallèle à "Modifier une donnée"), avec sa propre route
d'exécution serveur et son sous-formulaire dans l'éditeur de logique de
scène. Une variable peut aussi se créer à la volée depuis le sélecteur du
panneau de visibilité, sans quitter les propriétés de l'élément.
La condition n'est évaluée qu'en mode jouable (/game/<slug>/play), jamais
dans l'éditeur, pour que l'élément reste toujours sélectionnable. Un
élément masqué se réévalue en direct après toute action "Modifier une
donnée/variable", via le même mécanisme de rafraîchissement déjà utilisé
par la Jauge et le Répéteur.
Corrige au passage deux bugs découverts en testant bout en bout : (1)
apply_ctx plantait sur le nouveau marqueur interne _forge_play_mode (un
booléen parmi les {{champ}} à substituer, qui attend des chaînes) ; (2)
_compare traitait toute valeur booléenne stockée en chaîne ("0" inclus,
donc toujours vraie en Python) comme vraie - correct pour les champs
d'objet (entiers SQLite) mais faux pour les variables globales (toujours
stockées en texte).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|