gem-graph/gem-graph-client
gem-graph
/
gem-graph-client
3
0
Fork 0
Code Issues 14 Pull Requests Projects Releases Activity

doxygen main() cleaned

This commit is contained in:
Jean Sirmai 2024-10-28 09:44:51 +01:00
parent f7951934db
commit 68ba797f3f
Signed by: jean
GPG Key ID: FB3115C340E057E3
16 changed files with 130 additions and 271 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -1,2 +1,3 @@
bin/* bin/*
build/* build/*
doc/html/*

76
doc/(pesonnal notes) → doc/(personnal notes)
View File

@ -1,3 +1,75 @@
links > GNOME platform
https://docs.gtk.org/gio/class.Application.html
https://developer.gnome.org/documentation/tutorials/application.html
https://docs.gtk.org/gtk3/getting_started.html < WARNING Gtk3
https://developer.gnome.org/documentation/introduction.html
https://developer.gnome.org/documentation/index.html
-----------------------------------------------------------------------------
https://fr.wikipedia.org/wiki/Disque_de_Poincar%C3%A9
//----------------------------- personal notes ---------------------------
// TODO (ranger ça !)
/*
2024-08-31 Un point sur l'état d'avancement du client:
TODO (bottlenecks)
- images (++)
- arbres (et listes) (++)
- logging (ref : /var/log/messages)
- menus (pas indispensables à ce stade)
À redéfinir: répartition des tâches (mesures) client/serveur.
Comment traiter le cas extrême où *toutes* les règles
sont des règles d'intérêt ?
(cas d'une erreur rare, non systématique où il faut "remonter le temps",
pas à pas, à partir du premier état qui met l'erreur en évidence)
Pour effectuer cette "remontée", il faut une liste complète
de toutes les règles appliquées.
Cette liste doit comporter, pour chaque item (= chaque exécution d'une règle):
- identité de la règle
- lieu d'exécution (dans l'espace global)
- date d'exécution
NB Il ne peut y avoir d'ambiguité ou d'erreur due au parallélisme
car, si les espaces locaux de deux exécutions de règles se recouvrent,
elles ne peuvent avoir été exécutées simultanément.
À mon avis, le serveur ne peut effectuer cette tâche car
la "remontée dans le temps" nécessite l'inspection 'de visu' de chaque état.
Inspection veut dire ici: reconnaissance de formes
et ce travail (visuel) ne peut être pré-programmé
(bien qu'il doive être systématique), car le concepteur du modèle
ne sait pas quelle est l'erreur et ne peut prévoir ce qu'il va découvrir.
Ceci n'exclut pas qu'il puisse - qu'il doive - effectuer plusieurs essais
(de "remontée dans le temps") en sélectionnant, par exemple,
différentes règles d'intérêt à chaque fois
ni qu'il puisse se programmer des outils d'aide
(mais tout ceci ne semble pas avoir sa place dans le serveur).
NB À ce stade de la conception d'un modèle, les erreurs sont encore fréquentes
et les 'runs' sont nécessairement de brève durée.
Des 'runs' de longue durée n'ont de sens qu'une fois ce débuggage effectué.
Il y a donc peu de problèmes à craindre du fait de la limite de la bande passante.
*/
-------
https://thevaluable.dev/sed-cli-practical-guide-examples/#the-basics-of-sed https://thevaluable.dev/sed-cli-practical-guide-examples/#the-basics-of-sed
@ -119,7 +191,7 @@ https://docs.gtk.org/gtk4/class.Widget.html#height-for-width-geometry-management
// GtkSizeRequestMode get_request_mode (GtkWidget* widget); // GtkSizeRequestMode get_request_mode (GtkWidget* widget);
// gtk_window_set_default_size (GTK_WINDOW (a_box), 30, 400); < TO STUDY // gtk_window_set_default_size (GTK_WINDOW (a_box), 30, 400); < TO STUDY
https://docs.gtk.org/gtk4/section-text-widget.html texts https://docs.gtk.org/gtk4/section-text-widget.html texts
https://docs.gtk.org/gtk4/drag-and-drop.html drag-and-drop https://docs.gtk.org/gtk4/drag-and-drop.html drag-and-drop
https://docs.gtk.org/gtk4/class.GestureZoom.html GtkGestureZoom https://docs.gtk.org/gtk4/class.GestureZoom.html GtkGestureZoom
https://docs.gtk.org/gtk4/class.ListView.html https://docs.gtk.org/gtk4/class.ListView.html
https://blog.gtk.org/2020/09/08/on-list-models/ < TODO https://blog.gtk.org/2020/09/08/on-list-models/ < TODO
@ -148,7 +220,7 @@ puis, après déclaration du bouton, gtk_box_append (GTK_BOX (box), button);
grid = gtk_grid_new (); grid = gtk_grid_new ();
gtk_window_set_child (GTK_WINDOW (window), grid); gtk_window_set_child (GTK_WINDOW (window), grid);
button = gtk_button_new_with_label (" I "); n fois button = gtk_button_new_with_label (" I "); n fois
gtk_grid_attach (GTK_GRID (grid), button, 0, 0, 1, 1); n fois gtk_grid_attach (GTK_GRID (grid), button, 0, 0, 1, 1); n fois
-------------------------------------------------------------------------------- --------------------------------------------------------------------------------

