gem-graph-client/src/main.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/calls.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) fonctions appelantes
 *                     -  (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.jean.gg_hack", 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.