Justement à ce propos, il serait bien d'en savoir un peu plus sur les modes de donations (flattr ou autres) ; tout n'est pas très clair ?!
Pour GIMP? Alors déjà, comme tu le notes, oui nos fonds GIMP sont gérés par la fondation GNOME. C'est un peu comme si on avait un compte chez GNOME (et si je ne me trompe pas, ils prennent un pourcentage pour payer l'administratif supplémentaire que ça leur donne). La raison, c'est que GIMP en soi n'a pas d'entité juridique propre. C'est ce qu'on appellerait une association de fait dans les pays francophones (au moins en France et Belgique). Mais note bien que cet argent donné à GIMP va vraiment à GIMP. GNOME garde une comptabilité distincte et cet argent donné pour nous n'est absolument pas utilisé par GNOME. Il est juste gardé par eux en notre nom.
Ensuite à quoi sert cet argent? Il sert principalement à réunir les développeurs régulièrement, dans des évènements comme Wilber Week ou Libre Graphics Meeting. Cela ne paye pas directement du développement. Mais comme Pierre Jarillon le note dans un commentaire, les rencontres de développeurs restent très importantes et ne sont pas à négliger. Je ne veux surtout pas donner l'impression de vouloir minimiser cela et si c'est là où tu veux donner, merci!
Pour soutenir plus directement du développement, tu peux donner mensuellement directement à 2 développeurs seulement (c'est expliqué sur la page officielle de donation de GIMP), c'est à dire les 2 seuls développeurs en lien avec GIMP qui essaient de vivre du logiciel libre: Øyvind Kolås, le mainteneur de GEGL, et moi-même (second plus gros contributeur de GIMP après Michael Natterer, mainteneur de GIMP). Øyvind fait donc des trucs plutôt côté moteur graphique; moi je travaille plus sur l'interface graphique, l'utilisabilité, etc. J'ai aussi énormément travaillé sur la stabilité. C'est simple quand on a commencé à utiliser GIMP, en 2012, il plantait pour un oui ou pour un non. C'est d'ailleurs comme ça que j'ai vraiment commencé à contribuer (parce que j'ai commencé à corriger des bugs, puis de plus en plus) et depuis j'ai corrigé pas mal de crashs et bugs et j'aime à penser que de nos jours, on est pour beaucoup dans sa stabilité (c'est simple, on l'utilise des heures durant, tous les jours, et ça marche). Les contributions d'Øyvind et moi-même sont tout aussi essentielles et complémentaires; c'est à toi de voir ce que tu préfères financer.
Bon le financement d'Øyvind marche bien mieux que le notre, j'imagine que c'est beaucoup pour le fait que c'est parce qu'il est dans le projet depuis 13 ans, alors que nous seulement 5 ans. Et aussi qu'on est nul en marketing. Sûrement aussi que le double côté film + développement nous dessert car certaines personnes ne semblent pas vouloir payer pour un film d'animation, juste du développement logiciel. Mais pour moi, c'est essentiel, car je ne coderais pas sur GIMP autant si ça ne nous servait pas justement au quotidien. Nous sommes des contributeurs car c'est notre outil quotidien. C'est donc indissociable pour moi.
Voilà tu sais tout. Tu as donc 3 cibles de financement: le projet GIMP core (tu paieras alors tout le côté communautaire), Øyvind si tu veux financer du développement sur GEGL, et ZeMarmot pour financer du développement sur GIMP même, à un peu tous les niveaux. On peut être financé par Tipeee en euro, patreon en dollar, ou comme noté dans un autre commentaire, tu peux donner directement à l'association LILA qui est l'organisme chapeautant le projet ZeMarmot, évitant ainsi des frais de plateforme (par exemple avec un virement bancaire récurrent), avec un message expliquant que cette donation est pour le développement sur GIMP principalement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Donc GIMP depuis 98, avec pas mal d'espoir de rattraper l’éternel Photoshop.
Juste pour être sûr qu'on se comprend, notre objectif n'est pas de "rattraper" Photoshop, ni de le copier. On fait notre propre logiciel de création graphique, aussi bien qu'on puisse et en Libre. Le but de GIMP n'a jamais été d'être un clone. Je ne dis pas que c'est ce que tu voulais dire. C'est pas très clair. Mais au cas où, je le précise car c'est un commentaire qu'on a régulièrement. :-)
Les soucis ne sont pas les fonctionnalités mais le flous éternel autour 12 et 16 bits natif. Les soucis ne sont pas les fonctionnalités mais le flous éternel autour 12 et 16 bits natif.
Il n'y a pas vraiment de flou, c'est très simple: en 2.8, y a prise en charge de 8 bits seulement, et en 2.10 y aura prise en charge 16 et 32 bits pour l'image de travail. :-)
Pour du 12 bits, je sais pas si y a des formats d'image qui ont cette profondeur, mais si oui, on devrait alors pouvoir exporter en 12 bits sans problème à partir d'une image de travail 16 ou 32.
Ensuite comme quelqu'un le note, la version de développement (estampillée 2.9) est déjà très fonctionnelle et stable au quotidien et te permettrait déjà de travailler des images en 16/32 bits. On utilise essentiellement la version 2.9 depuis plus d'un an pour le projet ZeMarmot. Maintenant soyons clair que c'est une version de développement et il peut y avoir de la casse. Pour une utilisation pro de la version de développement, il convient d'être tout de même un utilisateur éclairé au cas où les choses se passent mal. On fait gaffe, mais on ne peut absolument pas assurer une stabilité parfaite entre 2 versions de développement. Mais ça reste faisable. On le fait bien (mais évidemment en tant que développeur de GIMP, je suis un utilisateur assez éclairé aussi!).
Dractable, Krita, Blender ex.. avancent à pas de géants avec des moyens pas forcement plus important.
Vu de notre côté, on avance aussi bien, mais c'est moins visible car on ne sort pas de version avec nos avancées. Et donc oui, vu de l'extérieur, ça n'a pas l'air d'avancer et c'est frustrant, je le comprends tout à fait. D'où le problème de versionnement qu'on essaie de résoudre et dont je parle dans cette news.
Ensuite "des moyens pas forcément plus importants"… alors Darktable oui, c'est le seul de la liste où c'est vrai. Mais Blender ont leur fondation derrière qui a maintenant des moyens de plus en plus conséquents (pas encore gigantesque, mais ils font quand même des crowdfunding à plusieurs centaines de milliers d'euros, et touchent du financement européen du même ordre de grandeur, ils ont leur cloud avec abonnement, etc.), et Krita ont créé leur propre fondation et font du marketing à fond, des crowdfundings, etc.
GIMP reste essentiellement communautaire. Néanmoins il y a quelques développeurs, notamment moi, qui essayons justement de nous donner des moyens financiers. Le jour où notre financement Tipeee ou Patreon sera de quelques milliers par mois, alors oui on pourra commencer à dire qu'on commence à avoir des moyens pour développer GIMP professionnellement. À ce jour, le développement de GIMP est financé avec des cacahuètes.
Donc oui les numéros de version compte ça fait plus de 5 ans que le 3 est attendu
Qui attend le 3? On n'a même pas vraiment commencé à travailler dessus. Bien sûr, on a quelques commits de temps en temps, mais c'est minime. On maintient la branche juste assez pour qu'elle compile avec GTK+3. Et de temps en temps, on fait quelques trucs, mais c'est pas assez pour dire qu'y a du dév actif.
Le développement actif est quasi essentiellement sur la version 2.10. C'est là où les choses se passent et la seule version à attendre pour l'instant.
la 2.10 va encor donner l'impression que l'on avance à tous petit pas
Je ne comprends pas, le problème est juste une histoire de numéro? Chez GIMP, le second nombre indique une sortie majeure. 2.10 sera autant une majeure que 3.0. De même que 2.8 était une sortie majeure.
Bonne chose, mauvaise chose, je ne sais pas. Peut-être que cela changera un jour. J'ai l'impression qu'historiquement, cela suit simplement les versions de GTK+. Avec l'accélération du versionnement de GTK+, ça voudrait d'ailleurs dire que les versions de GIMP risquent d'accélérer aussi beaucoup après GIMP 3. On verra.
si GEGL est le moteur complet par défaut avec effectivement une prise en charge natif du 16 b et + politiquement ça ferrait dans les chaumières OUF !!!
Ben oui, GEGL a la prise en charge du 16 bit (même 32 bit, qui est maintenant le format natif de GIMP). C'est ce qu'on dit. Je pense que tu n'as simplement pas suivi les nouvelles de GIMP depuis… 4 ou 5 ans? ;-)
Bon bien sûr, ça implique de suivre les news de dév, puisqu'il n'y a effectivement pas de sortie de version stable. Donc je comprends l'incompréhension, pas de problème.
mais si les version avancent à tous petit pas ce la parais suspect à plus d'un
Qu'est-ce qui paraît suspect? Que GIMP est un logiciel libre développé à 99.999% par du bénévolat dans le temps libre, que personne ne bosse à temps plein, payé, et qu'on est pas un business? J'ai du mal à comprendre où tu veux en venir.
Personnellement j'aimerais bien en vivre et pouvoir faire cela (développer GIMP) à temps plein. Mais pour cela, il faut nous soutenir financièrement sur les liens du projet ZeMarmot donnés juste au dessus. Parce qu'autrement, nous dire que ça paraît "suspect" que ça avance pas plus vite, ben ça me fait juste mal au cœur. ;-(
À l'heure actuelle mon état d'esprit est le suivant: on finit notre épisode cette année et si on a pas atteint un financement acceptable pour vivre décemment (à l'heure actuelle, le financement ne paye même pas un loyer, surtout qu'on fait tout dans les règles et qu'y a des charges sociales en salaire, etc. C'est pour te dire que si y a une définition de la précarité, je rentre dedans), ben on commencera à chercher des alternatives et mon implication à GIMP en souffrira probablement drastiquement malheureusement. Et il n'y aura rien de "suspect" au fait que la rapidité de développement de GIMP diminuera beaucoup plus puisque je suis le second plus gros contributeur depuis plusieurs années. Ensuite il reste Mitch, qui fait 2 fois plus de commits que moi en ayant son propre business. Je sais pas vraiment comment il fait (enfin si, je sais; il contribue à GIMP depuis 20 ans et connaît son code bien mieux que moi, et aussi il a beaucoup plus d'expérience de développement en général que moi). Mais il est entièrement bénévole alors lui reprocher aussi de pas aller assez vite serait tout aussi aberrant.
Voilà j'espère que ça te donne une autre perspective sur le développement de GIMP et les "moyens" (assez imaginaires) que tu sembles imaginer derrière son développement.
Donc je souhaite bon courage à toutes les équipes de développent, je continuerai à promouvoir se formidable logiciel.
Bonne et belle journée à tous le monde
Merci. En tous cas, tu as l'air de bonne foi et amical (contrairement à d'autres cas; malheureusement contribuer à GIMP, c'est s'exposer à pas mal d'insultes et de haine et je suis pas toujours bien taillé pour cela; mais je travaille pour me durcir le caractère et être moins sensible à la méchanceté, car des fois ça a été dur). Mais je te conseillerais de faire attention dans ton choix de mots car ils peuvent être assez mal pris. Surtout quand justement je cherche à en vivre mais n'y arrive pas (j'ai parfois l'impression de faire des appels au crowdfunding dans le vide).
J'espère que mon explication t'aura un peu éclairé sur GIMP et son développement. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Quelle serait la différence entre version mineure et majeure dans ce cas si les mineures ont de nouvelles fonctionnalités ?
Pour l'instant il y a quand même de grandes différences. En tous cas 2.10 avec un changement profond du moteur graphique (certes déjà en cours, mais jusqu'alors GEGL n'était utilisé que pour des trucs superficiels, maintenant c'est vraiment partout); puis 3.0 avec le passage à GTK+3, ce qui va débloquer aussi beaucoup de choses normalement, avec prise en charge améliorée des tablettes, amélioration des thèmes, route vers HiDPI, etc. Plein de choses merveilleuses et féériques qui nous sont promises. Ensuite je suis persuadé que tout ne sera pas magique et qu'il faudra travailler un peu pour y arriver, mais au moins on sera sur le chemin. Pour l'instant avec GTK+2, on est un peu contre un mur.
Mais oui peut-être qu'à terme, la différence entre une mineure et une majeure pourra s'amenuiser. Est-ce un mal? Je ne pense pas. Même le noyau Linux n'a pas vraiment de différence entre ses majeures et ses mineures. On le voit bien dans les emails de Linus pour décider les passages de majeures, en général il l'accompagne d'une blague, genre "j'ai plus assez de doigts pour compter". Et voilà on est passé sur une majeure version 4.x du noyau sur un coup de tête et un sondage sans aucune autre logique que "est-ce que vous avez envie ou pas qu'on passe à v4?"
Est-ce un problème? Je ne pense pas vraiment, surtout si ça permet de rendre le développement plus énergique (on peut sans cesse créer des nouvelles fonctionnalités attrayantes!).
Ce serait un système à la Firefox ou à la Libreoffice ?
Firefox, oui. Je ne sais pas quel système utilise LO, mais si c'est comme Firefox, alors oui aussi.
La seule chose que je voudrais faire différemment que Firefox, c'est de garder une promesse de stabilité de l'API un certain temps. Et pour ça, les versions à point restent un bon moyen simple pour reconnaître la stabilité, contrairement à un simple entier. Firefox, de ce que je comprends, c'est qu'ils cassent l'API sur un coup de tête un peu n'importe quand, et que pour un dév de plugin, il faut vraiment se tenir à jour à chaque version et lire le changelog en détail. Avec une promesse de stabilité basé sur un numéro de version, c'est facile: le premier chiffre est le même, donc mon plugin continuera à fonctionner.
Je pense que cela reste un très bon intérêt aux numéros à point.
Ensuite, je me réserve le droit de changer d'avis dans un sens ou l'autre. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne m’attendais pas à ce que ça passe en première page. Sinon, j’aurais mieux écrit mon journal…
Dans ce cas, je tiens à préciser que lorsque je parle de « résumé des points importants », ce sont des points importants « personnels ". D’autres contributeurs ont aussi bossé sur des choses très importantes. Notamment, il y a eu un travail (qui est toujours en cours) très important sur la base de Linear is the new black par Pippin, Mitch et les contributeurs GEGL. Ce travail se base sur le principe que les images en 32 bits flottants en lumière linéaire sont le format de travail idéal.
Aussi, les modes de calques (et plein d’autres fonctionnalités) ont été revus et l’interface utilisateur mise à jour par Mitch, en se basant sur le travail précédent. Bien sûr, comme la compatibilité descendante est un besoin majeur pour nous, les anciennes implémentations de modes sont toutes présentes à vie et utilisées en chargeant de vieux documents (de sorte qu’un ancien XCF aura toujours le même rendu, même dans 10 ans)¹ mais l’interface utilisateur est faite de telle sorte que les nouveaux documents utiliseront les nouvelles implémentations (bien qu’il restera possible de trifouiller pour retrouver les anciennes). Je ne veux pas trop parler de cela en détail, car j’ai peur de dire des bêtises.
Un peintre et contributeur (de rapports de bogues, d’idées, de propositions d’amélioration…), Americo Gobbo, fait d’ailleurs pas mal de recherche sur les nouvelles possibilités de GIMP en la matière, surtout les applications directes à la peinture numérique grâce aux nouveaux modes de calques. Notamment, il peint en texturant ses brosses. Voir ses expérimentations, par exemple ça ou encore ceci ou cela… Il fait aussi quelques vidéos intéressantes sur le sujet.
Il n’était pas présent à Wilber Week (il sera à LGM, je l’ai invité au nom de GIMP car son travail est intéressant et important pour améliorer GIMP et son interface graphique), mais ses expérimentations de brosses et textures se basent directement sur des changements de code de janvier.
Lands Improvisations, par Americo Gobbo (expérimentations d’ajout de texture sur les brosses avec les modes de blend/composition)
Et c’est sans parler du travail de Elle Stone (qui n’était pas présente non plus mais est souvent sur IRC), une experte des couleurs et algorithmes, l’une des plus grosses critiques de GIMP, mais en même temps une contributrice majeure en revue de code et d’algorithme ultra‐poussé (elle n’est pas développeuse, mais elle lit le code à l’occasion et fait des correctifs algorithmiques), tests de versions de développement au pixel près, pointage de problème (on ne peut rien cacher sous le tapis avec elle !) avec force insistance, etc. Je ne comprends pas tout ce qu’elle dit car elle est très calée, mais ses revues sont de grande valeur.
On a aussi eu un contributeur (qui ne veut pas voir son nom cité) dont le trip est d’implémenter des algorithmes de recherche, et il a fait pas mal de contributions sur GEGL et aussi sur GIMP lors du Wilber Week. Il fait d’ailleurs du code de très bonne qualité. On espère qu’il restera avec nous. :-)
Il s’est donc passé pas mal de choses pendant et autour de cette Wilber Week. On était plusieurs développeurs et contributeurs sur place (et d’autres qui ne pouvaient venir, genre Ell, un contributeur majeur de ces derniers mois). Voilà, je voulais donc revenir un peu sur mon impression de compte‐rendu, qui a l’air bien terne si jamais on croit que c’est le compte‐rendu complet de Wilber Week : ça ne l’est pas ! C’était un compte‐rendu tout à fait personnel. D’ailleurs, on prévoit aussi un compte‐rendu plus global de l’évènement sur gimp.org.
C’est personnel dans le sens : je m’y suis impliqué. Pas dans le sens « le reste m’intéresse pas », bien entendu. :P
C’est super excitant ce que d’autres font en parallèle. C’est ça aussi qui est cool : travailler dans une équipe hétéroclite qui bosse sur plein de trucs différents tous très intéressants ! Franchement, je n’aimerais pas donner l’impression que Wilber Week, c’était juste pour faire un paquet Flatpak et discuter du changement de logique de version à dix personnes pendant une semaine (aussi intéressants que soient ces deux items !). Cette dépêche a peut‐être été promue un peu vite. Si j’avais su… Il aurait fallu la compléter un peu avant. :-)
Mais merci quand même ! ;-)
[1] Pour la petite histoire, sous Photoshop, pa exemple, certains fichiers identiques peuvent apparaître différemment selon qu’ils sont ouverts avec CS5 ou CS6. C’est un problème assez sérieux pour des gens qui travailleraient en équipe avec versions disparates (problème classique dans le logiciel propriétaire, car mettre à jour signifie payer une mise à jour de licence) ou simplement pour réutiliser ses vieux documents.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Par contre une version mineure n'en est plus une si des nouveautés apparaissent.
Pourquoi? C'est qu'une question de définition. Hormis le fait qu'historiquement beaucoup de projets (dont GIMP) suivaient effectivement cette définition, tu peux tout à fait redéfinir, et dire par exemple qu'une version majeure, c'est quand tu changes quelque chose de… majeur justement (comme le moteur graphique, cas de GIMP 2.10, ou le toolkit graphique, cas de GIMP 3), et une mineure, c'est le reste.
D'ailleurs, si on souhaite se rapprocher du "versionnement sémantique", utilisé massivement, surtout pour des bibliothèques (peu les logiciels finaux) libres, tu peux tout à fait rajouter des fonctionnalités dans une mineure. Ce qui importe, c'est de le faire en restant compatible avec l'existant (tant qu'on ne change pas de version majeure). GIMP fournissant aussi une API (pour les plugins), c'est le cas, ça l'a toujours été et ne changera pas: les plugins existants resteront compatibles (d'ailleurs le numéro majeur considéré pour la libgimp est le premier, comme habituellement en semver, alors que pour le logiciel GIMP, c'est le second qui fait la majeure; donc notre API est encore plus conservative que le logiciel graphique, et c'est bien).
Personnellement le type de sortie continue que je vois, on ne ferait simplement plus de différence entre majeure et mineure. Simplement on pourrait sortir sans arrêt des mises-à-jour, que ce soit avec juste un correctif, ou avec une nouvelle fonctionnalité. Comme beaucoup de logiciels font de nos jours (notamment Firefox). Je sais que ça a fait jaser à l'époque de Firefox et que les gens ont cru que c'était juste un coup marketing (pour avoir le numéro de version le plus haut possible), mais je pense que cela pourrait vraiment libérer le développement. Pouvoir sortir des nouveautés sans arrêt, dès qu'elles sont vraiment finies, c'est super. Pourquoi s'encombrer avec des règles artificielles?
Bien sûr, il faudra garder des règles de compatibilité pour les plugins tout de même. Par exemple sur Firefox justement, les problèmes sont nombreux et beaucoup d'entre nous perdent des plugins régulièrement aux mises-à-jour. ;-( Un peu plus de stabilité serait bienvenu.
Donc en un sens, on peut garder les concepts de majeures et mineures mais limiter cela aux APIs ou aux changements graphiques vraiment profonds. Et c'est un peu la direction que nous prenons avec GIMP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je n'ai pas regardé plus loin, mais juste en vidant mes cookies, je peux voter deux fois :/
Ah. Je n'ai pas testé. On avait vu qu'on ne pouvait pas voter avec un second ordinateur dans le même appart (donc même IP) donc j'ai supposé que ça se base vraiment sur l'IP. Mais si tu dis que juste vider ses cookies suffit, alors c'est vraiment programmé n'importe comment.
Déjà que même de base la logique d'un vote par IP n'est pas très bonne, déjà parce que ça interdit à plusieurs personnes de voter si derrière la même IP (typiquement la famille derrière une même box, ou ses collègues au boulot), mais surtout car — comme tu l'indiques — ça rend le bourrage facile. Beaucoup de fournisseurs d'accès ne garantissent pas d'IP stable, en particulier avec des connexions 3G.
(et vu leur remontée fulgurante depuis hier, je soupçonne assez fortement les deux premiers actuels)
Le second, c'est nous. Et si on est second (et on a même été premier pendant un moment), c'est grâce à linuxfr! Merci Linuxfr. :-)
On était genre 5ème, puis j'ai publié ce journal, et en une demi journée, on a passé tout le monde (c'est simple, j'ai publié en début de soirée, le lendemain au réveil, on était premier). Ça a continué sur la lancée pendant une bonne journée ou plus, et à un moment on a même eu plus de 200 votes d'écart avec le second! Mais là ça s'est calmé; les votes pour GIMP Motion augmentent encore régulièrement, mais plus très vite. :-/
Donc notre remontée fulgurante, c'est pas du bourrage, c'est du linuxfrage (le site avec un lectorat de libriste si grand qu'il est connu pour faire des DDOS involontaires de petits serveurs lorsque certains liens sont si intéressants que tout le monde clique!). ;-)
Le premier, on s'est posé la question, en effet. Surtout que hier soir, quand ils nous ont dépassé, on a lancé des messages sur les réseaux sociaux pour activer nos soutiens; lorsqu'on a difficilement grimpé à leur niveau et dépassé de quelques votes, ils ont soudainement fait un bon de plus de 100 votes en genre 30 minutes. Ça m'a paru suspect.
Ensuite je veux pas médire sans savoir. Ils ont peut-être une communauté très vaste aussi et savent bien faire jouer leur communication. Apparemment ils ont une "app" de téléphone et poussent les utilisateurs à voter en promettant de débloquer des fonctionnalités lorsqu'ils atteignent des paliers de vote.
Au final, même s'ils utilisent vraiment des techniques de changement d'IP (mais j'en sais rien), ce n'est certes pas fair-play, mais peut-être pas contre les règles. Le règlement n'indique pas que les votes doivent être limités à un par personne physique. Il dit juste:
limité à un seul vote par adresse IP
Nous on va continuer à la jouer cool, ne serait-ce que parce que j'ai pas que ça à faire que de piper les dés. On va se contenter de lancer quelques appels comme on l'a fait sur linuxfr et espérer que la communauté du libre saura être plus importante en nombre. Pour moi, LinuxFR a encore fait (il y a 2 jours, avec le nombre de vote impressionnant qu'on a eu) une démonstration épatante du pouvoir de la communauté du logiciel libre… et en plus seulement à l'échelle francophone!
Le premier gagne automatiquement 1500€ ?
Oui. Par contre, le gagnant du prix du public est "disqualifié" automatiquement des prix du jury (ce que je trouvais totalement idiot au début, soit dit en passant car le grand prix est de 5000 €! Mais maintenant que je me rends compte que c'est si simple de "bourrer les urnes", c'est peut-être la raison).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui y a encore plein de trucs avec lesquels je suis pas tout à fait heureux. En plus le fait d'être bloqué sur GTK+2 n'aide pas. J'ai hâte qu'on passe à GIMP 3 pour profiter de certaines nouvelles widgets.
Ceci dit, quand tu parles de "manipulation de fenêtres", j'imagine que tu parles des divisions en panneaux que l'on peut redimensionner en cliquant-déplaçant la bordure. Peut-être que ça se voit pas bien en vidéo, mais c'est en fait assez simple et intuitif car ce type de GUI est très classique. En plus j'ai fait ce screencast juste avant d'uploader, sur mon ordi portable qui a un écran assez restreint. Avec un grand écran, voire plusieurs écrans (configuration classique chez les graphistes et animateurs), ce type de problème se poserait beaucoup moins.
Mais ça n'empêche pas que plein de choses doivent être améliorés quand même. :-)
Pour le moment, j'essaie de me concentrer surtout sur le cœur de certaines fonctionnalités, et accélérer les chargements, etc. (ça se voit pas dans la vidéo, car c'est pas le but; le traitement d'image pour la vidéo, c'est pas facile pour obtenir un bon compromis entre une prévisualisation fluide, ce qui veut en général dire qu'il y a eu du préchargement, et une GUI qui soit réactive malgré le dit-préchargement).
Donc bon, oui y a du boulot! Par conséquent merci pour avoir cliqué! Si on gagne, ça me donnera du temps pour pouvoir travailler dessus. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne peux pas te donner de réponse avisée sur ton problème exact. Par contre, dans tous les cas : sauvegarde tes données. Quand tu fais ce genre de manips, il ne faut jamais supposer qu'il n'y aura aucun problème. voilà pour mon conseil du jour. ;)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Très bon (ou mauvais) code qui sera juger… par des développeurs (dont c'est le métier)
Dont c'est le métier? Pas forcément. On ne regarde que la qualité du code, pas le CV. La personne pourrait être éboueur de profession ou pilote de course qu'on ne le saurait même pas. Si le code est bon, on l'intègre, sinon on propose des améliorations possibles pour intégration ultérieure potentielle (on appelle cela de la "revue de code" et on en reçoit tous, même les mainteneurs des plus gros projets demandent aux autres qu'ils revoient leur code).
Ça me va si celui qui me dit ça est à même de l'évaluer
…
(vous par un développeur, nous par un designer)
Donc un projet qui n'a aucun designer ne pourra alors jamais en avoir puisque les designers ne pourront jamais être jugé par un designer déjà présent? Là y a comme un problème de poule et d'œuf, non?
ça peut être des devs s'ils savent
C'est déjà mieux. Pourtant tu continues à faire bien trop de distinction, à classer les gens et les mettre dans une case ('dév', 'designer'…), à confondre qualité et profession/métier (comme je l'ai dit et je le répète ça joue, bien entendu, mais c'est loin d'être du 100%)… Et surtout tu dis ça, mais clairement en vrai tu juges sans savoir si ce sont des gens qui "savent". As-tu fait un background check sur l'ensemble des gens que tu as cité et moqué (pour ne pas dire craché dessus, disons le clairement) dans ton post de blog? J'ai quand même l'impression que tu me classeras direct dans la catégorie "sale développeur qui y comprend rien" si on a affaire sur un projet. Or j'ai fait de l'ergonomie à l'université, avec des projets où j'ai fait des tests utilisateurs, etc. Ensuite je n'ai pas poursuivi du tout dans ce domaine et suis le premier à dire que je suis loin d'un expert design ou ergonome. Mais ça n'en reste pas moins un sujet qui m'intéresse, je lis sur le sujet, je veux en savoir plus, etc. Alors dans quelle catégorie je rentre? Suis-je quand même un "dév qui sait"?
C'est une question bien rhétorique car je ne m'attends pas à ce que tu me répondes direct. Enfin… j'espère que tu n'allais pas le faire. Ce serait bien présomptueux. Et c'est là mon point d'argument: tu ne peux pas avoir d'avis sur chaque contributeur à un projet avec juste quelques messages en arrivant sur un nouveau projet. Et ce que ce soit pour la programmation ou le design.
Je pense que tu accepterais moins ces "refus de patches" et de contributions si elles étaient repoussées par des non devs sur des prétextes fallacieux. "Tenez j'ai codé un système pour améliorer la sécu" "lol non on en veut pas et on aime pas ton indentation".
L'indentation dans le code est importante et on intègre les problèmes d'indentation dans la revue de code. On appelle cela le "style" du code, il doit rester cohérent dans l'ensemble du code pour que celui-ci reste lisible et compréhensible. Ce n'est absolument pas une sorte de réaction de kikoolol comme tu sembles le penser, est même potentiellement insultant (comme beaucoup de choses que tu sembles penser des développeurs) et montre une incompréhension du travail de développeur.
Bien sûr si c'est l'unique problème, on pourrait simplement intégrer le patch et corriger l'indentation ensuite nous-même, ce qu'on fait parfois. Mais c'est important de le dire et de demander au contributeur de corriger lui-même son indentation. Si on veut garder les contributeurs et les pousser à continuer, ils doivent savoir quelles sont nos règles pour améliorer leurs patchs au fur et à mesure. En plus ce genre de choses sont très bien prises par les contributeurs justement. Tout revue de code est en générale bien reçue (en tous cas par les développeurs qui n'ont pas un égo surdimensionné, qui veulent vraiment aider, qui veulent aussi apprendre parfois, etc.) et montre bien qu'on s'intéresse au patch et qu'on veut l'intégrer.
Donc très mauvais exemple. Et ça montre que tu ne comprends pas du tout ce que font les développeurs encore une fois.
Pour te donner un exemple plus artistique (car il se trouve que j'ai un certain bagage dans le milieu artistique, moi-même déjà, mais aussi en collaboration technique avec des artistes). C'est un peu comme si un dessinateur utilisait son propre style dans un film d'animation au lieu d'utiliser le style du film (donc y aurait un perso différent stylistiquement des autres dans la scène). Tu peux transposer ça avec des arts plastiques où plusieurs artistes travaillent sur une même œuvre, sur la musique aussi avec des musiciens qui jouent ensemble, etc. Bien sûr, je parle pas d'œuvres où mélanger des styles très différent est justement le but (type cadavre exquis!), mais de trucs plus classiques. Il y a un moment où l'harmonisation du style des intervenants est tout aussi important que la compétence intrinsèque de chacun si on veut que l'œuvre finale soit belle. [*] On appelle cela du travail d'équipe!
Sur ces belles paroles, je pense que ce sera mon dernier message. J'ai pas l'impression que la discussion va vraiment évoluer et surtout j'ai le sentiment que tu as juste une dent contre les développeurs de logiciel libre, voire contre le logiciel libre dans son ensemble (à la façon dont tu as l'air d'attaquer quasi chaque projet).
C'est vraiment dommage car on a en effet vraiment besoin de designers. Ce pourquoi j'essayais de donner mon avis sur la question pour voir si on pouvait amender les choses. J'ai pas l'impression. :-/
[*] P.S.: après réflexion, mon parallèle n'est pas idéal car l'indentation n'influe pas directement sur le logiciel final (contrairement au style d'un dessin pour une œuvre dessinée). L'indentation en programmation est plus une histoire d'organisation. Un meilleur parallèle serait alors simplement des gens qui travaillent ensemble mais quelqu'un qui refuserait de suivre l'organisation du groupe. Genre il range des dossiers par date alors que tout le monde a décidé de ranger par ordre alphabétique (car c'est son style d'organisation, il veut pas qu'on lui impose un autre, vous comprenez!). Bien sûr, on peut quand même arriver à un travail acceptable, mais cela met clairement des bâtons dans les roues de la dynamique globale.
Je garde quand même l'autre exemple car plus artistique et te parlera peut-être plus, et je pense que c'est pas si différent au final, car la conclusion est la même: il s'agit au final de travail d'équipe et il faut savoir parfois faire des concessions sur son style le temps d'un projet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Hmm… J'ai répondu sur le blog par correction, mais je me rends compte que la vraie discussion se passe apparemment ici. Même l'auteur d'origine ne semble plus répondre qu'ici. Allez hop! Je recopie ma réponse (rédigée en s'adressant à ce designer).
Bonjour,
Ce billet dit des choses justes, mais aussi d'autres qui me font peur, notamment après avoir vécu une mauvaise expérience avec un designer dans le libre justement.
Globalement je suis totalement d'accord avec le fait que l'on doit laisser le designer bosser et qu'il est le boss dans son domaine. Il est celui qui doit avoir le dernier mot dans ce qu'il fait.
Par contre, il est normal qu'il y ait une étape intermédiaire entre "inconnu au bataillon" et "mainteneur de tout l'aspect design du logiciel". C'est la même chose pour les développeurs. Dans beaucoup de logiciels libres, si un contributeur fait un très bon code dans une zone que personne n'a touché depuis des lustres, non seulement ce code sera accepté et intégré au logiciel, mais en plus si ce contributeur reste dans le coin et continue à contribuer, il sera considéré comme le "mainteneur" de ce bout de code et celui qui décide. Mais la condition, c'est bien: "si un contributeur fait un très bon code".
Parce que du mauvais code, y en a aussi plein (développeur pro ou pas), et si un développeur se ramène dans un projet avec comme intro "J’ai 11 ans d’expérience dans le développement, j’ai réglé des problématiques conceptuelles sur des sites et des projets stratégiques gargantuesques impliquant des dizaines de personnes juste pour la partie logicielle, donc chill, je peux gérer ton projet", ben ça me fera ni chaud ni froid. Et la réponse sera la même que pour un autre: ok on accepte les patchs, on attend le tien.
Note que j'ai croisé des professionnels qui ont des années d'expérience et dont les compétences m'impressionnent absolument pas, tout comme j'ai croisé des étudiants ou très jeunes développeurs qui trouvaient vraiment des solutions extrêmement pertinentes et qualitatives sur des problèmes très complexes. L'expérience, c'est important, mais ce n'est pas tout. Et ceci s'applique quel que soit le métier.
Donc oui, je suis totalement d'accord sur le fait qu'il faut laisser travailler et avoir le dernier mot au designer, mais il faut d'abord que ce dernier passe l'étape où on l'accepte comme un designer du projet. Tu ne peux absolument pas critiquer la décision de l'équipe SPIP comme tu le fais, par exemple. Note que je l'aime bien cette proposition de design, mais bon voilà, je contribue/décide pas chez SPIP. J'ai aussi eu des patchs refusés dans ma vie dans divers projets. Souvent j'y ai passé des heures et des heures. Mais voilà, c'est la vie. Je vais pas en faire une sorte de conclusion générale (et négative) sur le processus de développement dans le logiciel libre, ni me faire une opinion générale (et très négative aussi) sur une équipe de gens que je ne connais simplement pas, encore moins aller la diffuser dans un post.
Il y a aussi cette dualité stricte entre designer et développeur, que je n'aime pas. Comme je disais, je suis tout à fait d'accord que le designer doit décider des choses du design. Mais cela ne doit pas l'empêcher de pouvoir écouter les développeurs. Un développeur, c'est pas non plus un abruti qui a du caca dans les yeux, comme tu le dis si poétiquement. Ce n'est pas parce qu'on est développeur qu'on est forcément un débile du design ou qu'on ne peut pas avoir de bonne idées. De même qu'un designer peut aussi avoir de très bonnes idées pour les développeurs (il n'est pas toujours nécessaire de savoir programmer pour comprendre le boulot du développeur, ce n'est qu'une — parfois minime même — partie du boulot de développeur, ce que certains designers ne semblent pas voir).
Je parlais de mauvaise expérience, c'était justement avec un designer qui marquait une triple et très stricte catégorisation des gens: designer, développeur et utilisateur. Je me rappelle même qu'en réunion, une fois, il commence en notant un triangle sur tableau blanc pour noter les 3 catégories clairement séparées (la base de sa philosophie de contribution quoi). Il nous disait alors très clairement que les développeurs étaient des abrutis qui ne devaient absolument pas toucher ou parler du design. Un peu comme toi. Super expérience [ironique], je le dis tout de suite. Comme quoi, y a pas que les designers qui se font mal traiter par les dévs et peuvent mal vivre la collaboration (franchement j'ai très mal vécu cette collaboration et je suis très heureux qu'il soit parti, ça a débloqué beaucoup de choses car justement on le considérait comme le boss du design et on avait accepté son leadership dans ce domaine! Selon moi une erreur puisque c'était ce genre de personne, mais ça montre bien que c'est tout à fait possible). L'inverse existe donc aussi.
Le fait est que le designer est en effet celui avec l'expérience, la connaissance théorique, etc. sur le design. Il est celui qui aura le dernier mot. Ça ne l'empêche pas de pouvoir parfois avoir tort (voire d'être mauvais, comme un développeur peut être mauvais, etc. Le fait d'être un professionnel n'empêche pas cela) ou de pouvoir revoir ses idées en prenant en compte des contre-propositions. Le dév, c'est un techos; mais ça l'empêche pas d'avoir des idées dans le champs du design, et parfois bonnes, qui sait! Quant à l'utilisateur (non parce que ce designer considérait aussi que les gens ne savaient pas ce qui était bon pour eux et qu'il ne fallait donc pas les écouter, ce avec quoi je ne suis absolument pas d'accord non plus; je ne sais pas quelle est ta position sur le sujet, mais puisque tu considères qu'il ne faut écouter que le designer dont c'est le métier, j'imagine que tu te positionnes donc aussi pareil?)… les designers et développeurs sont pas aussi des utilisateurs potentiels? Pourquoi faire une sorte de limite stricte? Au final, les "utilisateurs", ben c'est des gens. Et ils ont aussi le droit à une opinion (même si — encore une fois — oui ils sont pas des designers pros et le(s) designer(s) du projet sera celui avec le dernier mot).
Ensuite dans ma vie, j'ai aussi eu de très bonnes interactions avec des designers (dans le logiciel propriétaire, c'est triste à dire!). Je me souviens de jobs où je lisais une spéc, puis j'allais m'asseoir à côté du designer et faisais quelques commentaires. Parfois il m'expliquait pourquoi mes idées n'allaient pas, puis après une discussion, je comprenais et remballais l'idée. D'autres fois, il comprenait mes idées, était d'accord, et faisait évoluer sa spéc. Franchement, ça se passait super bien, extrêmement bonne collaboration et très bon souvenir. Et c'était aussi un designer avec des années d'expériences, etc. etc. Mais la question n'est pas là!
Au final, je conclurai généralement: le logiciel libre, c'est comme partout, c'est fait d'humains avant tout. Et comme tout entre humains, la collaboration, ça veut aussi dire discuter et savoir prendre un peu sur soi de temps de temps. Aussi savoir accepter les critiques d'ailleurs (du moment qu'elles sont constructives et pas agressives, bien sûr!).
Je trouve que le libre est un très bon environnement pour se former à la fois une estime de soi, mais aussi une forme d'humilité.
Je travaille sur des logiciels libres, dont un très gros, et je suis constamment à la recherche de designers qui accepteraient de prendre la charge du design (ou d'une partie de celui-ci) parce que c'est un très vieux logiciel qui a vraiment une vieille GUI basée sur des paradigmes d'il y a plus de 20 ans (22 ans cette année). Une fois qu'on se sera mis d'accord, on considérera leurs choix comme des décisions. Mais ça ne doit pas empêcher les discussions et clairement je suis à la recherche de quelqu'un qui ne considérera pas les développeurs comme des sous-hommes. Je ne dis pas que c'est nécessairement ton cas. Je n'ai aucune idée de comment se passerait la collaboration avec toi et ne connais pas ton travail, ni n'ai aucun moyen de juger vraiment juste par cet article de blog. Peut-être que ça se passerait super bien, qui sait! Mais j'avoue que ça fait un peu peur de lire ton avis sur la collaboration avec les développeurs, ou du moins ce que je crois en comprendre. :-/
Ensuite je lis peut-être mal entre les lignes et me plante peut-être sur tes dires et intentions. Donc bah j'espère que tu trouveras ton bonheur dans le design de logiciel libre! Car oui, beaucoup de logiciels en ont vraiment besoin (ceux auxquels je contribue aussi sont clairement du lot!). Je suis d'accord sur ce point.
Donc bonne continuation!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Du coup si on veut installer un logiciel qui utilise une dépendance du runtime GNOME et que l'on a pas ce dernier il faudra tout de même tirer les 250 dépendances (200 de Freedesktop et 50 de GNOME) ?
Non. :-)
Ça se répond en petits morceaux.
1/ Déjà en vrai y a un runtime et un SDK faits en même temps. Le runtime ne contient que ce qui est nécessaire pour exécuter les logiciels (librairies partagées, etc.) alors que le SDK contient aussi les trucs de développement (headers de lib, mais aussi des outil divers comme les autotools, etc.). Les dévs doivent bien sûr installer tout, mais les autres n'installent que le runtime. Ça fait déjà beaucoup moins de dépendances que la liste "naïve" que j'ai faite précédemment avec un grep et un wc pour compter les lignes.
2/ Un runtime comme celui de freedesktop va contenir énormément de libs que beaucoup de logiciels utilisent sans même forcément s'en rendre compte (car pas en dépendance directe). Que ce soit libpng, ou les libs X11 ou Wayland, si votre appli a une GUI, vous en aurez vraisemblablement besoin. Beaucoup de cas d'usage "bureau" feront aussi des appels DBus, même si vous n'en avez aucune connaissance dans votre code. Vous voudrez forcément les libs alsa et pulseaudio pour le son, les diverses libs de Desktop ou d'affichage de texte, etc.
Au final ce sont des libs de base qui sont nécessaires pour quasi toute appli graphique (même si la dépendance n'est pas directe). Il faut bien voir que le "bureau linux" est lui-même vraiment stratifié sur de nombreux niveaux sur lesquels la plupart des logiciels graphiques s'appuient. Dire un chiffre genre "200" bibliothèques peut paraître énorme, mais je vous assure, pour faire tourner votre ordi super-moderne, ça ne l'est pas du tout! Même en espace disque, ce ne sera pas énorme. Beaucoup de libs de base sont très simples et ne tiendront que sur quelques Ko une fois compilés. Le fameux "faire une seule chose et le faire bien".
3/ Si vraiment vous êtes dans un cas exceptionnel où vous pouvez faire tourner l'application sur quasi aucune dépendance, vous êtes libre de faire votre propre runtime super-minimal.
Si vous voulez dépendre du runtime Freedesktop, mais pas de celui de GNOME: supposons qu'il y a une seule lib que vous voulez qui est dans le runtime GNOME, vous pouvez aussi bien l'ajouter dans votre Flatpak et vous baser sur le runtime Freedesktop. Il n'est pas nécessaire de tirer le runtime GNOME.
4/ Aussi il faut bien se rendre compte que si les gens se mettent à installer Flatpak, ils auront probablement déjà les principaux runtimes, dont celui de GNOME (et celui de KDE). Celui-ci est partagé entre les applications et téléchargé une seule fois, donc pas téléchargé pour une application unique. C'est plutôt efficace et permet des Flatpaks de taille réduite.
En outre, côté sécurité, ça signifie que vous bénéficierez de la réactivité de l'équipe de Flatpak (contenu du runtime Freedestop) ainsi que de l'équipe GNOME (runtime GNOME) donc des mises-à-jour de sécurité de ces 2 runtimes. En tant que développeur d'application, c'est autant de dépendances dont on n'aura pas à s'inquiéter.
Au final, je trouve ce système de niveaux de runtime les uns au dessus des autres assez bien et cela permet de bien diluer le travail entre les packageurs de divers projets, de garantir une sécurité plutôt bonne tout en ayant des mises-à-jour fonctionnelles régulières.
Pour le moment, mon expérience est assez positive. Je n'ai que des problèmes d'accès de fonctionnalités du bureau qui ne sont pas encore possible parfois à cause de la problématique "sandbox". Mais ce sont des problèmes connus et sur lesquels l'équipe de Flatpak travaille. Mon interaction avec eux est plutôt constructive jusqu'à présent (GIMP étant un logiciel avec pas mal de dépendances, et qualifiable de relativement complexe, j'ai forcément rencontré plusieurs petits embêtements ici et là).
P.S.: je conclurai avec un truc auquel je viens juste de penser; le fait d'installer des apps KDE est toujours très ennuyeux dans les distribs classiques, car cela va souvent tirer des dizaines d'autres applications graphiques (souvent pas parce que ce sont de vrais dépendances, mais parce que les packageurs de distribs veulent se simplifier la vie et "supposent" que si vous voulez une application KDE, ça veut dire que vous les voulez toutes) qui vont notamment polluer mon overview lors d'une recherche d'application (ou les menus d'application pour ceux qui en ont encore). Cela ne sera — je pense bien — pas possible avec Flatpak et si j'installe une application KDE qui aura été packagé en Flatpak, je pense que je n'aurai que cette app dans mon overview/menu ce qui améliorera le confort d'utilisation. Et au besoin, désinstaller le runtime Flatpak KDE sera 1000 fois plus simple, minimal en taille et propre que me débarrasser des dépendances multiples dans mon système principal. C'est aussi un gros avantage!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
P.S.: en tous cas pour Flatpak. Pour Docker, je sais pas, mais comme c'est orienté plutôt services et système de prob, j'en doute. Et pour d'autres alternatives de bureau, type Snap, aucune idée non plus du modèle adopté.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tu cites déjà la réponse dans ton journal. Je pense que Flatpak, si le projet continue dans la bonne direction (ça a l'air d'être le cas pour l'instant), peut être la solution au problème cité.
Note que je ne considère absolument pas que le système de paquet par distribution est cassé pour autant, ni qu'il disparaîtra. C'est simplement complémentaire. L'écosystème logiciel GNU est simplement devenu trop important pour que tous les logiciels intéressants soient inclus dans les paquets gérés par la distrib (on peut voir cela comme un succès du "bureau Linux" si on veut alimenter le troll! :P). Donc il faut trouver des solutions pour répartir mieux le travail, et ça veut en général dire que les développeurs doivent s'y mettre. Par contre — on le sait bien depuis le temps — faire un paquet par distribution n'est pas gérable, surtout si ce sont des logiciels faits sur le temps libre (cas non rare dans le logiciel libre!). Un format standard comme flatpak, utilisable sur toute distribution GNU/Linux, est donc une très bonne alternative.
Mais là, qui va s'assurer que tout vos containers utilisent bien la dernière version patchée d'une bibliothèque critique ?
Alors je sais pas comment ça marche pour Docker que tu cites aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique (surtout parce que c'est fait pour les serveurs et on veut pas voir des trucs genre maj auto en prod!). Par contre Flatpak a un système de dépôt. En gros, chaque projet aura désormais un mini-dépôt de paquets pour ses logiciels et mettra à jour ses dépendances (note: il est aussi possible de faire des Flatpak standalone, sans dépôt, mais ce n'est pas la procédure conseillée).
Ainsi quand le projet mettra à jour son paquet, l'ensemble des gens qui auront installé ce paquet recevront des notifications qu'une mise-à-jour est dispo. Personne ne se baladera avec des applis et dépendances trouées (tant que le projet upstream est maintenu). Note que le projet n'a même pas à maintenir l'ensemble des dépendances possibles d'un logiciel puisque Flatpak fonctionne par "niveaux" de runtime. Ainsi le projet Flatpak lui-même maintient un runtime "Freedesktop" qui à lui seul contient déjà environ 200 dépendances de base qui vont suffire pour énormément de projets. Le projet GNOME aussi maintient un runtime, basé sur celui Freedesktop et qui ajoute environ 50 dépendances. Le projet KDE aussi maintient un runtime. Un logiciel doit simplement choisir un runtime sur lequel se baser.
Pour énormément de projet, celui signifie qu'il n'y aura peut-être aucune dépendance supplémentaire à ajouter dans le Flatpak (et donc à maintenir), ou très peu. Cela dilue énormément la tâche tout en permettant de rester sécurisé.
Ainsi pour les distributions, ça ne change pas grand chose: elles peuvent continuer à proposer les logiciels les plus notables notamment, et avoir des mises-à-jour fonctionnelles pas forcément au taquet (mais une fois tous les 6 mois ou 1 an en fonction du cycle de sortie de la distrib). Ça sera suffisant pour la majorité des logiciels.
Les développeurs eux auront moins de travail puisqu'il n'y aura plus qu'un seul paquet à maintenir pour être dispo partout.
Enfin tout le monde aura accès à des mises-à-jour immédiates fonctionnelles ET de sécurité si on choisit d'installer le paquet Flatpak upstream.
En tous cas, le projet GIMP par exemple fournira désormais un paquet Flatpak upstream que je crée et maintiens. Je pense que c'est vraiment une avancée car jusqu'à ce jour, les gens sous Windows ont un installeur, ceux sous OSX un DMG, et sous Linux… on leur disait d'attendre le paquet de leur distrib ou de compiler. Ça fait limite "citoyens de seconde zone" (bon c'est pas vrai, hein. Quasi tous les dévs de GIMP sont sous Linux, et donc ça veut dire notamment que la version nux est bien plus stable que les autres! Mais bon on pourrait croire). Ben plus maintenant. Tant que je serai dév de GIMP, les linuxiens auront leur Flatpak (bon à part si une alternative encore mieux fait son apparition bien sûr, ou si je découvre un truc horrible qui me fait changer d'avis sur l'utilité… espérons que non, mais on sait jamais!) et seront toujours des citoyens de première zone! :-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En effet, je pense que leur suite creative cloud a encore une longue vie devant elle. D'ailleurs même le logiciel "Flash" a probablement un avenir sous son nouveau nom Animate. Simplement le "focus" a changé et le but n'est plus d'exporter en format Flash mais en HTML5 ou en d'autres formats vidéos.
Donc oui, Flash, le format, est sur la pente descendante, et Shockwave l'est encore plus (depuis bien plus longtemps puisque cette technologie fut justement totalement éclipsée par Flash quasi dès ses débuts! C'est dire à quel point c'est mort. J'explique cela dans les sections "Premier pas", puis "Age Sombre" de l'article sur Flash) et c'est donc normal que les logiciels dédiés à ces formats disparaissent (ou deviennent génériques comme fut le cas pour "Animate").
Mais effectivement je doute qu'Adobe en tant que société soit mourante. Pas du tout même. Une petite recherche sur le web indique un chiffre d'affaire en croissance. Apparemment ils ont eu une baisse du chiffre en 2013-14 (si je comprends bien comment on lit ces tableaux) mais ils sont repartis en force en 2015.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Microsoft Office est l'un des fleurons commerciaux de Microsoft. Il me semble — si je ne m'abuse — que cela compte pour une grande part dans les revenus de la compagnie (rapide recherche sur le net, si je comprends bien les graphiques, surtout le dernier, leur suite office fait environ 25% de leur revenu, au delà des produits serveur et des OSes).
Le fait est qu'aujourd'hui comme il y a 20 ans, une chose n'a pas changé: les gens ont besoin d'écrire des textes (courriers, contrats, histoires…) et pour cela les traitements de texte de ce type reste l'outil essentiel de la majeure partie des gens. Les tableurs sont aussi une ressource très commune et ne disparaîtront pas de sitôt, les gens en entreprise ont régulièrement besoin de faire des présentations…
Donc quelle est l'intérêt d'investir dans une suite office, vraiment? Quand tout dans l'utilisation informatique quotidienne des gens ainsi que dans les chiffres de l'entreprise informatique qui vend la suite office la plus utilisée au monde montre qu'il y a un potentiel financier énorme, cela me paraît une bien étrange question… :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On a déjà beaucoup avec strictement des assos de logiciels libres, mais c'est pas exclu. Les contributeurs qui créeront l'album décideront de ce qui rentre dans le cadre du projet ou non.
Par contre, il faudrait que cette association, Kokopelli, nous contacte (un simple email) et nous envoie les autocollants d'abord.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce sont juste des logos, ou aussi des autocollants? Il faut que les gens puissent pouvoir se les procurer (sans les imprimer eux même, mais plutôt à un stand TuxFamily par exemple…). Et si ce sont bien des autocollants, lesquels et quelles dimensions métriques?
Merci! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
La différence entre et tutu . Sémantiquement, c’est compliqué de savoir lequel est la « forme à utiliser ».
Ben quand tu as un truc unique qui peut être exprimé en valeur simple, tu fais un attribut. Ensuite dès que c'est une donnée compliquée (qui va être composée de plusieurs valeurs), ou que tu peux en avoir plusieurs, c'est forcément un nœud fils. Quand tu crées ton schéma, c'est à toi de connaître tes données.
Un protocole qui impose l’encodage va quelque part à l’encontre de la norme.
Pas du tout. On avait ce type de remarques régulièrement sur XMPP, du type "XMPP, c'est pas du vrai XML car vous n'utilisez qu'une partie des fonctionnalités" (voir les restrictions XML). Mais non, ce n'est pas vrai. Tout flux XMPP est un document XML absolument bien formé qui sera traité sans erreur dans n'importe quel parseur XML générique.
Encore une fois, XML n'a pas pour but d'être un format final en soi. Il n'y a aucune sémantique dans XML. D'ailleurs si tu fais une recherche sur la spec du terme "semantic", ça ne retourne qu'une seule occurrence qui dit exactement cela:
This specification does not constrain the application semantics, use, or (beyond syntax) names of the element types and attributes, except that names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are reserved for standardization in this or future versions of this specification.
C'est à chacun de faire un format et d'y ajouter de la sémantique. La création du format final peut ainsi passer par se limiter à un sous-ensemble de XML. C'est comme l'utilisation d'un langage de programmation: cela n'oblige absolument pas les développeurs à utiliser toutes les fonctionnalités du dit-langage, voire même les autorise à en interdire certaines dans leur programme (exemple très courant: le C++ où beaucoup de développeurs vont interdire l'utilisation de certains fonctionnalités dans leur code, comme dans le Google C++ style guide; notamment les exceptions sont une fonctionnalité interdite dans beaucoup de gros projets C++). Est-ce à dire que le code C++ de Google ou d'ID Software (Doom 3) n'est pas du C++ parce qu'ils n'utilisent qu'un sous-ensemble (clairement interdisant pas mal de fonctionnalités)?
Enfin pour revenir plus précisément à cette fonctionnalité (codage de caractères dans XML), la spéc dit clairement:
(processors are, of course, not required to support all IANA-registered encodings)
Puis un peu plus bas:
Unless an encoding is determined by a higher-level protocol, it is also a fatal error if an XML entity contains no encoding declaration and its content is not legal UTF-8 or UTF-16.
Comme tu vois, la spéc XML est clairement préparée à ce que le codage puisse être déterminé non par la déclaration, mais par le protocole de plus haut niveau (par exemple XMPP). XML est vraiment fait dans l'optique qu'il va en général y avoir une spéc de plus haut niveau qui donnera une vraie sémantique aux éléments et attributs. Sans cela, XML n'est qu'une sorte de syntaxe ou grammaire générique.
Si tu veux un exemple simple, une contrainte comme « date < date_du_jour » (contrainte métier tout à fait raisonnable) n’est pas exprimable. Au final, la validation xsd ne te dispense pas de faire ton boulot correctement.
Bien sûr, tu ne peux pas tout valider dans un schéma XML (qui est aussi un format générique et n'a bien entendu aucune logique par rapport à ton besoin particulier, ou "logique métier" comme on dit), mais tu parlais pas de ça. Tu parlais des types de base et comme quoi XML n'en avait pas hormis string, contrairement à json. Je te réponds que si, avec les schémas. Et maintenant tu réponds que ça fait pas le café non plus! Faut pas changer non plus d'argument à chaque phrase! Non parce que json non plus ne fait le café! :P
Le fait est que XML a des types de base, et c'était donc ma réponse à ton assertion comme quoi il n'y en avait pas; et qu'en plus la validation de ces types peut être faite avant le code spécifique (pas en json, où ça doit être fait dans le code, à moins d'ajouter un mécanisme de schéma spécifique au json). Ça n'empêche en effet absolument pas une validation complémentaire dans le code si nécessaire (comme ton exemple de date). Mais au moins, on sait que les données arrivent directement dans le bon type si on valide avec un schéma.
Par curiosité, comment tu fais quand tu as des données arborescentes à représenter dans tes fichiers de conf (ou simplement des listes) à plat ?
Je l'explique plus haut, dans un autre commentaire. En gros, si tu as un besoin super complexe dans un fichier destiné à être édité par un humain de manière régulière, j'aurais tendance à dire qu'y a un problème plus profond de design logiciel. Si tu dois représenter des données très complexes, faut alors avoir une interface graphique adaptée et compréhensible (et en interne, un format adapté, pas du clé=valeur). Parce que je suis désolé, mais que ce soit du json ou du XML, si y a plusieurs niveaux et une arborescence avancée, c'est juste imbitable pour un non-programmeur. Je mets pas ça entre les mains des gens par design comme étant dans le fonctionnement normal de l'application.
Un truc que tu veux éditable par les gens dans le fonctionnement habituel du programme, c'est un fichier très simple. Sinon y a vraiment un problème de design.
Ensuite ces formats clé=valeur ont tout de même des types de base (chaînes de caractère, nombre et booléen), et des listes (ex: le format clé=valeur standardisé par Freedesktop, dont je donne déjà le lien plus haut a des listes avec séparation des éléments par des point-virgules). Et puis il y a des groupes (mais ca s'arrête là au niveau "arborescence", pas de niveau supplémentaire au delà).
Il y a un minimum de fonctionnalité tout de même! :-)
Cela devrait être bien suffisant pour un fichier destiné à édition manuelle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
si c'est pour une édition par des humains, je préfère YAML.
J'ai eu une fois à implémenter un parseur YAML. C'était vraiment l'horreur. Ils ont fait des choix vraiment bizarres et ont défini plein de façons de noter la même donnée. On ne s'en rend pas compte côté utilisateur car on va en général utiliser la même notation partout. Mais quand on fait un parseur, il faut être exhaustif (pour ce 1% de gens qui vont envoyer des fichiers avec cette syntaxe). Très mauvaise expérience.
Si pour une édition par des humains, je préfère quelque chose de bien plus simple encore, type fichiers clé-valeur simple. Il y a des formats de ce type standardisés, typiquement celui de FreeDesktop qui fut défini pour les fichiers .desktop (donc utilisés par la plupart des — sinon tous les — bureaux libres). Ce type de format reste simple à parser (et en général, y a même pas besoin de faire soi-même, si on utilise une bibliothèque de bureau, par exemple glib). Ce format peut contenir des chaînes de caractères, nombres, booleans et des listes, des sections (même la localisation est prise en charge si besoin est, et elle peut être automatisée avec extraction du texte original par gettext puis génération de fichiers qui contiennent toutes les localisations; c'est ce qui est fait en général pour localiser les fichiers desktop!) et il n'emploie pas 10 variantes par type ni de logique super-compliquées.
Sinon y a aussi des formats encore plus simples, plus proches du INI de Microsoft (le format standardisé par Freedesktop est d'ailleurs très proche, bien qu'avec quelques différences) qui est aussi beaucoup utilisé, même sur nos systèmes libres.
Ces formats sont souvent suffisants et je ne vois pas l'utilité d'apporter la complexité du YAML pour un fichier destiné à être édité par des humains. Ensuite je dis pas, YAML a des fonctionnalités plus avancées et peut-être dans des cas d'usage très particuliers, il convient de monter d'un cran et d'utiliser ce format. Mais je n'ai jamais eu le cas. En général, lorsque le besoin devient vraiment complexe, ce n'est plus un format que je destine à l'édition par des humains, mais par un programme (et à ce moment, ce n'est pas non plus le YAML que je vais choisir).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
meilleur rapport signal / bruit (moins d’octets perdus)
Le XML (comme tout format texte avec syntaxe répétitive) est très compressible, rendant l'argument obsolète. Tous les formats ou protocoles qui sont basés sur XML le compressent dans l'usage "normal" (hors débuggage où on désactivera la compression temporairement).
pas de différentiation entre attribut et valeur du nœud
Je ne comprends pas ce que tu veux dire.
encodage fixé par la norme
Si c'est pour de l'échange de fichier, le fichier XML définit simplement son codage dans sa déclaration. Ensuite le décodage est quand même un truc de base sur tous les systèmes. La seule problématique est lorsqu'un format de fichier ne déclare pas le codage donc il faut faire de la détection (ce qui n'est pas du 100% de réussite). Mais comme XML le fait, y a pas de problème ici.
En plus dans les faits, très souvent les sous-formats vont imposer un codage unique (souvent UTF-8). C'est le cas par exemple de XMPP.
types de base existants dans le langage (liste, flottants, chaînes), faisant partie de la norme, là où XML n’a que des chaînes
Si tu fais du XML bête et méchant, sans schéma, oui il n'y a pas vraiment de types. Mais un format XML est fait pour être défini (en fait XML en soi est un format générique pour faire des formats spécifiques!), par exemple dans un schéma XML et là tu as tous les types que tu veux.
En outre, là où XML va avoir une étape de validation générique au niveau de ton parseur (que tu n'as donc en général pas à implémenter dans le code; en utilisant une bibliothèque XML externe, on se contente de fournir le schéma et la validation est faite pour nous), tu dois en général implémenter de la validation spécifique pour un format json.
Sans compter la reprise sur erreur: comme XML a une étape de validation du schéma, il est capable d'ignorer tout erreur de contenu (mauvais type, attributs inconnus, etc.), mais en le prenant en compte, avec par exemple simplement un avertissement dans le programme qu'il y a une corruption possible du fichier. En très peu de ligne (encore une fois, en se reposant sur une bibliothèque générique), on va définir de la gestion d'erreur précise pour divers cas et on ne sortira en erreur complète que sur les problèmes majeurs. C'est même la base de certains sous-formats de XML, par exemple XMPP encore, qui est extensible par nature, a certaines caractéristiques obligatoires mais peut aussi accueillir des extensions (et un client/serveur peut les ignorer s'il ne les prend pas en charge mais sans jamais casser la connexion ou le transfert fiable et complet des données).
Json pourrait faire tout cela bien sûr, mais nécessite beaucoup de code spécifique et sera donc bien plus prompt aux erreurs de programmation. Surtout en gestion d'erreur, on sait tous que c'est exactement le genre de trucs chiants que beaucoup vont laisser "pour plus tard"; et le manque dans le code ne se voit pas pendant longtemps — puisque logiquement en général le contenu utilisé est valide — jusqu'au jour où on tombe sur un bout de données corrompu et là, le programme risque de vraiment mal le prendre!
Ensuite XML est clairement beaucoup plus lourd à mettre en place et ce n'est pas à utiliser selon moi pour des usages simples. Genre effectivement pour une API web, on va peut-être éviter de la compression (quoique ça dépend; même pour du json, si l'API est faite pour transporter pas mal de données, cela peut être rentable de compresser). De même pour plein de petits formats très courts (typiquement dans une API web, on peut considérer que chaque réponse à une fonction a potentiellement un format différent), on veut peut-être pas écrire plein de mini-schémas XML. Ce serait vite ennuyeux.
Dans plein de cas, json est bien plus léger, simple et flexible. Donc c'est plus agréable pour tous ces petits usages simples. Par contre dans le cas de la création d'un format long et complexe, beaucoup utilisé et structuré, je ne choisirai probablement jamais json. C'est juste le moyen idéal pour se retrouver avec des fichiers invalides sans même s'en rendre compte pendant des semaines (jusqu'au jour où notre programme a besoin de parser ce bout du fichier et saute à notre figure).
Quant à des fichiers de conf (si on prévoit édition par un humain), je n'utiliserais ni json ni XML, mais un format simple "attribut: valeur" ou "attribut = valeur", type fichiers INI. Parce que quand on parle d'édition et lisibilité possible par un humain, je suis désolé mais ni json ni XML ne sont de bons choix. Typiquement c'est très facile de casser un fichier de l'un ou l'autre format (classique: oublier le tag fermant en XML ou le crochet fermant en json).
Par contre lisibilité par un développeur (pour débugguer par exemple), je trouve les 2 aussi lisibles du moment qu'ils indentés pour faciliter le débuggage (et les 2 aussi illisibles s'ils sont pas indentés ou sans retour à la ligne).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Soutenir l’œuf et la poule !. Évalué à 10.
Pour GIMP? Alors déjà, comme tu le notes, oui nos fonds GIMP sont gérés par la fondation GNOME. C'est un peu comme si on avait un compte chez GNOME (et si je ne me trompe pas, ils prennent un pourcentage pour payer l'administratif supplémentaire que ça leur donne). La raison, c'est que GIMP en soi n'a pas d'entité juridique propre. C'est ce qu'on appellerait une association de fait dans les pays francophones (au moins en France et Belgique). Mais note bien que cet argent donné à GIMP va vraiment à GIMP. GNOME garde une comptabilité distincte et cet argent donné pour nous n'est absolument pas utilisé par GNOME. Il est juste gardé par eux en notre nom.
Ensuite à quoi sert cet argent? Il sert principalement à réunir les développeurs régulièrement, dans des évènements comme Wilber Week ou Libre Graphics Meeting. Cela ne paye pas directement du développement. Mais comme Pierre Jarillon le note dans un commentaire, les rencontres de développeurs restent très importantes et ne sont pas à négliger. Je ne veux surtout pas donner l'impression de vouloir minimiser cela et si c'est là où tu veux donner, merci!
Pour soutenir plus directement du développement, tu peux donner mensuellement directement à 2 développeurs seulement (c'est expliqué sur la page officielle de donation de GIMP), c'est à dire les 2 seuls développeurs en lien avec GIMP qui essaient de vivre du logiciel libre: Øyvind Kolås, le mainteneur de GEGL, et moi-même (second plus gros contributeur de GIMP après Michael Natterer, mainteneur de GIMP). Øyvind fait donc des trucs plutôt côté moteur graphique; moi je travaille plus sur l'interface graphique, l'utilisabilité, etc. J'ai aussi énormément travaillé sur la stabilité. C'est simple quand on a commencé à utiliser GIMP, en 2012, il plantait pour un oui ou pour un non. C'est d'ailleurs comme ça que j'ai vraiment commencé à contribuer (parce que j'ai commencé à corriger des bugs, puis de plus en plus) et depuis j'ai corrigé pas mal de crashs et bugs et j'aime à penser que de nos jours, on est pour beaucoup dans sa stabilité (c'est simple, on l'utilise des heures durant, tous les jours, et ça marche). Les contributions d'Øyvind et moi-même sont tout aussi essentielles et complémentaires; c'est à toi de voir ce que tu préfères financer.
Bon le financement d'Øyvind marche bien mieux que le notre, j'imagine que c'est beaucoup pour le fait que c'est parce qu'il est dans le projet depuis 13 ans, alors que nous seulement 5 ans. Et aussi qu'on est nul en marketing. Sûrement aussi que le double côté film + développement nous dessert car certaines personnes ne semblent pas vouloir payer pour un film d'animation, juste du développement logiciel. Mais pour moi, c'est essentiel, car je ne coderais pas sur GIMP autant si ça ne nous servait pas justement au quotidien. Nous sommes des contributeurs car c'est notre outil quotidien. C'est donc indissociable pour moi.
Voilà tu sais tout. Tu as donc 3 cibles de financement: le projet GIMP core (tu paieras alors tout le côté communautaire), Øyvind si tu veux financer du développement sur GEGL, et ZeMarmot pour financer du développement sur GIMP même, à un peu tous les niveaux. On peut être financé par Tipeee en euro, patreon en dollar, ou comme noté dans un autre commentaire, tu peux donner directement à l'association LILA qui est l'organisme chapeautant le projet ZeMarmot, évitant ainsi des frais de plateforme (par exemple avec un virement bancaire récurrent), avec un message expliquant que cette donation est pour le développement sur GIMP principalement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: le floue
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Wilber Week, GIMP, interviews des développeurs et sortie de la 2.10 à venir !. Évalué à 10.
Juste pour être sûr qu'on se comprend, notre objectif n'est pas de "rattraper" Photoshop, ni de le copier. On fait notre propre logiciel de création graphique, aussi bien qu'on puisse et en Libre. Le but de GIMP n'a jamais été d'être un clone. Je ne dis pas que c'est ce que tu voulais dire. C'est pas très clair. Mais au cas où, je le précise car c'est un commentaire qu'on a régulièrement. :-)
Il n'y a pas vraiment de flou, c'est très simple: en 2.8, y a prise en charge de 8 bits seulement, et en 2.10 y aura prise en charge 16 et 32 bits pour l'image de travail. :-)
Pour du 12 bits, je sais pas si y a des formats d'image qui ont cette profondeur, mais si oui, on devrait alors pouvoir exporter en 12 bits sans problème à partir d'une image de travail 16 ou 32.
Ensuite comme quelqu'un le note, la version de développement (estampillée 2.9) est déjà très fonctionnelle et stable au quotidien et te permettrait déjà de travailler des images en 16/32 bits. On utilise essentiellement la version 2.9 depuis plus d'un an pour le projet ZeMarmot. Maintenant soyons clair que c'est une version de développement et il peut y avoir de la casse. Pour une utilisation pro de la version de développement, il convient d'être tout de même un utilisateur éclairé au cas où les choses se passent mal. On fait gaffe, mais on ne peut absolument pas assurer une stabilité parfaite entre 2 versions de développement. Mais ça reste faisable. On le fait bien (mais évidemment en tant que développeur de GIMP, je suis un utilisateur assez éclairé aussi!).
Vu de notre côté, on avance aussi bien, mais c'est moins visible car on ne sort pas de version avec nos avancées. Et donc oui, vu de l'extérieur, ça n'a pas l'air d'avancer et c'est frustrant, je le comprends tout à fait. D'où le problème de versionnement qu'on essaie de résoudre et dont je parle dans cette news.
Ensuite "des moyens pas forcément plus importants"… alors Darktable oui, c'est le seul de la liste où c'est vrai. Mais Blender ont leur fondation derrière qui a maintenant des moyens de plus en plus conséquents (pas encore gigantesque, mais ils font quand même des crowdfunding à plusieurs centaines de milliers d'euros, et touchent du financement européen du même ordre de grandeur, ils ont leur cloud avec abonnement, etc.), et Krita ont créé leur propre fondation et font du marketing à fond, des crowdfundings, etc.
GIMP reste essentiellement communautaire. Néanmoins il y a quelques développeurs, notamment moi, qui essayons justement de nous donner des moyens financiers. Le jour où notre financement Tipeee ou Patreon sera de quelques milliers par mois, alors oui on pourra commencer à dire qu'on commence à avoir des moyens pour développer GIMP professionnellement. À ce jour, le développement de GIMP est financé avec des cacahuètes.
Qui attend le 3? On n'a même pas vraiment commencé à travailler dessus. Bien sûr, on a quelques commits de temps en temps, mais c'est minime. On maintient la branche juste assez pour qu'elle compile avec GTK+3. Et de temps en temps, on fait quelques trucs, mais c'est pas assez pour dire qu'y a du dév actif.
Le développement actif est quasi essentiellement sur la version 2.10. C'est là où les choses se passent et la seule version à attendre pour l'instant.
Je ne comprends pas, le problème est juste une histoire de numéro? Chez GIMP, le second nombre indique une sortie majeure. 2.10 sera autant une majeure que 3.0. De même que 2.8 était une sortie majeure.
Bonne chose, mauvaise chose, je ne sais pas. Peut-être que cela changera un jour. J'ai l'impression qu'historiquement, cela suit simplement les versions de GTK+. Avec l'accélération du versionnement de GTK+, ça voudrait d'ailleurs dire que les versions de GIMP risquent d'accélérer aussi beaucoup après GIMP 3. On verra.
Ben oui, GEGL a la prise en charge du 16 bit (même 32 bit, qui est maintenant le format natif de GIMP). C'est ce qu'on dit. Je pense que tu n'as simplement pas suivi les nouvelles de GIMP depuis… 4 ou 5 ans? ;-)
Bon bien sûr, ça implique de suivre les news de dév, puisqu'il n'y a effectivement pas de sortie de version stable. Donc je comprends l'incompréhension, pas de problème.
Qu'est-ce qui paraît suspect? Que GIMP est un logiciel libre développé à 99.999% par du bénévolat dans le temps libre, que personne ne bosse à temps plein, payé, et qu'on est pas un business? J'ai du mal à comprendre où tu veux en venir.
Personnellement j'aimerais bien en vivre et pouvoir faire cela (développer GIMP) à temps plein. Mais pour cela, il faut nous soutenir financièrement sur les liens du projet ZeMarmot donnés juste au dessus. Parce qu'autrement, nous dire que ça paraît "suspect" que ça avance pas plus vite, ben ça me fait juste mal au cœur. ;-(
À l'heure actuelle mon état d'esprit est le suivant: on finit notre épisode cette année et si on a pas atteint un financement acceptable pour vivre décemment (à l'heure actuelle, le financement ne paye même pas un loyer, surtout qu'on fait tout dans les règles et qu'y a des charges sociales en salaire, etc. C'est pour te dire que si y a une définition de la précarité, je rentre dedans), ben on commencera à chercher des alternatives et mon implication à GIMP en souffrira probablement drastiquement malheureusement. Et il n'y aura rien de "suspect" au fait que la rapidité de développement de GIMP diminuera beaucoup plus puisque je suis le second plus gros contributeur depuis plusieurs années. Ensuite il reste Mitch, qui fait 2 fois plus de commits que moi en ayant son propre business. Je sais pas vraiment comment il fait (enfin si, je sais; il contribue à GIMP depuis 20 ans et connaît son code bien mieux que moi, et aussi il a beaucoup plus d'expérience de développement en général que moi). Mais il est entièrement bénévole alors lui reprocher aussi de pas aller assez vite serait tout aussi aberrant.
Voilà j'espère que ça te donne une autre perspective sur le développement de GIMP et les "moyens" (assez imaginaires) que tu sembles imaginer derrière son développement.
Merci. En tous cas, tu as l'air de bonne foi et amical (contrairement à d'autres cas; malheureusement contribuer à GIMP, c'est s'exposer à pas mal d'insultes et de haine et je suis pas toujours bien taillé pour cela; mais je travaille pour me durcir le caractère et être moins sensible à la méchanceté, car des fois ça a été dur). Mais je te conseillerais de faire attention dans ton choix de mots car ils peuvent être assez mal pris. Surtout quand justement je cherche à en vivre mais n'y arrive pas (j'ai parfois l'impression de faire des appels au crowdfunding dans le vide).
J'espère que mon explication t'aura un peu éclairé sur GIMP et son développement. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mineures, majeures
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Wilber Week, GIMP, interviews des développeurs et sortie de la 2.10 à venir !. Évalué à 6.
Pour l'instant il y a quand même de grandes différences. En tous cas 2.10 avec un changement profond du moteur graphique (certes déjà en cours, mais jusqu'alors GEGL n'était utilisé que pour des trucs superficiels, maintenant c'est vraiment partout); puis 3.0 avec le passage à GTK+3, ce qui va débloquer aussi beaucoup de choses normalement, avec prise en charge améliorée des tablettes, amélioration des thèmes, route vers HiDPI, etc. Plein de choses merveilleuses et féériques qui nous sont promises. Ensuite je suis persuadé que tout ne sera pas magique et qu'il faudra travailler un peu pour y arriver, mais au moins on sera sur le chemin. Pour l'instant avec GTK+2, on est un peu contre un mur.
Mais oui peut-être qu'à terme, la différence entre une mineure et une majeure pourra s'amenuiser. Est-ce un mal? Je ne pense pas. Même le noyau Linux n'a pas vraiment de différence entre ses majeures et ses mineures. On le voit bien dans les emails de Linus pour décider les passages de majeures, en général il l'accompagne d'une blague, genre "j'ai plus assez de doigts pour compter". Et voilà on est passé sur une majeure version 4.x du noyau sur un coup de tête et un sondage sans aucune autre logique que "est-ce que vous avez envie ou pas qu'on passe à v4?"
Est-ce un problème? Je ne pense pas vraiment, surtout si ça permet de rendre le développement plus énergique (on peut sans cesse créer des nouvelles fonctionnalités attrayantes!).
Firefox, oui. Je ne sais pas quel système utilise LO, mais si c'est comme Firefox, alors oui aussi.
La seule chose que je voudrais faire différemment que Firefox, c'est de garder une promesse de stabilité de l'API un certain temps. Et pour ça, les versions à point restent un bon moyen simple pour reconnaître la stabilité, contrairement à un simple entier. Firefox, de ce que je comprends, c'est qu'ils cassent l'API sur un coup de tête un peu n'importe quand, et que pour un dév de plugin, il faut vraiment se tenir à jour à chaque version et lire le changelog en détail. Avec une promesse de stabilité basé sur un numéro de version, c'est facile: le premier chiffre est le même, donc mon plugin continuera à fonctionner.
Je pense que cela reste un très bon intérêt aux numéros à point.
Ensuite, je me réserve le droit de changer d'avis dans un sens ou l'autre. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Détails !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Wilber Week, GIMP, interviews des développeurs et sortie de la 2.10 à venir !. Évalué à 10. Dernière modification le 03 mars 2017 à 01:55.
Salut !
Je ne m’attendais pas à ce que ça passe en première page. Sinon, j’aurais mieux écrit mon journal…
Dans ce cas, je tiens à préciser que lorsque je parle de « résumé des points importants », ce sont des points importants « personnels ". D’autres contributeurs ont aussi bossé sur des choses très importantes. Notamment, il y a eu un travail (qui est toujours en cours) très important sur la base de Linear is the new black par Pippin, Mitch et les contributeurs GEGL. Ce travail se base sur le principe que les images en 32 bits flottants en lumière linéaire sont le format de travail idéal.
Aussi, les modes de calques (et plein d’autres fonctionnalités) ont été revus et l’interface utilisateur mise à jour par Mitch, en se basant sur le travail précédent. Bien sûr, comme la compatibilité descendante est un besoin majeur pour nous, les anciennes implémentations de modes sont toutes présentes à vie et utilisées en chargeant de vieux documents (de sorte qu’un ancien XCF aura toujours le même rendu, même dans 10 ans)¹ mais l’interface utilisateur est faite de telle sorte que les nouveaux documents utiliseront les nouvelles implémentations (bien qu’il restera possible de trifouiller pour retrouver les anciennes). Je ne veux pas trop parler de cela en détail, car j’ai peur de dire des bêtises.
Un peintre et contributeur (de rapports de bogues, d’idées, de propositions d’amélioration…), Americo Gobbo, fait d’ailleurs pas mal de recherche sur les nouvelles possibilités de GIMP en la matière, surtout les applications directes à la peinture numérique grâce aux nouveaux modes de calques. Notamment, il peint en texturant ses brosses. Voir ses expérimentations, par exemple ça ou encore ceci ou cela… Il fait aussi quelques vidéos intéressantes sur le sujet.
Il n’était pas présent à Wilber Week (il sera à LGM, je l’ai invité au nom de GIMP car son travail est intéressant et important pour améliorer GIMP et son interface graphique), mais ses expérimentations de brosses et textures se basent directement sur des changements de code de janvier.
Et c’est sans parler du travail de Elle Stone (qui n’était pas présente non plus mais est souvent sur IRC), une experte des couleurs et algorithmes, l’une des plus grosses critiques de GIMP, mais en même temps une contributrice majeure en revue de code et d’algorithme ultra‐poussé (elle n’est pas développeuse, mais elle lit le code à l’occasion et fait des correctifs algorithmiques), tests de versions de développement au pixel près, pointage de problème (on ne peut rien cacher sous le tapis avec elle !) avec force insistance, etc. Je ne comprends pas tout ce qu’elle dit car elle est très calée, mais ses revues sont de grande valeur.
On a aussi eu un contributeur (qui ne veut pas voir son nom cité) dont le trip est d’implémenter des algorithmes de recherche, et il a fait pas mal de contributions sur GEGL et aussi sur GIMP lors du Wilber Week. Il fait d’ailleurs du code de très bonne qualité. On espère qu’il restera avec nous. :-)
Il s’est donc passé pas mal de choses pendant et autour de cette Wilber Week. On était plusieurs développeurs et contributeurs sur place (et d’autres qui ne pouvaient venir, genre Ell, un contributeur majeur de ces derniers mois). Voilà, je voulais donc revenir un peu sur mon impression de compte‐rendu, qui a l’air bien terne si jamais on croit que c’est le compte‐rendu complet de Wilber Week : ça ne l’est pas ! C’était un compte‐rendu tout à fait personnel. D’ailleurs, on prévoit aussi un compte‐rendu plus global de l’évènement sur gimp.org.
C’est personnel dans le sens : je m’y suis impliqué. Pas dans le sens « le reste m’intéresse pas », bien entendu. :P
C’est super excitant ce que d’autres font en parallèle. C’est ça aussi qui est cool : travailler dans une équipe hétéroclite qui bosse sur plein de trucs différents tous très intéressants ! Franchement, je n’aimerais pas donner l’impression que Wilber Week, c’était juste pour faire un paquet Flatpak et discuter du changement de logique de version à dix personnes pendant une semaine (aussi intéressants que soient ces deux items !). Cette dépêche a peut‐être été promue un peu vite. Si j’avais su… Il aurait fallu la compléter un peu avant. :-)
Mais merci quand même ! ;-)
[1] Pour la petite histoire, sous Photoshop, pa exemple, certains fichiers identiques peuvent apparaître différemment selon qu’ils sont ouverts avec CS5 ou CS6. C’est un problème assez sérieux pour des gens qui travailleraient en équipe avec versions disparates (problème classique dans le logiciel propriétaire, car mettre à jour signifie payer une mise à jour de licence) ou simplement pour réutiliser ses vieux documents.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Soutenir l'œuf et la poule !
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Wilber Week, GIMP, interviews des développeurs et sortie de 2.10 à venir!. Évalué à 2.
Je confirme, ZeMarmot a reçu un soutien très généreux de GNU Computer. Merci beaucoup! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Version majeure / mineure
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Wilber Week, GIMP, interviews des développeurs et sortie de 2.10 à venir!. Évalué à 7.
Pourquoi? C'est qu'une question de définition. Hormis le fait qu'historiquement beaucoup de projets (dont GIMP) suivaient effectivement cette définition, tu peux tout à fait redéfinir, et dire par exemple qu'une version majeure, c'est quand tu changes quelque chose de… majeur justement (comme le moteur graphique, cas de GIMP 2.10, ou le toolkit graphique, cas de GIMP 3), et une mineure, c'est le reste.
D'ailleurs, si on souhaite se rapprocher du "versionnement sémantique", utilisé massivement, surtout pour des bibliothèques (peu les logiciels finaux) libres, tu peux tout à fait rajouter des fonctionnalités dans une mineure. Ce qui importe, c'est de le faire en restant compatible avec l'existant (tant qu'on ne change pas de version majeure). GIMP fournissant aussi une API (pour les plugins), c'est le cas, ça l'a toujours été et ne changera pas: les plugins existants resteront compatibles (d'ailleurs le numéro majeur considéré pour la libgimp est le premier, comme habituellement en semver, alors que pour le logiciel GIMP, c'est le second qui fait la majeure; donc notre API est encore plus conservative que le logiciel graphique, et c'est bien).
Personnellement le type de sortie continue que je vois, on ne ferait simplement plus de différence entre majeure et mineure. Simplement on pourrait sortir sans arrêt des mises-à-jour, que ce soit avec juste un correctif, ou avec une nouvelle fonctionnalité. Comme beaucoup de logiciels font de nos jours (notamment Firefox). Je sais que ça a fait jaser à l'époque de Firefox et que les gens ont cru que c'était juste un coup marketing (pour avoir le numéro de version le plus haut possible), mais je pense que cela pourrait vraiment libérer le développement. Pouvoir sortir des nouveautés sans arrêt, dès qu'elles sont vraiment finies, c'est super. Pourquoi s'encombrer avec des règles artificielles?
Bien sûr, il faudra garder des règles de compatibilité pour les plugins tout de même. Par exemple sur Firefox justement, les problèmes sont nombreux et beaucoup d'entre nous perdent des plugins régulièrement aux mises-à-jour. ;-( Un peu plus de stabilité serait bienvenu.
Donc en un sens, on peut garder les concepts de majeures et mineures mais limiter cela aux APIs ou aux changements graphiques vraiment profonds. Et c'est un peu la direction que nous prenons avec GIMP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bourrage d'urne.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Votez pour « GIMP Motion », extension de GIMP pour l’animation (projet ZeMarmot). Évalué à 2.
Ah. Je n'ai pas testé. On avait vu qu'on ne pouvait pas voter avec un second ordinateur dans le même appart (donc même IP) donc j'ai supposé que ça se base vraiment sur l'IP. Mais si tu dis que juste vider ses cookies suffit, alors c'est vraiment programmé n'importe comment.
Déjà que même de base la logique d'un vote par IP n'est pas très bonne, déjà parce que ça interdit à plusieurs personnes de voter si derrière la même IP (typiquement la famille derrière une même box, ou ses collègues au boulot), mais surtout car — comme tu l'indiques — ça rend le bourrage facile. Beaucoup de fournisseurs d'accès ne garantissent pas d'IP stable, en particulier avec des connexions 3G.
Le second, c'est nous. Et si on est second (et on a même été premier pendant un moment), c'est grâce à linuxfr! Merci Linuxfr. :-)
On était genre 5ème, puis j'ai publié ce journal, et en une demi journée, on a passé tout le monde (c'est simple, j'ai publié en début de soirée, le lendemain au réveil, on était premier). Ça a continué sur la lancée pendant une bonne journée ou plus, et à un moment on a même eu plus de 200 votes d'écart avec le second! Mais là ça s'est calmé; les votes pour GIMP Motion augmentent encore régulièrement, mais plus très vite. :-/
Donc notre remontée fulgurante, c'est pas du bourrage, c'est du linuxfrage (le site avec un lectorat de libriste si grand qu'il est connu pour faire des DDOS involontaires de petits serveurs lorsque certains liens sont si intéressants que tout le monde clique!). ;-)
Le premier, on s'est posé la question, en effet. Surtout que hier soir, quand ils nous ont dépassé, on a lancé des messages sur les réseaux sociaux pour activer nos soutiens; lorsqu'on a difficilement grimpé à leur niveau et dépassé de quelques votes, ils ont soudainement fait un bon de plus de 100 votes en genre 30 minutes. Ça m'a paru suspect.
Ensuite je veux pas médire sans savoir. Ils ont peut-être une communauté très vaste aussi et savent bien faire jouer leur communication. Apparemment ils ont une "app" de téléphone et poussent les utilisateurs à voter en promettant de débloquer des fonctionnalités lorsqu'ils atteignent des paliers de vote.
Au final, même s'ils utilisent vraiment des techniques de changement d'IP (mais j'en sais rien), ce n'est certes pas fair-play, mais peut-être pas contre les règles. Le règlement n'indique pas que les votes doivent être limités à un par personne physique. Il dit juste:
Nous on va continuer à la jouer cool, ne serait-ce que parce que j'ai pas que ça à faire que de piper les dés. On va se contenter de lancer quelques appels comme on l'a fait sur linuxfr et espérer que la communauté du libre saura être plus importante en nombre. Pour moi, LinuxFR a encore fait (il y a 2 jours, avec le nombre de vote impressionnant qu'on a eu) une démonstration épatante du pouvoir de la communauté du logiciel libre… et en plus seulement à l'échelle francophone!
Oui. Par contre, le gagnant du prix du public est "disqualifié" automatiquement des prix du jury (ce que je trouvais totalement idiot au début, soit dit en passant car le grand prix est de 5000 €! Mais maintenant que je me rends compte que c'est si simple de "bourrer les urnes", c'est peut-être la raison).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Il y a beaucoup de "manipulation de fenêtres".
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Votez pour « GIMP Motion », extension de GIMP pour l’animation (projet ZeMarmot). Évalué à 5.
Oui y a encore plein de trucs avec lesquels je suis pas tout à fait heureux. En plus le fait d'être bloqué sur GTK+2 n'aide pas. J'ai hâte qu'on passe à GIMP 3 pour profiter de certaines nouvelles widgets.
Ceci dit, quand tu parles de "manipulation de fenêtres", j'imagine que tu parles des divisions en panneaux que l'on peut redimensionner en cliquant-déplaçant la bordure. Peut-être que ça se voit pas bien en vidéo, mais c'est en fait assez simple et intuitif car ce type de GUI est très classique. En plus j'ai fait ce screencast juste avant d'uploader, sur mon ordi portable qui a un écran assez restreint. Avec un grand écran, voire plusieurs écrans (configuration classique chez les graphistes et animateurs), ce type de problème se poserait beaucoup moins.
Mais ça n'empêche pas que plein de choses doivent être améliorés quand même. :-)
Pour le moment, j'essaie de me concentrer surtout sur le cœur de certaines fonctionnalités, et accélérer les chargements, etc. (ça se voit pas dans la vidéo, car c'est pas le but; le traitement d'image pour la vidéo, c'est pas facile pour obtenir un bon compromis entre une prévisualisation fluide, ce qui veut en général dire qu'il y a eu du préchargement, et une GUI qui soit réactive malgré le dit-préchargement).
Donc bon, oui y a du boulot! Par conséquent merci pour avoir cliqué! Si on gagne, ça me donnera du temps pour pouvoir travailler dessus. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Sauvegarde
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Installer DeepIn en Triple boot avec Windows et ElementaryOS Loki déjà installés. Évalué à 4.
Je ne peux pas te donner de réponse avisée sur ton problème exact. Par contre, dans tous les cas : sauvegarde tes données. Quand tu fais ce genre de manips, il ne faut jamais supposer qu'il n'y aura aucun problème. voilà pour mon conseil du jour. ;)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mon commentaire sur le blog…
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 10.
Dont c'est le métier? Pas forcément. On ne regarde que la qualité du code, pas le CV. La personne pourrait être éboueur de profession ou pilote de course qu'on ne le saurait même pas. Si le code est bon, on l'intègre, sinon on propose des améliorations possibles pour intégration ultérieure potentielle (on appelle cela de la "revue de code" et on en reçoit tous, même les mainteneurs des plus gros projets demandent aux autres qu'ils revoient leur code).
Donc un projet qui n'a aucun designer ne pourra alors jamais en avoir puisque les designers ne pourront jamais être jugé par un designer déjà présent? Là y a comme un problème de poule et d'œuf, non?
C'est déjà mieux. Pourtant tu continues à faire bien trop de distinction, à classer les gens et les mettre dans une case ('dév', 'designer'…), à confondre qualité et profession/métier (comme je l'ai dit et je le répète ça joue, bien entendu, mais c'est loin d'être du 100%)… Et surtout tu dis ça, mais clairement en vrai tu juges sans savoir si ce sont des gens qui "savent". As-tu fait un background check sur l'ensemble des gens que tu as cité et moqué (pour ne pas dire craché dessus, disons le clairement) dans ton post de blog? J'ai quand même l'impression que tu me classeras direct dans la catégorie "sale développeur qui y comprend rien" si on a affaire sur un projet. Or j'ai fait de l'ergonomie à l'université, avec des projets où j'ai fait des tests utilisateurs, etc. Ensuite je n'ai pas poursuivi du tout dans ce domaine et suis le premier à dire que je suis loin d'un expert design ou ergonome. Mais ça n'en reste pas moins un sujet qui m'intéresse, je lis sur le sujet, je veux en savoir plus, etc. Alors dans quelle catégorie je rentre? Suis-je quand même un "dév qui sait"?
C'est une question bien rhétorique car je ne m'attends pas à ce que tu me répondes direct. Enfin… j'espère que tu n'allais pas le faire. Ce serait bien présomptueux. Et c'est là mon point d'argument: tu ne peux pas avoir d'avis sur chaque contributeur à un projet avec juste quelques messages en arrivant sur un nouveau projet. Et ce que ce soit pour la programmation ou le design.
L'indentation dans le code est importante et on intègre les problèmes d'indentation dans la revue de code. On appelle cela le "style" du code, il doit rester cohérent dans l'ensemble du code pour que celui-ci reste lisible et compréhensible. Ce n'est absolument pas une sorte de réaction de kikoolol comme tu sembles le penser, est même potentiellement insultant (comme beaucoup de choses que tu sembles penser des développeurs) et montre une incompréhension du travail de développeur.
Bien sûr si c'est l'unique problème, on pourrait simplement intégrer le patch et corriger l'indentation ensuite nous-même, ce qu'on fait parfois. Mais c'est important de le dire et de demander au contributeur de corriger lui-même son indentation. Si on veut garder les contributeurs et les pousser à continuer, ils doivent savoir quelles sont nos règles pour améliorer leurs patchs au fur et à mesure. En plus ce genre de choses sont très bien prises par les contributeurs justement. Tout revue de code est en générale bien reçue (en tous cas par les développeurs qui n'ont pas un égo surdimensionné, qui veulent vraiment aider, qui veulent aussi apprendre parfois, etc.) et montre bien qu'on s'intéresse au patch et qu'on veut l'intégrer.
Donc très mauvais exemple. Et ça montre que tu ne comprends pas du tout ce que font les développeurs encore une fois.
Pour te donner un exemple plus artistique (car il se trouve que j'ai un certain bagage dans le milieu artistique, moi-même déjà, mais aussi en collaboration technique avec des artistes). C'est un peu comme si un dessinateur utilisait son propre style dans un film d'animation au lieu d'utiliser le style du film (donc y aurait un perso différent stylistiquement des autres dans la scène). Tu peux transposer ça avec des arts plastiques où plusieurs artistes travaillent sur une même œuvre, sur la musique aussi avec des musiciens qui jouent ensemble, etc. Bien sûr, je parle pas d'œuvres où mélanger des styles très différent est justement le but (type cadavre exquis!), mais de trucs plus classiques. Il y a un moment où l'harmonisation du style des intervenants est tout aussi important que la compétence intrinsèque de chacun si on veut que l'œuvre finale soit belle. [*] On appelle cela du travail d'équipe!
Sur ces belles paroles, je pense que ce sera mon dernier message. J'ai pas l'impression que la discussion va vraiment évoluer et surtout j'ai le sentiment que tu as juste une dent contre les développeurs de logiciel libre, voire contre le logiciel libre dans son ensemble (à la façon dont tu as l'air d'attaquer quasi chaque projet).
C'est vraiment dommage car on a en effet vraiment besoin de designers. Ce pourquoi j'essayais de donner mon avis sur la question pour voir si on pouvait amender les choses. J'ai pas l'impression. :-/
[*] P.S.: après réflexion, mon parallèle n'est pas idéal car l'indentation n'influe pas directement sur le logiciel final (contrairement au style d'un dessin pour une œuvre dessinée). L'indentation en programmation est plus une histoire d'organisation. Un meilleur parallèle serait alors simplement des gens qui travaillent ensemble mais quelqu'un qui refuserait de suivre l'organisation du groupe. Genre il range des dossiers par date alors que tout le monde a décidé de ranger par ordre alphabétique (car c'est son style d'organisation, il veut pas qu'on lui impose un autre, vous comprenez!). Bien sûr, on peut quand même arriver à un travail acceptable, mais cela met clairement des bâtons dans les roues de la dynamique globale.
Je garde quand même l'autre exemple car plus artistique et te parlera peut-être plus, et je pense que c'est pas si différent au final, car la conclusion est la même: il s'agit au final de travail d'équipe et il faut savoir parfois faire des concessions sur son style le temps d'un projet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Mon commentaire sur le blog…
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 10.
Hmm… J'ai répondu sur le blog par correction, mais je me rends compte que la vraie discussion se passe apparemment ici. Même l'auteur d'origine ne semble plus répondre qu'ici. Allez hop! Je recopie ma réponse (rédigée en s'adressant à ce designer).
Bonjour,
Ce billet dit des choses justes, mais aussi d'autres qui me font peur, notamment après avoir vécu une mauvaise expérience avec un designer dans le libre justement.
Globalement je suis totalement d'accord avec le fait que l'on doit laisser le designer bosser et qu'il est le boss dans son domaine. Il est celui qui doit avoir le dernier mot dans ce qu'il fait.
Par contre, il est normal qu'il y ait une étape intermédiaire entre "inconnu au bataillon" et "mainteneur de tout l'aspect design du logiciel". C'est la même chose pour les développeurs. Dans beaucoup de logiciels libres, si un contributeur fait un très bon code dans une zone que personne n'a touché depuis des lustres, non seulement ce code sera accepté et intégré au logiciel, mais en plus si ce contributeur reste dans le coin et continue à contribuer, il sera considéré comme le "mainteneur" de ce bout de code et celui qui décide. Mais la condition, c'est bien: "si un contributeur fait un très bon code".
Parce que du mauvais code, y en a aussi plein (développeur pro ou pas), et si un développeur se ramène dans un projet avec comme intro "J’ai 11 ans d’expérience dans le développement, j’ai réglé des problématiques conceptuelles sur des sites et des projets stratégiques gargantuesques impliquant des dizaines de personnes juste pour la partie logicielle, donc chill, je peux gérer ton projet", ben ça me fera ni chaud ni froid. Et la réponse sera la même que pour un autre: ok on accepte les patchs, on attend le tien.
Note que j'ai croisé des professionnels qui ont des années d'expérience et dont les compétences m'impressionnent absolument pas, tout comme j'ai croisé des étudiants ou très jeunes développeurs qui trouvaient vraiment des solutions extrêmement pertinentes et qualitatives sur des problèmes très complexes. L'expérience, c'est important, mais ce n'est pas tout. Et ceci s'applique quel que soit le métier.
Donc oui, je suis totalement d'accord sur le fait qu'il faut laisser travailler et avoir le dernier mot au designer, mais il faut d'abord que ce dernier passe l'étape où on l'accepte comme un designer du projet. Tu ne peux absolument pas critiquer la décision de l'équipe SPIP comme tu le fais, par exemple. Note que je l'aime bien cette proposition de design, mais bon voilà, je contribue/décide pas chez SPIP. J'ai aussi eu des patchs refusés dans ma vie dans divers projets. Souvent j'y ai passé des heures et des heures. Mais voilà, c'est la vie. Je vais pas en faire une sorte de conclusion générale (et négative) sur le processus de développement dans le logiciel libre, ni me faire une opinion générale (et très négative aussi) sur une équipe de gens que je ne connais simplement pas, encore moins aller la diffuser dans un post.
Il y a aussi cette dualité stricte entre designer et développeur, que je n'aime pas. Comme je disais, je suis tout à fait d'accord que le designer doit décider des choses du design. Mais cela ne doit pas l'empêcher de pouvoir écouter les développeurs. Un développeur, c'est pas non plus un abruti qui a du caca dans les yeux, comme tu le dis si poétiquement. Ce n'est pas parce qu'on est développeur qu'on est forcément un débile du design ou qu'on ne peut pas avoir de bonne idées. De même qu'un designer peut aussi avoir de très bonnes idées pour les développeurs (il n'est pas toujours nécessaire de savoir programmer pour comprendre le boulot du développeur, ce n'est qu'une — parfois minime même — partie du boulot de développeur, ce que certains designers ne semblent pas voir).
Je parlais de mauvaise expérience, c'était justement avec un designer qui marquait une triple et très stricte catégorisation des gens: designer, développeur et utilisateur. Je me rappelle même qu'en réunion, une fois, il commence en notant un triangle sur tableau blanc pour noter les 3 catégories clairement séparées (la base de sa philosophie de contribution quoi). Il nous disait alors très clairement que les développeurs étaient des abrutis qui ne devaient absolument pas toucher ou parler du design. Un peu comme toi. Super expérience [ironique], je le dis tout de suite. Comme quoi, y a pas que les designers qui se font mal traiter par les dévs et peuvent mal vivre la collaboration (franchement j'ai très mal vécu cette collaboration et je suis très heureux qu'il soit parti, ça a débloqué beaucoup de choses car justement on le considérait comme le boss du design et on avait accepté son leadership dans ce domaine! Selon moi une erreur puisque c'était ce genre de personne, mais ça montre bien que c'est tout à fait possible). L'inverse existe donc aussi.
Le fait est que le designer est en effet celui avec l'expérience, la connaissance théorique, etc. sur le design. Il est celui qui aura le dernier mot. Ça ne l'empêche pas de pouvoir parfois avoir tort (voire d'être mauvais, comme un développeur peut être mauvais, etc. Le fait d'être un professionnel n'empêche pas cela) ou de pouvoir revoir ses idées en prenant en compte des contre-propositions. Le dév, c'est un techos; mais ça l'empêche pas d'avoir des idées dans le champs du design, et parfois bonnes, qui sait! Quant à l'utilisateur (non parce que ce designer considérait aussi que les gens ne savaient pas ce qui était bon pour eux et qu'il ne fallait donc pas les écouter, ce avec quoi je ne suis absolument pas d'accord non plus; je ne sais pas quelle est ta position sur le sujet, mais puisque tu considères qu'il ne faut écouter que le designer dont c'est le métier, j'imagine que tu te positionnes donc aussi pareil?)… les designers et développeurs sont pas aussi des utilisateurs potentiels? Pourquoi faire une sorte de limite stricte? Au final, les "utilisateurs", ben c'est des gens. Et ils ont aussi le droit à une opinion (même si — encore une fois — oui ils sont pas des designers pros et le(s) designer(s) du projet sera celui avec le dernier mot).
Ensuite dans ma vie, j'ai aussi eu de très bonnes interactions avec des designers (dans le logiciel propriétaire, c'est triste à dire!). Je me souviens de jobs où je lisais une spéc, puis j'allais m'asseoir à côté du designer et faisais quelques commentaires. Parfois il m'expliquait pourquoi mes idées n'allaient pas, puis après une discussion, je comprenais et remballais l'idée. D'autres fois, il comprenait mes idées, était d'accord, et faisait évoluer sa spéc. Franchement, ça se passait super bien, extrêmement bonne collaboration et très bon souvenir. Et c'était aussi un designer avec des années d'expériences, etc. etc. Mais la question n'est pas là!
Au final, je conclurai généralement: le logiciel libre, c'est comme partout, c'est fait d'humains avant tout. Et comme tout entre humains, la collaboration, ça veut aussi dire discuter et savoir prendre un peu sur soi de temps de temps. Aussi savoir accepter les critiques d'ailleurs (du moment qu'elles sont constructives et pas agressives, bien sûr!).
Je trouve que le libre est un très bon environnement pour se former à la fois une estime de soi, mais aussi une forme d'humilité.
Je travaille sur des logiciels libres, dont un très gros, et je suis constamment à la recherche de designers qui accepteraient de prendre la charge du design (ou d'une partie de celui-ci) parce que c'est un très vieux logiciel qui a vraiment une vieille GUI basée sur des paradigmes d'il y a plus de 20 ans (22 ans cette année). Une fois qu'on se sera mis d'accord, on considérera leurs choix comme des décisions. Mais ça ne doit pas empêcher les discussions et clairement je suis à la recherche de quelqu'un qui ne considérera pas les développeurs comme des sous-hommes. Je ne dis pas que c'est nécessairement ton cas. Je n'ai aucune idée de comment se passerait la collaboration avec toi et ne connais pas ton travail, ni n'ai aucun moyen de juger vraiment juste par cet article de blog. Peut-être que ça se passerait super bien, qui sait! Mais j'avoue que ça fait un peu peur de lire ton avis sur la collaboration avec les développeurs, ou du moins ce que je crois en comprendre. :-/
Ensuite je lis peut-être mal entre les lignes et me plante peut-être sur tes dires et intentions. Donc bah j'espère que tu trouveras ton bonheur dans le design de logiciel libre! Car oui, beaucoup de logiciels en ont vraiment besoin (ceux auxquels je contribue aussi sont clairement du lot!). Je suis d'accord sur ce point.
Donc bonne continuation!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Flatpak pour les paquets de logiciels de bureau
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 10.
Non. :-)
Ça se répond en petits morceaux.
1/ Déjà en vrai y a un runtime et un SDK faits en même temps. Le runtime ne contient que ce qui est nécessaire pour exécuter les logiciels (librairies partagées, etc.) alors que le SDK contient aussi les trucs de développement (headers de lib, mais aussi des outil divers comme les autotools, etc.). Les dévs doivent bien sûr installer tout, mais les autres n'installent que le runtime. Ça fait déjà beaucoup moins de dépendances que la liste "naïve" que j'ai faite précédemment avec un
grepet unwcpour compter les lignes.2/ Un runtime comme celui de freedesktop va contenir énormément de libs que beaucoup de logiciels utilisent sans même forcément s'en rendre compte (car pas en dépendance directe). Que ce soit libpng, ou les libs X11 ou Wayland, si votre appli a une GUI, vous en aurez vraisemblablement besoin. Beaucoup de cas d'usage "bureau" feront aussi des appels DBus, même si vous n'en avez aucune connaissance dans votre code. Vous voudrez forcément les libs alsa et pulseaudio pour le son, les diverses libs de Desktop ou d'affichage de texte, etc.
Au final ce sont des libs de base qui sont nécessaires pour quasi toute appli graphique (même si la dépendance n'est pas directe). Il faut bien voir que le "bureau linux" est lui-même vraiment stratifié sur de nombreux niveaux sur lesquels la plupart des logiciels graphiques s'appuient. Dire un chiffre genre "200" bibliothèques peut paraître énorme, mais je vous assure, pour faire tourner votre ordi super-moderne, ça ne l'est pas du tout! Même en espace disque, ce ne sera pas énorme. Beaucoup de libs de base sont très simples et ne tiendront que sur quelques Ko une fois compilés. Le fameux "faire une seule chose et le faire bien".
3/ Si vraiment vous êtes dans un cas exceptionnel où vous pouvez faire tourner l'application sur quasi aucune dépendance, vous êtes libre de faire votre propre runtime super-minimal.
Si vous voulez dépendre du runtime Freedesktop, mais pas de celui de GNOME: supposons qu'il y a une seule lib que vous voulez qui est dans le runtime GNOME, vous pouvez aussi bien l'ajouter dans votre Flatpak et vous baser sur le runtime Freedesktop. Il n'est pas nécessaire de tirer le runtime GNOME.
4/ Aussi il faut bien se rendre compte que si les gens se mettent à installer Flatpak, ils auront probablement déjà les principaux runtimes, dont celui de GNOME (et celui de KDE). Celui-ci est partagé entre les applications et téléchargé une seule fois, donc pas téléchargé pour une application unique. C'est plutôt efficace et permet des Flatpaks de taille réduite.
En outre, côté sécurité, ça signifie que vous bénéficierez de la réactivité de l'équipe de Flatpak (contenu du runtime Freedestop) ainsi que de l'équipe GNOME (runtime GNOME) donc des mises-à-jour de sécurité de ces 2 runtimes. En tant que développeur d'application, c'est autant de dépendances dont on n'aura pas à s'inquiéter.
Au final, je trouve ce système de niveaux de runtime les uns au dessus des autres assez bien et cela permet de bien diluer le travail entre les packageurs de divers projets, de garantir une sécurité plutôt bonne tout en ayant des mises-à-jour fonctionnelles régulières.
Pour le moment, mon expérience est assez positive. Je n'ai que des problèmes d'accès de fonctionnalités du bureau qui ne sont pas encore possible parfois à cause de la problématique "sandbox". Mais ce sont des problèmes connus et sur lesquels l'équipe de Flatpak travaille. Mon interaction avec eux est plutôt constructive jusqu'à présent (GIMP étant un logiciel avec pas mal de dépendances, et qualifiable de relativement complexe, j'ai forcément rencontré plusieurs petits embêtements ici et là).
P.S.: je conclurai avec un truc auquel je viens juste de penser; le fait d'installer des apps KDE est toujours très ennuyeux dans les distribs classiques, car cela va souvent tirer des dizaines d'autres applications graphiques (souvent pas parce que ce sont de vrais dépendances, mais parce que les packageurs de distribs veulent se simplifier la vie et "supposent" que si vous voulez une application KDE, ça veut dire que vous les voulez toutes) qui vont notamment polluer mon overview lors d'une recherche d'application (ou les menus d'application pour ceux qui en ont encore). Cela ne sera — je pense bien — pas possible avec Flatpak et si j'installe une application KDE qui aura été packagé en Flatpak, je pense que je n'aurai que cette app dans mon overview/menu ce qui améliorera le confort d'utilisation. Et au besoin, désinstaller le runtime Flatpak KDE sera 1000 fois plus simple, minimal en taille et propre que me débarrasser des dépendances multiples dans mon système principal. C'est aussi un gros avantage!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: tendance
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 4. Dernière modification le 31 janvier 2017 à 00:34.
Si ça y répond même plutôt pas mal. :-)
Cf. mon message plus bas.
P.S.: en tous cas pour Flatpak. Pour Docker, je sais pas, mais comme c'est orienté plutôt services et système de prob, j'en doute. Et pour d'autres alternatives de bureau, type Snap, aucune idée non plus du modèle adopté.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Flatpak pour les paquets de logiciels de bureau
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 10.
Tu cites déjà la réponse dans ton journal. Je pense que Flatpak, si le projet continue dans la bonne direction (ça a l'air d'être le cas pour l'instant), peut être la solution au problème cité.
Note que je ne considère absolument pas que le système de paquet par distribution est cassé pour autant, ni qu'il disparaîtra. C'est simplement complémentaire. L'écosystème logiciel GNU est simplement devenu trop important pour que tous les logiciels intéressants soient inclus dans les paquets gérés par la distrib (on peut voir cela comme un succès du "bureau Linux" si on veut alimenter le troll! :P). Donc il faut trouver des solutions pour répartir mieux le travail, et ça veut en général dire que les développeurs doivent s'y mettre. Par contre — on le sait bien depuis le temps — faire un paquet par distribution n'est pas gérable, surtout si ce sont des logiciels faits sur le temps libre (cas non rare dans le logiciel libre!). Un format standard comme flatpak, utilisable sur toute distribution GNU/Linux, est donc une très bonne alternative.
Alors je sais pas comment ça marche pour Docker que tu cites aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique (surtout parce que c'est fait pour les serveurs et on veut pas voir des trucs genre maj auto en prod!). Par contre Flatpak a un système de dépôt. En gros, chaque projet aura désormais un mini-dépôt de paquets pour ses logiciels et mettra à jour ses dépendances (note: il est aussi possible de faire des Flatpak standalone, sans dépôt, mais ce n'est pas la procédure conseillée).
Ainsi quand le projet mettra à jour son paquet, l'ensemble des gens qui auront installé ce paquet recevront des notifications qu'une mise-à-jour est dispo. Personne ne se baladera avec des applis et dépendances trouées (tant que le projet upstream est maintenu). Note que le projet n'a même pas à maintenir l'ensemble des dépendances possibles d'un logiciel puisque Flatpak fonctionne par "niveaux" de runtime. Ainsi le projet Flatpak lui-même maintient un runtime "Freedesktop" qui à lui seul contient déjà environ 200 dépendances de base qui vont suffire pour énormément de projets. Le projet GNOME aussi maintient un runtime, basé sur celui Freedesktop et qui ajoute environ 50 dépendances. Le projet KDE aussi maintient un runtime. Un logiciel doit simplement choisir un runtime sur lequel se baser.
Pour énormément de projet, celui signifie qu'il n'y aura peut-être aucune dépendance supplémentaire à ajouter dans le Flatpak (et donc à maintenir), ou très peu. Cela dilue énormément la tâche tout en permettant de rester sécurisé.
En tous cas, le projet GIMP par exemple fournira désormais un paquet Flatpak upstream que je crée et maintiens. Je pense que c'est vraiment une avancée car jusqu'à ce jour, les gens sous Windows ont un installeur, ceux sous OSX un DMG, et sous Linux… on leur disait d'attendre le paquet de leur distrib ou de compiler. Ça fait limite "citoyens de seconde zone" (bon c'est pas vrai, hein. Quasi tous les dévs de GIMP sont sous Linux, et donc ça veut dire notamment que la version nux est bien plus stable que les autres! Mais bon on pourrait croire). Ben plus maintenant. Tant que je serai dév de GIMP, les linuxiens auront leur Flatpak (bon à part si une alternative encore mieux fait son apparition bien sûr, ou si je découvre un truc horrible qui me fait changer d'avis sur l'utilité… espérons que non, mais on sait jamais!) et seront toujours des citoyens de première zone! :-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: En dehors de Flash
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal adobe c'est bientôt mort ?. Évalué à 10.
En effet, je pense que leur suite creative cloud a encore une longue vie devant elle. D'ailleurs même le logiciel "Flash" a probablement un avenir sous son nouveau nom Animate. Simplement le "focus" a changé et le but n'est plus d'exporter en format Flash mais en HTML5 ou en d'autres formats vidéos.
Donc oui, Flash, le format, est sur la pente descendante, et Shockwave l'est encore plus (depuis bien plus longtemps puisque cette technologie fut justement totalement éclipsée par Flash quasi dès ses débuts! C'est dire à quel point c'est mort. J'explique cela dans les sections "Premier pas", puis "Age Sombre" de l'article sur Flash) et c'est donc normal que les logiciels dédiés à ces formats disparaissent (ou deviennent génériques comme fut le cas pour "Animate").
Mais effectivement je doute qu'Adobe en tant que société soit mourante. Pas du tout même. Une petite recherche sur le web indique un chiffre d'affaire en croissance. Apparemment ils ont eu une baisse du chiffre en 2013-14 (si je comprends bien comment on lit ces tableaux) mais ils sont repartis en force en 2015.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: La FSF et le logiciel libre en phase terminale ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Flash est en phase terminale!. Évalué à 9.
Microsoft Office est l'un des fleurons commerciaux de Microsoft. Il me semble — si je ne m'abuse — que cela compte pour une grande part dans les revenus de la compagnie (rapide recherche sur le net, si je comprends bien les graphiques, surtout le dernier, leur suite office fait environ 25% de leur revenu, au delà des produits serveur et des OSes).
Le fait est qu'aujourd'hui comme il y a 20 ans, une chose n'a pas changé: les gens ont besoin d'écrire des textes (courriers, contrats, histoires…) et pour cela les traitements de texte de ce type reste l'outil essentiel de la majeure partie des gens. Les tableurs sont aussi une ressource très commune et ne disparaîtront pas de sitôt, les gens en entreprise ont régulièrement besoin de faire des présentations…
Donc quelle est l'intérêt d'investir dans une suite office, vraiment? Quand tout dans l'utilisation informatique quotidienne des gens ainsi que dans les chiffres de l'entreprise informatique qui vend la suite office la plus utilisée au monde montre qu'il y a un potentiel financier énorme, cela me paraît une bien étrange question… :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Changement de logo chez Mozilla (donc changement d'autocollants)
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
Wow. Ça change vraiment!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: KOKOPELLI
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
On a déjà beaucoup avec strictement des assos de logiciels libres, mais c'est pas exclu. Les contributeurs qui créeront l'album décideront de ce qui rentre dans le cadre du projet ou non.
Par contre, il faudrait que cette association, Kokopelli, nous contacte (un simple email) et nous envoie les autocollants d'abord.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mageia.org
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
Même questions que pour TuxFamily, plus haut! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TuxFamily.org
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
Salut,
Ce sont juste des logos, ou aussi des autocollants? Il faut que les gens puissent pouvoir se les procurer (sans les imprimer eux même, mais plutôt à un stand TuxFamily par exemple…). Et si ce sont bien des autocollants, lesquels et quelles dimensions métriques?
Merci! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Incoming PauLLA Stickers ! :D
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
Super! Merci. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: XML sapu et autres billevesées
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 4. Dernière modification le 13 janvier 2017 à 17:42.
Ben quand tu as un truc unique qui peut être exprimé en valeur simple, tu fais un attribut. Ensuite dès que c'est une donnée compliquée (qui va être composée de plusieurs valeurs), ou que tu peux en avoir plusieurs, c'est forcément un nœud fils. Quand tu crées ton schéma, c'est à toi de connaître tes données.
Pas du tout. On avait ce type de remarques régulièrement sur XMPP, du type "XMPP, c'est pas du vrai XML car vous n'utilisez qu'une partie des fonctionnalités" (voir les restrictions XML). Mais non, ce n'est pas vrai. Tout flux XMPP est un document XML absolument bien formé qui sera traité sans erreur dans n'importe quel parseur XML générique.
Encore une fois, XML n'a pas pour but d'être un format final en soi. Il n'y a aucune sémantique dans XML. D'ailleurs si tu fais une recherche sur la spec du terme "semantic", ça ne retourne qu'une seule occurrence qui dit exactement cela:
C'est à chacun de faire un format et d'y ajouter de la sémantique. La création du format final peut ainsi passer par se limiter à un sous-ensemble de XML. C'est comme l'utilisation d'un langage de programmation: cela n'oblige absolument pas les développeurs à utiliser toutes les fonctionnalités du dit-langage, voire même les autorise à en interdire certaines dans leur programme (exemple très courant: le C++ où beaucoup de développeurs vont interdire l'utilisation de certains fonctionnalités dans leur code, comme dans le Google C++ style guide; notamment les exceptions sont une fonctionnalité interdite dans beaucoup de gros projets C++). Est-ce à dire que le code C++ de Google ou d'ID Software (Doom 3) n'est pas du C++ parce qu'ils n'utilisent qu'un sous-ensemble (clairement interdisant pas mal de fonctionnalités)?
Enfin pour revenir plus précisément à cette fonctionnalité (codage de caractères dans XML), la spéc dit clairement:
Puis un peu plus bas:
Comme tu vois, la spéc XML est clairement préparée à ce que le codage puisse être déterminé non par la déclaration, mais par le protocole de plus haut niveau (par exemple XMPP). XML est vraiment fait dans l'optique qu'il va en général y avoir une spéc de plus haut niveau qui donnera une vraie sémantique aux éléments et attributs. Sans cela, XML n'est qu'une sorte de syntaxe ou grammaire générique.
Bien sûr, tu ne peux pas tout valider dans un schéma XML (qui est aussi un format générique et n'a bien entendu aucune logique par rapport à ton besoin particulier, ou "logique métier" comme on dit), mais tu parlais pas de ça. Tu parlais des types de base et comme quoi XML n'en avait pas hormis string, contrairement à json. Je te réponds que si, avec les schémas. Et maintenant tu réponds que ça fait pas le café non plus! Faut pas changer non plus d'argument à chaque phrase! Non parce que json non plus ne fait le café! :P
Le fait est que XML a des types de base, et c'était donc ma réponse à ton assertion comme quoi il n'y en avait pas; et qu'en plus la validation de ces types peut être faite avant le code spécifique (pas en json, où ça doit être fait dans le code, à moins d'ajouter un mécanisme de schéma spécifique au json). Ça n'empêche en effet absolument pas une validation complémentaire dans le code si nécessaire (comme ton exemple de date). Mais au moins, on sait que les données arrivent directement dans le bon type si on valide avec un schéma.
Je l'explique plus haut, dans un autre commentaire. En gros, si tu as un besoin super complexe dans un fichier destiné à être édité par un humain de manière régulière, j'aurais tendance à dire qu'y a un problème plus profond de design logiciel. Si tu dois représenter des données très complexes, faut alors avoir une interface graphique adaptée et compréhensible (et en interne, un format adapté, pas du clé=valeur). Parce que je suis désolé, mais que ce soit du json ou du XML, si y a plusieurs niveaux et une arborescence avancée, c'est juste imbitable pour un non-programmeur. Je mets pas ça entre les mains des gens par design comme étant dans le fonctionnement normal de l'application.
Un truc que tu veux éditable par les gens dans le fonctionnement habituel du programme, c'est un fichier très simple. Sinon y a vraiment un problème de design.
Ensuite ces formats clé=valeur ont tout de même des types de base (chaînes de caractère, nombre et booléen), et des listes (ex: le format clé=valeur standardisé par Freedesktop, dont je donne déjà le lien plus haut a des listes avec séparation des éléments par des point-virgules). Et puis il y a des groupes (mais ca s'arrête là au niveau "arborescence", pas de niveau supplémentaire au delà).
Il y a un minimum de fonctionnalité tout de même! :-)
Cela devrait être bien suffisant pour un fichier destiné à édition manuelle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci LinuxFR!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primés de novembre 2016. Évalué à 5. Dernière modification le 13 janvier 2017 à 16:25.
Aujourd'hui je reçois un paquet énorme, je me dis "mais qu'est-ce que c'est? J'ai rien commandé!".
J'ouvre et c'est en fait le livre qui a été mis dans un paquet qui fait peut-être 15 fois sa taille!
Enfin voilà, ça m'a fait marrer alors je voulais partager car envoyer un livre dans un si énorme paquet, c'est pas commun quand même. :P
Merci encore!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: XML sapu et autres billevesées
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
J'ai eu une fois à implémenter un parseur YAML. C'était vraiment l'horreur. Ils ont fait des choix vraiment bizarres et ont défini plein de façons de noter la même donnée. On ne s'en rend pas compte côté utilisateur car on va en général utiliser la même notation partout. Mais quand on fait un parseur, il faut être exhaustif (pour ce 1% de gens qui vont envoyer des fichiers avec cette syntaxe). Très mauvaise expérience.
Si pour une édition par des humains, je préfère quelque chose de bien plus simple encore, type fichiers clé-valeur simple. Il y a des formats de ce type standardisés, typiquement celui de FreeDesktop qui fut défini pour les fichiers
.desktop(donc utilisés par la plupart des — sinon tous les — bureaux libres). Ce type de format reste simple à parser (et en général, y a même pas besoin de faire soi-même, si on utilise une bibliothèque de bureau, par exemple glib). Ce format peut contenir des chaînes de caractères, nombres, booleans et des listes, des sections (même la localisation est prise en charge si besoin est, et elle peut être automatisée avec extraction du texte original par gettext puis génération de fichiers qui contiennent toutes les localisations; c'est ce qui est fait en général pour localiser les fichiers desktop!) et il n'emploie pas 10 variantes par type ni de logique super-compliquées.Sinon y a aussi des formats encore plus simples, plus proches du INI de Microsoft (le format standardisé par Freedesktop est d'ailleurs très proche, bien qu'avec quelques différences) qui est aussi beaucoup utilisé, même sur nos systèmes libres.
Ces formats sont souvent suffisants et je ne vois pas l'utilité d'apporter la complexité du YAML pour un fichier destiné à être édité par des humains. Ensuite je dis pas, YAML a des fonctionnalités plus avancées et peut-être dans des cas d'usage très particuliers, il convient de monter d'un cran et d'utiliser ce format. Mais je n'ai jamais eu le cas. En général, lorsque le besoin devient vraiment complexe, ce n'est plus un format que je destine à l'édition par des humains, mais par un programme (et à ce moment, ce n'est pas non plus le YAML que je vais choisir).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: XML sapu et autres billevesées
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
Le XML (comme tout format texte avec syntaxe répétitive) est très compressible, rendant l'argument obsolète. Tous les formats ou protocoles qui sont basés sur XML le compressent dans l'usage "normal" (hors débuggage où on désactivera la compression temporairement).
Je ne comprends pas ce que tu veux dire.
Si c'est pour de l'échange de fichier, le fichier XML définit simplement son codage dans sa déclaration. Ensuite le décodage est quand même un truc de base sur tous les systèmes. La seule problématique est lorsqu'un format de fichier ne déclare pas le codage donc il faut faire de la détection (ce qui n'est pas du 100% de réussite). Mais comme XML le fait, y a pas de problème ici.
En plus dans les faits, très souvent les sous-formats vont imposer un codage unique (souvent UTF-8). C'est le cas par exemple de XMPP.
Si tu fais du XML bête et méchant, sans schéma, oui il n'y a pas vraiment de types. Mais un format XML est fait pour être défini (en fait XML en soi est un format générique pour faire des formats spécifiques!), par exemple dans un schéma XML et là tu as tous les types que tu veux.
En outre, là où XML va avoir une étape de validation générique au niveau de ton parseur (que tu n'as donc en général pas à implémenter dans le code; en utilisant une bibliothèque XML externe, on se contente de fournir le schéma et la validation est faite pour nous), tu dois en général implémenter de la validation spécifique pour un format json.
Sans compter la reprise sur erreur: comme XML a une étape de validation du schéma, il est capable d'ignorer tout erreur de contenu (mauvais type, attributs inconnus, etc.), mais en le prenant en compte, avec par exemple simplement un avertissement dans le programme qu'il y a une corruption possible du fichier. En très peu de ligne (encore une fois, en se reposant sur une bibliothèque générique), on va définir de la gestion d'erreur précise pour divers cas et on ne sortira en erreur complète que sur les problèmes majeurs. C'est même la base de certains sous-formats de XML, par exemple XMPP encore, qui est extensible par nature, a certaines caractéristiques obligatoires mais peut aussi accueillir des extensions (et un client/serveur peut les ignorer s'il ne les prend pas en charge mais sans jamais casser la connexion ou le transfert fiable et complet des données).
Json pourrait faire tout cela bien sûr, mais nécessite beaucoup de code spécifique et sera donc bien plus prompt aux erreurs de programmation. Surtout en gestion d'erreur, on sait tous que c'est exactement le genre de trucs chiants que beaucoup vont laisser "pour plus tard"; et le manque dans le code ne se voit pas pendant longtemps — puisque logiquement en général le contenu utilisé est valide — jusqu'au jour où on tombe sur un bout de données corrompu et là, le programme risque de vraiment mal le prendre!
Ensuite XML est clairement beaucoup plus lourd à mettre en place et ce n'est pas à utiliser selon moi pour des usages simples. Genre effectivement pour une API web, on va peut-être éviter de la compression (quoique ça dépend; même pour du json, si l'API est faite pour transporter pas mal de données, cela peut être rentable de compresser). De même pour plein de petits formats très courts (typiquement dans une API web, on peut considérer que chaque réponse à une fonction a potentiellement un format différent), on veut peut-être pas écrire plein de mini-schémas XML. Ce serait vite ennuyeux.
Dans plein de cas, json est bien plus léger, simple et flexible. Donc c'est plus agréable pour tous ces petits usages simples. Par contre dans le cas de la création d'un format long et complexe, beaucoup utilisé et structuré, je ne choisirai probablement jamais json. C'est juste le moyen idéal pour se retrouver avec des fichiers invalides sans même s'en rendre compte pendant des semaines (jusqu'au jour où notre programme a besoin de parser ce bout du fichier et saute à notre figure).
Quant à des fichiers de conf (si on prévoit édition par un humain), je n'utiliserais ni json ni XML, mais un format simple "attribut: valeur" ou "attribut = valeur", type fichiers INI. Parce que quand on parle d'édition et lisibilité possible par un humain, je suis désolé mais ni json ni XML ne sont de bons choix. Typiquement c'est très facile de casser un fichier de l'un ou l'autre format (classique: oublier le tag fermant en XML ou le crochet fermant en json).
Par contre lisibilité par un développeur (pour débugguer par exemple), je trouve les 2 aussi lisibles du moment qu'ils indentés pour faciliter le débuggage (et les 2 aussi illisibles s'ils sont pas indentés ou sans retour à la ligne).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]