/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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" /* 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. * (en cours, 2024-07-09 10h40) * * * >>> 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. * * 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. * * * ******************************************************************************* * L I S T E D E S F O N C T I O N S A P P E L É E S * * ***************************************************************************** * (en cours, 2024-07-09 10h40) * * 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 celles qui concernent la 'state machine', dans 'automat.h', qui sont : * 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_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() * *..... * * * * ******************************************************************************* * L I S T E D E S F O N C T I O N S A P P E L A N T E S * * ***************************************************************************** * (en cours, 2024-07-09 10h40) * * * * * * (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.