26
doc/docbook/d0/d09/main_8c.xml
View File

@ -38,31 +38,7 @@
<para>By default, the main window opens on the overview page of the current model as specified in: src/widget/main_window/designer/widget_design_main_window().</para> <para>By default, the main window opens on the overview page of the current model as specified in: src/widget/main_window/designer/widget_design_main_window().</para>
<para><informaltable frame='bottom'><tgroup cols='1'><colspec align='center'/><tbody><row><entry align='center'> <para>About code organization, see src/readme.dox</para>
</entry></row></tbody></tgroup></informaltable>
</para>
<para>The code files are all located in the src (sources) directory (the headers in &apos;include&apos;). They are divided into several <emphasis role="bold">types of organisation</emphasis>:</para>
<para><itemizedlist>
<listitem>
<para><emphasis>hierarchical</emphasis>: the widgets that give the windows their appearance are organised in the form of a tree. Windows are the first level of depth. Next come the title bar and the pages designed to occupy the window space below the title bar. Each of these pages has its own hierarchical structure: it can be divided into horizontal or vertical strips, which can themselves be divided in the same way, with varying levels of depth right down to the last boxes, which contain lists of widgets such as buttons, sliders or images.</para>
</listitem><listitem>
<para><emphasis>list</emphasis>: the main <emphasis>sections</emphasis> of the fsm (finite state machine) constitute a list of at least four elements, each of which defines a set of possible states :<orderedlist>
<listitem>
<para>execute or edit (managing the appropriate tools states in both cases)</para>
</listitem><listitem>
<para>measure, operate on data, prepare displayable results</para>
</listitem><listitem>
<para>apply user preferences</para>
</listitem><listitem>
<para>indicate the desired state of windows and widgets</para>
</listitem></orderedlist>
The state of the fsm is uniquely defined at all times by all the parameters listed in these sections. All program actions depend on this state.</para>
</listitem><listitem>
<para><emphasis>transversal</emphasis>: the other functions that must be easily accessible by all the previous functions. They are therefore all located at the root. These are the functions that manage graphics, callbacks, utilities and the log.</para>
</listitem></itemizedlist>
</para>
<para><informaltable frame='bottom'><tgroup cols='1'><colspec align='center'/><tbody><row><entry align='center'> <para><informaltable frame='bottom'><tgroup cols='1'><colspec align='center'/><tbody><row><entry align='center'>
</entry></row></tbody></tgroup></informaltable> </entry></row></tbody></tgroup></informaltable>

2
doc/docbook/d3/d01/readme_8dox.xml
View File

