/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Gem-graph client * * * * Main * * * * Copyright © 2021 Libre en Communs * * Copyright © 2021 Adrien Bourmault * * Copyright © 2021 Arthur Menges * * Copyright © 2021 Jean Sirmai * * * * 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 . * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ #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.h' * SAUF celles qui concernent la 'state machine' qui sont dans 'base.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() * * (Ces fonctions iront dans un fichier 'automat.h') * * Les autres fonctions appelées par les fonctions callback() sont : * * widget_MAIN_WINDOW_design() * widget_DIALOG_WINDOW_design() * widget_TEXT_WINDOW_design() * * * Widgets.c appelle : * * on_bind_user_tree_factory() * on_axis_value_change() * graph_update_axis_stack() * * * * * (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.