GVLE devel

Cycle de développement
Le cycle de développement présenté dans cette section est largement inspiré des méthodes agiles comme l'extreme programming. Ce cycle se base principalement sur l'utilisation du programme Git.

Git

 * Chaque développeur possède son propre dépôt de développement sur la machine VLE dans lequel il publie les corrections de bogues ou les nouvelles caractéristiques.
 * Patrick Chabrier est l'intégrateur des patchs issus des développements sur l'interface graphique. Il synchronise les dépôts distants qui pointent sur les développeurs et envoie les patchs acceptés sur sa branche de développement.
 * Gauthier Quesnel est l'intégrateur des patchs lus et revus par Patrick Chabrier, il synchronise son dépôt courant sur celui de Patrick Chabrier et publie le code sur le dépôt Git officiel de VLE.

Sourceforge

 * Chaque développeur possède un compte sur Sourceforge.
 * Chaque développeur doit s'inscrire sur les listes de diffusion vle-user (pour les mails relatifs au projets) et vle-tracker (pour les suivis des tâches dans les trackers).
 * Chaque jour, un développeur s'attache à une tâche qu'il a pour mission de clore avant la fin de la journée.
 * Le développeur doit s'attacher à la tâche.
 * Lorsqu'un patch est clos, le développeur doit :
 * Mettre la tâche en status Pending.
 * Mettre la résolution de la tâche en Fixed.
 * Inscrire dans le commit message quelle est la tâche (ou quelles sont les tâches) qui est close en indiquant le ou les numéros de la tâche. Le message doit obligatoirement respecter la convention de rédaction suivante:Commandes Git de tous les jours.
 * Publier son patch sur sa branche distante.
 * Attendre les retours de l'intégrateur qui peut soit accepter le patch (passage de la tâche en status Closed) soit refuser le patch (passage de la tâche en status Open).
 * Se recynchroniser sur la branche de développement de Patrick

Les commandes Git des développeurs
La première étape est de créer les branches distantes vers les dépôts distants de : l'intégrateur des patchs de l'interface graphique et celui accessible en écriture pour déposer les patchs. git clone git://vle.git.sourceforge.net/gitroot/vle/vle git remote add vle ssh://etudiant@www.vle-project.org:6999/home/etudiant/git/vle-etudiant.git git remote add patrack git://www.vle-project.org/git/vle-patrack.git

Pour publier des patchs les développeurs doivent utiliser la commande git push sur leur dépôt de développement distant dans une branche à leur nom : git push vle branchlocale:nom_du_developpeur

Si un des patchs est accepté ou tout les matins, les développeurs doivent mettre à jour leurs branches locales avec les nouveaux patchs intégrés dans le dépôt de l'intégrateur : git fetch patrack git rebase patrack/master

Quelques opérations de maintenance qui peuvent être nécessaires:
Le stockage du patch correspondant au dernier commit git format-patch HEAD^

La suppression du dernier commit git reset --hard HEAD^

L'application d'un patch git am le_nom_du_patch.patch

La suppression des modifications du dernier commit portant sur un fichier en particulier git checkout HEAD^ le_nom_du_fichier git commit -a --amend

Les commandes Git de l'intégrateur
La première étape est de créer les branches distantes vers les dépôts distants de : l'intégrateur des patchs de l'interface graphique en écriture et celui accessible en lecture seule pour lire patchs des développeurs : git clone git://vle.git.sourceforge.net/gitroot/vle/vle git remote add vle ssh://chabrier@www.vle-project.org:6999/home/chabrier/git/vle-dev.git git remote add etudiant git://www.vle-project.org/git/vle-etudiant.git

Pour intégrer de nouveau patch, il faut récupérer les nouveautés du dépôt distant : git fetch etudiant

Ne pas oublier de se mettre à jour sur la machine VLE : git fetch origin

Et récupérer les patchs d'un des développeurs sur une branche locale : git checkout -b temp etudiant/nom_du_developpeur

Se synchroniser sur son propre dépôt distant : git fetch vle git rebase vle:master

Enfin, pour publier les patchs des développeurs : git push vle branchlocale:master

On peut vouloir faire du nettoyage, et supprimer des branches :

git branch [-d|-D] temp

Les bonnes pratiques
Dans le cadre du développement d'une interface graphique comme GVLE, il est important de bien se former aux outils proposés par les bibliothèques Gtkmm, Cairomm, libglademm etc. Ces bibliothèques proposent un ensemble de classes, fonctions génériques pour le développement d'interfaces graphiques. Il est aussi nécessaire de suivre le guide des bonnes pratiques de développements.

Développement d'une boîte de dialogue
La boîte de dialogue est l'un des composants les plus utilisés dans GVLE. Pour éviter d'écrire du code difficile à relire ou plus compliqué que nécessaire, nous vous proposons quelques règles à suivre pour leurs développements :


 * 1) Toutes les boîtes de dialogues doivent être développées dans Glade.
 * 2) Toutes les boîtes de dialogues doivent être gérées par une classe spécifique qui reçoit en paramètre une référence sur un objet Gnome::Glade::Xml.
 * 3) La gestion des boutons Ok, Annuler et Valider se fera dans le code qui appelle la boîte de dialogue.


 * Un premier exemple simple où l'utilisateur n'a que très peu d'interaction avec les widgets de la boîte de dialogue :

Les évolution GVLE 0.9

 * Corrections des nombreux bugs de l'interface graphiques, voir le tracker de VLE pour plus de détails. [***]