@ -12,6 +12,8 @@
<para>Gem-graph-client doc <link linkend="_readme_8dox">readme.dox</link> file. </para> <para>Gem-graph-client doc <link linkend="_readme_8dox">readme.dox</link> file. </para>
<para>(the .c extension is just crap)</para>
<para>This file is part of Gem-graph.</para> <para>This file is part of Gem-graph.</para>
<para>The code files are all located in the src (sources) directory (the headers in &apos;include&apos;). They are divided into several <emphasis role="bold">types of organisation</emphasis>:</para> <para>The code files are all located in the src (sources) directory (the headers in &apos;include&apos;). They are divided into several <emphasis role="bold">types of organisation</emphasis>:</para>

10
doc/docbook/dc/d0c/widget_2readme_8dox_8c.xml
View File

@ -4,23 +4,21 @@
<indexterm><primary>src/widget/readme.dox.c</primary></indexterm> <indexterm><primary>src/widget/readme.dox.c</primary></indexterm>
<para> <para>
<para>Gem-graph-client widget <link linkend="_readme_8dox">readme.dox</link> file. </para> <para>Gem-graph-client xxxxx readme.dox file (NB -&gt; The .c extension is just crap). </para>
</para> </para>
<section> <section>
<title>Detailed Description</title> <title>Detailed Description</title>
<para>Gem-graph-client widget <link linkend="_readme_8dox">readme.dox</link> file. </para> <para>Gem-graph-client xxxxx readme.dox file (NB -&gt; The .c extension is just crap). </para>
<para>(the .c extension is just crap)</para>
<para>This file is part of Gem-graph.</para> <para>This file is part of Gem-graph.</para>
<para>The code files are all located in the src (sources) directory (the headers in &apos;include&apos;). They are divided into several <emphasis role="bold">types of organisation</emphasis>:</para> <para>The code files are all located in the src (sources) directory They are divided into several <emphasis role="bold">types of organisation</emphasis>:</para>
<para><itemizedlist> <para><itemizedlist>
<listitem> <listitem>
<para><emphasis>hierarchical</emphasis>: the widgets that give the windows their appearance are organised in the form of a tree. Windows are the first level of depth. Next come the title bar and the pages designed to occupy the window space below the title bar. Each of these pages has its own hierarchical structure: it can be divided into horizontal or vertical strips, which can themselves be divided in the same way, with varying levels of depth right down to the last boxes, which contain lists of widgets such as buttons, sliders or images.</para> <para><emphasis>hierarchical</emphasis>: the widgets that give the windows their appearance are organised in the form of a tree. Windows are the first level of depth. Next come the title bars and the pages designed to occupy the windows space below the title bars. Each of these pages has its own hierarchical structure: it can be divided into horizontal or vertical strips, which can themselves be divided in the same way, with varying levels of depth right down to the last containers which contain lists of widgets such as buttons, bars, entries or images.</para>
</listitem><listitem> </listitem><listitem>
<para><emphasis>list</emphasis>: the main <emphasis>sections</emphasis> of the fsm (finite state machine) constitute a list of at least four elements, each of which defines a set of possible states :<orderedlist> <para><emphasis>list</emphasis>: the main <emphasis>sections</emphasis> of the fsm (finite state machine) constitute a list of at least four elements, each of which defines a set of possible states :<orderedlist>
<listitem> <listitem>

2
doc/docbook/dd/d01/fsm_8h.xml
View File

@ -359,7 +359,7 @@ This graph shows which files directly or indirectly include this file:<para>
<para><informaltable frame='bottom'><tgroup cols='1'><colspec align='center'/><tbody><row><entry align='center'> <para><informaltable frame='bottom'><tgroup cols='1'><colspec align='center'/><tbody><row><entry align='center'>
</entry></row></tbody></tgroup></informaltable> </entry></row></tbody></tgroup></informaltable>
</para> </para>
<section xml:id="_fsm_8h_1autotoc_md2"> <section xml:id="_fsm_8h_1autotoc_md1">
<title>J O U R N A L - M E T A - R U L E S</title> <title>J O U R N A L - M E T A - R U L E S</title>
<para>ref: sudo cat /var/log/messages</para> <para>ref: sudo cat /var/log/messages</para>

4
doc/docbook/de/d05/fsm_2readme_8dox_8c.xml
View File

