Goffi a écrit 1553 commentaires

Avec les propriétés, comme expliqué dans la dépêche, tu peux déjà faire un rendu dépendant de l'état.

Je n'ai pas poussé l'exemple trop loin pour ne pas rendre la dépêche trop indigeste, mais tu peux utiliser des conditions dans les valeurs. Par exemple dans mon client XMPP, je m'en sers pour afficher un avatar par défaut si je n'ai pas d'avatar pour l'entité, ou pour afficher une couleur de cadenas différente en fonction de l'état du chiffrement.

Exemple:

        MessAvatar:
            id: avatar
            source: root.mess_data.avatar['path'] if root.mess_data and root.mess_data.avatar else app.default_avatar
            on_press: root.chat.add_nick(root.nick)

Ce code créé un widget MessAvatar, et affiche l'avatar par default si aucun avatar n'est déclaré. Il ajoute aussi un handler pour mettre le surnom de l'utilisateur en cas de clique. En python, ça serait plus long à écrire, et un peu moins lisible.

Si tu dois ajouter/enlever dynamiquement des widgets, il faut passer par python, mais tes widgets peuvent être complètement déclarés dans kv, même si ajoutés ensuite dynamiquement.

À l'usage c'est très pratique, et c'est pas pour rien que ce n'est pas le seul framework à faire ceci (je pense à QML avec Qt par exemple).

C'est en complément, tu utilises toujours python à côté. Kv et son côté descriptif pour faire le squelette de ton UI c'est vraiment rapide est agréable.

Et c'est assez propre aussi d'avoir la partie UI pure séparée du code.

Après c'est vrai qu'aujourd'hui avec les dataclasses et Pydantic, on pourrait avoir un résultat similaire en restant en python (mais tout ceci n'existait pas quand Kivy a été conçu).

Si je comprends bien, tu perds tout le contenu à moins que tu ai fait une copie préalable ?

• Tu peux mettre en place une synchro automatique entre des dépôts facilement.
• Tu as une copie en local des dépôts sur lesquels tu travailles, et possiblement des tickets selon ton client (Libervia utilise un cache par exemple, tu peux retrouver à partir de là).

Ça va paraître provocateur mais est-ce que c’est pas plus simple :

• d’avoir un format d’export/import standard et de l’implémenter dans autant de forge que possible voir de faire des > outils pour les forges récalcitrantes
• de proposer une authentification OAuth avec la clique habituelle + github, gitlab, linuxfr,…

• Le format d'export standard, c'est la spéc XMPP.

