Avec un langage fortement typé et qui fait un max de vérifications à la compilation, tu t'évites l'écriture d'une paires de tests (débiles pour la plupart) qu'un langage interprété et faiblement typé t'oblige pour avoir la même rigueur avant déploiement.
La solidité de ton déploiement : c'est pas forcément au dev de gérer ça donc hs.
La simplicité du rollback : si tu rollback, c'est que t'as cassé la prod, non ? (donc pouvoir rollback c'est bien mais éviter de casser la prod, c'est mieux)
Niveau workflow, j'aurais plutôt parlé des logs, des métriques, des envs de recette avec cahiers de tests (tu sais, piloté par des humains : c'est encore ce qui se fait de mieux).
Pour des softs comme rigrep, l'objectif de l'auteur était clairement d'avoir un grep le plus rapide qui soit et la promesse est tenu en partie par le langage.
Pour les autres, effectivement, dans l'absolu, Rust ne se justifie sans doute pas.
Après, je pense que beaucoup ont tendance à mettre Rust dans la case "bas niveau" à tord.
De ma propre expérience, c'est pas forcément ce qui m'a attiré en premier.
J'ai voulu m'investir dans un langage robuste il y a 4 ans et je l'ai comparé à Go (et à d'autres) à l'époque.
Malgré sa jeunesse, il présentait des vertus sur le typage, pattern matching, programmation fonctionnel qui me semblait bien plus pointus que ceux de Go.
Je ne connais pas l'état actuel de Go mais vu comment ça a évolué niveau Rust : communauté, évol du langage, doc etc… je pense que je ferais le même choix aujourd'hui.
Crystal, que je ne connais que de nom, me parait plus exotique et Occaml (même constat pour Haskell) reste et restera (malgré son âge et sa maturité) un langage de niche plutôt académique.
A titre pro, j'ai jonglé avec Java et C# et je voulais aussi investir dans un langage qui soit moins piloté par une grosse boite donc difficile de privilégier des "Swift", "Kotlin", "Scala", "Go".
( Surtout Google qui n'a aucun scrupule à abandonner une techno dès qu'elle est pas rentable)
Sur l'aspect utilisateur, je trouve aussi qu'avoir des outils cli qui n'utilise pas de GC est un gros avantage.
Sur du linux, on sait très bien qu'on peut avoir un panel de softs très hétérogènes et que ça peut avoir un impact mémoire non négligeable tout cumulé.
Franchement, me dire que sur un serveur, un rpi etc, je vais avoir des cron avec des scripts en python, en nodejs, en scala, en Go etc… et bien je vais me taper n GC qui consomment de la mémoire inutilement.
En C ou en Rust, ça ne sera pas le cas. (sauf cas de fuite, bien entendu)
Je fais sans doute parti de ses dinosaures qui ont du mal à comprendre pourquoi on gaspille tant de mémoire actuellement pour des trucs basiques.
C'est pas du deep learning mais des pauvres scripts et plus c'est populaire et plus ça devrait être insignifiant en impact mémoire, en temps de démarrage etc.
Effectivement, quand j'ai vu que ça s'emballait… j'ai préféré ne pas répondre par peur que ça soit mal interprété peu importe mes propos.
Bien évidemment, en employant "modérateur", je partais du postulat que ce mot est neutre.
D'apprendre que l'équipe de modération est mixte me réjoui.
J'essaierai (dans la mesure de mes capacités) d'y faire attention à l'avenir.
C'est effectivement quelque chose que j'ai déjà envisagé.
Pour un autre projet, je me suis déjà amusé à mettre le nez dans les sources de grammalecte et parser certains dictionnaires.
Je dirais que l'intérêt pour gSpeech résiderais plus sur les données collectés plutôt que sur les algos qui sont plus dédiés a de la reconnaissance en vue d'un correctif.
En fait, la lib picovox lit déjà naturellement pas mal de texte correctement.
Il y a malheureusement quelques subtilités (que je comble avec les algos énumérés plus haut) et il est très délicat de les appréhender. (à part l'identifier via une lecture)
Je ne suis pas certain qu'il y ai des données tel que de la phonétique dans grammalecte mais si c'est le cas, ça pourrait être du pur caviar pour le second projet : speechtux.
Mais oui, y'a sans doute des pistes à explorer tel qu'une lecture gardé fluide malgré quelques fautes d'orthographes ou de saisie par exemple.
Alors, j'ai fait la même opération que l'auteur mais avec Nix et j'en suis actuellement à 7.3G (du -sh /nix/store) avec la dernière version de gimp, inkscape, geany, guake, une quinzaine de petits utilitaires et sans doute une bonne cinquantaine de doublons lié aux paquets que j'ai empaqueté.
Je pense, le mieux pour te faire une idée est déjà de faire l'install minimal et de surveiller paquet par paquet.
Tout est mis dans /nix/store (ou /gnu/store si tu pars sur guix) et il t'es donc facile de surveiller l'évolution.
Tout d'abord, merci de cet article.
Il n'y a quasiment aucun article francophone sur le sujet donc rien que pour ça, ça nécessite d'être souligné !
Connaissant Nix, je vois bien entendu beaucoup de similitudes.
/gnu/store au lieu de /nix/store mais même principe : des noms de paquet avec des hash.
Même constat que pour Nix : pourquoi diable avoir mis les hash avant les noms…
Pour ce qui est Snap et FlatPak : c'est très orienté user avec des outils graphiques mais dès qu'on regarde un peu de plus prêt… la magie n'opère plus.
Je pense avoir un peu de recul sur la création de paquets : j'ai déjà fait moultes paquets debian, un peu d'archlinux, des paquets Python, Rust et depuis peu Nix et j'ai trouvé (il y a un peu plus d'un an) les tutos et la doc de Snap et Flatpak totalement ridicules.
Dès qu'on sort du hello world avec plus de 2/3 dépendances, ça devient très compliqué à empaqueter et à maintenir.
J'estimes que dans la communauté Linux (tout du moins je l'espère), la qualité technique, la facilité des outils de création, la doc et l'aide ont souvent tout autant voir plus d'importance que l'outil final.
Cqfd : si personne n'est emballé pour empaqueter, le store au final restera vide.
Perso, je préfère engager du temps sur des projets comme apt/nix (guix, je découvre donc j'ai pas encore d'avis) plutôt que perdre mon temps avec snap/flatpak/appimage.
Pour ton comparatif Guix/Nix, 3 points non techniques et totalement subjectifs :
- Le nom Guix est sans doute mieux choisi que Nix car y'a pas d'embrouille pour les moteurs de recherche : point pour Guix.
- Le logo de Nix est une pure merveille d'ingéniosité : des lambdas qui forment un flocon de neige alors que Guix, je cherche toujours (une tête de gnou probablement) : point pour Nix
- les moteurs de recherche web des paquets : point pour Nix même si lent (la requète ajax qui rappatri un gros json avec tous les paquets est juste horrible)
Peux-être une question bête car j'ai peu d'expérience sur l'emquetage de projet en C++ : Les dépendances "boost, openssl, websocketpp, zlib" sont obligatoires ? Qu'elle est ton cheminement pour les trouver ?
Guix me parait sympa mais arrive bien après une version stable de Nix qui présente tous les avantages cités + d'avantages de paquets + 1 plus grande communauté.
Du coup, j'ai de la peine à comprendre l'intérêt autours de Guix (à part pour les barbus RMSiste) et déplore encore de la fragmentation qui ça engendre.
Etant l'auteur de l'aspect graphique et sachant que je n'ai finalisé les détails bien après les 90% de la partie technique, j'en suis pas mal responsable.
Les 2 points évoqués peuvent être corrigés mais je ne vois pas de solution "simple".
Le fait de choisir aléatoirement ou doivent être placé les animaux me semble plutôt bon didactiquement parlant.
Si l'on veut faire les choses bien, il faudrait déplacer les enclos de place je suppose.
Les animaux semble voler au dessus du poulailler : en gros, délimiter des zones ou les animaux peuvent être glissés mais pas déposés.
C'est pas impossible mais mon expérience me fait dire qu'on risque des bugs sournois. (surtout si on envisage le déplacement des enclos)
Pour la suppression d'un animal, c'est bien noté dans la consigne.
C'est l'aspect graphique qui ne te plais pas dans les boutons ?
Si oui, les rendre plus joyeux, ne veux pas forcément dire d'utiliser des images :le css fait des prouesses à faible frais désormais.
La partie démarrage pourrais se faire dans une petite modale qui serait caché une fois l'exercice commencé. (ça laisserais plus de place à l'écran également)
Un bouton d'aide avec un exemple par étapes pourrait rendre la compréhension plus efficace.
En se rappelant que cet applicatif fera partie d'un tout (une liste d'applicatif), ils nous faudra sans doute réfléchir à retrouver des codes communs tout en gardant un peu de souplesse sur des variétés graphiques.
Pour ce qui est d'écouter la consigne : je développe actuellement une refonte de gspeech (https://github.com/mothsART/speechtux) qui ferais office de serveur de synthèse vocale avec une API.
Via un petit greffon, il sera tout à fait possible de rajouter des consignes "sonores".
Néanmoins, à l'usage, je ne suis pas certain que beaucoup de classes seront équipés en casques afin d'éviter la cacophonie.
Ça reste donc une évolution loin d'être prioritaire.
Je ne me suis encore jamais plongé dans le projet Gcompris mais j'ai cru comprendre que c'était dev en QT donc pas forcément compatible avec de la techno web. (mais j'adorerais qu'on me prouve le contraire)
Quand tu parles de la possibilité de se séparer d'électron, y'a bien entendu la possibilité d'utiliser un petit serveur web local.
Dans mon éditeur interactif, j'ai fait le choix d'aller au plus simple : j'utilise l'API HTML5 file.
C'est pas parfait car ça nécessite de charger le fichier en mémoire puis de l'exporter une fois terminé.
Après, y'a sans doute des solutions hybrides possibles : ton soft s'ouvre sur un firefox qui contient une extension assurant la partie sauvegarde par exemple.
On parle aussi beaucoup des Progressives Web App mais j'ai pas encore suffisamment creusé la question.
Pour les exemples, il faudrait sans doute proposer un petit concours ici sur un thème : par exemple, illustrations éducatives pour les enfants des 3 premiers cycles. (Oui, si ça peut servir des projets comme Primtux, c'est encore mieux)
Enfin, j'ai parcourus quelques réalisations qui sont certes sympas mais qui ont manqués de réactivités les premières secondes (https://sozi.baierouge.fr/community/d/43-support-de-conf-rence-culture-libre).
Je vois plusieurs raisons de frustration à mon sens :
- fichier svg non minifié : un coup de svgo pourrait sans doute permettre de gagner quelques Mo précieux
- un chargement progressif : première slides chargés avant et pourquoi pas une barre de chargement
- les animations sont-elles effectués par le css ou le js ?
Une piste de réflexion que je me donne également pour mes futures projets webs : canvas est beaucoup plus réactif que svg.
J'ai effectué des tests de svg avec des animations css que j'ai comparé avec canvas (sur une grande matrice : 2048*2048) avec des animations js.
Eh bin, canvas était à chaque fois au moins 4 à 5 fois moins gourmand.
A creuser sans doute : une conversion du svg en canvas.
Voilà, je sais que la critique est au combien facile. J'espère que celle-ci sera suffisamment constructive.
Vu qu'elles sont intégrés par mes soins, tu peux me faire des remarques directement.
(Je ferais suivre si besoin)
A l'avenir (paquet debian séparé pour l'instant mais je vais sans doute faire pareil pour le dépôt GIT), je souhaites séparer contenu et éditeur pour éviter les amalgames.
Les exemples sont également visible dans l'éditeur. il suffit de les charger puis de les prévisualiser.
J'ai commencé également un paquet debian pour Primtux qui rassemble l'ensemble des illustrations définitives prêt à être utilisé dans le cadre éducatif : https://github.com/mothsART/illustrationsvg
Chaque illustration à son lanceur : .desktop et png
@ElectronLibre63 : Je viens de soumettre une PR : https://framagit.org/marsat/CTparental/merge_requests/1
Toi aussi tu pourrais le faire… ça te prendrais un tout petit peu plus de temps que ce commentaire.
(pour ma part : 10 minutes montre en main)
Je vais sans doute voir pour faire une autre PR pour le « 0 minutes déjà utilisées »
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 3. Dernière modification le 13 mai 2020 à 23:50.
Ouais, enfin l'un n'empêche pas l'autre.
Avec un langage fortement typé et qui fait un max de vérifications à la compilation, tu t'évites l'écriture d'une paires de tests (débiles pour la plupart) qu'un langage interprété et faiblement typé t'oblige pour avoir la même rigueur avant déploiement.
La solidité de ton déploiement : c'est pas forcément au dev de gérer ça donc hs.
La simplicité du rollback : si tu rollback, c'est que t'as cassé la prod, non ? (donc pouvoir rollback c'est bien mais éviter de casser la prod, c'est mieux)
Niveau workflow, j'aurais plutôt parlé des logs, des métriques, des envs de recette avec cahiers de tests (tu sais, piloté par des humains : c'est encore ce qui se fait de mieux).
[^] # Re: Flatpak?
Posté par mothsART . En réponse au journal Sortie de ./play.it 2.11.4. Évalué à 2.
Pourquoi Flatpak ? Et pourquoi pas Nix ?
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à -2.
https://www.youtube.com/watch?v=3w5cwBrvtf4
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 9.
Pour des softs comme rigrep, l'objectif de l'auteur était clairement d'avoir un grep le plus rapide qui soit et la promesse est tenu en partie par le langage.
Pour les autres, effectivement, dans l'absolu, Rust ne se justifie sans doute pas.
Après, je pense que beaucoup ont tendance à mettre Rust dans la case "bas niveau" à tord.
De ma propre expérience, c'est pas forcément ce qui m'a attiré en premier.
J'ai voulu m'investir dans un langage robuste il y a 4 ans et je l'ai comparé à Go (et à d'autres) à l'époque.
Malgré sa jeunesse, il présentait des vertus sur le typage, pattern matching, programmation fonctionnel qui me semblait bien plus pointus que ceux de Go.
Je ne connais pas l'état actuel de Go mais vu comment ça a évolué niveau Rust : communauté, évol du langage, doc etc… je pense que je ferais le même choix aujourd'hui.
Crystal, que je ne connais que de nom, me parait plus exotique et Occaml (même constat pour Haskell) reste et restera (malgré son âge et sa maturité) un langage de niche plutôt académique.
A titre pro, j'ai jonglé avec Java et C# et je voulais aussi investir dans un langage qui soit moins piloté par une grosse boite donc difficile de privilégier des "Swift", "Kotlin", "Scala", "Go".
( Surtout Google qui n'a aucun scrupule à abandonner une techno dès qu'elle est pas rentable)
Sur l'aspect utilisateur, je trouve aussi qu'avoir des outils cli qui n'utilise pas de GC est un gros avantage.
Sur du linux, on sait très bien qu'on peut avoir un panel de softs très hétérogènes et que ça peut avoir un impact mémoire non négligeable tout cumulé.
Franchement, me dire que sur un serveur, un rpi etc, je vais avoir des cron avec des scripts en python, en nodejs, en scala, en Go etc… et bien je vais me taper n GC qui consomment de la mémoire inutilement.
En C ou en Rust, ça ne sera pas le cas. (sauf cas de fuite, bien entendu)
Je fais sans doute parti de ses dinosaures qui ont du mal à comprendre pourquoi on gaspille tant de mémoire actuellement pour des trucs basiques.
C'est pas du deep learning mais des pauvres scripts et plus c'est populaire et plus ça devrait être insignifiant en impact mémoire, en temps de démarrage etc.
[^] # Re: Ça a l'air intéressant mais on aimerait avoir une présentation du logiciel
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 6.
Effectivement, quand j'ai vu que ça s'emballait… j'ai préféré ne pas répondre par peur que ça soit mal interprété peu importe mes propos.
Bien évidemment, en employant "modérateur", je partais du postulat que ce mot est neutre.
D'apprendre que l'équipe de modération est mixte me réjoui.
J'essaierai (dans la mesure de mes capacités) d'y faire attention à l'avenir.
[^] # Re: synergie ?
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 4.
C'est effectivement quelque chose que j'ai déjà envisagé.
Pour un autre projet, je me suis déjà amusé à mettre le nez dans les sources de grammalecte et parser certains dictionnaires.
Je dirais que l'intérêt pour gSpeech résiderais plus sur les données collectés plutôt que sur les algos qui sont plus dédiés a de la reconnaissance en vue d'un correctif.
En fait, la lib picovox lit déjà naturellement pas mal de texte correctement.
Il y a malheureusement quelques subtilités (que je comble avec les algos énumérés plus haut) et il est très délicat de les appréhender. (à part l'identifier via une lecture)
Je ne suis pas certain qu'il y ai des données tel que de la phonétique dans grammalecte mais si c'est le cas, ça pourrait être du pur caviar pour le second projet : speechtux.
Mais oui, y'a sans doute des pistes à explorer tel qu'une lecture gardé fluide malgré quelques fautes d'orthographes ou de saisie par exemple.
[^] # Re: Common Voice
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 1. Dernière modification le 17 avril 2020 à 15:01.
J'avais un peu oublié ce projet.
Je vais prendre le temps d'y participer.
Qui sait, un jour gSpeech s'interfacera peut-être dessus.
[^] # Re: Ça a l'air intéressant mais on aimerait avoir une présentation du logiciel
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 2. Dernière modification le 16 avril 2020 à 20:40.
Très bien.
Serais-ce possible à un modérateur de rajouter en intro :
Egalement, serait-il possible de remplacer :
par :
[^] # Re: Ça a l'air intéressant mais on aimerait avoir une présentation du logiciel
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 6.
T'as pas à être désolé, il manque effectivement un prélude. (je pensais, à tord que c'était assez connu)
Y'a un peu de doc ici : https://doc.ubuntu-fr.org/svoxpico et je viens d'éditer ça :
https://wiki.primtux.fr/doku.php/gspeech
Je compléterais sans doute mais tu m'as pris de court.
Et oui, c'est bien de la synthèse vocale (et non de la reconnaissance vocal).
# oubli : appli "j'écoute puis j'écrit"
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 6.
J'ai oublié de mettre le lien de l'app Primtux "J'écoute puis j'écris" (non finalisé) : https://primtux.fr/applications/ecoute-ecris/
[^] # Re: snap et faltpak : on nous ment sur la marchandise
Posté par mothsART . En réponse à la dépêche Guix pour remplacer mon gestionnaire de paquets APT. Évalué à 1.
Alors, j'ai fait la même opération que l'auteur mais avec Nix et j'en suis actuellement à 7.3G (du -sh /nix/store) avec la dernière version de gimp, inkscape, geany, guake, une quinzaine de petits utilitaires et sans doute une bonne cinquantaine de doublons lié aux paquets que j'ai empaqueté.
Je pense, le mieux pour te faire une idée est déjà de faire l'install minimal et de surveiller paquet par paquet.
Tout est mis dans /nix/store (ou /gnu/store si tu pars sur guix) et il t'es donc facile de surveiller l'évolution.
# snap et faltpak : on nous ment sur la marchandise
Posté par mothsART . En réponse à la dépêche Guix pour remplacer mon gestionnaire de paquets APT. Évalué à 7. Dernière modification le 21 mars 2020 à 21:46.
Tout d'abord, merci de cet article.
Il n'y a quasiment aucun article francophone sur le sujet donc rien que pour ça, ça nécessite d'être souligné !
Connaissant Nix, je vois bien entendu beaucoup de similitudes.
/gnu/store au lieu de /nix/store mais même principe : des noms de paquet avec des hash.
Même constat que pour Nix : pourquoi diable avoir mis les hash avant les noms…
Pour ce qui est Snap et FlatPak : c'est très orienté user avec des outils graphiques mais dès qu'on regarde un peu de plus prêt… la magie n'opère plus.
Je pense avoir un peu de recul sur la création de paquets : j'ai déjà fait moultes paquets debian, un peu d'archlinux, des paquets Python, Rust et depuis peu Nix et j'ai trouvé (il y a un peu plus d'un an) les tutos et la doc de Snap et Flatpak totalement ridicules.
Dès qu'on sort du hello world avec plus de 2/3 dépendances, ça devient très compliqué à empaqueter et à maintenir.
J'estimes que dans la communauté Linux (tout du moins je l'espère), la qualité technique, la facilité des outils de création, la doc et l'aide ont souvent tout autant voir plus d'importance que l'outil final.
Cqfd : si personne n'est emballé pour empaqueter, le store au final restera vide.
Perso, je préfère engager du temps sur des projets comme apt/nix (guix, je découvre donc j'ai pas encore d'avis) plutôt que perdre mon temps avec snap/flatpak/appimage.
Pour ton comparatif Guix/Nix, 3 points non techniques et totalement subjectifs :
- Le nom Guix est sans doute mieux choisi que Nix car y'a pas d'embrouille pour les moteurs de recherche : point pour Guix.
- Le logo de Nix est une pure merveille d'ingéniosité : des lambdas qui forment un flocon de neige alors que Guix, je cherche toujours (une tête de gnou probablement) : point pour Nix
- les moteurs de recherche web des paquets : point pour Nix même si lent (la requète ajax qui rappatri un gros json avec tous les paquets est juste horrible)
# Sympa
Posté par mothsART . En réponse au journal Gestion de paquets et DevOps avec Nix, tour d'horizon sur un cas concret. Évalué à 1. Dernière modification le 24 janvier 2020 à 13:45.
Comme toujours, très édifiant.
Peux-être une question bête car j'ai peu d'expérience sur l'emquetage de projet en C++ : Les dépendances "boost, openssl, websocketpp, zlib" sont obligatoires ? Qu'elle est ton cheminement pour les trouver ?
# intéresssé mais
Posté par mothsART . En réponse au journal Guix : un outil pour les remplacer tous. Évalué à 6.
Guix me parait sympa mais arrive bien après une version stable de Nix qui présente tous les avantages cités + d'avantages de paquets + 1 plus grande communauté.
Du coup, j'ai de la peine à comprendre l'intérêt autours de Guix (à part pour les barbus RMSiste) et déplore encore de la fragmentation qui ça engendre.
[^] # Re: première analyse scientifique
Posté par mothsART . En réponse au journal À la campagne, application éducative javascript. Évalué à 1.
Oui, donc QT5, à part javascript, c'est pas du web.
L'ancienne version c'est du GTK, Python et C.
[^] # Re: première analyse scientifique
Posté par mothsART . En réponse au journal À la campagne, application éducative javascript. Évalué à 1.
Etant l'auteur de l'aspect graphique et sachant que je n'ai finalisé les détails bien après les 90% de la partie technique, j'en suis pas mal responsable.
Les 2 points évoqués peuvent être corrigés mais je ne vois pas de solution "simple".
Le fait de choisir aléatoirement ou doivent être placé les animaux me semble plutôt bon didactiquement parlant.
Si l'on veut faire les choses bien, il faudrait déplacer les enclos de place je suppose.
Les animaux semble voler au dessus du poulailler : en gros, délimiter des zones ou les animaux peuvent être glissés mais pas déposés.
C'est pas impossible mais mon expérience me fait dire qu'on risque des bugs sournois. (surtout si on envisage le déplacement des enclos)
Pour la suppression d'un animal, c'est bien noté dans la consigne.
[^] # Re: première analyse scientifique
Posté par mothsART . En réponse au journal À la campagne, application éducative javascript. Évalué à 1.
C'est l'aspect graphique qui ne te plais pas dans les boutons ?
Si oui, les rendre plus joyeux, ne veux pas forcément dire d'utiliser des images :le css fait des prouesses à faible frais désormais.
La partie démarrage pourrais se faire dans une petite modale qui serait caché une fois l'exercice commencé. (ça laisserais plus de place à l'écran également)
Un bouton d'aide avec un exemple par étapes pourrait rendre la compréhension plus efficace.
En se rappelant que cet applicatif fera partie d'un tout (une liste d'applicatif), ils nous faudra sans doute réfléchir à retrouver des codes communs tout en gardant un peu de souplesse sur des variétés graphiques.
Pour ce qui est d'écouter la consigne : je développe actuellement une refonte de gspeech (https://github.com/mothsART/speechtux) qui ferais office de serveur de synthèse vocale avec une API.
Via un petit greffon, il sera tout à fait possible de rajouter des consignes "sonores".
Néanmoins, à l'usage, je ne suis pas certain que beaucoup de classes seront équipés en casques afin d'éviter la cacophonie.
Ça reste donc une évolution loin d'être prioritaire.
Je ne me suis encore jamais plongé dans le projet Gcompris mais j'ai cru comprendre que c'était dev en QT donc pas forcément compatible avec de la techno web. (mais j'adorerais qu'on me prouve le contraire)
# PWA ?
Posté par mothsART . En réponse à la dépêche De Sozi 12 à Sozi 19. Évalué à 4.
Sympa comme soft!
Quand tu parles de la possibilité de se séparer d'électron, y'a bien entendu la possibilité d'utiliser un petit serveur web local.
Dans mon éditeur interactif, j'ai fait le choix d'aller au plus simple : j'utilise l'API HTML5 file.
C'est pas parfait car ça nécessite de charger le fichier en mémoire puis de l'exporter une fois terminé.
Après, y'a sans doute des solutions hybrides possibles : ton soft s'ouvre sur un firefox qui contient une extension assurant la partie sauvegarde par exemple.
On parle aussi beaucoup des Progressives Web App mais j'ai pas encore suffisamment creusé la question.
Pour les exemples, il faudrait sans doute proposer un petit concours ici sur un thème : par exemple, illustrations éducatives pour les enfants des 3 premiers cycles. (Oui, si ça peut servir des projets comme Primtux, c'est encore mieux)
Enfin, j'ai parcourus quelques réalisations qui sont certes sympas mais qui ont manqués de réactivités les premières secondes (https://sozi.baierouge.fr/community/d/43-support-de-conf-rence-culture-libre).
Je vois plusieurs raisons de frustration à mon sens :
- fichier svg non minifié : un coup de svgo pourrait sans doute permettre de gagner quelques Mo précieux
- un chargement progressif : première slides chargés avant et pourquoi pas une barre de chargement
- les animations sont-elles effectués par le css ou le js ?
Une piste de réflexion que je me donne également pour mes futures projets webs : canvas est beaucoup plus réactif que svg.
J'ai effectué des tests de svg avec des animations css que j'ai comparé avec canvas (sur une grande matrice : 2048*2048) avec des animations js.
Eh bin, canvas était à chaque fois au moins 4 à 5 fois moins gourmand.
A creuser sans doute : une conversion du svg en canvas.
Voilà, je sais que la critique est au combien facile. J'espère que celle-ci sera suffisamment constructive.
[^] # Re: PrimTux démarre la création de contenu pour l'école par des illustrations interactives
Posté par mothsART . En réponse au journal Edit Interactive SVG 1.1. Évalué à 2.
Corrigé, merci.
[^] # Re: PrimTux démarre la création de contenu pour l'école par des illustrations interactives
Posté par mothsART . En réponse au journal Edit Interactive SVG 1.1. Évalué à 1.
Bien sur, tu peux retrouver mes coordonnées dans le changelog
[^] # Re: PrimTux démarre la création de contenu pour l'école par des illustrations interactives
Posté par mothsART . En réponse au journal Edit Interactive SVG 1.1. Évalué à 2.
Vu qu'elles sont intégrés par mes soins, tu peux me faire des remarques directement.
(Je ferais suivre si besoin)
A l'avenir (paquet debian séparé pour l'instant mais je vais sans doute faire pareil pour le dépôt GIT), je souhaites séparer contenu et éditeur pour éviter les amalgames.
[^] # Re: PrimTux démarre la création de contenu pour l'école par des illustrations interactives
Posté par mothsART . En réponse au journal Edit Interactive SVG 1.1. Évalué à 2.
Les exemples sont également visible dans l'éditeur. il suffit de les charger puis de les prévisualiser.
J'ai commencé également un paquet debian pour Primtux qui rassemble l'ensemble des illustrations définitives prêt à être utilisé dans le cadre éducatif : https://github.com/mothsART/illustrationsvg
Chaque illustration à son lanceur : .desktop et png
# commande eg
Posté par mothsART . En réponse au journal Ligne de commande : les 20 mémos d'un « autodidacte ». Évalué à 2.
Faut rassembler tout ton savoir dans un dépôt git utilisable par eg : https://github.com/srsudar/eg
[^] # Re: impressionnant
Posté par mothsART . En réponse à la dépêche PrimTux — nouvelle version pour les écoles. Évalué à 3. Dernière modification le 29 octobre 2018 à 13:58.
@ElectronLibre63 : Je viens de soumettre une PR : https://framagit.org/marsat/CTparental/merge_requests/1
Toi aussi tu pourrais le faire… ça te prendrais un tout petit peu plus de temps que ce commentaire.
(pour ma part : 10 minutes montre en main)
Je vais sans doute voir pour faire une autre PR pour le « 0 minutes déjà utilisées »
# Quel moteur de rendu ?
Posté par mothsART . En réponse au journal Un navigateur totalement personnalisable ? En Lisp ? Next-browser. Évalué à 2.
Au final, ça utilise du webkit derrière ou un autre moteur de rendu ?