@ -4,13 +4,13 @@
<indexterm><primary>src/fsm/readme.dox.c</primary></indexterm> <indexterm><primary>src/fsm/readme.dox.c</primary></indexterm>
<para> <para>
<para>Gem-graph-client fsm <link linkend="_readme_8dox">readme.dox</link> file. </para> <para>Gem-graph-client fsm readme.dox file. </para>
</para> </para>
<section> <section>
<title>Detailed Description</title> <title>Detailed Description</title>
<para>Gem-graph-client fsm <link linkend="_readme_8dox">readme.dox</link> file. </para> <para>Gem-graph-client fsm readme.dox file. </para>
<para>(the .c extension is just crap)</para> <para>(the .c extension is just crap)</para>

20
doc/docbook/de/d0f/readme_8dox_8c.xml
View File

@ -1,24 +1,24 @@
<?xml version='1.0' encoding='UTF-8' standalone='no'?> <?xml version='1.0' encoding='UTF-8' standalone='no'?>
<section xmlns="http://docbook.org/ns/docbook" version="5.0" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="_readme_8dox_8c" xml:lang="en-US"> <section xmlns="http://docbook.org/ns/docbook" version="5.0" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="_readme_8dox_8c" xml:lang="en-US">
<title>src/widget/readme.dox.c File Reference</title> <title>src/readme.dox.c File Reference</title>
<indexterm><primary>src/widget/readme.dox.c</primary></indexterm> <indexterm><primary>src/readme.dox.c</primary></indexterm>
<para> <para>
<para>Gem-graph-client widget readme.dox file. </para> <para>Gem-graph-client src readme.dox file (NB -&gt; The .c extension is just crap). </para>
</para> </para>
<section> <section>
<title>Detailed Description</title> <title>Detailed Description</title>
<para>Gem-graph-client widget readme.dox file. </para> <para>Gem-graph-client src readme.dox file (NB -&gt; The .c extension is just crap). </para>
<para>This file is part of Gem-graph.</para> <para>This file is part of Gem-graph.</para>
<para>The code files are all located in the src (sources) directory (the headers in &apos;include&apos;). They are divided into several <emphasis role="bold">types of organisation</emphasis>:</para> <para>The code files are all located in the src (sources) directory They are divided into several <emphasis>types of organisation</emphasis>:</para>
<para><itemizedlist> <para><itemizedlist>
<listitem> <listitem>
<para><emphasis>hierarchical</emphasis>: the widgets that give the windows their appearance are organised in the form of a tree. Windows are the first level of depth. Next come the title bar and the pages designed to occupy the window space below the title bar. Each of these pages has its own hierarchical structure: it can be divided into horizontal or vertical strips, which can themselves be divided in the same way, with varying levels of depth right down to the last boxes, which contain lists of widgets such as buttons, sliders or images.</para> <para><emphasis>hierarchical</emphasis>: the widgets that give the windows their appearance are organised in the form of a tree. Windows are the first level of depth. Next come the title bars and the pages designed to occupy the windows space below the title bars. Each of these pages has its own hierarchical structure: it can be divided into horizontal or vertical strips, which can themselves be divided in the same way, with varying levels of depth right down to the last containers which contain lists of widgets such as buttons, bars, entries or images.</para>
</listitem><listitem> </listitem><listitem>
<para><emphasis>list</emphasis>: the main <emphasis>sections</emphasis> of the fsm (finite state machine) constitute a list of at least four elements, each of which defines a set of possible states :<orderedlist> <para><emphasis>list</emphasis>: the main <emphasis>sections</emphasis> of the fsm (finite state machine) constitute a list of at least four elements, each of which defines a set of possible states :<orderedlist>
<listitem> <listitem>
@ -38,6 +38,12 @@ The state of the fsm is uniquely defined at all times by all the parameters list
<para><informaltable frame='bottom'><tgroup cols='1'><colspec align='center'/><tbody><row><entry align='center'> <para><informaltable frame='bottom'><tgroup cols='1'><colspec align='center'/><tbody><row><entry align='center'>
</entry></row></tbody></tgroup></informaltable> </entry></row></tbody></tgroup></informaltable>
</para> </para>
<para><formalpara><title>See also</title>
<para>Model–view–controller || Model–view–viewmodel || Action–domain–responder || Multitier_architecture <link xlink:href="https://en.wikipedia.org/wiki/Multitier_architecture">https://en.wikipedia.org/wiki/Multitier_architecture</link> (presentation, logic, data) </para>
</formalpara>
</para>
</section> </section>
</section> </section>

