338 lines
12 KiB
Plaintext
338 lines
12 KiB
Plaintext
L'utilisation d'OpenGL fait que la première version de Gem-graph sera tout naturellement en 3D.
|
|
Le modèle de marche aléatoire de dimères sera aussi facile à y réaliser que dans un modèle 1D
|
|
(on pourrait même se servir d'une seule règle au lieu de deux !) (mais deux règles permettront un meilleur rendu).
|
|
|
|
Modifier la forme des flèches ?
|
|
Pour cette première version, la forme "central star" + "cône" a l'avantage de la simplicité.
|
|
La "central star" de chaque cube est commune aux six flèches possibles qui sont orientées chacune vers une face différente.
|
|
Dans la version actuelle, elle est redessinée si plusieurs flèches sont dans le même cube.
|
|
Ce dessin est peu coûteux (deux lignes superposées pour chaque nouvelle flèche)
|
|
et ce cas (plusieurs flèches dans le même cube) sera peu fréquent dans les premiers modèles développés. Mais... TODO
|
|
|
|
Le plus simple serait un trait allant du centre d'un cube au centre d'une de ses faces.
|
|
Ce serait peu lisible pour des objets mais pourrait avoir un intérêt pour les tags (balises) éventuellement associés aux objets ou situations.
|
|
Ces tags seraient machine-readable. Nécessairement. Seraient-ils human-readable aussi ? Ce serait idéal ! A inventer ou essayer, en tout cas.
|
|
Un seul trait aurait sûrement un intérêt dans la représentation de voisinages de Moore 3D
|
|
(Je préfère ne pas imaginer ça pour l'instant ! Il va falloir choisir de ne représenter ou de ne visualiser qu'une partie des connexions à la fois...).
|
|
|
|
Le premier objectif des versions à venir est l'extension du voisinage.
|
|
Un voisinage type von Neumann 3D - le plus simple possible si on le veut symétrique par rapport aux axes de l'espace - est tout à fait indiqué pour cette première version.
|
|
Mais les versions à venir devraient travailler en priorité avec des voisinages type Moore 3D approximativement spériques de rayon proche de celui de l'espace local.
|
|
Par ailleurs, Gem-graph ne peut avoir sa puissance théorique maximale que s'il peut utiliser un voisinage étendu à tout l'espace.
|
|
Mais cette puissance est vraisemblablement inutile, sauf pour les démonstrations mathématiques d'équivalence avec les automates cellulaires, par exemple, ou d'autres formalismes.
|
|
Par ailleurs, il est d'ores et déjà possible d'utiliser pleinement le "poids" (weight) ou la "charge" (load) des flèches.
|
|
|
|
! WARNING ! J'ai inversé pôle Nord et pôle Sud. Et c'est à corriger, je pense. 👀️
|
|
Ce sera une convention, bien sûr. Mais comment la choisir ? J'ai imaginé superposer repère orthonormé et repère géodésique.
|
|
Si je regarde un repère orthonormé 3D:
|
|
les +x sont à ma droite, les -x à ma gauche (Est - Ouest)
|
|
les +y en haut, les -y en bas (Zénith - Nadir) et... si l'axe des z vient vers moi,
|
|
les +z sont derrière moi et les -z devant. Donc les -z sont au Nord (que je regarde) et les +z sont au Sud.
|
|
|
|
Les vertex situés aux intersections des "grilles" (X-X, Y-Y et Z-Z) sont-ils utiles ?
|
|
Ils le seraient si ses cubes individuels étaient coloriés ou soulignés pour mettre en valeur des flèches qu'ils contiennent ou d'autres particularités.
|
|
Mais tant qu'il n'est pas possible de rendre sélectivement transparentes les parois de cubes individuels (ou de tel ou tel objet dessiné par les flèches),
|
|
cette fonction est inutilisable et les vertex situés aux intersections des grilles sont donc inutiles.
|
|
On pourrait ne garder que ceux situés sur les faces de l'espace qui, eux, servent à tracer les grilles X-X, Y-Y et Z-Z.
|
|
Le nombre de vertex de l'espace serait alors de 12 par cube-unité (soit 12 * x * y * z) plus les vertex intersections des seules faces de l'espace (soit (x * y + x * z + y * z) * 2).
|
|
A raison, bien sûr de trois nombres par vertex plus les couleurs.
|
|
|
|
Je comprends (maintenant seulement !) que si des régions du buffer lignes (idem pour le buffer triangles) sont laissées vides (occupées par des zéros)
|
|
elles seront néanmoins redessinées en permanence et que le seul moyen d'éviter cela est de réallouer la taille du buffer à chaque délétion ou chaque ajout de flèche.
|
|
|
|
Néanmoins, lorsque le nombre de flèches présent dans l'espace est invariant, - cas de mes premiers modèles - il peut être avantageux de travailler dans un buffer de taille fixe.
|
|
Il faut, pour cela, fixer une "densité maximale de flèches dans l'espace" nécessairement arbitraire.
|
|
Bien que ce nombre reste toujours arbitraire, on peut estimer que certaines de ses valeurs seront plus utiles/utilisables que d'autres :
|
|
- un espace totalement vide ou totalement saturé ne pourrait rien représenter
|
|
- un espace trop vide ou trop plein (à définir - c'est intuitif) aurait peu de chances de représenter des phénomènes intéressants.
|
|
La marche aléatoire d'un seul ou de quelques dimères dans un grand espace, par exemple, servira plus de test pour le bon fonctionnement de Gem-graph que de modèle d'étude.
|
|
- on peut considérer un espace rempli de flèches aux 2/3 comme équivalent à un espace repli au tiers (1/3) mais où les flèches seraient écrites "en creux"
|
|
et, par conséquent, moins lisibles. Inutile, donc, de remplir plus de la moitié de l'espace.
|
|
D'expérience,
|
|
- les densités de l'ordre du tiers (1/3 des unités de l'espace occupées par au moins une flèche) suffisent à représenter un nombre de phénomènes tel
|
|
qu'il n'est pas nécessaire, au moins dans un premier temps, de prévoir davantage (mais des réalloc sont toujours possibles) et les densités trop fortes sont peu lisibles.
|
|
Un buffer lignes pourrait donc avoir une taille fixe qui serait calculée selon les paramètres suivants :
|
|
- x * y * z = nombre de cubes
|
|
- nombre de flèches moyen par cube = 2 (il s'agit d'un nombre "moyen" qui surestime très probablement le nombre de flèches utilisé par la plupart des modèles)
|
|
- dessin d'une flèche seule dans un cube = 3 + 4 traits (soit 14 nombres)
|
|
Faut-il coder cette option ?
|
|
|
|
|
|
|
|
|
|
|
|
-------------------------- notes, refs, doc, liens -------------------------
|
|
|
|
https://www.gnu.org/software/guile-gnome/docs/gtk/html/GtkToolButton.html
|
|
https://wiki.gnome.org/HowDoI/CustomWidgets
|
|
|
|
|
|
SIGNAL
|
|
------
|
|
https://web.mit.edu/barnowl/share/gtk-doc/html/gobject/signal.html
|
|
https://docs.gtk.org/gobject/signals.html#Memory_management_of_signal_handlers
|
|
https://docs.gtk.org/gobject/func.signal_connect.html
|
|
|
|
|
|
WIP: le 3ème boutton de la barre, en haut à gauche, change d'icone si toggled
|
|
|
|
CSS
|
|
---
|
|
https://www.w3.org/TR/CSS/#css
|
|
https://www.w3.org/Style/CSS/Overview.en.html
|
|
http://css.mammouthland.net/feuille-de-style-css-debutant.php
|
|
|
|
https://docs.gtk.org/gtk3/method.Widget.set_name.html
|
|
Widgets can be named, which allows you to refer to them from a CSS file.
|
|
https://docs.w3cub.com/gtk~4.0/gtkstylecontext.html
|
|
https://docs.gtk.org/gtk3/class.StyleContext.html
|
|
GtkStyleContext is an object that stores styling information affecting a widget defined by GtkWidgetPath.
|
|
|
|
on peut déclarer les styles à différents endroits, et selon ces endroits ils seront plus ou moins prioritaires.
|
|
On obtient donc une cascade de styles. Par priorité décroissante :
|
|
- styles définis par l'utilisateur, s'il en déclare
|
|
- styles locaux : attributs d'éléments html pour des mises en forme ponctuelles
|
|
- styles en interne, dans l'en-tête de la page (ne vaudront que our cette page)
|
|
- feuille de style externe : c'est de loin la meilleure chose à faire et la plus pratique à maintenir
|
|
|
|
On commence en général une feuille de style par un "reset"
|
|
pour mettre tous les navigateurs à peu près (!) dans le même état de départ...
|
|
|
|
syntaxe : sélecteur {propriété: valeur;}
|
|
sélecteur = balise (X)HTML (body ; h1 ; p, etc.), l'identifiant (id) ou la classe (class) ;
|
|
propriété = attribut qu'on veut appliquer (font ; background ; margin ; etc.)
|
|
valeur = ce qui indique les caractéristiques de la propriété.
|
|
|
|
unités
|
|
couleurs : utiliser plutôt les valeurs hexadécimales
|
|
tailles des polices de caractère : préférer les unité de longueur relatives aux unités absolues
|
|
|
|
Pour que les couleurs des liens changent selon leur état (non visité, visité, survolé, actif, ayant le focus),
|
|
on utilise des pseudo-classes qui se déclarent par : link, :visited, :hover, :active et :focus.
|
|
Il est important de respecter cet ordre de déclarations.
|
|
|
|
Feuille de style externe
|
|
Enregistrer le code CSS dans un fichier s'appelant (par exemple) "style.css",
|
|
et mettre dans l'en-tête de la page html (entre les balises <head></head>) :
|
|
<link href="style.css" rel="stylesheet" media="all" type="text/css">
|
|
|
|
Styles CSS dans le code
|
|
<p style="text-align:center; color:red"> lorem ipsum </p>
|
|
|
|
|
|
|
|
|
|
à lire (puis à supprimer)... 2024-05-28
|
|
|
|
/* ----------------------------- */
|
|
/* == reset */
|
|
/* ----------------------------- */
|
|
|
|
/* base font-size corresponds to 10px and is adapted to rem unit */
|
|
html {
|
|
font-size: 62.5%;
|
|
}
|
|
body {
|
|
background-color: #fff;
|
|
color: #000;
|
|
font-family: "Century Gothic", helvetica, arial, sans-serif;
|
|
font-size: 1.4em; /* equiv 14px */
|
|
line-height: 1.5; /* adapt to your design */
|
|
}
|
|
|
|
/* font-sizing for content */
|
|
/* preserve vertical-rythm, thanks to http://soqr.fr/vertical-rhythm/ */
|
|
p,
|
|
ul,
|
|
ol,
|
|
dl,
|
|
blockquote,
|
|
pre,
|
|
td,
|
|
th,
|
|
label,
|
|
textarea,
|
|
caption,
|
|
details,
|
|
figure,
|
|
hgroup {
|
|
font-size: 1em; /* equiv 14px */
|
|
line-height: 1.5;
|
|
margin: 1.5em 0 0;
|
|
}
|
|
h1, .h1-like {
|
|
font-size: 1.8571em; /* equiv 26px */
|
|
font-weight: normal;
|
|
line-height: 1.6154em;
|
|
margin: .8077em 0 0 0;
|
|
}
|
|
h2, .h2-like {
|
|
font-size: 1.7143em; /* equiv 24px */
|
|
font-weight: normal;
|
|
line-height: 1.75em;
|
|
margin: .875em 0 0 0;
|
|
}
|
|
h3, .h3-like {
|
|
font-size: 1.5714em; /* equiv 22px */
|
|
font-weight: normal;
|
|
line-height: 1.909em;
|
|
margin: .9545em 0 0 0;
|
|
}
|
|
h4, .h4-like {
|
|
font-size: 1.4286em; /* equiv 20px */
|
|
font-weight: normal;
|
|
line-height: 1.05em;
|
|
margin: 1.05em 0 0 0;
|
|
}
|
|
h5, .h5-like {
|
|
font-size: 1.2857em; /* equiv 18px */
|
|
font-weight: normal;
|
|
line-height: 1.1667em;
|
|
margin: 1.1667em 0 0 0;
|
|
}
|
|
h6, .h6-like {
|
|
font-size: 1.1429em; /* equiv 16px */
|
|
font-weight: normal;
|
|
line-height: 1.3125em;
|
|
margin: 1.3125em 0 0 0;
|
|
}
|
|
|
|
/* alternate font-sizing */
|
|
.smaller {
|
|
font-size: .7143em; /* equiv 10px */
|
|
line-height: 2.1em;
|
|
}
|
|
.small {
|
|
font-size: .8571em; /* equiv 12px */
|
|
line-height: 1.75em;
|
|
}
|
|
.big {
|
|
font-size: 1.1429em; /* equiv 16px */
|
|
line-height: 1.3125em;
|
|
}
|
|
.bigger {
|
|
font-size: 1.2857em; /* equiv 18px */
|
|
line-height: 1.1667em;
|
|
}
|
|
.biggest {
|
|
font-size: 1.4286em; /* equiv 20px */
|
|
line-height: 1.05em;
|
|
}
|
|
|
|
/* soft reset */
|
|
html,
|
|
body,
|
|
textarea,
|
|
figure,
|
|
label {
|
|
margin: 0;
|
|
padding: 0;
|
|
}
|
|
ul,
|
|
ol {
|
|
padding-left: 2em;
|
|
}
|
|
code,
|
|
pre,
|
|
samp {
|
|
white-space: pre-wrap;
|
|
font-family: consolas, 'DejaVu Sans Mono', courier, monospace;
|
|
}
|
|
code { line-height: 1em; }
|
|
table { margin-bottom: 1.5em; }
|
|
|
|
/* avoid top margins on first content element */
|
|
p:first-child,
|
|
ul:first-child,
|
|
ol:first-child,
|
|
dl:first-child,
|
|
blockquote:first-child,
|
|
pre:first-child,
|
|
h1:first-child,
|
|
h2:first-child,
|
|
h3:first-child,
|
|
h4:first-child,
|
|
h5:first-child,
|
|
h6:first-child {
|
|
margin-top: 0;
|
|
}
|
|
|
|
/* avoid margins on nested elements */
|
|
li p,
|
|
li ul,
|
|
li ol {
|
|
margin-top: 0;
|
|
margin-bottom: 0;
|
|
}
|
|
|
|
/* HTML5 tags */
|
|
article, aside, details, figcaption, figure, footer, header, hgroup, nav, section {
|
|
display: block;
|
|
}
|
|
|
|
/* max values */
|
|
img, table, td, blockquote, code, pre, textarea, input, video {
|
|
max-width: 100%;
|
|
}
|
|
|
|
/* you shall not pass */
|
|
div, textarea, table, td, th, code, pre, samp {
|
|
word-wrap: break-word;
|
|
-webkit-hyphens: auto;
|
|
-moz-hyphens: auto;
|
|
-ms-hyphens: auto;
|
|
-o-hyphens: auto;
|
|
hyphens: auto;
|
|
}
|
|
|
|
/* pictures */
|
|
img {
|
|
width: auto;
|
|
height: auto;
|
|
vertical-align: middle;
|
|
}
|
|
a img { border: 0; }
|
|
|
|
/* scripts */
|
|
body > script {display: none !important;}
|
|
|
|
/* skip-links */
|
|
.skip-links {
|
|
position: absolute;
|
|
}
|
|
.skip-links a {
|
|
position: absolute;
|
|
left: -9999px;
|
|
padding: 0.5em;
|
|
background: #000;
|
|
color:#fff;
|
|
text-decoration: none;
|
|
}
|
|
.skip-links a:focus {
|
|
position: static;
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// https://docs.gtk.org/gtk4/class.Widget.html#building-composite-widgets-from-template-xml TODO Learn !
|
|
// gtk_widget_class_bind_template_callback_full (GtkToggleButton, ui_toggle_sidebar, "clicked"); // "main_button_sidebar"
|
|
|
|
// https://docs.gtk.org/gtk4/class.Widget.html#building-composite-widgets-from-template-xml
|
|
static void gtk_widget_class_dispose_template() {} // TODO ?
|
|
|
|
/* -------------------------------------------------------------------------- */
|