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/callbacks.h"

/* 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
 * > 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_').
 * 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
 * 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'
 *
 *
 * 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
 */



/*         L I S T E   D E S   F I C H I E R S   A   R E N O M M E R          */

/* 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_').

 * Tous les fonctions appelées par les fonctions callback() sont dans 'widgets'
 * SAUF:  (en cours - 2024-07-08  7h50)
 */


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.