6
doc/docbook/index.xml
View File

@ -23,7 +23,6 @@
</chapter> </chapter>
<chapter> <chapter>
<title>File Documentation</title> <title>File Documentation</title>
<xi:include href="d3/d01/readme_8dox.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="d7/d01/action_8h.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="d7/d01/action_8h.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="d3/d0a/base_8h.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="d3/d0a/base_8h.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="dd/d01/fsm_8h.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="dd/d01/fsm_8h.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
@ -41,6 +40,9 @@
<xi:include href="d8/d00/init_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="d8/d00/init_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="d7/d08/log_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="d7/d08/log_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="d0/d09/main_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="d0/d09/main_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="de/d05/fsm_2readme_8dox_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="de/d0f/readme_8dox_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="dc/d0c/widget_2readme_8dox_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="d8/d06/signal_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="d8/d06/signal_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="da/d0c/gl_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="da/d0c/gl_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="df/d0a/io_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="df/d0a/io_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
@ -92,8 +94,6 @@
<xi:include href="d2/d0e/fsm_2results_2manager_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="d2/d0e/fsm_2results_2manager_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="d3/d09/widget_2manager_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="d3/d09/widget_2manager_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="d5/d0a/modal_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="d5/d0a/modal_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="de/d05/fsm_2readme_8dox_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="dc/d0c/widget_2readme_8dox_8c.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
</chapter> </chapter>
<index/> <index/>
</book> </book>

6
doc/links > GNOME platform
View File

@ -1,6 +0,0 @@
https://docs.gtk.org/gio/class.Application.html
https://developer.gnome.org/documentation/tutorials/application.html
https://docs.gtk.org/gtk3/getting_started.html < WARNING Gtk3
https://developer.gnome.org/documentation/introduction.html
https://developer.gnome.org/documentation/index.html

22
doc/rtfm/man3/main.c.3
View File