Modeling Plug-ins

 * Développer les plug-ins de modélisation génériques pour :
 * statechart ; [**]
 * Decision ; [**]
 * Grilles / Graphes (structure de modèles, matrixtr, graphtr) ; [** à travailler chez nous]
 * Équations différentielles ; [*]
 * Automate cellulaire (CellDEVS / CellQSS) ;
 * Réseaux de Petri.


 * DifferenceEquation : avoir dans l'observable d'un modèle toutes ses Var en liste pré-remplie de ses ObservablesPorts, qu'il ne resterait plus qu'à associer à des Views. [***]


 * Apports aux plug-ins de modélisation :
 * Saisie de la documentation niveau modèle (Doxygen like) avec le plug-in [** à travailler chez nous] :
 * Qu'est ce que la documentation ? documenter le source plutôt que le fichier VPZ, récupérer la doc du source pour alimenter GVLE.
 * Au delà de génération de code C++, compléter le fichier CMake automatiquement. [- ???]

Output Plug-ins EOV / GVLE

 * Visualisation de plan d'activité [*].
 * Plug-in de représentation de graphes avec structures différentes d'un point [*].

Paquets

 * Compilation :
 * Pouvoir compiler avec l'option -j n pour utiliser plusieurs coeurs. [***]
 * Ajouter une fonction pour compiler en une fois (configure + build) tous les paquets dont dépend un fichier .vpz. [***, ce n'est pas de l'interface graphique]


 * Nouveau fichier dans un paquet :
 * Pouvoir ouvrir des fichiers "pré-remplis" en fonction de ce qu'on souhaite faire: Difference Equation, DEVS ... On aurait un menu: New Files / DEVS ou QSS ou etc. [***]
 * Dans le menu préférence pouvoir spécifier ce qu'on veut comme en-tête de fichier (licence ?), quand on en crée un nouveau. [***, découper les préférences en deux (GVLE et paquets)]


 * Dépôts de paquets :
 * Intégrer le téléchargement des paquets. [NB : c'est un travail pour un projet d'année avec un étudiant en M1. Travaux à poursuivre]. (ftp/http, paquets sources et paquets précompilés win32 etc.).

Affichage

 * Proposer un mode d'affichage alternatif de la structure des modèles :
 * Un mode simplifié, avec un et un seul lien entre deux modèles s'ils sont couplés, les modèles étant symbolisés par des cercles de différentes couleurs en fonction de leur nature (atomique, couplé, extensions, executive). Le passage de la souris sur une connexion liste l'ensemble des ports et des connexions des deux modèles connectés. [NB : c'est un travail pour un projet d'année avec un étudiant en M2]. [- ??? w&s]
 * Un mode Flat view qui affiche uniquement les modèles atomiques et leurs couplage.


 * Affichage de modèles générés par un exécutive après initialisation. [*]
 * Dump d'un vpz pour une observation ? [**]
 * Lancer la simulation puis plug-in d'observation ? [- ???]

Coeur GVLE

 * Intégrer la bibliothèque EOV dans GVLE. [***]
 * Fournir une représentation de type tableur dans les plug-ins d'EOV pour les fichiers tabulaires. [**]


 * Développer une fonction pour afficher vle.log de manière user friendly lorsque l'on est en mode debug : [*]
 * Affichage de la trace d'un modèle particulier, mettre en forme les infos de trace.
 * Cette fonction pourrait elle être accessible pour paramétrage depuis un menu ?


 * Rajouter un "Run debug" dans le menu. [***]
 * Est ce qu'on peut rajouter des éléments de debugger classique C++ ? [- ???]


 * Importation de parties de VPZ :
 * Ajouter la possibilité de choisir les éléments à importer via la fonction Import Model [***, relecture générale demandée].
 * Lors de l'import d'une classe, proposer l'import des conditions. [***, relecture générale demandée]


 * Multiple VPZ en même temps [***, très dure] :
 * Copier/coller d'un modèle d'un VPZ à un autre VPZ
 * Copier coller dans tous les sens VPZ<->Classes (perdu en cours de route)


 * Documentation
 * Quid de la documentation ? Lien entre le code source de modèles et la structure du modèle ? [*** travail à faire chez nous]


 * Les classes de modèles :
 * Édition directe.

Remarques ergonomiques

 * Globale :
 * Aller plus loin dans le développement de l'arbre des modèles (Conditions, ports...).
 * Proposer une liste arborescente pour les conditions expérimentales.
 * Accéder aux informations portant sur un modèle en particulier (Conditions...).
 * Revoir les boîtes de saisie des values complexes (map, set, tuple, matrix).
 * Copier/coller aussi dans les treeViews des modèles.
 * Menu contextuel sur la fenêtre graphique.


 * Remarques issues de la formation nov. 2009 :
 * Dans les menus, mettre le sens dans l'ordre chronologique d'utilisation.
 * Changer la forme de curseur en fonction de l'outil sélectionné.
 * Pourquoi appuyer sur la molette centrale pour les modèles couplés et pas juste un clique normal ?
 * Quand on double clic sur le modèle couplé pour l'ouvrir, surligner dans l'explorateur de modèles.
 * Le menu projet dans simulation n'est pas logique.
 * Assouplir le lien entre les dynamiques, conditions, etc. et les codes sources.
 * Afficher si le modèle atomique dispose d'une dynamique, de conditions et d'observable en passant la souris sur le modèle.