WIP: création de automat.h
This commit is contained in:
parent
509e7b6191
commit
11909920f0
|
@ -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 ();
|
||||
|
||||
|
|
@ -28,7 +28,7 @@
|
|||
* * * * * * * * * * * * * * * * * * * * * * * * * * */
|
||||
|
||||
|
||||
#include "../include/base.h"
|
||||
#include "../include/automat.h"
|
||||
|
||||
|
||||
/******************************************************************************/
|
||||
|
|
41
src/main.c
41
src/main.c
|
@ -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)
|
||||
|
|
Loading…
Reference in New Issue