353 lines
14 KiB
C
353 lines
14 KiB
C
/* * * * * * * * * * * * * * * * * * * * * * * * * * *
|
|
* *
|
|
* Gem-graph client *
|
|
* *
|
|
* Main *
|
|
* *
|
|
* Copyright © 2021 Libre en Communs <contact@a-lec.org> *
|
|
* Copyright © 2021 Adrien Bourmault <neox@a-lec.org> *
|
|
* Copyright © 2021 Arthur Menges <arthur.menges@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 "../include/signal.h"
|
|
|
|
/* Comment renommer les fonctions ?
|
|
* Cette question dépend de plusieurs choix
|
|
* nécessairement provisoires mais nécessaires.
|
|
*
|
|
*
|
|
* > Sur quel modèle se guider pour organiser le client gem-graph ?
|
|
* Comment l'adapter ? Que faut-il garder ? Que faut-il améliorer ?
|
|
* https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
|
|
* https://en.wikipedia.org/wiki/Multitier_architecture
|
|
*
|
|
* > Quelles structures sont suffisamment individualisées dès aujourd'hui,
|
|
* ou ont un développement suffisamment prévisible (modules, interfaces)
|
|
* pour qu'on puisse décider de les renommer
|
|
* (et comment classer et nommer les autres) ?
|
|
*
|
|
* > Comment rendre "human-readable" des noms d'un langage "machine-readable" ?
|
|
*
|
|
* _________________
|
|
*
|
|
* >>> Nous avons à nous choisir des règles de renommage des fonctions
|
|
* qui soient conformes aux 'bonnes pratiques' du 'génie logiciel'
|
|
* ET soient les plus pertinentes possibles pour notre cas particulier.
|
|
* (interrompu le 2024-07-09 à 23h00)
|
|
*
|
|
*
|
|
* >>> Proposition : Toute fonction utilisée par un autre module doit
|
|
* - commencer D'ABORD par le nom de ce module,
|
|
* - indiquer ENSUITE sa nature (get, set, print,...)
|
|
* - et ENFIN son objet (STATE, RULES, STACK,...)
|
|
*
|
|
* ex: widget_get_RULES_page()
|
|
* automat_set_STATE_RULES_DATA()
|
|
* on_save_CURRENT_MODEL()
|
|
* model_get_DIM_VALUE()
|
|
* model_get_NEXT_ARROW()
|
|
* area_get_GRAPH_STACK() ou graph_get_GRAPH_STACK()
|
|
*
|
|
* 'model' == parse ('model' est un alias de 'parse')
|
|
* 'graph' == area ('graph' est un alias de 'area')
|
|
* 'on_' == callback ('on_' est un alias de 'callbacks')
|
|
* Ainsi, TOUS les callbacks sont dans le fichier 'src/callbacks.c'
|
|
* Leur nom commence TOUJOURS par: 'on_'
|
|
* ET AUCUN AUTRE nom de fonction ne commence par 'on_'.
|
|
*
|
|
*
|
|
* > selon ces règles, get_user_tree_model()
|
|
* devrait être renommé : tree_get_USER_TREE_MODEL()
|
|
*
|
|
* > si, comme c'est prévisible, 'state.c' devient un dossier contenant :
|
|
* les fichiers 'controls.c', 'camera.c', 'contrasts.c' et d'autres,
|
|
* alors, get_ZOOM_box()
|
|
* devrait être renommé : state_camera_get_ZOOM_box()
|
|
*
|
|
* _________________
|
|
*
|
|
*
|
|
* QUELLE EST L'ORGANISATION ACTUELLE ?
|
|
*
|
|
* 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 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.
|
|
*
|
|
* 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, ces trois widgets principaux
|
|
* 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
|
|
* soit inclus dans le fichier 'rules.c'
|
|
* (puisque cet arbre est dans la page (le widget) 'rules')
|
|
* soit, s'il est trop volumineux, et pour faciliter la lisibilité,
|
|
* dans un dossier 'rules.c' (ou 'rules' ?)
|
|
* qui regroupera les différents widgets du widget 'rules'.
|
|
*
|
|
* NB Il est possible qu'il y ait besoin d'autres structures d'arbres:
|
|
* dans 'rules', par exemple, il est important de pouvoir visualiser
|
|
* l'utilisation (l'activité) des différentes règles
|
|
* 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_') ('on_' est un alias).
|
|
*
|
|
* 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 transversales.
|
|
* --------------------------------
|
|
*
|
|
* Les fonctions 'transversales' comme celles de
|
|
* 'graph' 'parse', possiblement 'tree' mais - surtout - 'automat',
|
|
* doivent pouvoir être accédées directement
|
|
* sans avoir à passer par la hiérarchie des widgets et/ou callbacks.
|
|
* Elles restent à la racine: 'src/
|
|
*
|
|
*
|
|
* 'state machine' ou 'automat' va centraliser l'identification
|
|
* des états (apparences) de la fenêtre et des transitions entre ces apparences;
|
|
* 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.
|
|
*
|
|
* Exemple, muni des deux 'sous-automates' :
|
|
* > { EXEC, EDIT }; // xor
|
|
* > { STATE, RULES, DATA }; // xor
|
|
* la 'state machine' peut se trouver dans 2 x 3 = 6 états.
|
|
* (voir automat.h lignes 39-40)
|
|
*
|
|
*
|
|
* 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...
|
|
*
|
|
*
|
|
* '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.
|
|
* Leur recueil et leur mémorisation seront probablement des fonctions centrales
|
|
* mais leur mise en oeuvre suivra probalement les voies hiérarchiques.
|
|
*
|
|
* 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') ?
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*******************************************************************************
|
|
* L I S T E D E S F O N C T I O N S A R E N O M M E R *
|
|
* *****************************************************************************
|
|
*
|
|
* Ces fonctions peuvent être énumérées selon leur source ou leur destination.
|
|
* Il y a, en tout, à ce jour :
|
|
* - (86) fonctions appelées (dont 6 data)
|
|
* - (m) appels de fonction
|
|
* - (e) enum
|
|
* - (s) struct
|
|
* - (d) define
|
|
*
|
|
* NB Seules les fonctions spécifiques de gem-graph-client sont prises en compte.
|
|
* Les fonctions 'static' ne sont pas comptées.
|
|
*
|
|
* (déplacer systématiquement les enum, struct, size_t, etc. vers les include ?)
|
|
*
|
|
*
|
|
*
|
|
*******************************************************************************
|
|
* L I S T E D E S F O N C T I O N S A P P E L É E S *
|
|
* *****************************************************************************
|
|
* (interrompu le 2024-07-09 à 23h00)
|
|
*
|
|
* main 1
|
|
* callbacks 18
|
|
* automat 8 + 2 enum
|
|
* parse 8
|
|
* 35
|
|
*
|
|
* graph / area 11 + 1 struct + 1 size_t
|
|
* graph / stack 3 + 1 struct + 2 size_t + 1 int
|
|
* graph / draw 5
|
|
* graph / grid 4
|
|
* graph / init 2
|
|
* graph / shader.frag 1
|
|
* graph / shader.vert 1
|
|
* 27
|
|
*
|
|
* widget / heads 10
|
|
* widget / rules 1
|
|
* widget / state 1
|
|
* widget / stock 2
|
|
* widget / tree 2 + 1 struct
|
|
* widget / labo 1
|
|
* 17
|
|
*
|
|
* data / image 5
|
|
* data / text 2
|
|
*
|
|
* TOTAL 86
|
|
*
|
|
* Tous les fonctions appelées par les fonctions callback() sont dans 'widgets.h'
|
|
* SAUF les 8 suivantes qui concernent la 'state machine' et qui sont dans 'automat.h' :
|
|
|
|
* set_EXEC_EDIT() get_EXEC_EDIT()
|
|
* set_STATE_RULES_DATA() get_STATE_RULES_DATA()
|
|
* set_OBJECTS_box_RESET_VALUE() get_OBJECTS_box_RESET_VALUE()
|
|
* set_SITUATIONS_box_RESET_VALUE() get_SITUATIONS_box_RESET_VALUE()
|
|
*
|
|
*
|
|
* Les autres fonctions appelées par les fonctions callback() sont :
|
|
*
|
|
* widget_head_MAIN_WINDOW_design()
|
|
* widget_head_DIALOG_WINDOW_design()
|
|
* widget_head_TEXT_WINDOW_design()
|
|
*
|
|
*
|
|
* Widgets.c appelle :
|
|
*
|
|
* on_bind_user_tree_factory()
|
|
* on_axis_value_change()
|
|
* graph_update_axis_stack()
|
|
*
|
|
*.....
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*******************************************************************************
|
|
* L I S T E D E S A P P E L S D E F O N C T I O N S *
|
|
* *****************************************************************************
|
|
* grep -r "set_EXEC_EDIT" | wc > 5 lignes
|
|
* mais il n'y a que 2 appels des fonctions
|
|
*
|
|
* NB vérifier que tous les accès aux variables
|
|
* passent systématiquement par les get / set. (en utilisant 'static')
|
|
*
|
|
*
|
|
*
|
|
* - QUOI - - COMBIEN - D'OÙ -
|
|
*
|
|
*
|
|
* on_windows_activation 1 main
|
|
*
|
|
*
|
|
* get_EXEC_EDIT 1 callbacks
|
|
* 1 widget / state
|
|
*
|
|
* set_EXEC_EDIT 2 callbacks
|
|
*
|
|
* get_STATE_RULES_DATA 1 callbacks
|
|
*
|
|
* set_STATE_RULES_DATA 3 callbacks
|
|
*
|
|
* get_OBJECTS_box_RESET_VALUE 1 automat
|
|
*
|
|
* set_OBJECTS_box_RESET_VALUE 1 callbacks
|
|
*
|
|
* get_SITUATIONS_box_RESET_VALUE 1 automat
|
|
*
|
|
* set_SITUATIONS_box_RESET_VALUE 1 callbacks
|
|
*
|
|
*.....
|
|
*
|
|
*
|
|
*
|
|
*
|
|
* (interrompu le 2024-07-09 à 23h00)
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
* Faut-il déplacer systématiquement les enum, struct, size_t, etc.
|
|
* vers les include ?
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*/
|
|
|
|
|
|
int main (int argc, char **argv)
|
|
{
|
|
GtkApplication *app;
|
|
int status;
|
|
|
|
app = gtk_application_new ("org.gem-graph", G_APPLICATION_DEFAULT_FLAGS);
|
|
g_signal_connect (app, "activate", G_CALLBACK (on_windows_activation), NULL);
|
|
|
|
status = g_application_run (G_APPLICATION (app), argc, argv);
|
|
g_object_unref (app);
|
|
|
|
return status;
|
|
}
|
|
|
|
|
|
// GTK itself does not support event sounds, << A GREAT WAY TO DEBUG ! TODO
|
|
// you have to use a loadable module like the one that comes with libcanberra.
|
|
|