OK donc une pile graphique "intégrée" similaire à ce qu'on a sous Android, macOS, Windoze…
… c'est bien ce que voulais dire, juste le détour par QNX m'a terrifié 😄.
Pouvoir faire ça, c'est surtout une question de position privilégiée AMHA. Être le manitou de l'équipe de design d'un OS.
Car sinon, à compétence équivalente, que ce soit sous Linux (qui a une pile minimaliste) ou les OS de "marque" (qui ont des grosses piles intégrées à leur sauce), tu ne pourras proposer qu'un énième toolkit à la commu (ce qui n'est pas un souci pour moi, à partir du moment où on fait ça avec conviction).
La vache, ça m'apprendra à tenter le mode sérieux 😃 (dés que ça cause "d'approche micro-kernel", tu renifles le truc aussi über-élégant qu'über-compliqué -> impossible à maintenir !)
Du coup @devnewton, penses-tu qu'on devrait écrire une "Wlib", légère surcouche ne dépendant de rien et fournissant le strict nécessaire (apparence de synchrone, API de dessin, widgets en carton, etc…). Ou palapeine ?
C'est peut être mieux que ce que proposait X11, mais moins bien que ce qu'on voit sur les autres OS.
Les autres OS ont effectivement une direction claire, un "style par défaut", un SDK, un kit de widgets associé, etc.
Linux n'a jamais eu ça, et même la centralisation à travers X11/Xorg a toujours été une anomalie qui datait des années "consortium UNIX" propriétaires.
Les participants actuels à Wayland sont bien moins intéressés encore à fournir ça, et mettent bien plus de temps à se mettre d'accord ; d'où le côté minimaliste qui délègue ailleurs.
un programme doit se fader une registry, un "listage" d'interfaces avec des callbacks et des conversions de void* : on dirait du Java en mode ProblemFactory ;
C'est effectivement la base de l'API 😁.
On s'abonne à un "registry" qui va nous indiquer dans un callback les interfaces qu'il suppose ; on s'abonne à celles qui nous intéressent, qui vont nous indiquer dans des callbacks ce qu'il se passe, etc…
Je trouve pas ça si horrible, moi ! L'avantage est que c'est extensible à l'infini, et négociable au runtime. Le fait est que le projet en est très fier, au point de le pousser ailleurs comme protocole IPC généraliste ;-).
PS : les conversions de void*, c'est moi qui les fait à cause du point ci-dessous.
le code doit gérer des variantes selon le "shell" : ça sent l'API parti en prod avant d'être sec
Alors là je suis d'accord, et c'est le plus gros problème à mon sens… juste plus pour longtemps.
Quand Wayland est sorti, l'abstraction du shell (= window manager) s'appelait "wl_shell", elle était tout de suite incomplète pour éviter de prendre trop position (pas de minimisation, pas de passage de focus…) et après coup on s'est aperçus qu'elle avait pas mal de race conditions .
L'alternative nommée "xdg-shell" a passé des années en état instable, il fallait un peu la suivre, et ce n'est que récemment qu'elle est passée stable (sous le nom "xdg-wm-base", pour qu'on la repère bien).
Je les gère encore car je voulais vraiment que les exemples marchent chez tout le monde, même avec du code de 2016. Et du coup ué je convertis les types du shell en void* ;).
Mais on pourrait ne pas le faire et raccourcir tous les exemple de ~50 lignes… ou comme moi ici utiliser "libdecor" qui gère tout ça elle-même !
il n'y a pas d'API pour dessiner, je sais que ce point fait débat, mais ça me semble idiot pour un serveur d'affichage de ne pas savoir afficher :-)
Alors oui c'est clivant. Le fait est que personne n'utilisait plus les API de dessin de X11 (genre "XDrawCircle") car elles étaient vieilles et aliasées, mais passait par celles des libs de toolkits (genre cairo ou Skia).
Wayland a été conçu pour supporter ce cas d'usage, et rien de plus.
Qu'est-ce-qui te déplaît là-dedans?
Tu aurais voulu que le projet Wayland fournisse lui-même une lib "wrapper" pour des opérations courantes -comme créer des fenêtres? Un peu comme Xlib par-dessus xcb?
Là où je donne raison à ton commentaire David : on avait un gros truc monolithique et dépassé (X11/X.org).
En passant à Wayland, on a supprimé le code dépassé, et en même temps :
- on a réinternalisé une toute petite partie de ce qui était omis par X11 (le window manager p.ex.) ;
- on s'est abstenu d'internaliser d'autres chose qui sur d'autres OS le sont depuis toujours (les widgets p.ex., largement pris en charge sous Nunux par des toolkits genre GTK/Qt);
- on a externalisé/délégué la partie initialisation bas niveau de l'affichage (qui se retrouve maintenant éclatée entre les différents compositeurs).
C'est un cas un peu unique dans le soft. D'une certaine façon, c'est très UNIXien dans le sens "modularité". Il se trouve que ça convient très bien à certains domaines comme l'embarqué, qui veulent remplacer et optimiser chaque brique facilement.
Mais ceux qui pensaient que ça aiderait le desktop ou simplifierait la partie "code commun" en sont pour leurs frais ;-).
Weston (le compositeur de référence), GNOME et Enlightenment ont chacun leur propre implémentation.
À noter que :
- Weston fournit une lib réutilisable du genre de wlroots. Qu'elle n'ait pas été si utilisée indique soit ses limites, soit le manque de commu autour ;
- KDE s'appuie aujourd'hui beaucoup l'implémentation de Qt. Celle-ci est très utilisée dans d'autres contextes, notamment dans l'embarqué.
Mais en gros, l'API Wayland, c'est plus chose de xcb que de la Xlib.
Un protocole plus bas niveau et asynchrone, qui expose davantage les rouages dans le but avoué du projet : éviter le tearing.
Alors oui effectivement, une API utilisateur à la SDL va s'occuper de ça pour les devs pressés…
…mais il faut relativiser le jugement :
Concrètement, la version de seulement 450 lignes utiles d'ici, -réduite à l'aide d'une lib "helper" officielle du projet- c'est pas plus long qu'une appli X11 qui essaie de fonctionner correctement sous les window managers de GNOME, KDE…et le reste du monde.
On y a pas mal gagné sur l'existant quand même, et je trouve pas ça si compliqué !
Juste le rendu software basé sur des concepts UNIX un peu avancés (mémoire partagée) oui ça faut l'apprivoiser.
Mes pièces rouges : memset() casterait "volatile char*" en "char*", ce qui retirerait l'effet du "volatile".
C'est tout simple et cité plusieurs fois sur Stack Overflow entre autres.
Je viens d'essayer ça :
memset((volatile char*)password, 0, 16);
et ça m'a affiché :
memset_explicit.c:90:12: warning: passing argument 1 of ‘memset’ discards ‘volatile’ qualifier from pointer target type [-Wdiscarded-qualifiers]
Exact David !
D'ailleurs, et sans rapport direct… au début, la fin du code ressemblait à ça :
puts("Your password is still in memory... Inspect it now! (press any key...)");
getchar();
memset(password, 0, 16);
puts("Your password is now cleared! (press any key...)");
getchar();
return 0;
}
C'est-à-dire qu'il y avait une séquence "puts()/getchar()" supplémentaire entre le memset() et le return final.
Eh bien dans ce cas-là… le compilateur n'optimise pas non plus ! Car il s'agit de fonctions d'I/O et il considère que ça peut interférer avec les buffers -;). (dit autrement : c'est sensible !)
En fait, comme le dit @David Demelier ci-dessous (et si j'ai bien interprété sa réponse qui avait l'air en rapport),
appliquer "volatile" à la variable ne va pas forcément empêcher le compilo de la sortir, comme cité ici (même si je reconnais que c'est capillotracté, et perso je n'avais même pas réussi à le reproduire).
C'est pour cette raison que, sur le conseil d'un ami qui se reconnaîtra -cf les logs de commit ;-), j'ai appliqué la même logique que la bibliothèque Botan en le mettant plutôt sur le pointeur de fonction.
Effectivement !
Et en effet si tu regardes, c'est ce qui est fait ici dans le pire des cas :
// ici on gère toutes les architectures connues
#else
static void* (*volatile memset_explicit_unk)(void*, int, size_t) = memset;
#endif
Je dis le "pire", car cela fait une indirection qui tape sur le pointeur de fonction de la lib C.
Très suffisant bien sûr ! Mais juste potentiellement moins efficace que d'avoir soit :
- une implémentation locale qui tirerait un assembleur adapté ;
- son propre assembleur adapté :-)
et le fait que ça verrouille une petite zone mémoire pour le besoin.
(tu le sais bien sûr, mais je précise pour les non-initiés : il ne faut pas appliquer "volatile" sur la variable de la zone à effacer -ici "password"- mais sur l'appel de fonction comme ci-dessus)
Pour ceux qui passeraient rapidement et auraient du mal à saisir: memcpy() est une fonction C bas niveau qui permet de copier rapidement une zone mémoire "telle quelle".
Ça ne pose pas de problème en C lui-même ; mais en C++ qui est un langage objet plein de magie (smart pointers, références, constructeurs et destructeurs…), lui passer un objet de ce genre n'est justement 1) en général pas ce qu'on veut vraiment faire 2) un portail potentiel vers le fun !
Eh bien du coup, je te le confirme, preuve à l'appui :
09-27 21:12:54.142 31981 31981 E AndroidRuntime: FATAL EXCEPTION: main
09-27 21:12:54.142 31981 31981 E AndroidRuntime: Process: bim.app, PID: 31981
09-27 21:12:54.142 31981 31981 E AndroidRuntime: java.lang.NoSuchMethodError: No static method createPredefined(I)Landroid/os/VibrationEffect; in class Landroid/os/VibrationEffect; or its super classes (declaration of 'android.os.VibrationEffect' appears in /system/framework/framework.jar!classes2.dex)
Juste, parmi les infos souvent omises que j'aurais aimées trouver sur la page des releases, il y aurait la version minimale d'Android et les éventuelles dépendances (genre Google Play framework etc).
Ma remarque n'est pas innocente : j'ai installé l'APK et il ne démarre pas sur mon Android 9 habituel (bref écran noir, puis retour au homescreen).
Je n'ai pas le nécessaire ici pour t'en dire plus avec Logcat (ou son équivalent); par contre si tu veux bien me renseigner, je peux regarder -pour lundi au plus tard.
# fmacro-prefix-map
Posté par Tarnyko (site web personnel) . En réponse au journal Sortie de Bim! en version 6. Évalué à 6 (+4/-0).
Je connaissais pas ; intéressant !
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Tarnyko (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 2 (+0/-0). Dernière modification le 31 mars 2025 à 11:19.
OK donc une pile graphique "intégrée" similaire à ce qu'on a sous Android, macOS, Windoze…
… c'est bien ce que voulais dire, juste le détour par QNX m'a terrifié 😄.
Pouvoir faire ça, c'est surtout une question de position privilégiée AMHA. Être le manitou de l'équipe de design d'un OS.
Car sinon, à compétence équivalente, que ce soit sous Linux (qui a une pile minimaliste) ou les OS de "marque" (qui ont des grosses piles intégrées à leur sauce), tu ne pourras proposer qu'un énième toolkit à la commu (ce qui n'est pas un souci pour moi, à partir du moment où on fait ça avec conviction).
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Tarnyko (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 3 (+1/-0). Dernière modification le 31 mars 2025 à 10:52.
La vache, ça m'apprendra à tenter le mode sérieux 😃
(dés que ça cause "d'approche micro-kernel", tu renifles le truc aussi über-élégant qu'über-compliqué -> impossible à maintenir !)
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Tarnyko (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 2 (+0/-0).
Du coup @devnewton, penses-tu qu'on devrait écrire une "Wlib", légère surcouche ne dépendant de rien et fournissant le strict nécessaire (apparence de synchrone, API de dessin, widgets en carton, etc…). Ou palapeine ?
[^] # Re: mais mais mais... c'est nul !
Posté par Tarnyko (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 2 (+0/-0).
Les autres OS ont effectivement une direction claire, un "style par défaut", un SDK, un kit de widgets associé, etc.
Linux n'a jamais eu ça, et même la centralisation à travers X11/Xorg a toujours été une anomalie qui datait des années "consortium UNIX" propriétaires.
Les participants actuels à Wayland sont bien moins intéressés encore à fournir ça, et mettent bien plus de temps à se mettre d'accord ; d'où le côté minimaliste qui délègue ailleurs.
[^] # Re: mais mais mais... c'est nul !
Posté par Tarnyko (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 5 (+3/-0). Dernière modification le 26 mars 2025 à 15:31.
Haha, tu ne me décois pas, Newt' !
C'est effectivement la base de l'API 😁.
On s'abonne à un "registry" qui va nous indiquer dans un callback les interfaces qu'il suppose ; on s'abonne à celles qui nous intéressent, qui vont nous indiquer dans des callbacks ce qu'il se passe, etc…
Je trouve pas ça si horrible, moi ! L'avantage est que c'est extensible à l'infini, et négociable au runtime. Le fait est que le projet en est très fier, au point de le pousser ailleurs comme protocole IPC généraliste ;-).
PS : les conversions de void*, c'est moi qui les fait à cause du point ci-dessous.
Alors là je suis d'accord, et c'est le plus gros problème à mon sens… juste plus pour longtemps.
Quand Wayland est sorti, l'abstraction du shell (= window manager) s'appelait "wl_shell", elle était tout de suite incomplète pour éviter de prendre trop position (pas de minimisation, pas de passage de focus…) et après coup on s'est aperçus qu'elle avait pas mal de race conditions .
L'alternative nommée "xdg-shell" a passé des années en état instable, il fallait un peu la suivre, et ce n'est que récemment qu'elle est passée stable (sous le nom "xdg-wm-base", pour qu'on la repère bien).
Je les gère encore car je voulais vraiment que les exemples marchent chez tout le monde, même avec du code de 2016. Et du coup ué je convertis les types du shell en void* ;).
Mais on pourrait ne pas le faire et raccourcir tous les exemple de ~50 lignes… ou comme moi ici utiliser "libdecor" qui gère tout ça elle-même !
Alors oui c'est clivant. Le fait est que personne n'utilisait plus les API de dessin de X11 (genre "XDrawCircle") car elles étaient vieilles et aliasées, mais passait par celles des libs de toolkits (genre cairo ou Skia).
Wayland a été conçu pour supporter ce cas d'usage, et rien de plus.
[^] # Re: mais mais mais... c'est nul !
Posté par Tarnyko (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 4 (+2/-0).
Qu'est-ce-qui te déplaît là-dedans?
Tu aurais voulu que le projet Wayland fournisse lui-même une lib "wrapper" pour des opérations courantes -comme créer des fenêtres? Un peu comme Xlib par-dessus xcb?
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Tarnyko (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 6 (+4/-0). Dernière modification le 26 mars 2025 à 13:25.
Là où je donne raison à ton commentaire David : on avait un gros truc monolithique et dépassé (X11/X.org).
En passant à Wayland, on a supprimé le code dépassé, et en même temps :
- on a réinternalisé une toute petite partie de ce qui était omis par X11 (le window manager p.ex.) ;
- on s'est abstenu d'internaliser d'autres chose qui sur d'autres OS le sont depuis toujours (les widgets p.ex., largement pris en charge sous Nunux par des toolkits genre GTK/Qt);
- on a externalisé/délégué la partie initialisation bas niveau de l'affichage (qui se retrouve maintenant éclatée entre les différents compositeurs).
C'est un cas un peu unique dans le soft. D'une certaine façon, c'est très UNIXien dans le sens "modularité". Il se trouve que ça convient très bien à certains domaines comme l'embarqué, qui veulent remplacer et optimiser chaque brique facilement.
Mais ceux qui pensaient que ça aiderait le desktop ou simplifierait la partie "code commun" en sont pour leurs frais ;-).
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par Tarnyko (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 3 (+1/-0). Dernière modification le 26 mars 2025 à 13:09.
Weston (le compositeur de référence), GNOME et Enlightenment ont chacun leur propre implémentation.
À noter que :
- Weston fournit une lib réutilisable du genre de wlroots. Qu'elle n'ait pas été si utilisée indique soit ses limites, soit le manque de commu autour ;
- KDE s'appuie aujourd'hui beaucoup l'implémentation de Qt. Celle-ci est très utilisée dans d'autres contextes, notamment dans l'embarqué.
[^] # Re: mais mais mais... c'est nul !
Posté par Tarnyko (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 8 (+6/-0). Dernière modification le 24 mars 2025 à 16:49.
Céça !
Mais en gros, l'API Wayland, c'est plus chose de xcb que de la Xlib.
Un protocole plus bas niveau et asynchrone, qui expose davantage les rouages dans le but avoué du projet : éviter le tearing.
Alors oui effectivement, une API utilisateur à la SDL va s'occuper de ça pour les devs pressés…
…mais il faut relativiser le jugement :
On y a pas mal gagné sur l'existant quand même, et je trouve pas ça si compliqué !
Juste le rendu software basé sur des concepts UNIX un peu avancés (mémoire partagée) oui ça faut l'apprivoiser.
[^] # Re: Tant qu’à traduire…
Posté par Tarnyko (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 2 (+0/-0).
Oui, et je trouve que ça ringe moins 😶.
[^] # Re: appel à la modération
Posté par Tarnyko (site web personnel) . En réponse au journal Hyprland est hypé. Évalué à 2 (+0/-0).
Soutien clair et total.
[^] # Re: volatile ?
Posté par Tarnyko (site web personnel) . En réponse au journal C23: un memset_explicit() qui carbure. Évalué à 4 (+2/-0).
La meilleure explication à mon sens.
Court et précis. Merci :-) !
[^] # Re: volatile ?
Posté par Tarnyko (site web personnel) . En réponse au journal C23: un memset_explicit() qui carbure. Évalué à 2 (+0/-0).
Non mais d'accord :-D.
En ce qui me concerne c'est bien plus une affaire de sécurité !
Après là j'avoue, c'est surtout un "jeu" de comprendre le détail des choses. L'existant marche quoi qu'il arrive !
[^] # Re: volatile ?
Posté par Tarnyko (site web personnel) . En réponse au journal C23: un memset_explicit() qui carbure. Évalué à 3 (+1/-0). Dernière modification le 21 janvier 2025 à 11:45.
Mes pièces rouges : memset() casterait "volatile char*" en "char*", ce qui retirerait l'effet du "volatile".
C'est tout simple et cité plusieurs fois sur Stack Overflow entre autres.
Je viens d'essayer ça :
et ça m'a affiché :
Un avis là-dessus ?
[^] # Re: volatile ?
Posté par Tarnyko (site web personnel) . En réponse au journal C23: un memset_explicit() qui carbure. Évalué à 3 (+1/-0). Dernière modification le 21 janvier 2025 à 10:50.
Exact David !
D'ailleurs, et sans rapport direct… au début, la fin du code ressemblait à ça :
C'est-à-dire qu'il y avait une séquence "puts()/getchar()" supplémentaire entre le memset() et le return final.
Eh bien dans ce cas-là… le compilateur n'optimise pas non plus ! Car il s'agit de fonctions d'I/O et il considère que ça peut interférer avec les buffers -;). (dit autrement : c'est sensible !)
[^] # Re: volatile ?
Posté par Tarnyko (site web personnel) . En réponse au journal C23: un memset_explicit() qui carbure. Évalué à 3 (+1/-0). Dernière modification le 21 janvier 2025 à 10:33.
En fait, comme le dit @David Demelier ci-dessous (et si j'ai bien interprété sa réponse qui avait l'air en rapport),
appliquer "volatile" à la variable ne va pas forcément empêcher le compilo de la sortir, comme cité ici (même si je reconnais que c'est capillotracté, et perso je n'avais même pas réussi à le reproduire).
C'est pour cette raison que, sur le conseil d'un ami qui se reconnaîtra -cf les logs de commit ;-), j'ai appliqué la même logique que la bibliothèque Botan en le mettant plutôt sur le pointeur de fonction.
[^] # Re: volatile ?
Posté par Tarnyko (site web personnel) . En réponse au journal C23: un memset_explicit() qui carbure. Évalué à 4 (+2/-0). Dernière modification le 21 janvier 2025 à 09:30.
Effectivement !
Et en effet si tu regardes, c'est ce qui est fait ici dans le pire des cas :
Je dis le "pire", car cela fait une indirection qui tape sur le pointeur de fonction de la lib C.
Très suffisant bien sûr ! Mais juste potentiellement moins efficace que d'avoir soit :
- une implémentation locale qui tirerait un assembleur adapté ;
- son propre assembleur adapté :-)
et le fait que ça verrouille une petite zone mémoire pour le besoin.
(tu le sais bien sûr, mais je précise pour les non-initiés : il ne faut pas appliquer "volatile" sur la variable de la zone à effacer -ici "password"- mais sur l'appel de fonction comme ci-dessus)
# Propre
Posté par Tarnyko (site web personnel) . En réponse au journal De GCC à Clang en passant par Firefox. Évalué à 7.
Propre (même si je n'utilise pas Clang) !
Pour ceux qui passeraient rapidement et auraient du mal à saisir: memcpy() est une fonction C bas niveau qui permet de copier rapidement une zone mémoire "telle quelle".
Ça ne pose pas de problème en C lui-même ; mais en C++ qui est un langage objet plein de magie (smart pointers, références, constructeurs et destructeurs…), lui passer un objet de ce genre n'est justement 1) en général pas ce qu'on veut vraiment faire 2) un portail potentiel vers le fun !
[^] # Re: Conversion implicite
Posté par Tarnyko (site web personnel) . En réponse au journal Le bon sens et le C++. Évalué à 3. Dernière modification le 14 novembre 2024 à 17:24.
Ouais il triche.
Limite il fait du poutaclique.
Mais comme c'est mon langage de réf', je râle pas -encore- trop ;)
# Vocabulaire
Posté par Tarnyko (site web personnel) . En réponse au message Impossible de suivre un tuto sur linux la communauté parle toujours avec un vocabulaire que j'ai pas. Évalué à 4.
Par exemple ?
# Fla$h
Posté par Tarnyko (site web personnel) . En réponse au message format de fichiers images + piste audio + timestamps. Évalué à 2.
Je me goure ou alors c'est le cas d'usage typique du Flash ;-) ?
[^] # Re: Ne démarre pas ; dépendances ou version d'Android ?
Posté par Tarnyko (site web personnel) . En réponse au journal Version 2 de Bim!, avec des menus. Évalué à 3.
Installé… parfait, ça marche, merci !
Maintenant il me reste à trouver 1) un ami 2) un 2ème Android
pour tester toussa 😉.
[^] # Re: Ne démarre pas ; dépendances ou version d'Android ?
Posté par Tarnyko (site web personnel) . En réponse au journal Version 2 de Bim!, avec des menus. Évalué à 2. Dernière modification le 27 septembre 2024 à 21:39.
Wow, merci pour la réponse 😀!
Eh bien du coup, je te le confirme, preuve à l'appui :
09-27 21:12:54.142 31981 31981 E AndroidRuntime: FATAL EXCEPTION: main
09-27 21:12:54.142 31981 31981 E AndroidRuntime: Process: bim.app, PID: 31981
09-27 21:12:54.142 31981 31981 E AndroidRuntime: java.lang.NoSuchMethodError: No static method createPredefined(I)Landroid/os/VibrationEffect; in class Landroid/os/VibrationEffect; or its super classes (declaration of 'android.os.VibrationEffect' appears in /system/framework/framework.jar!classes2.dex)
# Ne démarre pas ; dépendances ou version d'Android ?
Posté par Tarnyko (site web personnel) . En réponse au journal Version 2 de Bim!, avec des menus. Évalué à 3.
Hello Julien, ça a l'air cool !
Juste, parmi les infos souvent omises que j'aurais aimées trouver sur la page des releases, il y aurait la version minimale d'Android et les éventuelles dépendances (genre Google Play framework etc).
Ma remarque n'est pas innocente : j'ai installé l'APK et il ne démarre pas sur mon Android 9 habituel (bref écran noir, puis retour au homescreen).
Je n'ai pas le nécessaire ici pour t'en dire plus avec Logcat (ou son équivalent); par contre si tu veux bien me renseigner, je peux regarder -pour lundi au plus tard.