gem-graph/gem-graph-client
gem-graph
/
gem-graph-client
3
0
Fork 0
Code Issues 14 Pull Requests Projects Releases Activity

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

This commit is contained in:
Jean Sirmai 2024-07-07 07:25:08 +02:00
parent 56fad4b104
commit edebbc4f54
Signed by: jean
GPG Key ID: FB3115C340E057E3
2 changed files with 77 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

143
src/main.c
View File

@ -32,30 +32,42 @@
#include "../include/callbacks.h"
/* 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' (?) */
/* La description de l'aspect (du 'design') des fenêtres
/* https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
* https://en.wikipedia.org/wiki/Multitier_architecture
*
* Quel modèle pour l'organisation du client gem-graph ?
*
* Quelles structures apparaissent bien individualisables dès aujourd'hui ?
* Quelles structures (encore à peine ébauchées) ont un développement prévisible ?
* Quelles interfaces peut-on prévoir, vers quels modules à venir,
* afin de garder un code aussi simple et adaptable que possible ?
*
*
* 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
* une barre de titre (décrite dans 'headers.c')
* et s'ouvre sur la vue de l'état ('state.c') en mode 'EXEC'.
* Actuellement, par exemple, la fenêtre principale comporte :
* > une barre de titre (décrite dans 'headers.c') et
* > 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;
}

2
src/widget.c/labo.c
View File

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