Implement the script command functionalities in the event editor#706
Implement the script command functionalities in the event editor#706
Conversation
There was a problem hiding this comment.
Yop ! J'ai pu tester les différentes manipulations, c'est vraiment chouette ! 😄
Il faudra qu'on discute design avec @Walven concernant l'agencement de l'éditeur et les détails pour savoir si on met un helper à certains champs, mais c'est déjà top d'avoir la possibilité de manipuler ces nodes.
Quelques petites questions et remarques qui me semblent importantes vis à vis des critères d'acceptation de l'issue #619 et de ce qu'on considère à faire maintenant, afin qu'on se mette d'accord pour la suite. L'idée étant de ne pas avoir à créer 2/3 tickets pour faire de petites choses qu'on pourrait faire dès à présent.
- Est-ce qu'on veut vraiment faire diverger les textes des labels du formulaire et de ce qui est affiché sur la node ? C'est double travail de traduction et ça ajoute 2 fois les chaînes de caractères au Weblate. J'ai peut-être oublié des cas où c'est pertinent, donc vous pouvez me les rappeler au besoin, ça répondra à la question.
- On ne traduit pas "Comment" en "Commentaire" en français ?
- L'issue #619 mentionne "afficher seulement 3 lignes du script sur la node". Est-ce qu'on le fait maintenant ou est-ce qu'on attend d'avoir un mode "voir plus" (qui peut arriver assez tard) ?
- Quid de la documentation ? On l'ajoute sur le wiki une fois la PR fusionnée ?
|
Pour le point 1, effectivement ce serai plus simple de faire en sorte que ce soit les mêmes textes, ce sera plus simple et plus maintenable. Je corrige tout ça Pour le point 4, on en a pas encore discuté avec Palb, mais je pensais m'en occuper une fois cette PR validée, comme ça on est à peu près sûrs de la forme et du process pour ajouter une commande. D'ailleurs il ne faut pas merge la PR, PSDK va crash si on le fait. Avec Palb on avait évoqué l'idée d'une branche spécifique aux devs de la 3.0 en parallèle de la branche de dev, à voir si c'est quelque chose d'envisageable/maintenable. |
|
Point 3 : pour moi ça fait parti du design, donc à faire plus tard. Pour le point 4 je rejoins Aelysya, dès que c'est merge et qu'on valide le processus de création d'une commande, on pourra le documenter. Pour la branche 3.0 en parallèle, c'est maintenable si on rebase régulièrement. |
|
Est-ce qu'on ne s'éviterait pas la branche 3.0 en faisant en sorte que PSDK ne soit pas impacté par la présence d'événements ou non ? Via un ignore sur le dossier de son côté par exemple. Par contre ça me fait poser la question : est-ce qu'on ne s'éviterait pas des manips manuelles en créant le dossier / fichier par défaut si c'est nécessaire au chargement du projet ? |
|
J'ai commencé à écrire la documentation : A voir si on prend aussi le temps de faire une documentation par commande : |
|
@Aelysya a créé une MR sur PSDK pour ignorer le dossier events : https://gitlab.com/pokemonsdk/pokemonsdk/-/merge_requests/1735 Cela nous évitera tout imprévu. J'ai mis à jour la PR pour que Studio puisse charger le projet même si aucun event n'existe. |
3 participants
Description
This PR adds the command node "insert script" and it's editor. It also add the global state behaviour with events, and a basis for events entity model.
closes #619
Note before testing
In your test project, in the folder
Data/Studio, create a folder namedeventsand copy this file inside (to avoid having no existing entity for an entity class)Tests to perform
For the following tests, open the event's json file on the side to verify the actions you perform are correctly taken into account after saving.