/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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/widget.h" /* Sur quel modèle se guider pour structurer le client gem-graph ? * https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel * https://en.wikipedia.org/wiki/Multitier_architecture * * Le nom de toute fonction qui peut être appelée d'un autre module doit comporter : * - 1) le nom du module auquel elle appartient (widget, graphics, parse,...) * - 2) une indication sur son action (get, set, rec, fix, create, add,...) * - 3) une indication sur l'objet de cette action (STATE, RULES, STACK,...) * * ex: on_save_CURRENT_MODEL() * model_get_DIM_VALUE() * * Il est prévisible que 'state.c' devienne un dossier contenant * les fichiers 'controls.c', 'camera.c', 'contrasts.c' et d'autres, * Une fonction comme : get_ZOOM_box() * devra alors être renommé : state_camera_get_ZOOM_box() (par exemple) * * _________________ * * * ORGANISATION ACTUELLE * * 1) Les structures hiérarchiques. * -------------------------------- * * La description du 'design' des fenêtres se trouve dans le dossier 'widget' * et s'organise naturellement en arborescence, comme les widgets eux-mêmes. * * Il sera donc facile de répartir cette description en dossiers et fichiers * au fur à mesure de son développement. * * Actuellement, par exemple, la fenêtre principale comporte : * > une barre de titre (décrite dans 'topbar') 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... * * * 2) Les structures transversales. * -------------------------------- * * Les fonctions 'transversales' comme celles de 'graphics' 'parse', 'fsm', * doivent pouvoir être accédées directement * sans avoir à passer par la hiérarchie des widgets et/ou callbacks. * Elles restent à la racine: 'src/ * * * 'finite state machine' ('fsm') 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 'finite state machine' peut se trouver dans 2 x 3 = 6 états. * (voir fsm.h lignes 40-41) * * * 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... * * * 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 P P E L É E S * * ***************************************************************************** * ******************************************************************************* * 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 * * ***************************************************************************** */ #include "../include/widget.h" #include "../include/signal.h" 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. // Property GtkSettings:gtk-error-bell // property gtk-error-bell: gboolean [ read, write ] // When TRUE, keyboard navigation and other input-related errors will cause a beep.