@ -33,27 +33,7 @@ The \fBmain()\fP function \fBinitialises\fP the log, the finite state machine (f
.PP .PP
By default, the main window opens on the overview page of the current model as specified in: src/widget/main_window/designer/widget_design_main_window()\&. By default, the main window opens on the overview page of the current model as specified in: src/widget/main_window/designer/widget_design_main_window()\&.
.PP .PP
.PP About code organization, see src/readme\&.dox
.PP
The code files are all located in the src (sources) directory (the headers in 'include')\&. They are divided into several \fBtypes of organisation\fP:
.PP
.IP "\(bu" 2
\fIhierarchical\fP: the widgets that give the windows their appearance are organised in the form of a tree\&. Windows are the first level of depth\&. Next come the title bar and the pages designed to occupy the window space below the title bar\&. Each of these pages has its own hierarchical structure: it can be divided into horizontal or vertical strips, which can themselves be divided in the same way, with varying levels of depth right down to the last boxes, which contain lists of widgets such as buttons, sliders or images\&.
.IP "\(bu" 2
\fIlist\fP: the main \fIsections\fP of the fsm (finite state machine) constitute a list of at least four elements, each of which defines a set of possible states :
.IP " 1." 6
execute or edit (managing the appropriate tools states in both cases)
.IP " 2." 6
measure, operate on data, prepare displayable results
.IP " 3." 6
apply user preferences
.IP " 4." 6
indicate the desired state of windows and widgets
.PP
The state of the fsm is uniquely defined at all times by all the parameters listed in these sections\&. All program actions depend on this state\&.
.IP "\(bu" 2
\fItransversal\fP: the other functions that must be easily accessible by all the previous functions\&. They are therefore all located at the root\&. These are the functions that manage graphics, callbacks, utilities and the log\&.
.PP
.PP .PP
.PP .PP

2
doc/rtfm/man3/readme.dox.3
View File

@ -11,6 +11,8 @@ doc/readme.dox \- Gem-graph-client doc \fBreadme\&.dox\fP file\&.
.PP .PP
Gem-graph-client doc \fBreadme\&.dox\fP file\&. Gem-graph-client doc \fBreadme\&.dox\fP file\&.
(the \&.c extension is just crap)
.PP
This file is part of Gem-graph\&. This file is part of Gem-graph\&.
.PP .PP
The code files are all located in the src (sources) directory (the headers in 'include')\&. They are divided into several \fBtypes of organisation\fP: The code files are all located in the src (sources) directory (the headers in 'include')\&. They are divided into several \fBtypes of organisation\fP:

10
doc/rtfm/man3/readme.dox.c.3
View File

@ -2,23 +2,21 @@
.ad l .ad l
.nh .nh
.SH NAME .SH NAME
src/widget/readme.dox.c \- Gem-graph-client widget \fBreadme\&.dox\fP file\&. src/widget/readme.dox.c \- Gem-graph-client xxxxx readme\&.dox file (NB -> The \&.c extension is just crap)\&.
.SH SYNOPSIS .SH SYNOPSIS
.br .br
.PP .PP
.SH "Detailed Description" .SH "Detailed Description"
.PP .PP
Gem-graph-client widget \fBreadme\&.dox\fP file\&. Gem-graph-client xxxxx readme\&.dox file (NB -> The \&.c extension is just crap)\&.
(the \&.c extension is just crap)
.PP
This file is part of Gem-graph\&. This file is part of Gem-graph\&.
.PP .PP
The code files are all located in the src (sources) directory (the headers in 'include')\&. They are divided into several \fBtypes of organisation\fP: The code files are all located in the src (sources) directory They are divided into several \fBtypes of organisation\fP:
.PP .PP
.IP "\(bu" 2 .IP "\(bu" 2
\fIhierarchical\fP: the widgets that give the windows their appearance are organised in the form of a tree\&. Windows are the first level of depth\&. Next come the title bar and the pages designed to occupy the window space below the title bar\&. Each of these pages has its own hierarchical structure: it can be divided into horizontal or vertical strips, which can themselves be divided in the same way, with varying levels of depth right down to the last boxes, which contain lists of widgets such as buttons, sliders or images\&. \fIhierarchical\fP: the widgets that give the windows their appearance are organised in the form of a tree\&. Windows are the first level of depth\&. Next come the title bars and the pages designed to occupy the windows space below the title bars\&. Each of these pages has its own hierarchical structure: it can be divided into horizontal or vertical strips, which can themselves be divided in the same way, with varying levels of depth right down to the last containers which contain lists of widgets such as buttons, bars, entries or images\&.
.IP "\(bu" 2 .IP "\(bu" 2
\fIlist\fP: the main \fIsections\fP of the fsm (finite state machine) constitute a list of at least four elements, each of which defines a set of possible states : \fIlist\fP: the main \fIsections\fP of the fsm (finite state machine) constitute a list of at least four elements, each of which defines a set of possible states :
.IP " 1." 6 .IP " 1." 6

179
src/main.c
View File

@ -10,40 +10,12 @@
* the application and the windows and **closes** all the elements it opened * the application and the windows and **closes** all the elements it opened
* before the end of program execution. * before the end of program execution.
* *
* By default, the main window opens on the overview page of the current model * The default values of the fsm initial state are specified in:
* src/fsm/dispatch() lines 287-288 (user preferences are not more detailed)
* and, in accordance, the overview page of the current model is displayed
* as specified in: src/widget/main_window/designer/widget_design_main_window(). * as specified in: src/widget/main_window/designer/widget_design_main_window().
* *
* --- * About code organization, see src/readme.dox
*
* The code files are all located in the src (sources) directory
* (the headers in 'include').
* They are divided into several **types of organisation**:
*
* - *hierarchical*: the widgets that give the windows their appearance are
* organised in the form of a tree.
* Windows are the first level of depth.
* Next come the title bar and the pages designed to occupy the window space
* below the title bar.
* Each of these pages has its own hierarchical structure: it can be divided
* into horizontal or vertical strips, which can themselves be divided in the
* same way, with varying levels of depth right down to the last boxes, which
* contain lists of widgets such as buttons, sliders or images.
*
* - *list*: the main *sections* of the fsm (finite state machine) constitute
* a list of at least four elements, each of which defines a set of possible
* states :
* -# execute or edit (managing the appropriate tools states in both cases)
* -# measure, operate on data, prepare displayable results
* -# apply user preferences
* -# indicate the desired state of windows and widgets
* .
* The state of the fsm is uniquely defined at all times by all the parameters
* listed in these sections. All program actions depend on this state.
*
* - *transversal*: the other functions that must be easily accessible by all
* the previous functions. They are therefore all located at the root.
* These are the functions that manage graphics, callbacks, utilities
* and the log.
* *
* --- * ---
* *
@ -110,146 +82,3 @@ int main (int argc, char **argv)
return status; return status;
} }
//----------------------------- personal notes ---------------------------
// TODO (ranger ça !)
/*
* 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
*
*
* ORGANISATION ACTUELLE (Octobre 2024)
*
* 1) Les structures hierarchiques.
* --------------------------------
*
* La description du 'design' des fenêtres se trouve dans le dossier 'widget'
* et s'organise naturellement en arborescence,
* en se calquant sur l'arborescence des 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.)
* (nom provisoire : mal défini à ce stade; fonctions à répartir...)
*
* 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', 'prefer',
* et peut-être des structures communes à tous les arbres, listes, etc.
* 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...
*
*
* Leur recueil et la mémorisation des préférences des utilisateurs
* sont des fonctions centrales
* mais leur mise en oeuvre suivra probalement des 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') ?
*/
/*
2024-08-31 Un point sur l'état d'avancement du client:
TODO (bottlenecks)
- images (++)
- arbres (et listes) (++)
- logging (ref : /var/log/messages)
- menus (pas indispensables à ce stade))
À redéfinir: répartition des tâches (mesures) client/serveur.
Comment traiter le cas extrême où *toutes* les règles
sont des règles d'intérêt ?
(cas d'une erreur rare, non systématique où il faut "remonter le temps",
pas à pas, à partir du premier état qui met l'erreur en évidence)
Pour effectuer cette "remontée", il faut une liste complète
de toutes les règles appliquées.
Cette liste doit comporter, pour chaque item (= chaque exécution d'une règle):
- identité de la règle
- lieu d'exécution (dans l'espace global)
- date d'exécution
NB Il ne peut y avoir d'ambiguité ou d'erreur due au parallélisme
car, si les espaces locaux de deux exécutions de règles se recouvrent,
elles ne peuvent avoir été exécutées simultanément.
À mon avis, le serveur ne peut effectuer cette tâche car
la "remontée dans le temps" nécessite l'inspection 'de visu' de chaque état.
Inspection veut dire ici: reconnaissance de formes
et ce travail (visuel) ne peut être pré-programmé
(bien qu'il doive être systématique), car le concepteur du modèle
ne sait pas quelle est l'erreur et ne peut prévoir ce qu'il va découvrir.
Ceci n'exclut pas qu'il puisse - qu'il doive - effectuer plusieurs essais
(de "remontée dans le temps") en sélectionnant, par exemple,
différentes règles d'intérêt à chaque fois
ni qu'il puisse se programmer des outils d'aide
(mais tout ceci ne semble pas avoir sa place dans le serveur).
NB À ce stade de la conception d'un modèle, les erreurs sont encore fréquentes
et les 'runs' sont nécessairement de brève durée.
Des 'runs' de longue durée n'ont de sens qu'une fois ce débuggage effectué.
Il y a donc peu de problèmes à craindre du fait de la limite de la bande passante.
*/

