WIP: création de automat.h

This commit is contained in:
Jean Sirmai 2024-07-08 22:05:15 +02:00
parent 509e7b6191
commit 11909920f0
Signed by: jean
GPG Key ID: FB3115C340E057E3
3 changed files with 74 additions and 21 deletions

52
include/automat.h Normal file
View File

@ -0,0 +1,52 @@
/* * * * * * * * * * * * * * * * * * * * * * * * * * *
* *
* Gem-graph client *
* *
* Base header *
* *
* Copyright © 2021 Libre en Communs <contact@a-lec.org> *
* Copyright © 2021 Adrien Bourmault <neox@a-lec.org> *
* Copyright © 2021 Jean Sirmai <jean@a-lec.org> *
* *
* This file is part of Gem-graph. *
* *
* This program is free software: you can redistribute it and/or modify it *
* under the terms of the GNU Affero General Public License *
* as published by the Free Software Foundation, *
* either version 3 of the License, *
* or (at your option) any later version. *
* *
* This program is distributed in the hope that it will be useful, *
* but WITHOUT ANY WARRANTY; *
* without even the implied warranty of MERCHANTABILITY *
* or FITNESS FOR A PARTICULAR PURPOSE. *
* See the GNU Affero General Public License for more details. *
* *
* You should have received a copy of the GNU Affero General Public License *
* along with this program. If not, see <http://www.gnu.org/licenses/>. *
* *
* * * * * * * * * * * * * * * * * * * * * * * * * * */
#include <stdio.h>
/******************************************************************************/
/* S T A T E M A C H I N E */
/******************************************************************************/
enum choice_EXEC_EDIT { EXEC, EDIT }; // xor
enum choice_STATE_RULES_DATA { STATE, RULES, DATA }; // xor
void set_EXEC_EDIT (int prescribed);
void set_STATE_RULES_DATA (int prescribed);
void set_OBJECTS_box_RESET_VALUE (int prescribed);
void set_SITUATIONS_box_RESET_VALUE (int prescribed);
int get_EXEC_EDIT ();
int get_STATE_RULES_DATA ();
int get_OBJECTS_box_RESET_VALUE ();
int get_SITUATIONS_box_RESET_VALUE ();

View File

@ -28,7 +28,7 @@
* * * * * * * * * * * * * * * * * * * * * * * * * * */
#include "../include/base.h"
#include "../include/automat.h"
/******************************************************************************/

View File

@ -43,12 +43,12 @@
* afin de garder un code aussi simple et adaptable que possible ?
*
*
* 1) Les structures bien définies aujourd'hui.
* --------------------------------------------
* 1) Les structures hiérarchiques.
* --------------------------------
*
* La description de l'aspect (du 'design') des fenêtres
* se trouve dans le dossier 'widget.c'
* et s'organise naturellement en arborescence
* et s'organise naturellement sur le même modèle : en arborescence
* qu'il sera facile de répartir en dossiers et fichiers
* au fur à mesure de leur développement.
*
@ -71,6 +71,7 @@
* deviendront des dossiers et les widgets qu'ils contiennent
* des fichiers (ou des dossiers si besoin) et ainsi de suite...
*
*
* Dans cette logique,
* sauf s'il y a d'autres arbres que l'arbre des utilisateurs,
* l'actuel ficher 'tree.c' devrait être
@ -86,6 +87,7 @@
* ou de différents groupes de règles.
* Et donc de disposer d'un ou de plusieurs index vers ces règles.
*
*
* 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_').
@ -96,36 +98,35 @@
* pour alléger le fichier 'callbacks.h' (?)
*
*
* 2) Les structures dont le développement est prévisible.
* -------------------------------------------------------
* 2) Les structures transversales.
* --------------------------------
*
* Ce sont,aujourd'hui, les fonctions 'transversales' comme celles de
* 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
* et qui restent à la racine: 'src/
* doivent pouvoir être accédées directement
* sans avoir à passer par la hiérarchie des widgets et/ou callbacks.
* Elles 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
* Elle sera probablement décomposée 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
* - 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'
*
* 'parse' et 'read_file (char *filename)' qui se trouve dans 'base.h'
* font vraisemblablement partie d'un seul ensemble 'entrées / sorties'
*
*
* 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 ?
* leur recueil et leur mémorisation seront probablement des fonctions centrales
* mais leur mise en oeuvre suivra probalement la voie hiérarchique.
*
* On peut prévoir des préférences concernant l'apparence des widgets,
* les traductions, les 'disabilities'; etc.
@ -133,8 +134,8 @@
* >> des 'scripts' pour des 'méta-fonctions' (des 'macros') ?
*
*
* Comment préserver un code aussi simple et adaptable que possible ?
* ------------------------------------------------------------------
* Comment optimiser ?
* -------------------
*
* Modularité
* (définir les interfaces entre modules tôt et précisément)