• OAuth (qui est d'ailleurs supporté par XMPP) ne gère que l'authentification, et souvent tu as un compte en local qui est recréé. Ça n'est pas pareil qu'avoir tout le système décentralisé, avec les informations d'identité (vCard, avatar, etc), les clefs de chiffrement, les permissions, la possibilité de lier facilement des éléments ailleurs, l'inscription et les notifications, etc.
  Si je pouvais me connecter à Github avec mon compte linuxfr, ça ne changerait pas grand chose au fait que je ne peux pas facilement forker sur un autre serveur, lier un ticket, etc.

Tu compliques un peu, décentralisé ne veut pas dire avoir les commentaires distribués partout et reconstruire un truc cohérent après coup (ça peut vouloir dire ça si on veut, mais ça peut être beaucoup plus simple).

Dans le cas de XMPP, c'est le serveur pubsub du dépôt principal qui gère les tickets et tout (numéro de ticket, de merge request, etc), c'est un peu comme une mini forge centralisée. Donc tu peux modérer en cas de comportement incorrect ou de spam.

L'intérêt par rapport à une forge centralisée comme Github c'est que:

• c'est un compte XMPP, donc l'authentification est gérée par le mécanisme XMPP, donc le serveur de la personne qui contribue. Pas besoin de créer un compte sur chaque forge.

• Si une forge veut supprimer un projet (comme c'est déjà arrivé plusieurs fois sur Github, avec yt-dl par exemple), il est très facile de le passer sur une autre, et les contributeurs et contributrices peuvent continuer sans changer leur compte (en changeant uniquement l'adresse de la forge).

• Les tickets peuvent être clonées et mis sur une autre forge, c'est de simples nœuds pubsub à cloner.

• Git et Mercurial sont déjà décentralisés, donc pareil, il suffit de cloner pour aller ailleurs.

Bref, sur ta forge tu es chez toi et tu la gères comme tu l'entends. Comme une mini forge centralisée, à la grosse différence près c'est qu'il est très facile de passer sur une autre en cas de problème (technique, politique, etc.), sans avoir à recréer de compte pour les contributeurs et contributrices.

Github a un effet réseau énorme qui limite l'intérêt des petites forges parce que les gens ont la flemme de créer un autre compte, et que ça n'est pas possible/simple de faire des liens entre des tickets/des pull requests/autre sur d'autres forges.

Avec XMPP, chacun peut faire sa propre forge, et c'est l'équivalent un gros service en groupant plein de petits , on peut communiquer et lier facilement les choses entres elles. Je suppose que ce qui est fait avec ActivityPub est plus ou moins similaire (mais encore une fois, je n'ai pas suivi de près, vu que la roue est plus ou moins réinventée, encore une fois).

Courage, Libervia mérite tes efforts!

Merci :)

Ah tu parles spécifiquement des projets liés à ça, je pensais que tu critiquais tout le système NLnet/NGI. Dans le cas précis des forges basées sur ActivityPub, je n'ai pas suivi de près (j'avais été contacté vite fait quand ça a été commencé, puis XMPP ne les intéressait illes ont préféré refaire avec AP).

S'il y a de la demande, je ne serais pas contre intégrer ça à la passerelle AP<=>XMPP un jour (si c'est raisonnablement faisable), mais en attendant, XMPP rempli toutes les cases au moins pour moi.

Alors je fais en général les choses de manière générique, de façon a pouvoir changer de backend, et Libervia est extensible (je suis en train de travailler sur cette partie là aussi, et sur la doc) donc il peut il y avoir des contributions tierces et il sera sans doute possible de gérer d'autres VCS.

Par contre, si je veux passer à Git, c'est parce que c'est le VCS de référence incontestable. Pour d'autres options, ça ne sera pas dans l'immédiat, je n'ai pas actuellement les ressources (je suis complètement sous l'eau).

NlNet et co qui servent quand même souvent de vache à lait pour avoir des thunes et rien faire de substantiel

Alors je suis moi même bénéficiaire de subvention NLnet/NGI (j'en ai eu plusieurs), donc je ne suis pas neutre. Mais dire un truc pareil c'est franchement insultant autant pour le boulot de fou qu'ils et elles font, et pour les bénéficiaires.

Quand une subvention est acceptée (après une validation de plusieurs mois en 2 étapes, 1 première sélection suivie d'une deuxième avec des questions aux projets), on a un appel en visio pour présenter les choses, et on se met d'accord sur un "Memorandum of Understanding". Ça n'est pas un contrat (on n'est pas employé·e·s) mais c'est un accord sur les étapes à faire avec des livrables (une merge-request par exemple) et les sommes demandées. Ces étapes sont proposées par le projet et validées par l'équipe de NLnet, et la sommes des étapes doit correspondre au total accordé.

On ne reçoit rien si on ne fait rien, il faut finir une étape, et ensuite c'est vérifié, et enfin payé, ce qui peut mettre jusqu'à 3 semaines (et je me suis d'ailleurs plusieurs fois retrouvé mal parce que j'avais sous estimé — Comme tout développeur·se qui se respecte — le temps qu'il fallait pour une étape). Ça arrive d'ailleurs qu'on ne puisse pas finir toutes les étapes avant la fin du programme, et alors une partie de la somme accordée est perdue (ça m'est arrivée sur ma première subvention).

Alors il est fort possible, que sur tous les projets financés, certains n'ont pas fait toutes les étapes, et la subvention n'a pas donné ce qui était attendu (encore une fois ça n'est pas un contrat, il n'y a pas d'obligation, on ne reçoit juste par l'argent si les choses ne sont pas faites). Mais je vois énormément de projets, dont certains que j'utilise régulièrement, qui ont pu se développer grâce à NLnet/NGI, et d'ailleurs dans le monde XMPP il y a pas mal de spécifications qui ont vu le jour grâce à ça, et plusieurs logiciels qui ont pu se développer.

NLnet/NGI ont donné et donnent toujours un aide énorme à des tonnes de projets, et il y a de bonnes chances que celles et ceux qui me lisent en bénéficient via un projet financé.

C'est une des meilleures choses qui est arrivée au logiciel libre ces dernière années (et je suis loin d'être le seul à le dire).

