Documentation (main.c) > il y a des choix à faire avant de renommer les fonctions et les fichiers

src/main.c

@@ -32,30 +32,42 @@
 
 #include "../include/callbacks.h"
 
-/* Tous les callbacks sont dans le fichier 'src/callbacks.c'
+/* https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
- * et leur nom commence par: 'on_'
+ * https://en.wikipedia.org/wiki/Multitier_architecture
- * (aucun autre nom de fonction ne commence par 'on_').
+ *
- * S'ils deviennent trop nombreux, ils seront répartis
+ * Quel modèle pour l'organisation du client gem-graph ?
- * dans des fichiers regroupés dans un dossier: 'src/callbacks.c'.
+ *
- *                   (ou 'src/callbacks' ?)
+ * Quelles structures apparaissent bien individualisables dès aujourd'hui ?
- * La description des fonctions devrait plutôt précéder ces fonctions
+ * Quelles structures (encore à peine ébauchées) ont un développement prévisible ?
- * pour alléger le fichier 'callbacks.h' (?) */
+ * Quelles interfaces peut-on prévoir, vers quels modules à venir,
-
+ *         afin de garder un code aussi simple et adaptable que possible ?
-/* La description de l'aspect (du 'design') des fenêtres
+ *
+ *
+ * 1) Les structures bien définies aujourd'hui.
+ * --------------------------------------------
+ *
+ * La description de l'aspect (du 'design') des fenêtres
  * se trouve dans le dossier 'widget.c'
  * et s'organise naturellement en arborescence
  * qu'il sera facile de répartir en dossiers et fichiers
  * au fur à mesure de leur développement.
  *
- * Actuellement, par exemple, la fenêtre principale comporte
+ * Actuellement, par exemple, la fenêtre principale comporte :
- * une barre de titre (décrite dans 'headers.c')
+ * > une barre de titre (décrite dans 'headers.c') et
- * et s'ouvre sur la vue de l'état ('state.c') en mode 'EXEC'.
+ * > un widget 'child' (la partie sous la barre de titre)
+ *   qui peut prendre au moins trois apparences différentes :
+ *   - STATE (montre l'état de l'espace et les commandes associées)
+ *   - RULES (les règles et les commandes associées)
+ *   - STOCK (les données provenant des mesures, les outils d'analyse, etc.)
+ *           (mal défini à ce stade; sera très probablement réparti...)
+ *
+ * La fenêtre principale s'ouvre sur la vue de l'état ('state.c') en mode 'EXEC'.
  * Cette vue comporte trois panneaux (widgets) principaux:
  * sup, moyen, inf  ou encore: CONTRAST, CAMERA, CONTROL ou EDIT
  * si on veut les nommer d'après leur fonction.
  *
  * Lorsque la description de chaque widget s'affinera
- * et demandera plus de place, les trois widgets principaux
+ * et demandera plus de place, ces trois widgets principaux
  * deviendront des dossiers et les widgets qu'ils contiennent
  * des fichiers (ou des dossiers si besoin) et ainsi de suite...
  *
@@ -74,16 +86,62 @@
  * ou de différents groupes de règles.
  * Et donc de disposer d'un ou de plusieurs index vers ces règles.
  *
- * Les fonctions 'transversales' comme celles de
+ * Tous les callbacks sont dans le fichier 'src/callbacks.c'
+ * et leur nom commence par: 'on_'
+ * (aucun autre nom de fonction ne commence par 'on_').
+ * S'ils deviennent trop nombreux, ils seront répartis
+ * dans des fichiers regroupés dans un dossier: 'src/callbacks.c'.
+ *                   (ou 'src/callbacks' ?)
+ * La description des fonctions devrait plutôt précéder ces fonctions
+ * pour alléger le fichier 'callbacks.h' (?)
+ *
+ *
+ * 2) Les structures dont le développement est prévisible.
+ * -------------------------------------------------------
+ *
+ * Ce sont,aujourd'hui, les fonctions 'transversales' comme celles de
  * 'graph' 'parse', possiblement 'tree' mais - surtout - 'automat',
  * qui doivent pouvoir être accédées par plusieurs widgets ou callbacks
- * restent à la racine: 'src/'
+ * et qui restent à la racine: 'src/
+ *
+ * 'parse' et 'read_file (char *filename)' qui se trouve dans 'base.h'
+ * font vraisemblablement partie d'un ensemble 'entrées / sorties'
+ *
+ * 'state machine' ou 'automat' va centraliser l'identification
+ * des états (apparences) de la fenêtre et des transitions entre ces apparences;
+ * il sera probablement décomposé en de nombreux 'sous-automates' tels que
+ * chaque état de la fenêtre soit une combinaison unique
+ * des états de ces sous-automates.
+ *
+ * Les grandes fonctions du client seront lancées par cette state machine :
+ * - édition automatique (optimisation) de l'arbre des conditions
+ * - tests sur un mini-serveur local
+ * - analyses de données
  *
  * Pour l'instant, le 'include' de 'automat' est dans 'base.h'.
  * C'est une erreur (tolérable tant qu'automat est à l'état embryonnaire).
  * À terme, il y aura un fichier 'automat.h' dans le dossier 'include'
  *
- * (NB labo.c disparaitra, bien sûr !) */
+ *
+ * Les préférences des utilisateurs devront être prises en compte.
+ * Quelle organisation pour faciliter cela et comment s'assurer
+ *         de ne pas géner ces développements ?
+ *
+ * On peut prévoir des préférences concernant l'apparence des widgets,
+ *         les traductions, les 'disabilities'; etc.
+ * mais aussi concernant les méthodes de travail, l'usage des outils d'analyse, etc.
+ *         >>  des 'scripts' pour des 'méta-fonctions' (des 'macros') ?
+ *
+ *
+ * Comment préserver un code aussi simple et adaptable que possible ?
+ * ------------------------------------------------------------------
+ *
+ * Modularité
+ *        (définir les interfaces entre modules tôt et précisément)
+ * Commenter, faire tester (pas trop tôt, pas trop tard)
+ * Tests graphiques, tests unaires, profiling
+ */
+
 
 int main (int argc, char **argv)
 {
@@ -99,54 +157,3 @@ int main (int argc, char **argv)
   return status;
 }
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

src/widget.c/labo.c

@@ -29,6 +29,8 @@
 
 #include "../../include/widgets.h"
 
+// (NB  à terme, labo.c disparaitra, bien sûr !)
+
 
 /******************************************************************************/
 /*                                                                            */