Compare commits
3 Commits
3edeb139bb
...
74894b5253
Author | SHA1 | Date |
---|---|---|
Jean Sirmai | 74894b5253 | |
Jean Sirmai | 4d97b5328e | |
Jean Sirmai | 4ce6443e39 |
|
@ -403,7 +403,7 @@ MARKDOWN_ID_STYLE = DOXYGEN
|
||||||
# globally by setting AUTOLINK_SUPPORT to NO.
|
# globally by setting AUTOLINK_SUPPORT to NO.
|
||||||
# The default value is: YES.
|
# The default value is: YES.
|
||||||
|
|
||||||
AUTOLINK_SUPPORT = YES
|
AUTOLINK_SUPPORT = NO
|
||||||
|
|
||||||
# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
|
# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
|
||||||
# to include (a tag file for) the STL sources as input, then you should set this
|
# to include (a tag file for) the STL sources as input, then you should set this
|
||||||
|
@ -565,7 +565,7 @@ EXTRACT_PACKAGE = NO
|
||||||
# included in the documentation.
|
# included in the documentation.
|
||||||
# The default value is: NO.
|
# The default value is: NO.
|
||||||
|
|
||||||
EXTRACT_STATIC = NO
|
EXTRACT_STATIC = YES
|
||||||
|
|
||||||
# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined
|
# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined
|
||||||
# locally in source files will be included in the documentation. If set to NO,
|
# locally in source files will be included in the documentation. If set to NO,
|
||||||
|
@ -573,7 +573,7 @@ EXTRACT_STATIC = NO
|
||||||
# for Java sources.
|
# for Java sources.
|
||||||
# The default value is: YES.
|
# The default value is: YES.
|
||||||
|
|
||||||
EXTRACT_LOCAL_CLASSES = YES
|
EXTRACT_LOCAL_CLASSES = NO
|
||||||
|
|
||||||
# This flag is only useful for Objective-C code. If set to YES, local methods,
|
# This flag is only useful for Objective-C code. If set to YES, local methods,
|
||||||
# which are defined in the implementation section but not in the interface are
|
# which are defined in the implementation section but not in the interface are
|
||||||
|
@ -614,7 +614,7 @@ HIDE_UNDOC_MEMBERS = NO
|
||||||
# if EXTRACT_ALL is enabled.
|
# if EXTRACT_ALL is enabled.
|
||||||
# The default value is: NO.
|
# The default value is: NO.
|
||||||
|
|
||||||
HIDE_UNDOC_CLASSES = NO
|
HIDE_UNDOC_CLASSES = YES
|
||||||
|
|
||||||
# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
|
# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
|
||||||
# declarations. If set to NO, these declarations will be included in the
|
# declarations. If set to NO, these declarations will be included in the
|
||||||
|
|
|
@ -24,7 +24,8 @@
|
||||||
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
|
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
|
||||||
|
|
||||||
|
|
||||||
|
This dossier gives you information on how to make the best use of doc.
|
||||||
|
(a few tips for personalising it)
|
||||||
|
|
||||||
|
|
||||||
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
|
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
|
||||||
|
|
|
@ -1,34 +0,0 @@
|
||||||
Welcome to Gem-graph !
|
|
||||||
|
|
||||||
Gem-graph lets you move or transform drawn objects and can be used in all cases where drawings, designs or patterns are useful. You can draw anything you like. You can make it move or transform as you like. It is your design and you decide how you want it to evolve! You can use it to make a game. You can use it to make an animated representation (a model) of a phenomenon that interests you. You can represent what you want simply or in more realistic detail. Simple parts and more detailed parts can coexist in the same design. You can watch what you have created evolve without interfering or guiding it towards what you want to achieve. You can observe it in detail, go back, start again, measure, compare and keep the results that interest you so that you can play them again.
|
|
||||||
|
|
||||||
However, a certain amount of effort may be required to achieve the desired results. A complicated model will require more work than a simpler one, but it is possible to start with something simple and develop it step by step. In any case, you must draw what you want to see and say how you want it to move. Gem-graph cannot do that for you. Gem-graph can only help you to draw up and develop your idea. However, it can give you powerful tools to do so. All this is possible because the drawings that gem-graph manipulates are made up of very simple elements, all similar, driven by simple rules that can therefore be processed automatically. The tools provided by gem-graph give you access to the power of the automaton it uses to draw and animate your drawings, and this manual is here to help you to learn how to master them.
|
|
||||||
|
|
||||||
One way of doing this is to reproduce a very simple example, such as when a word processing program asks you to write "Hello world". For gem-graph, the equivalent of "Hello world" will be to move a small line on your screen. Once you have done this simple example, you will know enough to quickly build and animate much more complex drawings that suit your desires. If you like learning this way, this example is explained (here). If you prefer to learn by reading what the commands you see on the screen are doing, they have been detailed (here). The table of contents goes from the simplest to the most complicated. How to set up a simple model, observe it and measure what it does, then transform it by changing what you see and how it reacts.
|
|
||||||
|
|
||||||
------------
|
|
||||||
|
|
||||||
Our "Hello world" is the simplest program that gem-graph can execute. It consists of a single short arrow, which moves in a straight line in a single direction. To do this, we first had to draw this little arrow and then make it move. The result is certainly not very exciting, but this example is enough to show how a drawing is made and how it is animated. One state and one rule are enough. The rule only says: if an arrow is drawn here, I erase it and redraw it on the next square. For the moment, you don't need to know in detail how the rule works (it's described here). All that gem-graph needs to know is written in the "Hello world" file (here). If you open this file, you'll find a description of the arrow (here) and its movement (here).
|
|
||||||
|
|
||||||
------------
|
|
||||||
|
|
||||||
To improve this model, it is possible to give the arrow the ability to move in two directions: forwards or backwards. To do this, we need to add a second rule. This second rule says: if an arrow is drawn here, I erase it and redraw it on the previous square. A random draw (described here) is also necessary to determine whether the first or second rule applies. With these two rules and the random draw, the arrow now sometimes goes forwards, sometimes backwards. We can call this second model a "random walk".
|
|
||||||
|
|
||||||
------------
|
|
||||||
|
|
||||||
The second model (the random walk) had one state (the arrow) and two rules (forward/backward). Now here's a model with two states and two rules: the pendulum. This time, the arrow can be drawn either tilted forwards or tilted backwards (these are the two possible states) and the two rules switch the drawn arrow from one state to the other or vice versa. In the file, the states are (here) and the rules (here). The pendulum does not change place, but alternates between left and right. Like the previous ones, the programme is slowed down so that you can see the movements.
|
|
||||||
|
|
||||||
------------
|
|
||||||
|
|
||||||
Once you know how to write a state and a rule, you can write thousands of them: they will always be combinations of the same elementary form. However, it is also possible to combine programs: for example, you can combine the reports and rules from the two previous models to create a new model that shows both phenomena simultaneously. Once again, in the file, the states are (here) and the rules (here).
|
|
||||||
|
|
||||||
------------
|
|
||||||
|
|
||||||
A final simple example shows how a single rule can be applied to a multitude of states. The rule is the same as for the first model: an arrow can only be moved one square forward, but this time you have to check that the square forward is free. If it isn't, the arrow won't move. And this time, the space contains a multitude of arrows that have been randomly placed all over the place (see details here).
|
|
||||||
When you open this model, you see a multitude of small lines, all similar, some vertical, some horizontal, placed on a grid. When you set the model in motion, you see these little lines moving from left to right if they are horizontal, and up and down if they are vertical (a second rule vas added to do that). Their number is constant. They don't change shape or direction. There seems to be no accident when they cross. Nothing else happens.
|
|
||||||
|
|
||||||
------------
|
|
||||||
|
|
||||||
These five examples give an initial idea of the diversity of possible models and the operations that can be performed on them.
|
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,143 @@
|
||||||
|
Welcome to Gem-graph !
|
||||||
|
|
||||||
|
Gem-graph lets you move and transform drawn objects using an automaton. It's an
|
||||||
|
ideal tool for describing the evolution of a situation through drawing. Would
|
||||||
|
you like to see your drawings evolve automatically to represent a phenomenon?
|
||||||
|
Gem-graph lets you transform your drawings as you wish. You can draw whatever
|
||||||
|
you want. It's your drawing and you decide how it evolves! You can use gem-graph
|
||||||
|
to make a game. You can use it to make a model of a phenomenon that interests you.
|
||||||
|
You can represent what you want simply or in more realistic detail.
|
||||||
|
Simple parts and more detailed parts can coexist in the same design. You can
|
||||||
|
watch what you have created evolve without interfering or guiding it towards what
|
||||||
|
you want to achieve. You can mix several drawings and animations. You can observe
|
||||||
|
them in detail, modify them, go back, start again, measure, compare and keep the
|
||||||
|
results that interest you so that you can play them again.
|
||||||
|
|
||||||
|
However, a certain amount of effort will be required to achieve this. A complicated
|
||||||
|
model will require more work than a simpler one, but it is possible to start with
|
||||||
|
something simple and develop it step by step. In any case, you must draw what you
|
||||||
|
want to see and say how you want it to be transformed. Gem-graph cannot do that
|
||||||
|
for you. Gem-graph can only help you to draw up and develop your idea. However,
|
||||||
|
it can give you powerful tools to do so. The strength of gem-graph - short for
|
||||||
|
'geometric graph' - lies in the fact that it deals only with very simple drawing
|
||||||
|
elements, all of which are similar, and that the rules it uses to manipulate these
|
||||||
|
elements are equally simple and similar. As a result, these rules can be combined
|
||||||
|
and processed automatically, no matter how many there are. The tools provided by
|
||||||
|
gem-graph give you access to the power of the automaton it uses to draw and animate
|
||||||
|
your drawings, and this manual is here to help you to learn how to master them.
|
||||||
|
|
||||||
|
One way of doing this is to reproduce a very simple example, such as when a word
|
||||||
|
processing program asks you to write "Hello world". For gem-graph, the equivalent
|
||||||
|
of "Hello world" will be to move a small line on your screen. Once you have done
|
||||||
|
this simple example, you will know enough to quickly build and animate much more
|
||||||
|
complex drawings that suit your desires. If you like learning this way, this
|
||||||
|
example is explained (here). If you prefer to learn by reading what the commands
|
||||||
|
you see on the screen are doing, they have been detailed (here). The table of
|
||||||
|
contents goes from the simplest to the most complicated. How to set up a simple
|
||||||
|
model, observe it and measure what it does, then transform it by changing what
|
||||||
|
you see and how it reacts.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
Our "Hello world" is the simplest program that gem-graph can execute. It consists
|
||||||
|
of a single short arrow, which moves in a straight line in a single direction.
|
||||||
|
To do this, we first had to draw this little arrow and then make it move. The
|
||||||
|
result is certainly not very exciting, but this example is enough to show how a
|
||||||
|
drawing is made and how it is animated. One state and one rule are enough. The
|
||||||
|
rule only says: if an arrow is drawn here, I erase it and redraw it on the next
|
||||||
|
square. For the moment, you don't need to know in detail how the rule works
|
||||||
|
(it's described here). All that gem-graph needs to know is written in the
|
||||||
|
"Hello world" file (here). If you open this file, you'll find a description of
|
||||||
|
the arrow (here) and its movement (there).
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
To improve this model, it is possible to give the arrow the ability to move in
|
||||||
|
two directions: forwards or backwards. To do this, we need to add a second rule.
|
||||||
|
This second rule says: if an arrow is drawn here, I erase it and redraw it on the
|
||||||
|
previous square. A random draw (described here) is also necessary to determine
|
||||||
|
whether the first or second rule applies. With these two rules and the random
|
||||||
|
draw, the arrow now sometimes goes forwards, sometimes backwards. We can call
|
||||||
|
this second model a "random walk".
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
The second model (the random walk) had one state (the arrow) and two rules
|
||||||
|
(forward/backward). Now here's a model with two states and two rules:
|
||||||
|
the pendulum. This time, the arrow can be drawn either tilted forwards or tilted
|
||||||
|
backwards (these are the two possible states) and the two rules switch the drawn
|
||||||
|
arrow from one state to the other or vice versa. In the file, the states are (here)
|
||||||
|
and the rules (here). The pendulum does not change place, but alternates between
|
||||||
|
left and right. Like the previous ones, you can slow down the programme so that
|
||||||
|
you can observe the movements.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
Once you know how to write a state and a rule, you can write thousands of them:
|
||||||
|
they will always be combinations of the same elementary form. However, it is also
|
||||||
|
possible to combine programs: for example, you can combine the reports and rules
|
||||||
|
from the two previous models to create a new model that shows both phenomena
|
||||||
|
simultaneously. Once again, in the file, the states are (here) and the rules
|
||||||
|
(here).
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
The next example shows how the same rule can be applied to a multitude of states.
|
||||||
|
The rule is the same as that used in the first model: an arrow can only be moved
|
||||||
|
one square forward, but this time you have to check that the square forward is
|
||||||
|
free. If it isn't, the arrow won't move. Once the rule has been modified in this
|
||||||
|
way, it can be applied to a multitude of arrows distributed randomly in space
|
||||||
|
(see details here).
|
||||||
|
When you set the model in motion, you will see all these small lines moving from
|
||||||
|
left to right. A single rule is responsible for all these movements.
|
||||||
|
For a small fee, we can apply the two rules of the 'random walk' model to all the
|
||||||
|
arrows distributed in this space, and they will then all behave in the same way,
|
||||||
|
sometimes moving forwards, sometimes backwards.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
|
||||||
|
In the next example, we first build a model similar to the previous one: a
|
||||||
|
multitude of arrows are randomly distributed in space, but this time they are
|
||||||
|
vertical and the movements are up and down instead of right and left. Then, we
|
||||||
|
add this model to the previous state and set the final model in motion. We see
|
||||||
|
then little lines moving from left to right or reverse if they are horizontal,
|
||||||
|
and up and down or reverse if they are vertical. Their number is constant. They
|
||||||
|
don't change shape or direction. There seems to be no accident when they cross.
|
||||||
|
Nothing else happens.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
The last example in this series, because it shows a multitude of diverse and
|
||||||
|
simultaneous movements, perhaps gives the impression of a more complex system.
|
||||||
|
It would be easy to make it even more complex, but it's much more interesting
|
||||||
|
to show how gem-graph can be used to analyse and control that complexity (here). At
|
||||||
|
this point, it's time to compare gem-graph to other classes of automata that do
|
||||||
|
quite similar things, and to look at what it can actually do and what its
|
||||||
|
limitations are.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
The main difference between gem-graph models and agent-based models is that
|
||||||
|
gem-graph deals with situations, not agents. In a situation where several agents
|
||||||
|
are interacting and each agent could apply a different rule, gem-graph considers
|
||||||
|
and processes the situation. Not the agents. Whatever the state - the new
|
||||||
|
situation - that results from his action, his decision-making process will have
|
||||||
|
been simple and straightforward. It will therefore be easy to modify and control.
|
||||||
|
And the diversity of possible new situations will be far greater than that
|
||||||
|
offered by agent-based models.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
The comparison between gem-graphs and cellular automata first comes up against
|
||||||
|
a question of vocabulary. What is commonly called a 'rule' in one and the other
|
||||||
|
is not the same thing. Gem-graphs and cellular automata have the same power:
|
||||||
|
anything that can be done by one can be done by the other, but their writing is
|
||||||
|
not the same (details of this comparison here).
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
How can gem-graph be used to analyse and control the complexity of what it
|
||||||
|
represents and sets in motion? This chapter introduces the gem-graph mechanism.
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,51 @@
|
||||||
|
Welcome to Gem-graph !
|
||||||
|
|
||||||
|
Gem-graph lets you move and transform drawn objects using an automaton. It's an ideal tool for describing the evolution of a situation through drawing. Would you like to see your drawings evolve automatically to represent a phenomenon? Gem-graph lets you transform your drawings as you wish. You can draw whatever you want. It's your drawing and you decide how it evolves! You can use gem-graph to make a game. You can use it to make a model of a phenomenon that interests you. You can represent what you want simply or in more realistic detail. Simple parts and more detailed parts can coexist in the same design. You can watch what you have created evolve without interfering or guiding it towards what you want to achieve. You can mix several drawings and animations. You can observe them in detail, modify them, go back, start again, measure, compare and keep the results that interest you so that you can play them again.
|
||||||
|
|
||||||
|
However, a certain amount of effort will be required to achieve this. A complicated model will require more work than a simpler one, but it is possible to start with something simple and develop it step by step. In any case, you must draw what you want to see and say how you want it to be transformed. Gem-graph cannot do that for you. Gem-graph can only help you to draw up and develop your idea. However, it can give you powerful tools to do so. The strength of gem-graph - short for 'geometric graph' - lies in the fact that it deals only with very simple drawing elements, all of which are similar, and that the rules it uses to manipulate these elements are equally simple and similar. As a result, these rules can be combined and processed automatically, no matter how many there are. The tools provided by gem-graph give you access to the power of the automaton it uses to draw and animate your drawings, and this manual is here to help you to learn how to master them.
|
||||||
|
|
||||||
|
One way of doing this is to reproduce a very simple example, such as when a word processing program asks you to write "Hello world". For gem-graph, the equivalent of "Hello world" will be to move a small line on your screen. Once you have done this simple example, you will know enough to quickly build and animate much more complex drawings that suit your desires. If you like learning this way, this example is explained (here). If you prefer to learn by reading what the commands you see on the screen are doing, they have been detailed (here). The table of contents goes from the simplest to the most complicated. How to set up a simple model, observe it and measure what it does, then transform it by changing what you see and how it reacts.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
Our "Hello world" is the simplest program that gem-graph can execute. It consists of a single short arrow, which moves in a straight line in a single direction. To do this, we first had to draw this little arrow and then make it move. The result is certainly not very exciting, but this example is enough to show how a drawing is made and how it is animated. One state and one rule are enough. The rule only says: if an arrow is drawn here, I erase it and redraw it on the next square. For the moment, you don't need to know in detail how the rule works (it's described here). All that gem-graph needs to know is written in the "Hello world" file (here). If you open this file, you'll find a description of the arrow (here) and its movement (there).
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
To improve this model, it is possible to give the arrow the ability to move in two directions: forwards or backwards. To do this, we need to add a second rule. This second rule says: if an arrow is drawn here, I erase it and redraw it on the previous square. A random draw (described here) is also necessary to determine whether the first or second rule applies. With these two rules and the random draw, the arrow now sometimes goes forwards, sometimes backwards. We can call this second model a "random walk".
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
The second model (the random walk) had one state (the arrow) and two rules (forward/backward). Now here's a model with two states and two rules: the pendulum. This time, the arrow can be drawn either tilted forwards or tilted backwards (these are the two possible states) and the two rules switch the drawn arrow from one state to the other or vice versa. In the file, the states are (here) and the rules (here). The pendulum does not change place, but alternates between left and right. Like the previous ones, you can slow down the programme so that you can observe the movements.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
Once you know how to write a state and a rule, you can write thousands of them: they will always be combinations of the same elementary form. However, it is also possible to combine programs: for example, you can combine the reports and rules from the two previous models to create a new model that shows both phenomena simultaneously. Once again, in the file, the states are (here) and the rules (here).
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
The next example shows how the same rule can be applied to a multitude of states. The rule is the same as that used in the first model: an arrow can only be moved one square forward, but this time you have to check that the square forward is free. If it isn't, the arrow won't move. Once the rule has been modified in this way, it can be applied to a multitude of arrows distributed randomly in space (see details here).
|
||||||
|
When you set the model in motion, you will see all these small lines moving from left to right. A single rule is responsible for all these movements.
|
||||||
|
For a small fee, we can apply the two rules of the 'random walk' model to all the arrows distributed in this space, and they will then all behave in the same way, sometimes moving forwards, sometimes backwards.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
|
||||||
|
In the next example, we first, we build a model similar to the previous one: a multitude of arrows are randomly distributed in space, but this time they are vertical and the movements are up and down instead of right and left. Then, we add this model to the previous state and set the final model in motion. We see then little lines moving from left to right or reverse if they are horizontal, and up and down or reverse if they are vertical. Their number is constant. They don't change shape or direction. There seems to be no accident when they cross. Nothing else happens.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
The last example in this series, because it shows a multitude of diverse and simultaneous movements, perhaps gives the impression of a more complex system. It would be easy to make it even more complex, but it's much more interesting to show how gem-graph can be used to analyse and control that complexity. At this point, it's time to compare gem-graph to other classes of automata that do quite similar things, and to look at what it can actually do and what its limitations are.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
The main difference between gem-graph models and agent-based models is that gem-graph deals with situations, not agents. In a situation where several agents are interacting and each agent could apply a different rule, gem-graph considers and processes the situation. Not the agents. Whatever the state - the new situation - that results from his action, his decision-making process will have been simple and straightforward. It will therefore be easy to modify and control. And the diversity of possible new situations will be far greater than that offered by agent-based models.
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
The comparison between gem-graphs and cellular automata first comes up against a question of vocabulary. What is commonly called a 'rule' in one and the other is not the same thing. Gem-graphs and cellular automata have the same power: anything that can be done by one can be done by the other, but their writing is not the same (details of this comparison here).
|
||||||
|
|
||||||
|
------------
|
||||||
|
|
||||||
|
How can gem-graph be used to analyse and control the complexity of what it represents and sets in motion? This chapter introduces the gem-graph mechanism.
|
||||||
|
|
|
@ -1,18 +1,29 @@
|
||||||
/**
|
/**
|
||||||
* @file
|
* @file
|
||||||
* Fsm (finite state machine) header
|
* Client fsm (finite state machine) header
|
||||||
*
|
*
|
||||||
* This file is part of Gem-graph.
|
* This file is part of Gem-graph.
|
||||||
*
|
*
|
||||||
*
|
*
|
||||||
* This commit introduces the functions that the log needs.
|
* This commit introduces:
|
||||||
|
*
|
||||||
|
* - the two functions that enable main() to init and close the log:
|
||||||
|
* fsm_trigger_log_init() and fsm_trigger_log_close()
|
||||||
|
*
|
||||||
|
* - the two functions that enable main() to init and close the fsm:
|
||||||
|
* fsm_init() and fsm_close()
|
||||||
|
*
|
||||||
|
* - the two functions that enable the fsm to init and close its structures:
|
||||||
|
* fsm_structures_init() and fsm_structures_close()
|
||||||
|
*
|
||||||
|
*
|
||||||
* @see readme.docs and this text below.
|
* @see readme.docs and this text below.
|
||||||
*
|
*
|
||||||
* ---
|
* ---
|
||||||
*
|
*
|
||||||
* The two structures and the two enums listed below will stay in the fsm header.
|
* The two log structures and the two enums listed below stay in the fsm header.
|
||||||
*
|
*
|
||||||
* All functions are now in dedicated files.
|
* All log functions are now in dedicated files.
|
||||||
*
|
*
|
||||||
* The most important function: fsm_add_log() is in the file:
|
* The most important function: fsm_add_log() is in the file:
|
||||||
* /src/fsm/log/manager.c
|
* /src/fsm/log/manager.c
|
||||||
|
@ -104,7 +115,7 @@
|
||||||
* https://en.wikipedia.org/wiki/Syslog
|
* https://en.wikipedia.org/wiki/Syslog
|
||||||
*
|
*
|
||||||
* All logs must contain at least one item from this enum and only one.
|
* All logs must contain at least one item from this enum and only one.
|
||||||
* This item can not be set to NULL.
|
* This item can NOT be set to NULL.
|
||||||
*
|
*
|
||||||
* @see fsm_add_log()
|
* @see fsm_add_log()
|
||||||
*/
|
*/
|
||||||
|
@ -244,4 +255,10 @@ void fsm_add_log (int severity,
|
||||||
const char *function_source,
|
const char *function_source,
|
||||||
const char *string_value);
|
const char *string_value);
|
||||||
|
|
||||||
|
void fsm_trigger_log_init();
|
||||||
|
void fsm_trigger_log_close();
|
||||||
|
|
||||||
|
void fsm_init (const char *initial_message_from_main);
|
||||||
|
void fsm_close (const char *final_message_from_main);
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,214 @@
|
||||||
|
/**
|
||||||
|
* @file
|
||||||
|
* Client fsm (Finite State Machine) control file.
|
||||||
|
*
|
||||||
|
* ---
|
||||||
|
*
|
||||||
|
* The fsm control instance
|
||||||
|
* - **initialises** the log and the rest of the fsm when triggered by main()
|
||||||
|
* - **checks** all triggered operations and **allocates** them if they are valid
|
||||||
|
* - **closes** all the elements it opened before handing over to main()
|
||||||
|
* .
|
||||||
|
*
|
||||||
|
* About code organization, see src/readme.dox
|
||||||
|
*
|
||||||
|
* ---
|
||||||
|
*
|
||||||
|
* @cond LICENSE
|
||||||
|
* Copyright © 2021 Libre en Communs <contact@a-lec.org>
|
||||||
|
* Copyright © 2021-2024 Adrien Bourmault <neox@a-lec.org>
|
||||||
|
* Copyright © 2021-2024 Jean Sirmai <jean@a-lec.org>
|
||||||
|
*
|
||||||
|
* 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/>.
|
||||||
|
* @endcond
|
||||||
|
*
|
||||||
|
* @file
|
||||||
|
* @brief
|
||||||
|
*
|
||||||
|
* This file is part of Gem-graph.
|
||||||
|
*
|
||||||
|
* @details
|
||||||
|
* The Finite State Machine (fsm) describes all the possible states of the
|
||||||
|
* Gem-graph client and all the transitions between them.
|
||||||
|
* It manages several kinds of exclusive states:
|
||||||
|
* - Run the model or edit it.
|
||||||
|
* - Select a single view of the model from all those possible.
|
||||||
|
* The different views show either the space, or the rule tree,
|
||||||
|
* or a single rule of interest, or measurements or results.
|
||||||
|
* NB an overview is possible, but it does not provide details.
|
||||||
|
* - Apply a selected measurement to the currently running model
|
||||||
|
* - Select some results for study or/and presentation.
|
||||||
|
* - Choose the user's preferred values for a set of parameters
|
||||||
|
* used to modify the appearance or behaviour of gem-graph.
|
||||||
|
*
|
||||||
|
* Each state of the fsm is a combination of each of these states.
|
||||||
|
*
|
||||||
|
* The current state of the fsm must be
|
||||||
|
* - saved at the end of a work session and
|
||||||
|
* - reread (available to the user) at the start of a new session.
|
||||||
|
*
|
||||||
|
* No state of the fsm should be defined in another module.
|
||||||
|
*
|
||||||
|
* No fsm transition should be executed in another module.
|
||||||
|
*
|
||||||
|
* The journal is created, edited and published from here.
|
||||||
|
*
|
||||||
|
* @cond LICENSE
|
||||||
|
* Copyright © 2021 Libre en Communs <contact@a-lec.org>
|
||||||
|
* Copyright © 2021-2024 Adrien Bourmault <neox@a-lec.org>
|
||||||
|
* Copyright © 2021-2024 Jean Sirmai <jean@a-lec.org>
|
||||||
|
*
|
||||||
|
* 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/>.
|
||||||
|
* @endcond
|
||||||
|
*/
|
||||||
|
|
||||||
|
|
||||||
|
#include "../../include/fsm.h"
|
||||||
|
|
||||||
|
|
||||||
|
/**
|
||||||
|
* Initiates the four lists:
|
||||||
|
* 'measures', 'results', 'displayables results' and 'preferences'.
|
||||||
|
* The items selected in these lists contribute to define the current state of
|
||||||
|
* the fsm.
|
||||||
|
* The exact number and status of the structures of the fsm are still being
|
||||||
|
* assessed.
|
||||||
|
*
|
||||||
|
* @callergraph
|
||||||
|
* @see fsm_init()
|
||||||
|
*/
|
||||||
|
static void fsm_structures_init()
|
||||||
|
{
|
||||||
|
/**< will be introduced later on:
|
||||||
|
|
||||||
|
fsm_add_log (info, FSM, "fsm/dispatch", "measures list init()",
|
||||||
|
"measurement processes");
|
||||||
|
fsm_list_init_measures();
|
||||||
|
|
||||||
|
fsm_add_log (info, FSM, "fsm/dispatch", "results list init()",
|
||||||
|
"measurement results (gross)");
|
||||||
|
fsm_list_init_results();
|
||||||
|
|
||||||
|
fsm_add_log (info, FSM, "fsm/dispatch", "displayables list init()",
|
||||||
|
"displayable results");
|
||||||
|
fsm_list_init_displayables();
|
||||||
|
|
||||||
|
fsm_add_log (info, FSM, "fsm/dispatch", "preferences list init()",
|
||||||
|
"preferences");
|
||||||
|
fsm_list_init_preferences();
|
||||||
|
*/
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
/**
|
||||||
|
* Closes the four lists:
|
||||||
|
* 'measures', 'results', 'displayables results' and 'preferences'.
|
||||||
|
* The items selected in these lists contribute to define the current state of
|
||||||
|
* the fsm.
|
||||||
|
* The exact number and status of the structures of the fsm are still being
|
||||||
|
* assessed.
|
||||||
|
*
|
||||||
|
* @callergraph
|
||||||
|
* @see fsm_close()
|
||||||
|
*/
|
||||||
|
static void fsm_structures_close()
|
||||||
|
{
|
||||||
|
/**< ? */
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
/**
|
||||||
|
* @brief fsm_init() is the first function called by main.c
|
||||||
|
* It initiates the journal and calls fsm_structures_init() that
|
||||||
|
*
|
||||||
|
* @since 2024-08
|
||||||
|
*
|
||||||
|
* @callergraph
|
||||||
|
* @see main()
|
||||||
|
*
|
||||||
|
* @callgraph
|
||||||
|
* @see trigger_fsm_log_init()
|
||||||
|
* @see fsm_add_log()
|
||||||
|
* @see fsm_list_init_measures()
|
||||||
|
* @see fsm_list_init_results()
|
||||||
|
* @see fsm_list_init_displayables()
|
||||||
|
* @see fsm_list_init_preferences()
|
||||||
|
*
|
||||||
|
* @param *initial_info_from_main
|
||||||
|
*/
|
||||||
|
void fsm_init (const char *initial_info_from_main)
|
||||||
|
{
|
||||||
|
fsm_trigger_log_init(); /**< fsm_init_log(() can't be called from here
|
||||||
|
* because static fsm_log_struct gg_logs
|
||||||
|
* is in src/fsm/log/manager.c */
|
||||||
|
|
||||||
|
fsm_add_log (INFO, MAIN, "main", initial_info_from_main,
|
||||||
|
"👋️ (☕️) Hi everybody ! Here is Gem-Graph.");
|
||||||
|
|
||||||
|
fsm_add_log (INFO, FSM, "fsm/control", "fsm initialisation", "has began ✍️");
|
||||||
|
fsm_structures_init();
|
||||||
|
fsm_add_log (INFO, FSM, "fsm/control", "fsm initialisation", "has ended 😇️");
|
||||||
|
}
|
||||||
|
|
||||||
|
/**
|
||||||
|
* @brief fsm_close() is the last function called by main.c It closes all that
|
||||||
|
* was opened in reverse order before handing over to main().
|
||||||
|
*
|
||||||
|
* @details It ensures the fsm state is saved:
|
||||||
|
* - preferences
|
||||||
|
* - model
|
||||||
|
*
|
||||||
|
* Then it closes the four lists:
|
||||||
|
* - 'measures',
|
||||||
|
* - 'results',
|
||||||
|
* - 'displayables results' and
|
||||||
|
* - 'preferences'.
|
||||||
|
* and closes the journal
|
||||||
|
*
|
||||||
|
* @since 2024-08
|
||||||
|
*
|
||||||
|
* @callergraph
|
||||||
|
* @see main()
|
||||||
|
*
|
||||||
|
* @callgraph
|
||||||
|
* @see fsm_structures_close()
|
||||||
|
* @see fsm_trigger_log_close()
|
||||||
|
* @see fsm_add_log()
|
||||||
|
*
|
||||||
|
* @param *closing_info_from_main
|
||||||
|
*/
|
||||||
|
void fsm_close (const char *closing_info_from_main)
|
||||||
|
{
|
||||||
|
fsm_add_log (INFO, FSM, "fsm/control", "fsm closing", "has began");
|
||||||
|
fsm_structures_close();
|
||||||
|
fsm_add_log (INFO, FSM, "fsm/control", "fsm closing", "has ended");
|
||||||
|
|
||||||
|
fsm_add_log (INFO, MAIN, "main", closing_info_from_main,
|
||||||
|
"👋️😄️ That'all folks !");
|
||||||
|
|
||||||
|
fsm_trigger_log_close(); /**< fsm_clear_log(() can't be called from here
|
||||||
|
* because static fsm_log_struct gg_logs
|
||||||
|
* is in src/fsm/log/manager.c */
|
||||||
|
}
|
|
@ -57,9 +57,8 @@ static fsm_log_struct gg_logs;
|
||||||
*
|
*
|
||||||
* A message is send to the log for each documented event.
|
* A message is send to the log for each documented event.
|
||||||
*
|
*
|
||||||
* If there are too many events, one or several filters can be applied
|
* One or several filters can be applied here (and only here) before publication,
|
||||||
* here (and only here) before publication, to select only some events
|
* to select only some events of interest (during debugging, for example).
|
||||||
* of interest (during debugging, for example).
|
|
||||||
*
|
*
|
||||||
* These filters can operate on any the following five parameters:
|
* These filters can operate on any the following five parameters:
|
||||||
* severity, source, file_source (text), function_source (text),
|
* severity, source, file_source (text), function_source (text),
|
||||||
|
@ -102,3 +101,38 @@ void fsm_add_log (int severity,
|
||||||
)
|
)
|
||||||
fsm_add_log_event (&gg_logs, file_source, function_source, string_value);
|
fsm_add_log_event (&gg_logs, file_source, function_source, string_value);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/**
|
||||||
|
* this function is a relay: fsm_init_log() can't be called directly from
|
||||||
|
* fsm_init() in control because static fsm_log_struct gg_logs is in
|
||||||
|
* src/fsm/log/manager.c
|
||||||
|
*
|
||||||
|
*
|
||||||
|
* @since 2024-08
|
||||||
|
*
|
||||||
|
* @callergraph
|
||||||
|
* @see main()
|
||||||
|
*
|
||||||
|
*/
|
||||||
|
void fsm_trigger_log_init()
|
||||||
|
{
|
||||||
|
fsm_init_log (&gg_logs);
|
||||||
|
}
|
||||||
|
|
||||||
|
/**
|
||||||
|
* this function is a relay: fsm_publish_log() and fsm_clear_log() can't be
|
||||||
|
* called directly from fsm_close() in control because static fsm_log_struct
|
||||||
|
* gg_logs is in src/fsm/log/manager.c
|
||||||
|
*
|
||||||
|
* @since 2024-08
|
||||||
|
*
|
||||||
|
* @callergraph
|
||||||
|
* @see main()
|
||||||
|
*
|
||||||
|
*/
|
||||||
|
void fsm_trigger_log_close()
|
||||||
|
{
|
||||||
|
fsm_publish_log (gg_logs);
|
||||||
|
fsm_clear_log (&gg_logs);
|
||||||
|
}
|
||||||
|
|
||||||
|
|
55
src/main.c
55
src/main.c
|
@ -1,7 +1,6 @@
|
||||||
/**
|
/**
|
||||||
* @file
|
* @file
|
||||||
*
|
* Gem-graph-client main file.
|
||||||
* Gem-graph main file
|
|
||||||
*
|
*
|
||||||
* This file is part of Gem-graph. It contains only the main() function.
|
* This file is part of Gem-graph. It contains only the main() function.
|
||||||
*
|
*
|
||||||
|
@ -26,16 +25,22 @@
|
||||||
*
|
*
|
||||||
* ---
|
* ---
|
||||||
*
|
*
|
||||||
* The main() function will **initialise** the log, the finite state machine (fsm),
|
* The main() function
|
||||||
* the application and the windows and **close** all the elements it opened
|
* - **initialise**
|
||||||
* before the end of program execution.
|
* -# the log,
|
||||||
|
* -# the finite state machine (fsm),
|
||||||
|
* -# the application,
|
||||||
|
* -# the windows and
|
||||||
|
*
|
||||||
|
* - **close** all the elements it opened in reverse order
|
||||||
|
* before ending the program execution
|
||||||
|
* .
|
||||||
|
*
|
||||||
* In this commit, it does not implement g_application_activate() and has no
|
* In this commit, it does not implement g_application_activate() and has no
|
||||||
* handlers connected to the 'activate' signal (which triggers an error message).
|
* handlers connected to the 'activate' signal (which triggers an error message).
|
||||||
*
|
*
|
||||||
* The default values of the fsm initial state will be specified in:
|
* The default values of the fsm initial state will be specified in:
|
||||||
* src/fsm/dispatch(). They are user preference and, in accordance, the overview
|
* src/fsm/control(). They are user preferences.
|
||||||
* page of the current model will be displayed as they specify it in:
|
|
||||||
* src/widget/main_window/designer/widget_design_main_window().
|
|
||||||
*
|
*
|
||||||
* About code organization, see src/readme.dox
|
* About code organization, see src/readme.dox
|
||||||
*
|
*
|
||||||
|
@ -43,19 +48,49 @@
|
||||||
*/
|
*/
|
||||||
|
|
||||||
#include <gtk-4.0/gtk/gtk.h>
|
#include <gtk-4.0/gtk/gtk.h>
|
||||||
|
#include "../include/fsm.h" // finite state machine (fsm)
|
||||||
|
|
||||||
|
/**
|
||||||
|
* @since 2024-04
|
||||||
|
*
|
||||||
|
* @callgraph
|
||||||
|
* @see fsm_trigger_log_init()
|
||||||
|
* @see fsm_init()
|
||||||
|
* @see fsm_close()
|
||||||
|
* @see fsm_trigger_log_close()
|
||||||
|
* @see fsm_add_log()
|
||||||
|
*
|
||||||
|
* @param argc
|
||||||
|
* @param **argv
|
||||||
|
* @return status, the program errorlevel
|
||||||
|
*/
|
||||||
int main (int argc, char **argv)
|
int main (int argc, char **argv)
|
||||||
{
|
{
|
||||||
GtkApplication *app;
|
GtkApplication *app;
|
||||||
int status;
|
int status;
|
||||||
|
|
||||||
|
fsm_init ("first instruction / first log");
|
||||||
|
|
||||||
|
fsm_add_log (INFO, MAIN, "main", "*app = gtk_application_new()",
|
||||||
|
"| 👉️ trigger app initialization");
|
||||||
app = gtk_application_new ("org.gem-graph", G_APPLICATION_DEFAULT_FLAGS);
|
app = gtk_application_new ("org.gem-graph", G_APPLICATION_DEFAULT_FLAGS);
|
||||||
|
|
||||||
//g_signal_connect (app, "activate", G_CALLBACK (on_main_window_activation), NULL);
|
fsm_add_log (INFO, MAIN, "main",
|
||||||
//g_signal_connect (app, "activate", G_CALLBACK (on_dialog_window_activation), NULL);
|
"g signal connect (activate)",
|
||||||
|
"| 👉️ windows creation requested");
|
||||||
|
|
||||||
|
// g_signal_connect (app, "startup", G_CALLBACK (on_windows_startup), NULL);
|
||||||
|
// g_signal_connect (app, "activate", G_CALLBACK (on_windows_activation), NULL);
|
||||||
|
|
||||||
|
fsm_add_log (INFO, MAIN, "main",
|
||||||
|
"no g signal connect (activate)",
|
||||||
|
"| 🖐️ windows creation denied");
|
||||||
|
|
||||||
status = g_application_run (G_APPLICATION (app), argc, argv);
|
status = g_application_run (G_APPLICATION (app), argc, argv);
|
||||||
g_object_unref (app);
|
g_object_unref (app);
|
||||||
|
fsm_add_log (INFO, MAIN, "main", "g_object unref (app)", "| 👌️ bye bye app !");
|
||||||
|
|
||||||
|
fsm_close("last instruction / last log");
|
||||||
|
|
||||||
return status;
|
return status;
|
||||||
}
|
}
|
||||||
|
|
Loading…
Reference in New Issue