On utilise les mêmes extensions oui, et on se connaît, si quelque chose ne fonctionne pas, on cherche à corriger.

Libervia gère aussi le blogging/microblogging, et c'est déjà implémenté dans la passerelle AP<=>XMPP (les messages directs sont convertis en messages de chat, les message publics sont convertis en blogs XMPP et vice versa).

Je suis justement en plein redesign, et il est fort probable que je passe finalement à Git, de plus en plus d'outils ne prenant en compte que Git (notamment uv qui devient la référence en Python). C'est dommage, Mercurial est vraiment un bon outil, et plus intuitif que Git.

C'est ce que je fais avec XMPP pour mon projet Libervia depuis des années  : une forge (enfin pour le moment des tickets et un système de merge requests) décentralisée, et accessible avec tout compte XMPP. C'est basé sur Pubsub, ça veut dire que de nombreuses chouette fonctionnalités sont possibles, comme le chiffrement de bout en bout (pour faire un ticket sensible, comme un rapport de bogue sur une faille de sécurité par exemple).

L'idée a été reprise pour ActivityPub avec ForgeFed. J'ai également une passerelle ActivityPub <=> XMPP, il est possible, si je trouve les ressources, d'ajouter une compatibilité pour ces fonctionnalités à terme.

Si tu veux que le serveur n'ait pas accès au contenu d'un groupe (MUC), il te faut du chiffrement de bout en bout. C'est en général OMEMO qui est utilisé, et pas mal de clients l'activent par défaut. Les salons peuvent être publics ou caché, ouverts à toutes et tous, ou accessible uniquement aux membres.

Pour monter facilement un serveur à héberger soit même, tu peux utiliser Snikket qui est maintenu par l'équipe de Prosody, et qui a des apps du même nom sur Android et iOS (mais qui fonctionne avec n'importe quel client XMPP).

"c'est null, ça marche pas"

Alors ça c'est un cas d'école de faute de développeur·se ! 😃

Ça avance oui, mais effectivement pas facile tous les jours. Je vais sans doute écrire un billet de blog à l'occasion pour faire le point.

En tout cas c'est vraiment chouette pour GIMP 3, sortir une telle version après des années de boulot, c'est quelques chose.

Bravo pour cette release et pour avoir tenu sur la longueur !

Vaut mieux attendre un mois ou deux, je suis en plein travail sur le design. Je ferai une annonce ici à la sortie de la prochaine version, ça sera le bon moment pour tester.

Il y a des clients spécialisés, notamment il y a Prose qui cible précisément ça : https://prose.org/ . Le chat professionnel est aussi un cas d'utilisation que je cible avec Libervia.

Mattermost apporte plus facilement des fonctions de travail en équipe (par exemple les wokflows)

Peux-tu me décrire précisément ce que c'est/me donner un cas d'utilisation concret ? J'ai des fonctionnalités d'automatisation dans ma TODO list, et du coup ça m'intéresse d'avoir des cas concret d'utilisation pour être sûr que ça aide.