23
doc/readme.dox → src/readme.dox.c
View File

@ -1,23 +1,21 @@
/** /**
* @page
* @file * @file
* Gem-graph-client doc readme.dox file. (the .c extension is just crap) * @brief Gem-graph-client src readme.dox file (NB -> The .c extension is just crap).
* *
* This file is part of Gem-graph. * @details This file is part of Gem-graph.
* *
* The code files are all located in the src (sources) directory * The code files are all located in the src (sources) directory
* (the headers in 'include'). * They are divided into several *types of organisation*:
* They are divided into several **types of organisation**:
* *
* - *hierarchical*: the widgets that give the windows their appearance are * - *hierarchical*: the widgets that give the windows their appearance are
* organised in the form of a tree. * organised in the form of a tree.
* Windows are the first level of depth. * Windows are the first level of depth.
* Next come the title bar and the pages designed to occupy the window space * Next come the title bars and the pages designed to occupy the windows
* below the title bar. * space below the title bars.
* Each of these pages has its own hierarchical structure: it can be divided * Each of these pages has its own hierarchical structure: it can be divided
* into horizontal or vertical strips, which can themselves be divided in the * into horizontal or vertical strips, which can themselves be divided in the
* same way, with varying levels of depth right down to the last boxes, which * same way, with varying levels of depth right down to the last containers
* contain lists of widgets such as buttons, sliders or images. * which contain lists of widgets such as buttons, bars, entries or images.
* *
* - *list*: the main *sections* of the fsm (finite state machine) constitute * - *list*: the main *sections* of the fsm (finite state machine) constitute
* a list of at least four elements, each of which defines a set of possible * a list of at least four elements, each of which defines a set of possible
@ -37,6 +35,11 @@
* *
* --- * ---
* *
* @see
* Model–view–controller || Model–view–viewmodel || Action–domain–responder ||
* Multitier_architecture https://en.wikipedia.org/wiki/Multitier_architecture
* (presentation, logic, data)
*
* @cond LICENSE * @cond LICENSE
* Copyright © 2021 Libre en Communs <contact@a-lec.org> * Copyright © 2021 Libre en Communs <contact@a-lec.org>
* Copyright © 2021-2024 Adrien Bourmault <neox@a-lec.org> * Copyright © 2021-2024 Adrien Bourmault <neox@a-lec.org>
@ -55,4 +58,4 @@
* You should have received a copy of the GNU Affero General Public License * 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/>. * along with this program. If not, see <http://www.gnu.org/licenses/>.
* @endcond * @endcond
*/ */

