Closed phtanguy closed 10 years ago
Suite à notre discussion du 4 avril, j'ai fait une représentation schématique du cycle de vie d'une manœuvre dans le contexte des échanges end user / opérateur Paparazzi. Le document est présent dans le répertoire docs (branche IHM-VetoServer-dev). Lien direct : https://github.com/legras/uav3i/blob/750b38554a869a9afb9cf3c1c90f9c71821c54bd/docs/Cycle%20de%20vie%20d%E2%80%99une%20man%C5%93uvre.pdf?raw=true C'est une base de discussion et ce n'est pas gravé dans le marbre mais j'aimerais bien qu'on en discute rapidement pour arriver à un consensus. C'est aussi en lien avec le ticket #29.
Manoeuver dispose maintenant (branche Mnver-states-dev) des méthodes suivantes :
public boolean isPinned()
public boolean isSelected()
public boolean isShared()
public enum ManoeuverRequestedStatus {NONE, ASKED, REFUSED, ACCEPTED};
public ManoeuverRequestedStatus getRequestedStatus()
public void setReqStatusAccepted()
public void setReqStatusRefused()
Mais, si on veut faire de la synchro de modifications IHM -> Veto, il faut ajouter une méthode qui signale/transmette les màj. Ton avis, Philippe ?
Le 02/06/2014 10:05, François Legras a écrit :
Manoeuver dispose maintenant (branche Mnver-states-dev) des méthodes suivantes :
public boolean isPinned() public boolean isSelected() public boolean isShared() public enum ManoeuverRequestedStatus {NONE, ASKED, REFUSED, ACCEPTED}; public ManoeuverRequestedStatus getRequestedStatus() public void setReqStatusAccepted() public void setReqStatusRefused()
Très bien !
Mais, si on veut faire de la synchro de modifications IHM -> Veto, il faut ajouter une méthode qui signale/transmette les màj. Ton avis, Philippe ?
Oui, on en avait déjà parlé. Je vois ça cet après-midi : ce matin, je bosse à la maison sur un autre sujet.
Je peux t'appeler dans l'après-midi ?
Bien sûr !
Modifications faites sur master, à tester (vérouillage des boutons share, ask, etc.).
Si c'est bon, on clos.
Vu ! J'ai mergé le master dans ma branche et fait quelques tests. Quelques problèmes qui surviennent lors de l'exécution de la méthode answerManoeuver(int id, boolean accepted) de SymbolMap (exécution côté table). Séquentiellement, ce qu'il se passe :
Je pense que le problème vient du point 4 : le déblocage se fait dans un bloc synchronized qui doit bloquer et provoque un timeout sur le Veto (affichage d'une trace d'erreur) et l'IHM table est complètement bloquée...
J'ai commenté le bloc synchronized et il ne semble plus y avoir de problèmes. Il est vraiment utile ?
Note -> le problème ne survient pas systématiquement : principalement quand un certain nombre de manœuvres ont été ajoutées avant que l'opérateur P. n'ait fait la validation.
Un [éventuel] souci : une manœuvre qui a été soumise à l'opérateur P. (acceptée ou refusée) redevient modifiable. Normal ?
Ajout au commentaire : la modification de la manœuvre précédemment soumise peut être re-soumise. Ce n'est donc pas illogique. Cependant, petit problème sur le bouton d'exécution qu'il faut "ré-enclencher" (bouton toggle).
Une fois que le veto a donné sa réponse, oui on peut remodifier.
Le 9 juil. 2014 à 17:11, Philippe TANGUY notifications@github.com a écrit :
Un [éventuel] souci : une manœuvre qui a été soumise à l'opérateur P. (acceptée ou refusée) redevient modifiable. Normal ?
— Reply to this email directly or view it on GitHub.
Oui, j'ai vu, j'avais fait un ajout au commentaire que tu n'as peut-être pas vu.
Ca bloque aussi en REPLAY.
Oui, mais comme pour le déplacement d'un manœuvre, tant qu'on n'a pas touché la partie trajectoire d'une manœuvre, ça marche.
Clos en même temps que #35. (voir commit 5ce211ed6a03c2c985672d8aa4cef4a8ecff8617)
Maintenant que la liason IHM/Veto est rétablie, trouver des cas d'utilisation les moins ambigus possibles pour une gestion correcte de la mission. Ci dessous photo du tableau lors de la rencontre du 4 avril 2014 :![2014-04-04 13 42 41](https://cloud.githubusercontent.com/assets/3634307/2615002/9e83e078-bbf2-11e3-8a70-86f7709ada0f.jpg)