Le problème principal, c'est que la plupart des clients sont développées par de très petites équipes, et la plupart du temps par des personnes seules. Peu de développeurs/développeuses de clients XMPP sont financé·e·s. NLnet/NGI ont fait beaucoup de bien de ce côté, mais il faut un modèle plus pérenne pour maintenir de tels logiciels et avoir les ressources pour rentre le tout agréable à utiliser, accessible, et complet.

De gros progrès ont été faits ces dernières années, et il y a des projets (dont Libervia sur lequel je travaille) qui cherchent à avoir un modèle viable sur le long terme.

XMPP et Matrix ne font pas tout à fait la même chose non ?

Qu'entends tu par là ? XMPP (et probablement Matrix aussi) permet de faire tout ce que fait Slack.

D'ailleurs, Jitsi c'est du XMPP.

Dans le journal précédent j'avais parlé de la Qidi Plus 4, je l'ai depuis achetée (n'ayant malheureusement pas de Fablab/Hackerspace à proximité). J'en suis pour le moment très content : elle est rapide, fonctionne très bien (je n'ai testé qu'avec du PLA pour le moment), on peut se connecter en SSH en root, et les logiciels fournis sont libres.

J'ai eu un crash avec "Qidi Studio" sur mon Arch, mais Orca Slicer fonctionne très bien, et cette imprimante ainsi que les filaments de la même marque sont pré-configurés, ça fonctionne directement.

En plus de ça, c'est une des rares imprimantes (et je pense la seule à ce prix) capable d'attendre des hautes températures avec la buse (370°C), ce qui lui permet d'utiliser des filaments techniques.

Elle est aussi compatible multi-couleurs avec un boîtier à venir.

D'après ce que j'ai lu, le support technique est réactif. Il y a eu quelques soucis au lancement de l'imprimante qui sont depuis réglés (aucun problème avec le mienne, j'ai juste du démonter l'extrudeur à cause d'un filament bloqué, mais c'est parce que j'ai utilisé un filament vieux de 10 ans qui s'est cassé au mauvais endroit).

On m'a dit que t'étais vers le stand Gnome, je suis passé, mais tu n'y étais pas, c'est pas grave, on se croisera une prochaine fois :)

Oui il y a toujours le XMPP Summit, c'est les 2 jours qui précèdent le FOSDEM. La XSF paye le salle et les repas de midi (plus un diner traditionnelle offert aux membres de la XSF), mais par contre on doit payer l'hébergement nous-même.

Le stand XMPP est le "RT Lounge", dans le debriefing on a justement fait remarquer que c'était dommage que XMPP n'apparaissaient pas dans le nom, beaucoup de personnes nous ont dit l'avoir cherché. Pareil pour la devroom, c'était le plus générique "RTC devroom", et la seul conf sur XMPP était la mienne.

Si tu cherches les infos à l'avenir, elles sont sur le le site officiel, son blog/sa newsletter, et sur le wiki.

Peter ne vient plus depuis longtemps, il est toujours trésorier, mais il s'est beaucoup éloigné de la technologie et ne suit plus que d'un œil.

Et oui bien sûr, pareil j'aurais bien vu ta conf, mais cette année je n'en ai vu aucune, j'ai été trop pris. J'ai juste fait un tour des stands. En fait je n'ai pas eu le temps de voir grand monde plus de quelques minutes cette année.

Passe nous voir au RT Lounge (K2), ça nous fera plaisir de te voir!

Malheureusement j'arrive à peine. Trop tard pour voir la conf.

Merci de ta réponse. Sur la papier ça a l'air vraiment pas mal, je vais attendre un peu et voir l'évolution, peut être attendre la sortie du boîtier multi-couleurs.

Merci pour cette réponse détaillée. Il y a les colorants et les rainures/creux, et aussi le fait de changer de fil, et des résidus qui traînent ça et là. Dans le cas de l'entonnoir à poivre plus haut ça n'est probablement pas bien grave, mais pour une utilisation régulière au contact des aliments, je ne serais pas très à l'aise.