12
src/widget/readme.dox.c
View File

@ -1,23 +1,21 @@
/** /**
* @page
* @file * @file
* Gem-graph-client widget readme.dox file. (the .c extension is just crap) * Gem-graph-client xxxxx readme.dox file (NB -> The .c extension is just crap).
* *
* This file is part of Gem-graph. * This file is part of Gem-graph.
* *
* The code files are all located in the src (sources) directory * The code files are all located in the src (sources) directory
* (the headers in 'include').
* They are divided into several **types of organisation**: * They are divided into several **types of organisation**:
* *
* - *hierarchical*: the widgets that give the windows their appearance are * - *hierarchical*: the widgets that give the windows their appearance are
* organised in the form of a tree. * organised in the form of a tree.
* Windows are the first level of depth. * Windows are the first level of depth.
* Next come the title bar and the pages designed to occupy the window space * Next come the title bars and the pages designed to occupy the windows
* below the title bar. * space below the title bars.
* Each of these pages has its own hierarchical structure: it can be divided * Each of these pages has its own hierarchical structure: it can be divided
* into horizontal or vertical strips, which can themselves be divided in the * into horizontal or vertical strips, which can themselves be divided in the
* same way, with varying levels of depth right down to the last boxes, which * same way, with varying levels of depth right down to the last containers
* contain lists of widgets such as buttons, sliders or images. * which contain lists of widgets such as buttons, bars, entries or images.
* *
* - *list*: the main *sections* of the fsm (finite state machine) constitute * - *list*: the main *sections* of the fsm (finite state machine) constitute
* a list of at least four elements, each of which defines a set of possible * a list of at least four elements, each of which defines a set of possible