J'hésite: est-ce une blague de ta part ou bien tu n'as pas bien lu mon commentaire?… 😛
Bon au cas où, je tombe dans le piège quand même. Oui c'est normal, puisque comme je disais, c'est une animation en SVG visible seulement sur les pages en erreur 404 (a.k.a. liens morts). J'ai donc mis un lien vers une page qui n'existe pas exprès (note le nom de la page: https://www.gimp.org/jenesuispasla; j'aurais aussi bien pu donner: https://www.gimp.org/youplaboum) pour permettre aux gens de voir cette animation.
Donc sur gimp.org, quand vous ouvrez n'importe quelle page en 404, vous verrez un petit Wilber (mascotte/logo de GIMP) qui marche jusqu'au milieu de page, et essaie d'ouvrir l'en-tête mais n'y parvient pas, et est alors dépité. 😢
Ensuite peut-être ne vois-tu pas l'animation. Dans ce cas, je suppose que tu as un des rares navigateurs qui ne prend pas en charge les animations SMIL (c'est à dire soit Opera Mini, soit IE, les 2 seuls qui ne savent pas lire les SVGs animés en SMIL à ce jour, du moins d'après les infos trouvées, ou une version pas à jour d'un autre navigateur).
Dernier cas: peut-être faisais-tu bien une blague et avais-tu bien compris que oui cette page est 404, et oui c'est normal, non c'était pas une erreur, car c'est bien ainsi qu'on peut voir notre SVG animé. 😃
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pas en Libre, malheureusement, aux dernières nouvelles. Nous avons fait cette animation "à la dure", c'est à dire que les dessins sont faits dans Inkscape, mais sont animés en éditant ensuite le SVG dans un éditeur de texte.
Bon ça fait quelques années, mais je n'ai entendu parler d'aucun logiciel libre qui ait ajouté la prise en charge du SVG animé depuis.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Quelqu'un a suggéré de demander sur des forums Blender. Je ne peux que réitérer la proposition.
Le "pro NVIDIA" était vrai y a quelques années. Mais depuis ils ont pas mal bossé avec AMD (et Intel aussi) et la situation s'est beaucoup améliorée.
Pour le coup d'utiliser la carte pour affichage seulement lorsque tu utilises Blender, je sais pas si c'est possible (mais pourquoi pas après tout! Les écrans ont plusieurs entrées. Pourquoi ne pourrait on pas logiciellement décider laquelle est active à un moment donné?). Mais ça ne t'empêche pas au moins de l'utiliser juste pour le rendu déjà ce qui est un énorme gain de temps et évite qu'elle soit constamment bruyante. C'est entièrement configurable dans les préférences.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Déjà, en quoi le mot "GIMP" cause-t-il problème? Y a deux trucs:
Une Insulte?
Ça peut vouloir dire "boiteux" en anglais. C'était ça le problème initial des gens derrière Glimpse (même s'ils se sont raccrochés aussi au second problème ensuite). A priori, même chez les anglophones natifs, ce problème est assez controversé car cette "insulte" serait considérée plutôt datée et quasi inusitée de nos jours. En tous cas, c'est ce qui ressort du fait que beaucoup de gens d'origine UK ou US disent régulièrement sur des forums anglophones (genre reddit) qu'ils avaient jamais entendu cette insulte de leur vie bien qu'étant natifs et que pour eux, "gimp" ne leur évoquait jamais que le logiciel.
L'une des bases de l'argumentaire est donc que ce serait un terme insultant pour les handicapés (le terme exact qui fut employé est "ableist insult", ce qui se traduirait apparemment en "insulte validiste"; on apprend de nouveaux mots tous les jours!), ainsi qu'une insulte de cours d'école. Pour le second point, je ne sais pas, mais pour le premier, on a régulièrement des gens qui répondent être eux-même handicapés et n'avoir aucun problème avec le mot "gimp" ou le fait que GIMP soit appelé ainsi. Par exemple c'est le commentaire le plus plussé sous cette vidéo. Ou encore dans le rapport de bug qui a tout débuté (j'en reparlerai plus tard), un des développeurs de GIMP (qui est surtout un des développeurs principaux de Darktable, mais qui fait aussi des patchs réguliers à GIMP et traînent beaucoup sur notre salon IRC, etc.) a lui même annoncé être un boiteux (pour info: c'est vrai, vous pouvez confirmer par exemple si vous venez à un Libre Graphics Meeting) et ne pas avoir de problème non plus avec ce nom.
Une référence de film
Le second problème, qui n'était absolument pas mentionné dans le problème originel (il est possible que cette personne ne connaissait pas ce problème; il m'a fallu des années pour le découvrir moi-même, même en contribuant à GIMP), et qui pourtant est pour moi plus problématique est l'utilisation du terme dans les milieux sado-maso. On appelle souvent les costumes entièrement en cuir des costumes de "gimp". Une recherche marrante dans un moteur de recherche serait donc "gimp mask" (les masques de calques étant des termes courants en graphisme numérique).
Ce terme vient en fait de Pulp Fiction. Pour ceux qui l'ont vu, il y a ce personnage qui vit dans un coffre dans la cave d'une boutique, entièrement vêtu de cuir, et qui s'appelle "the Gimp". La phrase la plus célèbre en rapport avec ce personnage est "Bring out the Gimp" (cf. la scène (⚠️ NSFW ⚠️)). Pour la petite histoire, d'après des interviews des créateurs originels, le nom du programme vient bien de ce personnage de Pulp Fiction, car c'était le film à la mode de l'époque (sorti la même année que GIMP). Donc déjà il faut bien noter que ce terme ne vient pas d'une pratique sado-maso. Le nom du costume sado-maso de même que celui de ce programme viennent simplement du nom d'un personnage d'un film de cinéma. Ils ont la même origine, l'un ne vient pas de l'autre.
Mais oui, clairement cela a lancé un nouveau terme dans ce milieu particulier.
Le premier point — le plus important — est que le logiciel est vraiment vraiment connu sous ce nom. On parle de millions d'utilisateurs. On n'a pas vraiment de stats, mais par exemple à l'époque où le binaire Windows était distribué sur Sourceforge, on avait apparemment entre 4 et 7 millions de téléchargements par version pour Windows. C'était à l'époque 2.8. Avec la sortie de 2.10 et les énormes efforts faits depuis, c'est probablement bien plus maintenant.
Je sais que Flatpak à lui seul a presque 100.000 téléchargements unique pour la dernière version, en notant que Flatpak est un pouillième des téléchargements Linux, qui sont eux même un pouillième des téléchargements totaux.
Tout ça pour dire que changer de nom, ce n'est pas rien. Ça ne se fait pas sur un coup de tête. Beaucoup de grosses entreprises avec des moyens formidables se sont cassés les dents dans du rebranding. Et dans tous les cas, cela demande un gros engagement "marketing" sur plusieurs mois, voire années. Or on n'a clairement pas ces moyens chez GIMP en terme de nombre de contributeurs ou d'argent à dépenser.
Personnellement je pense qu'on devrait au moins implémenter un système de vérification de version (pas de mise-à-jour automatique, mais au moins une vérification sur internet qui avertit quand on utilise pas la dernière version avec un lien à cliquer pour mettre à jour). Cette vérification serait bien sûr désactivable et surtout même avec option de compilation (car inutile pour les binaires installés par systèmes avec mise-à-jour, typiquement les distribs Linux). Cela permettrait aux gens qui mettent à jour très irrégulièrement les logiciels de retrouver un GIMP qui aurait changé de nom même des années après.
Hormis ce type de système, ou même plus, changer de nom serait totalement irresponsable envers les gens qui se retrouverait avec un logiciel non à jour et sans possibilité de trouver de la doc.
Le nom complet: GNU Image Manipulation Program
Le second point est que le nom n'est pas "gimp", ou "Gimp", mais bien "GIMP": il s'agit d'un acronyme et vous êtes libres d'utiliser le vrai nom pour ne pas à avoir à prononcer GIMP: GNU Image Manipulation Program.
Notons aussi qu'il n'y a pas d'article devant depuis GIMP 2.4, soit depuis 12 ans maintenant. Ce n'est donc pas "The GIMP" comme on le lit parfois mais bien "GIMP" tout court (je ne sais pas pourquoi l'article a été retiré mais je me dis que c'était peut-être justement pour s'éloigner de l'historique Pulp Fiction? Je n'étais pas là à l'époque…).
Ensuite bien sûr que "GIMP" est écrit ici et là, mais il est alors clair que ce n'est pas une insulte, ni rien du genre. C'est un acronyme.
Une évolution dans le bon sens
On dit aussi souvent que si vous faites une recherche web "gimp", vous ne tombez que sur des résultats en rapport avec le logiciel en première page (essayez! Me croyez pas sur parole). Ça ne parle pas de handicap, ni de sado-masochisme. Déjà cela rejoint le problème de la notoriété du logiciel que l'on casserait avec un rebranding mais ça veut aussi dire que notre logiciel a fait complètement dévié le sens premier de ce mot, qui était peut-être en effet insultant dans un sens plus ancien. De nos jours, parler de GIMP, même parmi des anglophones natifs, la plupart des gens pensent au logiciel. Beaucoup de gens disent donc qu'on a redéfini ce mot en lui donnant une connotation positive, et c'est une très bonne chose.
L'idée serait donc de se battre contre les mauvais usages d'un mot, non en donnant du poids aux sens négatifs du terme, ce qui donne surtout du pouvoir à ces mauvais usages, mais bien en les réutilisant dans des sens positifs. Beaucoup pensent donc que c'est quelque chose à encourager et par conséquent affirment qu'un renommage ne serait pas forcément une bonne idée.
Les autres arguments
Y a plein d'autres arguments contre l'idée du changement de nom. Déjà, comme je le disais, beaucoup de natifs eux-même affirment ne jamais avoir entendu cette insulte qui serait vraiment datée, et clairement dès que le sujet est abordé, il y a des gens dans tous les sens (on peut vraiment pas parler d'unanimité). On n'a aucune stats en vrai de l'usage de ce terme dans son sens insultant. Là on changerait donc un nom qui a 24 ans d'ancienneté, basé sur les dires de quelques personnes sans preuve concrète.
Ensuite y a la problématique du langage. Tout le monde n'est pas natif-anglais! Or même en parlant très bien anglais, la plupart des gens à travers le monde n'ont aucune idée des sens secondaires de "gimp", aiment le logiciel et le nom, et se demandent donc pourquoi ils devraient le changer pour satisfaire des anglophones.
D'ailleurs qui peut réellement prétendre faire un nom qui n'est offensant dans aucun langage du monde (par exemple certaines personnes relevaient que "dust" veut dire "idiot" en norvégien apparemment)? Ah! On me souffle dans l'oreillette que Glimpse a cette prétention. Je cite leur FAQ:
we checked its meaning in every known language
Alors soit ces gens sont de véritables génies méconnus, soit ce sont de fieffés menteurs. Tous les langages du monde? Sérieusement?
Y a aussi le fait que l'un des arguments principaux (en fait à la base, le seul argument) du problème était que ce terme offenserait les handicapés. Or à ce jour, je ne crois pas avoir vu (mais je suis loin de suivre tous les forums de près) le moindre handicapé confirmant cette affirmation. Par contre on a vu l'inverse. D'ailleurs même dans le rapport de bug d'origine, je citais le contributeur qui a pris part et répondait directement à une question "Are the developers members of the community who are called gimps? pour dire ben oui, au moins un l'est. Sa réponse est resté sans suite (mais avec quelques downvotes des gens qui n'aimaient pas qu'un contributeur puisse être handicapé apparemment! Un peu le monde à l'envers quand on nous accuse ainsi d'être insultant envers les handicapés). Donc à ce jour, il n'y a pas vraiment de preuve sûre que ce serait vraiment considéré comme un terme insultant par les handicapés.
Anecdote supplémentaire: un journaliste a fait un article sur ce fork (on notera que l'auteur est américain, né aux US et qu'il dit aussi qu'il ne connaissait pas non plus le sens péjoratif de "gimp" avant de tomber sur ce fork) a trouvé un projet d'une compagnie de danse américaine avec 4 danseurs handicappés et appelé "The Gimp project". Il soulève donc encore une fois que ce terme ne semble pas utilisé péjorativement ou mal pris par tous les handicapés en tous cas. Là encore une fois, on parle de plusieurs cas de natifs de la langue anglaise.
On notera aussi que ces personnes (du fork) affirment que les gens dans l'administration ou les universités/écoles américaines ne veulent pas utiliser GIMP à cause du nom. D'une part, on sait que c'est faux en règle générale. On a parfois des retours de gens qui l'utilisent en école américaine. On sait même que la NASA utilise (de temps en temps, y a des tweets ou similaire, souvent avec des cartes de satellites ou autre, et parfois ils citent GIMP). On sait aussi que certaines entreprises américaines proposent GIMP dans leur bibliothèque de logiciels autorisés/téléchargeable par le personnel (je me souviens d'au moins un retour à ce sujet qui nous disait que ce logiciel ne posait aucun problème pour leur entreprise US et qu'il était installable officiellement).
Ensuite oui, peut-être que certaines écoles/administrations refusent. Ceci dit, plusieurs fois quand une telle affirmation a été faite, on a demandé si la personne pouvait nous faire parvenir un document expliquant un refus par rapport au nom (et pas une autre raison), etc. À ce jour, on n'a jamais eu de retour. J'aimerais vraiment connaître le détail de ces histoires, pas du "et si", ni du "on m'a refusé, c'est forcément à cause du nom".
Je noterai enfin qu'en France par exemple, il n'y a aucun problème de ce côté là. Aryeom a enseigné GIMP à l'université (publique) en 2018-2019, et elle va redonner un cursus en 2019-2020. Elle a aussi fait un séminaire GIMP et animation au CNRS. Mais bon là c'est juste l'argument du langage: le fait que "GIMP" ne pose aucun problème en français. Mais c'est toujours un argument important car il n'y a pas que l'anglais dans le monde (certains semblent l'oublier).
La position officielle officieuse de l'équipe GIMP (bis repetita)
En plus des points plus hauts, qui sont ceux de la FAQ de GIMP, il y a en fait d'autres choses, qui ne sont pas écrites dans la FAQ mais qui sont discutées sur IRC.
À ce jour, et pour autant qu'on le sache, personne n'est absolument contre un renommage. Je l'ai dit plus haut: ce n'est juste pas un truc à faire à la légère. C'est le principal problème. On se lève pas un matin en se disant "tiens, si je renommais GIMP"? Les gens derrière ce fork n'ont clairement aucune idée des implications et du travail derrière la maintenance d'un logiciel si complexe, et surtout des responsabilités qui viennent avec. Ben oui, on s'est créé des obligations! Même si on le fait pour nous et pour s'amuser, on est aussi conscient qu'on doit faire les choses avec un minimum de compatibilité et de respect des gens. Que ce soit ne pas casser une interface de programmation (pour les plug-ins) entre versions mineures et sans prévenir (des années en avance avec des avertissements de dépréciation à la compilation ou à l'exécution!), ne pas retirer des fonctionnalités même si on ne les utilise pas nous-même, ou autre chose, on fait vraiment attention.
Là pour le nom, je le disais plus haut, on ne perd pas juste la notoriété du nom, mais on fait se perdre les gens! Les gens qui chercheraient sur internet et ne retrouveraient plus GIMP (car il aurait changé de nom, et peu suivent les nouvelles des logiciels au quotidien), les gens qui ne peuvent plus mettre à jour et se retrouvent avec des failles dans une vieille version (car ils ne savent pas qu'il y a eu renommage ni où trouver le logiciel renommé), les gens qui cherchent de la doc et ne trouveraient plus 2 décennies de documentation et de livres publiés dans le commerce car ils ne sauraient pas que le logiciel X s'appelait GIMP juste quelques années auparavant. Etc.
Donc revenons à ce que je disais: personne n'est contre un renommage et on en a discuté plus d'une fois (et ce, bien avant ce rapport de bug qui a provoqué ce fork). À ce jour, notre idée favorite serait de fournir 2 versions de GIMP: GIMP et un autre nom (possiblement "GNU imp", qui pourrait se traduire par le lutin GNU et permettrait un bon jeu de lettres en gardant finalement la même base de lettres, mais sans jamais écrire "GIMP" seul). Peut-être même avec un seul installeur qui offrirait le choix des versions (nom originel ou nom "pour toute la famille/l'entreprise").
L'un des contributeurs a même essayé de faire un petit preuve-de-concept pour du renommage qui serait capable de renommer même les chaînes de caractère traduisible sans faire double de travail pour les traducteurs.
Voilà, c'est donc à quel point on n'est absolument pas hostile à une solution qui pourrait satisfaire tout le monde, bien au contraire. On est conscient du passif historique du nom (qui nous a été légué, on le rappelle) et même si on doute que la situation soit aussi horrible que ce que ces personnes affirment (GIMP est aussi beaucoup utilisé au Royaume Uni, aux US et dans tous les autres pays anglophones), on n'est pas contre une évolution. Mais ça doit être bien fait. Et ça prend du temps.
Mais alors pourquoi ces gens ont-ils forkés?
Le fork
Je vais donc raconter comment s'est passé le fork! Une personne a donc ouvert un rapport de bug (en fait en écrivant ça, je me suis rendu compte que le rapport a été rendu non visible par un admin GNOME, donc hormis ceux avec un compte GNOME, vous ne pourrez pas le lire malheureusement) pour changer le nom tard en soirée (soirée pour l'Europe de l'ouest du moins, ce qui est le fuseau horaire des principaux contributeurs de GIMP, dont moi; ce qui n'est pas un problème en soi… sauf que…), et en même temps a posté le lien sur plusieurs des gros sites de discussions (Hacker News, cross-posté sur plusieurs forums Reddit, dont le Linux, d'autres sites dont j'ai aucune idée, et surtout certains réseaux sociaux, etc. Apparemment on a été très attaqué sur la "communauté" Mastodon, paraît-il; d'ailleurs je me préparais justement à installer un serveur Mastodon pour notre association et j'ai mis en pause suite à cela, car j'ai pris peur de nous jeter dans la gueule du loup; ça m'a pas donné envie quoi 😕), clairement donc avec l'optique de rameuter des gens pour faire du forcing (enfin j'ai du mal à voir une autre raison à faire quelque chose comme ça).
Au final, le lendemain, au réveil, j'ai découvert un nouveau rapport de bug avec… 140 messages écrits dans la nuit (le rapport s'est arrêté à 187 messages quand un des admins de GNOME a décidé de fermer les commentaires, sans compter 5 messages dans un second rapport identique que quelqu'un a cru bon de faire pour appuyer la demande)! En plus comme j'ai configuré pour recevoir tout en email, imaginez ma belle boîte aux lettres électronique envahie ce matin là de 140 emails avant même mon premier café. Notons aussi qu'on ne parle pas de centaines de personnes, hein. D'un rapide coup d'œil, je dirais qu'il doit y avoir eu 10 personnes au plus qui ont participé et ont écrit tous ces messages.
Dans cette cohue, j'ai choisi de ne même pas participer. C'est un peu comme si y avait une manif de gens violents devant votre porte, criant tous en même temps des choses diverses et inintelligibles, pas forcément nombreux mais bruyants, et en tous cas, ça ferait suffisamment peur pour que votre première réaction ne soit sûrement pas de vous dire: je vais aller dehors et me mettre au milieu de la meute pour discuter calmement avec ces gens qui vont bien sûr répondre posément à mes arguments construits.
Non, Mitch, notre mainteneur, a eu la seule réaction possible dans une telle situation: il a fermé le rapport comme il aurait fermé sa porte à clé si des gens criaient devant sa porte. Franchement, même si on était 100% pour le changement de nom, y a pas d'autre chose à faire dans ce cas.
Notons qu'il n'y a eu aucune autre réaction d'aucun autre développeur (sauf Tobias qui a déclaré être lui-même boiteux, comme expliqué plus haut).
Néanmoins les gens s'emballent sur les méchants développeurs de GIMP. Puis au final, certains ont fait le fork. Ok pourquoi pas!
En tous les cas, c'est un début assez triste pour un logiciel qui veut se placer dans une optique "inclusive". Parce que ce qu'ils ont fait, si ce n'est pas considéré comme du harcèlement (187 messages en moins de 24h par une poignée de personnes, forçant au final un admin GNOME à intervenir), je me demande ce qui l'est.
Honnêtement j'ai même beaucoup hésité à écrire ce commentaire ici car ces gens ont montré ne vraiment pas être civil et clairement faire du ciblage de gens à attaquer. Et j'aimerais pas devenir une telle cible. Le harcèlement peut vraiment faire des ravages dans les contributeurs de logiciels libres et j'aimerais vraiment éviter en être victime.
Pour info, aucun des "développeurs" du fork n'a jamais contribué la moindre ligne de code à GIMP (à notre connaissance). Ce sont des parfaits inconnus jusqu'à ce jour, bien que certains étaient des contributeurs à d'autres projets GNOME a priori.
Par contre ils aiment bien dire partout qu'on est des gros méchants qui ne respectons pas les handicapés (y en a même qui ont annoncé vouloir reporter GIMP comme ne respectant pas le Code of Conduct de GNOME de par son nom insultant pour nous chasser de la plateforme; et après on nous parle d'inclusion…), et aussi que notre code est mauvais (ça je l'ai pas trop vu moi-même, il paraît que c'est les choses qui se disent dans leur canal de discussion; j'ai pas poussé le vice jusqu'à m'y connecter moi-même!). D'ailleurs ils disent dans leur fork qu'ils vont changer l'interface pour enfin implémenter des fonctionnalités beaucoup demandés, comme si c'était pas ce qu'on fait déjà au quotidien ou qu'on aurait refusé (pour info, on n'a jamais refusé de code de qualité pour aucune fonctionnalité; on a même intégré pas mal de code problématique en passant énormément de temps à corriger quand l'idée est bonne; quant à implémenter nous-même: on n'est pas des esclaves et on peut avoir nos propres priorités; ne pas implémenter quelque chose ne veut pas dire être contre, ni même qu'on ne l'implémenterait pas un jour; juste on ne l'implémente pas maintenant parce qu'on implémente autre chose qui nous botte plus d'abord).
Je rappelle qu'on est parfaitement conscient de plein de choses à améliorer et ça fait pas mal d'années qu'on fait que ça (améliorer). On a même un wiki officiel où on note pas mal de résultats de discussions, de spécifications, etc. au sujet du redesign progressif du logiciel. D'ailleurs ces gens en sont conscients et connaissent ce wiki, mais ils continuent à faire comme si on ne veut rien améliorer.
Mais bon soit, ils veulent parler technique! Ben techniquement, le fork ne nous impressionne pas. Je compte 8 commits en août, et c'est essentiellement des changements mineurs, genre README, ou mettre les dépendances en submodule (ils connaissent pas pkg-config?). Pour comparaison sur GIMP master: 499 commits, 989 files changed, 111265 insertions(+), 71558 deletions(-) si mon git-fu est correct; et je parle de trucs super cool genre une méga-amélioration de l'API des plug-ins, la prise en charge de Python 3, JavaScript, Lua pour les plug-ins, et du travail en cours pour l'agrandissement automatique de calques, voire à terme des calques infinis. Ça ce sont les trucs principaux qui furent en chantier ce mois-ci chez GIMP, plus les machins en branche, genre l'animation comme fonctionnalité de base du logiciel.
En gros ils ont l'air d'avoir du mal avec le code (et c'est normal, ça fait 7 ans, et je découvre toujours des choses!).
Alors si on regarde leurs rapports de bug, on voit qu'ils ont changé leur plan: ils ont décidé qu'ils allaient faire leur propre GUI dans un langage de script (en cours de choix) en parallèle à leur modification de GIMP. Uhuh. 🙄
Donc l'idée c'est que le code est trop compliqué pour eux (ce qui veut dire qu'il est mauvais, bien sûr!) et donc on se donne encore plus de travail!
Par contre, en parallèle, ils ont déjà créé un site web, et surtout une page Patreon. Je parle du jour même du fork. Leur première action, avant même d'avoir quoi que ce soit à montrer, c'est de demander des sous! J'oserais qualifier cela d'indécent.
J'adore aussi que dans leurs news régulières, ils arrêtent pas de dire qu'ils avancent énormément. Non parce que soyons sérieux, n'importe qui qui sait lire un log de développement peut voir qu'il n'y a pas grand chose à se mettre sous la dent (genre apparemment ils ont changé le thème par défaut, des trucs du genre). Et ils vont régulièrement sur les sites de news pour faire parler d'eux. En marketing, ils sont forts. Ça oui.
Mais personnellement pour moi, ils ont cumulé tout ce qu'il ne faut pas faire dans un rapport de bug, et tous les comportements à ne surtout pas avoir en société pour un travail commun agréable. Si on devait faire un livre sur "Comment contribuer à un logiciel libre", leur action pourrait être cité comme la liste de tout ce qu'il ne faut surtout pas faire.
D'ailleurs le jour où on fera finalement le renommage (ou la solution intermédiaire pour mettre tout le monde content), je refuserai d'avoir affaire à eux s'ils veulent essayer de faire comme s'ils en étaient l'origine (ce qui n'est pas le cas, soyons clair). Je ne fais pas du libre pour avoir du drame et ne veut pas travailler avec des personnes si malveillantes.
Voilà, c'est mon avis, et un peu celui de tous les dévs de GIMP, je pense.
Est ce qu'ils ont discuté avec l'équipe ?
Non. Ils sont venus, ont gueulés, nous ont pas laissé en placer une (c'était impossible dans ce type de conditions, comme dit plus haut), puis sont repartis tout heureux d'avoir pu prouver à quel point on est des méchants qui aiment insulter les handicapés.
La fragmentation de LL étant son plus grand point faible, ce genre d'annonce, n'est pas très plaisante.
Il n'y a absolument pas à s'inquiéter de ce point de vue là. Comme je l'ai dit précédemment, absolument aucune de ces personnes n'avait jamais contribué à GIMP, et je doute qu'ils le fassent jamais, même après un renommage officiel. Et comme j'ai dit, je suis pas sûr de vouloir avoir affaire à eux (en vrai, je suis un peu plus raisonnable que ça — j'exagère exprès — bien sûr que je regarderai un patch s'il est intéressant, mais j'attends d'eux qu'ils ne soient plus aussi violents si ce jour arrive).
Pour info, on a rien contre les forks. En soi, un fork n'est pas forcément mauvais. On a déjà essayé d'inviter les créateurs de certains forks. Par exemple, j'ai personnellement fait une invitation officielle au créateur de GIMP-painter pour venir discuter à Libre Graphics Meeting; ça inclue défraiement du transport d'où que cette personne soit dans le monde, ainsi que du logement pour 10 jours, ce qui permet aussi de faire un peu de tourisme, et même une bonne partie des repas étaient payés. Malheureusement cette personne n'a pas répondu. Un fork intéressant, idéalement on aimerait bien sûr que la personne derrière nous rejoigne et qu'on fasse un super logiciel ensemble, mais on est pas du tout contre dans l'absolu si cette personne préfère continuer dans son coin. Toutes nos invitations sont sans obligation (bien sûr, on invite en espérant pouvoir discuter, trouver une entente et pouvoir travailler ensemble, mais y a pas de contrat "si tu acceptes l'invitation, tu dois faire ci ou ça", c'est juste basé sur l'espoir d'avoir un bon feeling en se rencontrant).
De manière générale, chez GIMP, on a une vision assez communautaire du logiciel. Par exemple, on considère n'avoir aucun concurrent tout simplement car on n'est pas dans une telle logique de "concurrence". Ainsi on invite aussi régulièrement (ce qui inclue les défraiements) des développeurs darktable, ou même des contributeurs GNOME qui font des trucs cools autour du graphisme sous Linux, et cette année, on a invité le mainteneur actuel de MyPaint car il fait vraiment des trucs cools et on veut vraiment l'encourager (notamment car MyPaint semble dans une situation peu stable dernièrement et ce serait vraiment dommage si ça s'arrêtait), ce qu'on refera sûrement d'ailleurs. Moi je pense que tous ces supers logiciels peuvent vivre ensemble et quand certains crachent sur les autres, ce sont ces choses qui m'attristent.
Ce fork en particulier par contre, "Glimpse", il a été hostile du début à la fin. Et leur communication (plus active que le développement) est entièrement basée sur "dire du mal de GIMP et de son équipe", tout en affirmant le contraire dans des communiqués (genre dans la FAQ encore une fois, ils affirment être "de bons citoyens du Logiciel Libre").
ce genre d'annonce, n'est pas très plaisante.
Pour nous aussi, mais surtout pour tout ce que j'ai dit jusque là. Ensuite je ne cherche pas à suivre particulièrement ce qu'ils font, mais c'est assez dur de ne pas suivre un peu, car ils font vraiment campagne à fond contre nous, donc on les voit un peu partout et forcément on se met à cliquer des liens. 😕
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tout à fait. Si vous passez ~ 8h par jour, 5 jours par semaine, le coup plié, à dessiner sur papier sur un bureau, les problèmes sont les mêmes.
En fait c'est le même problème que celui de travailler sur un ordinateur portable, sans écran externe (ou simplement être sans cesse sur son téléphone ou sa tablette). On a le cou sans cesse tordu et ça pèse sur la colonne vertébrale. C'est juste mauvais pour le corps. L'image vient d'un des premiers résultats sur le problème sur site de nouvelle quelconque, avec droits à surgicaltechnology.com apparemment
Alors selon les personnes, on peut le faire pendant des années sans problème. Voire certains vont peut-être parvenir à bosser une vie entière à temps plein sur ordinateur portable sans aucun problème. Je ne sais pas. Mais cela reste à déconseiller et beaucoup ont des problèmes médicaux rapidement.
Ensuite on peut dessiner sur une table à dessin/d'architecte, c'est mieux mais cela reste peu optimal (on continue à s'incliner, moins mais tout de même). Origine: Wikimedia Commons, CC BY-SA 3.0 par Thamizhpparithi Maari
Le chevalet est effectivement idéal car le dessin se retrouve presque vertical, à hauteur de visage, donc on peut enfin se tenir droit. Ensuite comme certains le note, ce n'est pas adapté à toutes les techniques, et implique de dessiner/peindre sur support solide (ou bien de rajouter un plan solide derrière le support souple — par exemple papier tenu sur planche de bois avec des pinces pour faire tenir). Origine: Wikimedia Commons, domaine public par Mrs Scarborough.
À ce moment, un autre problème se pose: la main est constamment en l'air, et non posée sur un bureau. Imaginez devoir travailler en tapant sur un clavier en l'air => ça fatigue.
Ceci dit, Aryeom me dit qu'en peinture, il y a des techniques pour ne pas trop s’abîmer. Elle a appris (comme probablement toute personne ayant appris le dessin professionnellement) à utiliser le bras, et non le poignet (ce qui est l'origine de gros problèmes de santé, ce que les gens qui tapent beaucoup au clavier connaissent bien aussi), tout en gardant les épaules peu contractées. C'est fatigant et ça implique de se reposer sur les muscles du bras. Mais cela reste la meilleure position pour le dessin de longue haleine. Néanmoins Aryeom note aussi qu'il reste un gros problème spécifique au dessin sur tablette-écran et qu'on ne retrouve pas avec les supports physiques. Dans la technique suscitée, qui utilise le bras et non le poignet, on va garder le poignet droit (si on casse le poignet, ça n'a plus de sens) avec le pinceau ou crayon tenu en l'air (mine en haut, comme si on tenait un marteau; cette comparaison vient de moi! Ahahah). Ce n'est pas pour tous les dessins, mais par exemple pour dessiner les grandes lignes. Or cette technique n'est plus vraiment possible sur tablette où on dessine avec un stylo. Pour dessiner ainsi sans casser le poignet, c'est possible même avec des crayons car les dessinateurs les taillent en longueur (je déconseille de tailler vos stylets numériques 😛 qui sont quand même vendu ~100€ pour les modèles pro! 😱 Je déconne pas). Sur ce point, le dessin sur ordinateur a donc bien un vrai souci d'ergonomie pour la santé des peintres numériques, car on sollicite trop le poignet, malgré les techniques de dessin classiques enseignées depuis des siècles. C'est un retard sur le dessin physique.
Sinon pour revenir à notre cas en particulier, on a succombé à la tentation de la tablette écran. On n'avait jamais eu ça jusque là, et il nous fallait essayer, même si on savait que ce n'était pas idéal ergonomiquement, ce qu'on disait déjà dans des vieux commentaires ici. Bon on a pris directement une grosse tablette-écran (24") parce que je pense que ça réduit les risques, justement parce qu'il est possible de changer l'inclinaison de cette tablette bien plus facilement (donc on peut se retrouver dans une situation proche du chevalet). Les petites tablettes écrans sont probablement le pire, car elle sont toujours posées sur le bureau (avec éventuellement un petit angle), jamais en face de soi.
Malheureusement l'expérience n'est pas terrible, comme craint. Notamment le support écran de Wacom coûte une fortune mais est super pas ergonomique (ironie, ils l'ont appelé "Ergo stand") parce qu'il a bien une position haute et une position basse pour lesquelles on peut changer l'inclinaison, mais il manque une position intermédiaire.
On voit bien le problème sur cette photo, où Aryeom s'était résignée à la position basse avec forte inclinaison, ce qui reste une position de travail toujours courbée (on est plus dans la situation "table à dessin" que "chevalet"): Origine: Compte Twitter de ZeMarmot
Depuis ils ont fait un nouveau support écran qui a l'air bien plus flexible. À essayer… si on avait les sous… 😞
Comme Aryeom a des soucis au dos/épaules et est allée voir le kiné plusieurs semaines à cause de cela, on a cherché des alternatives. Dernièrement elle semble être relativement satisfaite d'une nouvelle position où elle met l'écran en vertical (en fait c'est surtout qu'ainsi elle obtient une sorte de position intermédiaire, par contre elle perd en dimension horizontale): Origine: Compte Twitter de ZeMarmot
Le kiné aussi lui dit que c'est une bien meilleure position.
En conclusion, il faut rappeler que ces métiers du dessin sont de toutes façons des métiers très contraignants pour le corps. C'est aussi le cas pour les métiers non numériques, sur papier, etc. Ensuite selon le métier exact, ce sera pire ou non. Certains seront plus ou moins statiques (ici, c'est complètement statique: elle doit être à son bureau). Aussi certains métiers de design vont demander des choses plus diverses (on dessine moins), mais en animation, hors les périodes de pré-prod (script, storyboard, etc.), on est surtout dans du dessin pur et dur à la chaîne.
Donc la conclusion, c'est probablement qu'y a pas de solution miracle, mais faut surtout essayer de trouver le meilleur compromis.
Notons que j'ai aussi remarqué, en regardant des photos de bureaux d'autres dessinateurs, que certains utilisent les tablettes-écrans, même grandes, à plat, comme si ce n'étaient pas des écrans, en regardant un second écran (ce qui pallie aussi au gros problèmes des tablettes écran de mauvaise qualité colorimétrique, ce qui est malheureusement souvent le cas). Cela permet de travailler droit, en posant sa main (moins fatigant donc, même si le problème du poignet se pose toujours beaucoup), et j'imagine que le fait que la tablette est aussi un écran est utile des fois, quand on veut dessiner des détails. Je ne sais pas, c'est une supposition. Je ne suis pas certain en fait à quel point c'est avantageux (ou simplement un luxe inutile) d'avoir une tablette-écran dans ce cas, et pourquoi ne pas simplement se limiter à une tablette normale.
Bien sûr le problème principal de ce choix ergonomique est le coût. Ces tablettes écran coûtent déjà une fortune. Les bons écrans graphiques pro coûtent aussi super chers. Sans compter qu'il faut alors un grand bureau pour mettre tout ça… 😓
P.S.: beaucoup de choses dites ici sont aussi valable, dans une plus ou moins grande mesure, à tous les métiers de bureau, et en particulier sur ordinateur. Les tendinites, les problèmes de main, de dos, de cou/épaule, etc. se retrouvent dans tous ces métiers.
P.S.: je me permets de rappeler que je ne fais que paraphraser/rapporter les connaissances et expériences d'Aryeom. Je ne suis pas dessinateur moi-même. Des erreurs peuvent éventuellement se glisser ici ou là même si je crois avoir plutôt bien réussi à rapporter les infos.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Le mec a un soucis mais il ne propose pas de solutions, alors qu'il est super bien placé pour savoir.
Je suis d'accord que son article est pas très constructif.
J'ai remarqué qu'il y a plein de pages web indiquant avec forces détails ce que voient les daltoniens, mais je ne suis jamais tombé sur une page qui indique clairement « utilisez telles couleurs pour que ça passe avec 99 % des gens » (je n'ai pas cherché pendant des heures non plus). À la place on a un tas de recommandations, de palettes de couleurs dans tous les sens, et au final on ne sait pas quelle couleurs utiliser pour les cas simples.
--> vous avez un lien vers un truc potable ?
Comme d'autres ont notés dans diverses réponses: ça n'existe pas! En tous cas, pas à ma connaissance.
Déjà parce que distinguer les couleurs, c'est pas facile (en général). Même chez les non-daltoniens! Que ce soit à cause de la lumière ambiante (ou éblouissante, ou au contraire trop faible, ou lumière fortement teintée, etc.), ou bien simplement par aptitude/entraînement ou simple différence entre chaque personne. Il m'arrive régulièrement de ne pas distinguer des différences entre certaines couleurs sans être daltonien.
Ensuite parce que même chez les daltoniens (ce qui a aussi été dit), y a plusieurs types de daltonisme. Wikipedia déjà m'en cite 7! Et ce sont des daltonismes vachement différents (je vais montrer plus bas).
Les "solutions" donc?
Utiliser la position dans les standards, comme le propose Benoît Sibaud plus haut, me semble en effet une très bonne idée. D'ailleurs c'est marrant mais dans d'autres pays, on utilise parfois d'autres couleurs pour les feux de circulations, voire on utilise les mêmes couleurs mais appelés différemment. Au Japon/Corée, le vert, ils disent souvent qu'il est bleu par exemple! Comme quoi, la couleur n'importe pas trop dans ce cas comparé à la position.
Ensuite (ce qui a aussi été dit, notamment par toi-même): utiliser les formes/dessins. C'est bien pour certaines choses, mais de même que pour les couleurs (même pour ceux avec vision "standard"), cela a ses limites, je trouve. Hormis si c'est pour reconnaître juste quelques cas différents.
Ou même tout simplement écrire! En toutes lettres, compréhensibles par tous (même les non-voyants si c'est dans un format parsable par une machine).
Enfin d'après moi, il n'est absolument pas gênant d'avoir des versions non-lisibles par un groupe à handicap, du moment qu'on a une alternative. Par exemple, le cas Arduino plus haut me semble totalement mauvais à partir du moment où:
(bon, la page d'ou vient cette image en particulier contient aussi le schéma avec un formalisme plus classique et les valeurs numériques indiquées. Mais c'est pas forcément le cas partout).
On s'en fiche que c'est pas le cas ailleurs. C'est le cas ici, donc il n'y a aucun problème à cette image selon moi. On ne va pas s'arrêter de faire de jolis images aux jolies couleurs (voire aux couleurs réelles ici) parce que certains handicaps ne permettent pas de les voir idéalement! Du moment qu'il y a une alternative, c'est ok.
De même que les non-voyants ne nous demandent pas de ne plus faire d'images, simplement d'y ajouter un alt texte compréhensible, ou de ne plus faire de vidéos, mais d'avoir soit une audio adéquate (bon si c'est un documentaire par exemple, pour une fiction, c'est plus dur!), soit des sous-titres parsables.
De même que les sourds ne nous demandent pas d'arrêter les vidéos non plus, mais ils veulent des sous-titres (avec bruitages inclus si possible).
Etc. etc.
Il est donc important de considérer les daltoniens, mais pas en essayant d'adapter toute couleur à tous les daltonismes possibles (ce qui me paraît impossible), mais bien en ayant des alternatives.
Pour les codes couleurs des résistances, cela me paraît complexes, mais je pense que simplement écrire en toute lettre me paraîtrait l'alternative la plus simple et la plus infaillible (au moins aux daltoniens; pour les non-voyants, c'est encore autre chose). Ce serait écrit en petit, mais après tout, les électroniciens ici disent utiliser une loupe, ou tout simplement un ohmmètre (et rien qu'avec cet instrument, finalement qui s'intéresse aux codes couleurs?).
Enfin, si vraiment vous faites une image avec des couleurs que vous voulez absolument différenciables pour tous, tout logiciel d'imagerie a des outils pour simuler différents handicaps de couleur. GIMP et Scribus au moins le permettent (pour 3 des types de daltonisme: protanopie, deutéranopie et tritanopie; Scribus a aussi l'option "Full color blindness", je suis pas sûr, mais ça correspond peut-être à l'achromatopsie; tous ces mots savants venant de Wikipédia!).
Les résultats sont différents cependant entre Scribus et GIMP. Je ne sais pas vraiment qui a raison. En fait j'ai l'impression que Scribus implémente l'absence totale de certains récepteurs alors que GIMP implémente seulement une insensibilité partielle (ex: Protanopie vs. Protanomalie, cf. toujours Wikipédia).
Voilà à quoi ressemble le tableau des bandes couleurs de l'article avec les simulations de daltonisme de GIMP et Scribus:
La conclusion à tout cela est qu'il n'y a pas de réponse miracle et trop de différences entre les gens et les déficiences visuelles de base. Donc je doute qu'il ait de réponse magique "quelles couleurs choisir?"
Par contre, toujours avoir des versions alternatives qui reviennent aux bases, l'une des bases étant l'écriture selon moi, car cela peut se comprendre avec la plupart des handicaps si on a les outils adaptés (qu'on soit sourd, non-voyants, daltonien, etc. si c'est écrit dans un format standard, il doit y avoir moyen de vous faire passer l'info).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne crois pas que cela change quelque chose. Même si le copyright est partagé, rien n'empêche un des détenteurs du copyright de continuer le développement en code fermé, et de forker le logiciel avec une autre licence. Si Code Lutins partage le copyright, le seul avantage est que Code Lutins pourrait lui aussi continuer le développement en code propriétaire. Je parle bien sûr dans le cas où il y a une clause de copyleft (GPL) […]
Ben non. S'il y a partage de copyright en GPL, personne ne peut changer la licence. Ça en reviendrait à avoir le droit de décider pour le travail d'autrui.
Cela n'est possible que si les changements des autres détenteurs de droits sont suffisamment petits pour ne pas être considérés comme une œuvre de l'esprit originale. En gros si les autres contributeurs ont juste contribué des corrections de bugs simples ou des changements vraiment triviaux. Donc ils pourraient ne pas être considérés co-auteurs par un juge.
Alternativement celui qui voudrait changer la licence devrait soit se débarrasser de fonctionnalités contenant du code d'autrui soit en réécrire l'implémentation.
C'est bien pour cela que les changements de licence sur les gros projets copyleft (GPL, etc.) sont si complexes (à dessein!) et la raison pour laquelle des organismes développant du Libre demandent parfois de signer des contrats de cession de droits d'auteur (pour pouvoir à tout moment relicensier, notamment pour des entreprises qui voudraient faire du double licence).
Personnellement je suis un des gros détenteurs de droits sur GIMP (même si c'est juste quelques pourcents en relatif, ça reste beaucoup en absolu) et j'ai absolument aucun droit d'en changer la licence. Même le mainteneur qui détient vraiment plus de droits après plus de 20 ans à développer GIMP ne pourrait relicensier. Et c'est bien!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tout à fait! Ma formulation était clairement un peu hasardeuse et cette phrase résume bien ce que j'entendais dans mon commentaire:
Il s'avère que nous avons des besoins pour le projet G'MIC qui sont compatibles avec le fait d'améliorer GIMP, ce qui est tout à fait satisfaisant pour nous (Jehan et moi-même)
Le travail est techniquement le soutien au développement de G'MIC (qui est d'ailleurs aussi un logiciel Libre, et pas des moindres, rappelons le!) et c'est bien ce que je fais. Cela a simplement été fait de manière qu'on s'y retrouve tous, notamment moi aussi dans mes buts personnels (ZeMarmot et GIMP), mais "développer GIMP" n'est pas le but de mon poste en effet. C'est seulement un effet collatéral non négligeable. 🥳
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai dit « facultatives ». Sur une distribution externe, ce n'est pas activé par défaut, mais il suffit d'une commande pour le faire (et c'est recommandé par le manuel, et proposé par le script d'installation). Le fait que ça ne soit pas activé par défaut est simplement dû à la procédure d'installation dans ce cas, plus qu'à un choix réfléchi. Sur le système Guix, c'est activé par défaut.
Ok.
Pour flatpak, je vois par exemple que gimp est basé sur "org.gnome.Platform", ce qui a l'air assez vague et sans doute plus gros que nécessaire. C'est défini quelque part ?
C'est un runtime GNOME. À ce jour, y a au moins 3 runtime majeurs: Freedesktop (assez simple avec peu de dépendances), KDE et GNOME (tous deux basés sur le runtime Freedesktop auquel ils ajoutent des dépendances assez classiques dans les logiciels KDE ou GNOME). Ils sont bien sûr défini quelque part:
GNOME runtime, je crois que c'est ce lien, à vérifier
KDE runtime, ça m'a l'air d'être ici bien que ça m'étonne que ce soit sur github (peut-être un mirroir?)
Ensuite oui dans un runtime, y a très probablement plus que nécessaire. Ça part évidemment du principe qu'un runtime est utilisé par de multiples applications et permet au contraire de partager la charge (construction des dépendances, téléchargements, espace disque, maintenance et mises à jour, etc.). Mais bien entendu si GIMP est le seul flatpak installé, ça aura l'effet inverse (ça fait installer beaucoup inutilement).
Qui construit ces images ?
Les mainteneurs de ces runtimes chez GNOME, KDE, etc.
Le paquet gimp a l'air de redéfinir tout ce dont il a besoin : gtk2, ibus-gtk2, etc…
C'est un cas particulier car GIMP utilise encore GTK+2. Il y a encore pas si longtemps, GTK+2 était inclus dans le runtime GNOME, et on avait pas besoin de le définir dans le manifest/compiler dans notre flatpak. Ça a changé avec la version 3.30 du runtime, où ils ont décidé de ne plus inclure la version 2. Ça a du sens si on considère que la plupart des logiciels n'utilise plus GTK+2 qui est vraiment en fin de vie, et donc ça sert à rien de l'avoir par défaut.
Donc si j'ai deux flatpak qui utilisent les mêmes dépendances, j'ai deux fois les mêmes dépendances ?
Dans le cas cité, oui, retirer GTK+2 du runtime a un prix. Dès que quelqu'un aura au moins 2 applications basés sur GTK+2, alors il y aura duplication. Je pense personnellement que les mainteneurs du runtime ont retiré GTK+2 un chouille trop tôt, car il y a encore plusieurs applications très répandues basées sur GTK+2 (ne serait-ce que GIMP, qui est tout de même le flatpak le plus téléchargé de tout le dépôt flathub).
Ensuite c'est toujours une décision difficile à évaluer: quand retirer une vieille dépendance pour essayer de pousser les développeurs d'application à se mettre à jour?
Mais dans le cas d'une dépendance qui est dans le runtime dont un flatpak dépend, il existe en une unique version pour tous les logiciels basés dessus.
Notre flatpak stable est ainsi un exemple typique d'un logiciel avec une longue histoire et un peu de dette technique. Ainsi on doit se taper en effet l'ajout de GTK+2 mais aussi d'autres technos liées, comme ibus-gtk2 ou webkitgtk (v2!), du Python 2 (et pygtk 2). Notre flatpak de développement est bien plus simple (GTK+3, Webkit récent, etc. dispos dans le runtime GNOME).
À la fin, les dépendances à l'exécution sont un sous-ensemble des dépendances à la compilation, ce qui garanti que ce soient les mêmes dans les deux cas.
Pareil pour flatpak. Un runtime est constitué d'un ".Platform" et d'un ".Sdk". Le ".Sdk" comprend en addition les dépendances de compilation et n'est pas téléchargé par les gens qui n'ont que besoin d'exécuter.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Cependant, il y a une différence majeure : avec aptitude quand le dépôt central (la liste de deb dans le fichier /etc/apt/source.list) est mis à jour par les mainteneurs de Debian, il n'est quasiment plus possible d'installer un paquet dans une version d'avant cette mise à jour. Sauf erreur de ma part.
Ce résultat de commande indique le commit actuel du flatpak de GIMP (avec le message de commit, ici "Update to GEGL 0.4.16.") ainsi que le commit parent (le dépôt flathub garde une dizaine de versions précédentes de chaque paquet). Il est possible de remonter dans les vieux commits:
$ flatpak remote-info flathub org.gimp.GIMP --commit=5c8a3dc204a12d4695c5bb7e98ea3b3862d78e52c1cf0f9b021c1dae836ecc95
GNU Image Manipulation Program - Create images and edit photographs
ID: org.gimp.GIMP
Ref: app/org.gimp.GIMP/x86_64/stable
Arch: x86_64
Branch: stable
Version: 2.10.10
License: GPL-3.0+ AND LGPL-3.0+
Collection: org.flathub.Stable
Download: 108,5 MB
Installed: 306,8 MB
Runtime: org.gnome.Platform/x86_64/3.32
Sdk: org.gnome.Sdk/x86_64/3.32
Commit: 5c8a3dc204a12d4695c5bb7e98ea3b3862d78e52c1cf0f9b021c1dae836ecc95
Parent: fdbcfcbb8e5a4a6f484674208c6bbdf96c6e37fe2df21983a444069e5949276f
Subject: Build GTK+2 with more patches. (d7578706)
Date: 2019-04-25 16:46:42 +0000
Et enfin si je veux, je peux installer une vieille version de GIMP: flatpak update --commit=5c8a3dc204a12d4695c5bb7e98ea3b3862d78e52c1cf0f9b021c1dae836ecc95 org.gimp.GIMP
Pour info, je veux pas avoir l'air de faire mon lourd à toujours vous comparer avec flatpak. C'est simplement que c'est le seul aussi système de paquet/conteneur que je connais bien. Donc j'essaie juste de comprendre les différences entre guix et flatpak parce que je connais pas grand chose d'autre dans cette catégorie. Bien sûr je pourrais aussi juste tester guix mais bon… comme tous, mon temps est limité, et je peux pas prendre trop de temps maintenant pour suivre de longues instructions d'installation (j'ai bien regardé le lien donné, mais quand j'ai vu la longue série de commande pour l'installation dite binaire, je me suis dit "un autre jour"; désolé!), j'espérais plutôt un truc basique (🛌 lazy mode). Alors j'essaie d'avoir déjà une première idée de base juste en discutant. ;-)
Et pour le coup, d'ailleurs, je suis toujours pas sûr des différences, hormis que guix recompile localement par défaut avec installations binaires optionnelles (avec flatpak, c'est l'inverse; c'est très facile de recompiler un flatpak: ça se fait en une commande à partir du fichier manifest, mais par défaut on privilégie une installation d'un binaire sur un dépôt).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Dans docker (que je connais mieux) on utilise un dockerfile (dans le meilleur des cas) pour spécifier des commandes à lancer. C'est une manière très impérative de faire, et qui dépend beaucoup de l'état extérieur au conteneur ou à docker.
Dans flatpak, on utilise aussi juste un manifest qui dit où trouver le tarball (avec un checksum pour vérifier) ou bien un dépôt (avec un commit). Si c'est un projet qui utilise un des systèmes de compilation classique (autotools, CMake, meson…), on dit quel système c'est et c'est bon. Éventuellement on peut ajouter des options à appliquer à l'étape de compilation.
Ça me semble plus proche de guix tel que tu le décris que de docker. :-)
J'ai cherché un peu dans votre dépôt, le manifeste de GIMP me semble être ça, celui pour flatpak est ça.
C'est assez similaire! :-)
Le dépôt de Guix de référence est son code source, sur savannah. Par défaut, seuls les paquets de ce dépôt sont présents. Ils sont mis à jour par guix pull qui récupère la dernière version de ce code, et donc des paquets. Il y a aussi deux fermes de constructions qui fournissent des binaires, mais elles sont facultatives
Ah ok, donc un guix install recompile le paquet par défaut. C'est pas idéal selon moi pour les utilisateurs finaux. Fournir des binaires devrait être la norme pour un système de paquets (avec bien sûr la possibilité de reconstruire le paquet pour comparaison binaire, reproductibilité, etc. C'est très cool, je dis pas que ça devrait pas être possible, je parle juste point de vue de celui qui veut juste installer GIMP). Je dis ça, j'adore Gentoo (je l'ai utilisé quelques années en distrib principale). Mais de nos jours, je veux juste pas me prendre la tête, faire confiance à des gens et ne recompiler moi-même que les logiciels que j'ai besoin de hacker. Ensuite ce n'est que mon avis et mon conseil (qui vaut ce qu'il vaut, c'est à dire pas forcément grand chose) aussi pour que cette technologie prenne sur le grand public. 😛
À moins bien sûr que guix est destiné aux développeurs seulement, mais je crois comprendre que vous voulez aussi que ce soit considéré comme un système de paquets pour tous.
guix environment gimp crée un environnement similaire à celui utilisé pour compiler réellement gimp. Il y a toutes les dépendances à la compilation déclarées dans la recette de gimp (dont make, gcc, et toutes les bibliothèques et outils nécessaires).
Ok. C'est intéressant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui ce sont des améliorations par rapport à 2.10.8. Depuis GIMP 2.10.0, on autorise de nouvelles fonctionnalités, même lors de sorties macro. Et on s'en prive pas! :)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ben justement je me demandais, je fais un dons récurent à GIMP (tous les mois) via paypal et via Gnome (avec la mention for GIMP).
Quand tu donnes à "GIMP", tu donnes de l'argent pour une utilisation communautaire. En gros GIMP n'existe pas. Il n'y a pas vraiment d'entité derrière, ce pourquoi GNOME nous sert aimablement d'entité parapluie. L'argent donné à GIMP sert donc notamment à défrayer nos rencontres annuelles (à Libre Graphics Meeting en particulier) et à financer diverses actions communautaires. Comme GIMP a des rentrées décentes de donation, nous redistribuons aussi pas mal. Par exemple, on est l'un des rares projets qui est capable de défrayer complètement ses contributeurs à Libre Graphics Meeting, et tous les ans, on héberge aussi gratuitement des contributeurs d'autres projets (je me souviens de gens de GNOME Photo, de la fondation GNOME, de Kdenlive, etc.). Comme on considère cet évènement (Libre Graphics Meeting toujours) comme important pour l'écosystème du graphisme libre, on l'a sorti plusieurs fois de la panade en donnant des sous (parfois beaucoup), notamment pour les années où l'organisation n'avait pas assez pour payer ce qu'elle devait; et même au moins une fois (de ce que j'en sais), on a payé le défraiement de voyage d'une majorité des contributeurs, tout projet confondu. Enfin très régulièrement, GIMP offre un évènement communautaire à l'ensemble du Libre Graphics Meeting (genre une soirée dans un bar, avec tournée aux frais de GIMP!).
En anecdote, y a aussi eu une année où l'organisation avait mal géré l'enregistrement vidéo, et on allait se retrouver sans traces des confs, ce qui aurait été très dommage. On avait donc acheté une caméra vidéo (aux frais de GIMP, à l'arrache) pour au moins enregistrer communautairement les conférences (de mémoire, un truc du genre); et cette année notamment on finance encore l'enregistrement des conférences en vidéo.
Bon je connais pas tous les détails car je n'ai pas géré l'argent de GIMP jusque là (donc pardonnez moi si j'ai dit une bêtise sur une des anecdotes, ce n'est pas impossible; mais ça donne l'idée de comment l'argent de GIMP peut être utilisé, de toutes façons), mais c'est en gros l'usage qui est fait des donations. C'est vraiment un usage communautaire car on estime que le graphisme Libre, c'est pas que GIMP et qu'on doive aussi aider les autres projets. Note que ce n'est pas quelque chose dont on fasse particulièrement la pub (à tel point que même moi, au cœur du projet, je ne me tiens pas au courant des détails). On est juste content d'aider. :-)
Un autre usage non négligeable est l'achat de matériel pour les contributeurs (moins fréquent que l'usage communautaire qui est annuel, pour le coup).
Vous touchez les sous tout de même
Donc est-ce qu'on touche des sous? C'est utilisé pour nous faire nous rencontrer annuellement, mais cet argent n'est pas pour nous personnellement, non. Ça ne m'a jamais permis de vivre par exemple. GIMP ne peut pas nous donner de sous, ni en particulier faire de salaire (pas d'entité, je rappelle).
Ce que je veux dire c'est quelle est la différence entre "Support Core Team Developers Directly"
Quand tu donnes directement aux développeurs, là oui tu es sûr que cet argent va aux développeurs pour leur travail. Ensuite nous ne sommes que 2 développeurs (sur 4, si on considère les 4 gros développeurs de GIMP/GEGL/babl qui font la majorité du travail) qui ont organisé une vie professionnelle autour du Libre: moi (avec le projet ZeMarmot, c'est le côté GIMP même, et à ce jour, je suis historiquement le troisième plus gros contributeur de GIMP en nombre de commits) et Øyvind Kolås (le mainteneur de GEGL). Donc ça ne finance pas tout le monde (certains ne cherchent pas à être payés pour GIMP, comme le mainteneur qui a un emploi autre et ne contribue que dans son temps libre). Mais par contre, ça crée de vrais salaires (je ne sais pas comment le mainteneur de GEGL s'est organisé, mais de notre côté, l'association LILA crée de vraies fiches de paie pour financer le film ZeMarmot, et donc pour le développement de GIMP; donc là oui, on en vit, clairement).
En conclusion, donner au projet GIMP, c'est pour l'aspect communautaire du projet. Donner à un contributeur (ou au projet qui le chapeaute, ZeMarmot dans mon cas), tu nous finances nous directement. Ça nous permet de vivre. C'est bien simple, il n'y aurait pas le projet ZeMarmot, je n'aurais jamais été en capacité de faire ce que j'ai fait jusque là. J'aurais probablement dû trouver un job "alimentaire" quelconque et aurait contribué un pouillème de ce que j'ai contribué à ce jour. Je n'aurais pas non plus été remarqué par le CNRS qui n'aurait alors pas décidé de m'engager personnellement, avec accord de principe que mon travail serve essentiellement dans les intérêts parallèles du CNRS (tester/implémenter des algorithmes et promouvoir le travail de recherche du CNRS) et de ZeMarmot/LILA (améliorer GIMP, le Libre en général et aider à notre travail de graphisme/animation). C'est à dire que le CNRS paie en ce moment du développement dans GIMP, avec de l'argent public, tout ça parce que ZeMarmot est devenu suffisamment visible pour leur faire de l'œil.
Donc j'ai envie de te dire que c'est bien de donner à LILA/ZeMarmot, mais forcément je prêche pour ma paroisse. C'est donc totalement biaisé. :P
Disons que c'est de l'argent direct pour du développement concret dans GIMP, surtout que le projet ZeMarmot est encore loin d'être stable et on n'est jamais complètement sûr si le projet sera en capacité de continuer, même un an de plus. C'est un équilibre plus que précaire et assez dur pour les nerfs.
Il y a aussi un autre aspect très positif dans le développement qu'on fait à LILA: on aime améliorer les logiciels libres dans une démarche concrète. On fait un vrai projet, avec des vrais pros du graphisme. On ne développe pas pour développer sans se demander si notre code est utile ou même simplement utilisable. Quand je fais de la merde, je peux assurer que notre artiste me le dit directement que mon super code, dont j'étais trop fier, est juste pas utilisable dans la vraie vie. Et donc je cherche des solutions, j'essaie de faire une interface adapté, de revoir mes a-priori, et ainsi de suite. Perso c'est un truc que j'adore. C'est pas de la "preuve de concept". C'est une preuve d'utilisation. C'est là où je pense que notre association, LILA, est vraiment super utile pour faire de GIMP un logiciel pro. Et c'est dans nos statuts de faire de vrais projets (libres eux-même, nos films étant visibles par tous sous licence Creative Commons by-sa, et même les données téléchargeables quand le projet finit, cf. par exemple nos données pour le film Peertube qu'on a fait pour Framasoft). On a mis les projets en premier dans nos objectifs, dans les statuts d'association, c'est fait exprès. C'est ainsi d'après nous qu'on fait les meilleures avancées (on ne crée/promeut pas le logiciel libre pour lui-même mais bien parce qu'il est utile, utilisable et utilisé).
Ensuite soyons clair, c'est aussi super important de donner à GIMP en tant que projet communautaire. C'est grâce à ça que je suis devenu un gros développeur moi-même. La première fois qu'on m'a invité au Libre Graphics Meeting (alors que j'avais juste une petite série de patchs à mon actif et était donc un petit contributeur), j'ai trouvé ça super cool. Puis ça m'a permis de rencontrer les autres et de sympathiser, ce qui a renforcé l'aspect "entre potes". Sans ça, je suis persuadé que je n'aurais pas décidé de m'impliquer davantage (à l'époque, je faisais juste des patchs par ci par là à divers projets en fonction de problèmes que je rencontrais, c'est tout; en l'occurrence, j'avais eu des bugs dans GIMP et avais juste décidé de les corriger pour mon utilisation propre; jamais je n'aurais imaginé être un jour l'un des développeurs principaux de GIMP, et l'un de ceux qui font les décisions cruciales sur la direction du projet), puis de co-créer le projet ZeMarmot pour faire un film qui me plait tout en développant du Libre, etc. Donc l'aspect communautaire est aussi super important. Ça fidélise les développeurs et la communauté, ça développe les échanges et les relations amicales, ça donne de l'importance à toutes les contributions, même les petites, etc.
Simplement je me fais moins de souci de ce côté là, car je sais que GIMP a pas mal de fonds, n'a pas de problèmes financiers (et n'en aura sûrement pas dans le futur non plus), alors que nous, on galère un peu. J'aimerais beaucoup qu'on atteigne enfin un jour un état financier stable pour notre projet, qui puisse financer non seulement mon développement et le travail de notre réalisatrice, mais aussi d'autres développeurs et d'autres artistes, quitte à reverser nous-même dans l'aspect communautaire au besoin.
Voili voilà. J'espère que c'est plus clair. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
1) Quels sont les similitudes et différences avec les technos flatpak ou snap? Genre vous parlez d'environnement indépendants, de conteneurs, etc. C'est du sandboxing avec des permissions, etc.?
En outre y a-t-il un serveur/dépôt Guix de référence? Quand on fait un guix search ou guix install, ça installe depuis un dépôt unique? Quelqu'un peut créer son propre dépôt? Qui crée les paquets?
J'aurais bien testé un guix install gimp mais guix ne semble pas dispo sur Fedora. ;-(
2) À croire que ça s'adresse à moi! 😛
Supposons que vous êtes un développeur de GIMP : guix environment gimp permet de produire un environnement avec tout ce dont vous avez besoin pour « hacker » GIMP, bien plus rapidement que l’installation manuelle de ses nombreuses dépendances.
Bon perso j'installe les dépendances de GIMP en quelques minutes et j'ai mon propre outil pour me créer mes environnement de développement (crossroad). Je me crée mes builds de GIMP indépendants en quelques secondes. Mais c'est intéressant de voir des alternatives. On aimerait bien en savoir plus sur ce que fait ce guix environment gimp. Notamment ça semble dire que ça installe aussi toutes les dépendances pour pouvoir compiler GIMP (ce que ne fait pas mon outil). Pour le coup, je veux bien plus de détails. On reste un peu sur sa faim!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pour compléter: historiquement l'inscription n'est pas obligatoire à LGM. Néanmoins s'inscrire en avance permet aux organisateurs d'avoir une idée du nombre de personnes qui seront présentes et ainsi de s'organiser (mieux) en conséquence. 🙂
Et oui, les confs sont en anglais. Je me souviens de cas où des locaux ont fait des confs dans la langue locale, mais cela reste des cas exceptionnels et ces confs ont eu peu de succès à cause de cela (car beaucoup de non-locaux ne pouvaient tout simplement pas comprendre, pas parce que ce n'était pas intéressant), donc la norme reste plutôt de tout faire en anglais.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Dans ce cas là, l'image finale pourrait (conditionnel car j'ai quand même des doutes) avoir plus d'information globalement que l'image initiale mais pas plus d'information sur la « réalité » représentée par l'image initiale.
Je crois que vous vous prenez tous la tête. Bien sûr que ces réseaux de neurones n'ont pas plus d'informations sur la "réalité" de l'image. Mais c'est quoi la réalité? En photographie, ou en imagerie artistique de manière générale, le but est d'avoir une bonne image finale. Quand ce sont des images représentants la réalité, le terme employé généralement est "crédibilité". On veut surtout une belle image crédible, pas forcément réaliste.
Pour en revenir donc à la demande initiale, Stinouff vous dit qu'il a testé ce site et que ça lui a donné des bons résultats, et vous venez tous lui faire la leçon que c'est pas possible de créer des informations qui n'existent pas alors qu'il a eu des résultats probants, là en vrai devant ses yeux! Et oui, vous avez raison dans la théorie (on ne crée pas de l'information à partir de rien), mais dans la pratique, ces algorithmes basés sur des réseaux de neurone y arrivent bien. Certes ces données créées viennent de l'apprentissage avec d'autres images. Certes ce n'est donc "pas la réalité". Mais même l'image originelle est-elle la "réalité"? J'ai lu suffisamment d'articles de photographes ou vu de confs de photographes qui expliquent que la photographie n'est pas la réalité pour affirmer que "non", ce n'est pas la réalité (au point qu'il y a des articles Wikipedia sur le sujet!). La photographie n'est pas la réalité donc déjà à la base, vous basez votre argumentation sur quelque chose de fragile. :-D
Perso je n'ai pas testé ce site car je n'ai pas envie de faire un compte et d'y balancer plein de photos persos, mais je n'ai pas de doute que c'est possible d'agrandir en gardant un résultat crédible. Les algos dits de "Super Resolution" sont très à la mode depuis plusieurs années, y a pleins de papiers de recherche sur des solutions diverses et a priori l'usage de réseaux de neurones sont une des solutions communes. Vous pourrez voir plein d'exemples sur des centaines d'articles sur le web qui montrent des résultats parfois impressionnants. Ça peut donner des résultats crédibles dans certains cas, c'est un fait. Faites juste une recherche sur le sujet.
Bon et maintenant pour faire une réponse à Stinouff: malheureusement, je ne crois pas qu'il existe une solution libre simple à mettre en place à l'heure actuelle pour la super résolution. En tous cas, pas dont j'ai entendu parler. :-/
En fait de ce que j'en ai compris, ce qui marche le mieux pour l'instant, c'est les réseaux de neurones, avec beaucoup de couches. On en arrive à avoir un modèle qui fait plusieurs GB. Pour une application de bureau, plusieurs GB à garder en mémoire juste pour faire tourner son algorithme (plus l'OS, le programme, l'image d'entrée, de sortie, etc.), c'est assez contraignant. Sans compter l'espace disque. Imaginez si GIMP par exemple faisait 10GB à l'installation sur votre disque (et si on se mettait à avoir plusieurs filtres utilisant des réseaux de neurones, ça pourrait grimper vite). Ce serait un problème!
Voilà, donc de ce que je comprends, ce serait le principal problème à ces algorithmes de nos jours. Technologiquement ce n'est pas forcément très complexe, et les papiers de recherche sont en général publics, donc implémentables. En plus on a des logiciels libres pour entraîner des réseaux de neurones (on lit parfois sur le sujet sur linuxfr). Donc y a pas grand chose techniquement qui empêcherait d'avoir ça si ce n'est que ce n'est pas pratique à utiliser. Et ça explique pourquoi la plupart des implémentations de nos jours sont des gens qui font tourner leur réseau sur un serveur qui ne fait que traiter des images à travers ce modèle, avec un business model consistant à faire payer les gens pour y uploader leur photos et obtenir un résultat.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce n'est pas tout-à-fait exact. J'ai dû faire un peu de défense face à des commentaires de mauvaise foi.
[…]
Comme je l'ai déjà dit dans une autre réponse, si tu te sens efficace quand tu utilises Git, c'est très bien ! Peut-être que Pijul n'est pas pour toi.
Hmmm… tout de même avec toutes les précautions que j'ai prises, cette réponse arrive quand même à être pas mal sur la défensive! Je pense avoir suffisamment expliqué que j'étais ouvert aux nouveautés. Et dire que j'aime bien/suis efficace avec git ne signifiait absolument pas que je ne veux pas de Pijul ou que ce n'est pas pour moi. Si c'est le cas, aurais-je vraiment écrit un super long message super diplomatique qui m'a pris du temps?
Peut-être serais-je encore plus efficace avec Pijul, qui sait! Ce n'est donc pas antithètique (être efficace avec git vs. Pijul est pour moi? Aucun rapport, fils unique!). 😛
Et la page du manuel "Why Pijul" a bien un lien vers un exemple concret avec du code C, où Git s'emmêle les pinceaux (en termes mathématiques, où Git n'est pas associatif) : https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html
Ok j'avais loupé ça, c'est intéressant, merci. L'exemple aurait mérité d'être recopié avec un joli formatage dans la dépêche, en bien placé. D'un seul coup on comprend beaucoup mieux et tu te serais évité pas mal de discussions, je pense!
C'est pour moi 100 fois plus explicatif que tous les mots mathématiques ou que les détails sémantiques (genre définir prouvé "scientifiquement" vs "mathématiquement"; désolé mais bon… 😛).
Sur la commutativité, tu as des exemples tout le temps quand tu utilises Git :
Encore une fois, un exemple concret ne serait pas de refus (tes 3 points ne sont pas des exemples concrets pour expliquer un tel usage). En un exemple, le coup de l'associativité est devenue concrête en 2 minutes de lecture (évitant ainsi de longs débats sur linuxfr). Ça vaudrait le coup de faire pareil avec la commutativité, non? :-)
Chaque fois que tu fais un rebase d'une branche sur une autre. C'est une opération qui n'est jamais nécessaire dans Pijul, elle est automatique dans 100% des cas.
Tiens là par exemple j'ai vraiment du mal à comprendre ce que tu me dis. Comment la branche peut-elle être rebasée sans demande explicite? Comment sait-elle sur quelle autre branche elle doit l'être? Et si je veux pas rebaser? Enfin bon là comme ça, ça me paraît juste magique. Ensuite y a sûrement une logique que je ne pige pas. D'où: un exemple concret serait utile.
Rebase a d'autres usages, comme par exemple retirer un vieux commit. Pijul fait ça (la commande est unrecord) sans changer l'identité des nouveaux commits, donc si tu as déjà poussé ce n'est pas grave.
Mais tu le retires-retires? Il n'est plus disponible du tout, plus de trace dans l'historique (genre pas comme un git revert où tu annules l'action du commit sans retirer dans l'historique)?
C'est tout de même assez tendancieux de permettre la réécriture à volonté (pour les branches publiques, notamment communément celle appelée "master" dans git). Et ce n'est pas seulement car on casse l'historique dans git (les hashs de commit qui ne sont pas cassés dans Pijul, j'ai bien compris cette partie!), mais bien aussi car réécrire l'histoire, c'est perdre des informations. Aussi les gens avec un vieux hash de commit ne peuvent plus le retrouver. Les seuls cas considérés comme acceptables sont normalement lorsqu'on a "commité" des infos méga-confidentielles par erreur (et encore… en général si on a fait ça, il faut surtout considérer que c'est trop tard cas on ne sait pas qui en a pris connaissance; donc réécrire l'histoire ne sert en général à rien, même dans ce cas, à part limiter les dégâts éventuellement le temps de changer les infos fuitées à la source).
C'est un autre problème que Pijul n'a pas, il y a une vraie représentation interne des conflits.
C'est un truc que tu as répété plusieurs fois dans tes commentaires. Et c'est aussi écrit dans la page "Why Pijul". Mais ça veut dire quoi concrêtement une "vraie représentation interne des conflits", pour nous autres simples développeurs qui veulent juste versionner nos sources?
⚠ Je ne te demande pas de me le réexpliquer avec d'autres mots, et surtout pas des termes mathématiques! ⚠
Encore une fois, un exemple concret vaut tous les discours. Genre un copier-coller du résultat d'un conflit de merge, et comment il est corrigé par le développeur qui utilise Pijul (genre le workflow avec les diverses commandes Pijul; qu'est-ce que le dév voit dans ses fichiers? comment les modifie-t-il? etc.). Ça, je pense que je comprendrais. :-)
(et cette fois j'ai bien regardé si j'ai pas loupé un lien sur la page "Why Pijul? qui donne un tel exemple; et il me semble que non, ou alors c'est bien caché!)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai vachement hésité avant d'écrire ce commentaire car je vois bien que vous êtes un peu sur la défensive. Je le comprends, c'est pas facile d'être sans cesse comparé par des gens qui comprennent pas votre techno à une autre techno plus connue (bon en même temps, c'est un peu votre faute aussi; vous lancez la discussion/comparaison dès le second paragraphe de l'article et dès le début du lien "Why Pijul"! Donc on a l'impression que votre principal atoût vient de la comparaison avec git). Mais c'est justement ça le prob. On comprends pas suffisamment pour appréhender l'avancée technologique.
Quand d'autres demandent des exemples, c'est pas pour vous prendre en défaut donc le prenez pas mal. En tous cas moi c'est pas le cas donc je réitère la question posée par d'autres: pourrait on avoir des exemples concrets ? J'ai bien vu les multiples réponses à cette question mais il me semble qu'aucune ne répond vraiment. On veut vraiment un exemple bête et méchant de la vraie vie.
Genre vous donnez 2 patchs (avec explicite diff) et vous montrez comment git le gère différemment (et surtout mal dans un cas) selon l'ordre (puisque l'un des points de vos algos est que l'ordre ne change pas le résultat contrairement à git). Puis vous montrez que pijul lui le fait bien dans tous les cas.
Autre exemple: un merge de 2 patchs qui génère un conflit avec git alors que pijul donne le résultat attendu sans conflit.
Ou bien d'autres exemples qui correspondent mieux aux problèmes résolus par Pijul (les miens sont peut-être mauvais mais justement c'est parce que j'ai du mal à comprendre; en tous cas en lisant plus haut, c'est ce que je comprends être les 2 gros problèmes réglés pas Pijul).
Clairement je trouve ça intéressant. Comme tout le monde j'ai eu mes emmerdes avec des conflits de merge foireux dans git, etc. Aussi je suis complètement techno-agnostique. git marche plutôt bien et j'en suis globalement content mais si demain un truc fait 10 fois mieux, j'aurai aucun remords à changer. Pourquoi pas?!
Donc je suis vraiment en train de demander naïvement des détails pour comprendre Pijul.
Car les algos prouvés scientifiquement c'est cool mais au final c'est pas ce que je vois en tant que dev de base. Me dire que "les patchs commutent" ou "sont associatifs", j'ai beau avoir fait des maths et comprendre plus ou moins ce que ça veut dire dans un contexte de système de versionnement, j'ai quand même du mal à voir ce que ça m'apporte concrètement pour mon boulot de dév au quotidien. D'ailleurs je pense faire partie des gens qui savent plutôt bien utiliser git et pourtant j'en connais pas les algos (comme vous l'expliquez très bien dans d'autres commentaires que la plupart des gens ne savent pas comment ça marche en interne; c'est vrai. Ça nous empêche pas de l'utiliser suffisamment efficacement pour nos besoins au quotidien). Ce qui prouve que l'usage final compte beaucoup (même si évidemment les algos aussi; et je suis parfaitement conscient à quel point ça doit être frustrant pour des chercheurs d'avoir l'impression que peu s'intéressent à la beauté de votre algo! J'en suis désolé!). Je fais partie de ces ingés simples qui font plutôt des implémentations pratiques d'algo d'ailleurs (en ce moment je bosse même pour le CNRS pour implémenter des algos dans GIMP). Je suis sûrement pas le meilleur dev du monde mais je pense pas être trop mauvais non plus. Donc je me dis que si je trouve pas ça si "intuitif", c'est que ça l'est peut-être pas autant que vous semblez le croire (ce qui ne veut pas dire que c'est mauvais pour autant!).
Et oui je me rends bien compte que je marche sur beaucoup d'œufs dans mon commentaire (ce qui le rend super long) mais c'est parce que j'ai l'impression qu'à chaque fois que quelqu'un compare à git ou vous demande des exemples, vous vous sentez attaqués. Franchement c'est pas le cas. Pour parler de mon cas personnel, je trouve juste sincèrement l'explication floue. J'ai l'impression que vous présentez une super techno du futur mais que je comprends rien à ce qu'elle apporte (de mieux que ce qui existe) en vrai… Hormis d'être une techno du futur!
Donc j'essaie d'y aller le plus diplomatiquement possible pour m'éviter de me prendre vos foudres ou que vous vous sentiez insultés. J'espère que ça marche, que vous le prendrez donc pas mal et m'apporterez des exemples concrets!
Merci! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce serait bien que l'affichage des URL contenant des caractères non ascii soit systématiquement contrôlé et que les caractères hors ascii soient colorés d'une façon très perceptible.
Alors ça sûrement pas. C'est la pire des réponses au problème qui pourrait être faite. Et malheureusement c'est le genre de réponses qui est souvent faite par certains développeurs des pays occidentaux et ça explique probablement en partie le peu d'intérêt des logiciels libres dans pas mal de pays (en tous cas, dans les pays extrême-orientaux, je peux attester que le libre est très anecdotique par exemple). De nos jours, pas mal de trucs se sont vachement améliorés heureusement, mais par exemple pendant longtemps, les difficultés pour installer les méthodes d'entrée pour langue non européennes rendaient évident que des barrières étaient créées dès l'installation d'un OS libre.
Donc pour bien revenir au sujet, non pas tout le monde n'utilise les caractères latin (encore moins le sous-ensemble ASCII) et il n'y a aucune raison pour l'imposer au monde entier.
Ainsi si on prend les exemples: Αlaska est problématique, oui, mais parce que le reste des lettres est dans l'alphabet latin et surtout "Alaska" est un nom propre en anglais.
Mais si maintenant le mot était Αλάσκα (qui apparemment veut dire Alaska en grec, cf. Wikipédia) alors le Α (alpha majuscule grec) est attendu et ce serait le A ASCII qui serait problématique, et possiblement utilisé pour tromper autrui (pas forcément, notez bien, mais "possiblement").
Ensuite on pourrait imaginer des cas où mélanger les alphabets/syllabaires peut être acceptables, que ce soit pour des jeux de mots ou du character art (beaucoup utilisent des scripts non locaux pour leur forme, j'en ai repéré sur linuxfr même, au fil des ans). Ou simplement on pourrait imaginer un franco-grec avec un prénom composé (un nom français, un grec, ça ne me paraît pas improbable), etc. Donc ce n'est pas forcément un problème simple à résoudre. Mais si on veut gérer ces problèmes, c'est par ce type de réflexion et pas en disant "tout en ASCII". On est dans un monde Unicode, et c'est une avancée, pas de retour en arrière SVP! :P
De mémoire, il me semble qu'il existe même plusieurs RFCs qui évoquent ce type de problèmes (notamment pour la problématique des noms de domaine acceptables), et ce sur de nombreuses pages (je peux assurer qu'aucune de ces RFC ne dira juste "utilisez tous ASCII", surtout en s'adressant à des pays dont la langue n'utilise pas les caractères latins!).
Sinon, et pour parler un peu de la librairie de l'article, en jetant un œil au README du dépôt, il semblerait que cette bibliothèque gère certains trucs intéressants. Déjà je vois les notions de mixed script, etc. J'ai pas cherché beaucoup plus loin, mais ça a l'air correct d'un rapide coup d'œil. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne comprend pas aussi le message "there is no way that you could be certain about this" ?
Même si tu as un source code, tu ne peux jamais être certain que le code qui tourne sur le serveur est celui dont tu as le source code… hormis la parole de celui qui a installé. Mais les promesses n'engagent que ceux qui y croient.
Si toi par contre, tu installes le logiciel sur ton serveur, alors bien sûr, tu peux (techniquement, ça ne veut pas nécessairement dire que tu vas le faire, mais au moins c'est possible) être sûr qu'il n'y a aucune porte dérobée… hormis si tu en rajoutes une toi-même bien sûr! Et dans ce cas, la situation se renverse.
C'est le principe de "Software as a Service".
La conclusion est que ce message s'adresse aux gens qui utilisent le service web (qui n'ont pas de preuve autre que la parole de l'admin), pas à ceux qui l'installent (lesquels peuvent savoir si les photos sont gardées). Et ce logiciel dit donc aux gens de rester critique et de ne pas croire aveuglément n'importe qui. C'est pas parce qu'on vous dit une chose que c'est nécessairement vrai. Donc évitons de balancer nos photos de nu si on veut être sûr qu'elles se retrouvent pas n'importe où.
Je trouve un tel message plutôt une bonne idée. Mais comme tu le montres, il faut peut-être un peu de background pour en comprendre tout le sens.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est historique. Bien sûr qu'à ce jour, GIF a plus d'outils. Et ça sera toujours le cas tant que des plateformes accepteront GIF (le jour où les plateformes se mettront à accepter WebP ou APNG et refuser GIF, la tendance pourra commencer à s'inverser).
Mais WebP commence à être bien pourvu en terme d'outillage tout de même. Ça reste la conclusion. Et GIMP notamment peut aisément générer des WebP animés. :-)
Ensuite je parlais d'APNG car à ce jour, c'est le principal autre remplaçant possible dans cette niche (bon y a MNG aussi qui est le format standardisé et justement la raison pour laquelle le patch APNG n'est pas accepté upstream dans libpng; mais ce format a complètement loupé son entrée de manière étonnante, en étant quasi pas pris en charge dans les navigateurs), même si j'étais bien conscient que tu n'en parlais pas. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En fait au contraire, l'outillage est la raison pour laquelle je donne un avantage à WebP, par exemple comparé à APNG (alors que pour la visualisation, APNG semble avoir plus de pénétration, car dans son cas, le seul navigateur majeur sans prise en charge semble être Microsoft Edge, qui a récemment annoncé passer au moteur de Chrome, donc qui pourra lire WebP à terme).
Le truc, c'est que WebP a une bibliothèque bien maintenue alors que pour visualiser APNG, y a un fork de libpng (en fait juste un patch) que divers navigateurs semblent embarquer. Or cela est un problème pour beaucoup de logiciels libres (on n'a pas trop envie d'embarquer un fork, ce qui en plus revient à le maintenir).
Prendre en charge WebP (que ce soit en lecture ou en écriture) au contraire, ça se fait en quelques appels de fonction. Et en cas de problème, c'est simple de rapporter un bug ou d'envoyer des patchs (je l'ai déjà fait, équipe réactive). Alors qu'APNG, c'est un projet obscur sur Sourceforge qui distribue un patch. On trouve des dizaines de forks qui ont appliqué diverses versions de ce patch un peu partout.
Et comme on peut s'y attendre, très peu de distributions (aucune que je connaisse en fait, mais j'ai vu cette affirmation quelque part, reference needed!) ne l'appliquent (je rappelle, ça ne crée pas un libapng, ça patch direct libpng). Ce qu'il faut pour une vraie adoption, c'est une vraie librairie libapng dans son propre espace de domaine.
Donc non, pour WebP, au contraire, l'outillage est son point fort. En Libre, que ce soit GIMP, ffmpeg, ImageMagick, la plupart des gros projets prennent en charge nativement et sont capables de générer des animations WebP très aisément.
De même pour beaucoup des gros logiciels propriétaires, soit nativement soit par plug-in.
Aucun problème d'outillage 🛠️! :-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En plus du fait que webp propose la transparence (notamment partielle, pas juste une transparence binaire) comme tu le notes, y a aussi la prise en charge d'animation.
Ça en fait un remplaçant des plus sérieux au format GIF (pour une plus petite taille de fichiers, on a des animations de meilleure qualité d'image, et de la transparence partielle).
Sauf erreur, de nos jours, le seul navigateur majeur (qui a au moins quelques pourcentages de part de marché) sans prise en charge est Safari. C'est le seul blocage qui pourrait empêcher certains de ne plus utiliser le format GIF au profit de WebP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mauvais exemple
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal JS dans linuxfr ?. Évalué à 4.
J'hésite: est-ce une blague de ta part ou bien tu n'as pas bien lu mon commentaire?… 😛
Bon au cas où, je tombe dans le piège quand même. Oui c'est normal, puisque comme je disais, c'est une animation en SVG visible seulement sur les pages en erreur 404 (a.k.a. liens morts). J'ai donc mis un lien vers une page qui n'existe pas exprès (note le nom de la page: https://www.gimp.org/jenesuispasla; j'aurais aussi bien pu donner: https://www.gimp.org/youplaboum) pour permettre aux gens de voir cette animation.
Donc sur gimp.org, quand vous ouvrez n'importe quelle page en 404, vous verrez un petit Wilber (mascotte/logo de GIMP) qui marche jusqu'au milieu de page, et essaie d'ouvrir l'en-tête mais n'y parvient pas, et est alors dépité. 😢
Ensuite peut-être ne vois-tu pas l'animation. Dans ce cas, je suppose que tu as un des rares navigateurs qui ne prend pas en charge les animations SMIL (c'est à dire soit Opera Mini, soit IE, les 2 seuls qui ne savent pas lire les SVGs animés en SMIL à ce jour, du moins d'après les infos trouvées, ou une version pas à jour d'un autre navigateur).
Dernier cas: peut-être faisais-tu bien une blague et avais-tu bien compris que oui cette page est 404, et oui c'est normal, non c'était pas une erreur, car c'est bien ainsi qu'on peut voir notre SVG animé. 😃
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mauvais exemple
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal JS dans linuxfr ?. Évalué à 4.
Pas en Libre, malheureusement, aux dernières nouvelles. Nous avons fait cette animation "à la dure", c'est à dire que les dessins sont faits dans Inkscape, mais sont animés en éditant ensuite le SVG dans un éditeur de texte.
Bon ça fait quelques années, mais je n'ai entendu parler d'aucun logiciel libre qui ait ajouté la prise en charge du SVG animé depuis.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mauvais exemple
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal JS dans linuxfr ?. Évalué à 6.
SVG permet de faire des animations sans recourir à des scripts et notamment sans JavaScript.
Voir par exemple la page 404 que le projet ZeMarmot a contribué à GIMP y a des années déjà : https://www.gimp.org/jenesuispasla
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: OpenCL et Driver libre ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au message N'utiliser une carte graphique que sous Blender.. Évalué à 2.
Quelqu'un a suggéré de demander sur des forums Blender. Je ne peux que réitérer la proposition.
Le "pro NVIDIA" était vrai y a quelques années. Mais depuis ils ont pas mal bossé avec AMD (et Intel aussi) et la situation s'est beaucoup améliorée.
Pour le coup d'utiliser la carte pour affichage seulement lorsque tu utilises Blender, je sais pas si c'est possible (mais pourquoi pas après tout! Les écrans ont plusieurs entrées. Pourquoi ne pourrait on pas logiciellement décider laquelle est active à un moment donné?). Mais ça ne t'empêche pas au moins de l'utiliser juste pour le rendu déjà ce qui est un énorme gain de temps et évite qu'elle soit constamment bruyante. C'est entièrement configurable dans les préférences.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Est ce qu'ils ont discuté avec l'équipe ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien fork de GIMP, cachez moi cette licence. Évalué à 10.
Sommaire
officielleofficieuse de l'équipe GIMP (bis repetita)Alors l'histoire complète:
Le nom
Déjà, en quoi le mot "GIMP" cause-t-il problème? Y a deux trucs:
Une Insulte?
Ça peut vouloir dire "boiteux" en anglais. C'était ça le problème initial des gens derrière Glimpse (même s'ils se sont raccrochés aussi au second problème ensuite). A priori, même chez les anglophones natifs, ce problème est assez controversé car cette "insulte" serait considérée plutôt datée et quasi inusitée de nos jours. En tous cas, c'est ce qui ressort du fait que beaucoup de gens d'origine UK ou US disent régulièrement sur des forums anglophones (genre reddit) qu'ils avaient jamais entendu cette insulte de leur vie bien qu'étant natifs et que pour eux, "gimp" ne leur évoquait jamais que le logiciel.
L'une des bases de l'argumentaire est donc que ce serait un terme insultant pour les handicapés (le terme exact qui fut employé est "ableist insult", ce qui se traduirait apparemment en "insulte validiste"; on apprend de nouveaux mots tous les jours!), ainsi qu'une insulte de cours d'école. Pour le second point, je ne sais pas, mais pour le premier, on a régulièrement des gens qui répondent être eux-même handicapés et n'avoir aucun problème avec le mot "gimp" ou le fait que GIMP soit appelé ainsi. Par exemple c'est le commentaire le plus plussé sous cette vidéo. Ou encore dans le rapport de bug qui a tout débuté (j'en reparlerai plus tard), un des développeurs de GIMP (qui est surtout un des développeurs principaux de Darktable, mais qui fait aussi des patchs réguliers à GIMP et traînent beaucoup sur notre salon IRC, etc.) a lui même annoncé être un boiteux (pour info: c'est vrai, vous pouvez confirmer par exemple si vous venez à un Libre Graphics Meeting) et ne pas avoir de problème non plus avec ce nom.
Une référence de film
Le second problème, qui n'était absolument pas mentionné dans le problème originel (il est possible que cette personne ne connaissait pas ce problème; il m'a fallu des années pour le découvrir moi-même, même en contribuant à GIMP), et qui pourtant est pour moi plus problématique est l'utilisation du terme dans les milieux sado-maso. On appelle souvent les costumes entièrement en cuir des costumes de "gimp". Une recherche marrante dans un moteur de recherche serait donc "gimp mask" (les masques de calques étant des termes courants en graphisme numérique).
Ce terme vient en fait de Pulp Fiction. Pour ceux qui l'ont vu, il y a ce personnage qui vit dans un coffre dans la cave d'une boutique, entièrement vêtu de cuir, et qui s'appelle "the Gimp". La phrase la plus célèbre en rapport avec ce personnage est "Bring out the Gimp" (cf. la scène (⚠️ NSFW ⚠️)). Pour la petite histoire, d'après des interviews des créateurs originels, le nom du programme vient bien de ce personnage de Pulp Fiction, car c'était le film à la mode de l'époque (sorti la même année que GIMP). Donc déjà il faut bien noter que ce terme ne vient pas d'une pratique sado-maso. Le nom du costume sado-maso de même que celui de ce programme viennent simplement du nom d'un personnage d'un film de cinéma. Ils ont la même origine, l'un ne vient pas de l'autre.
Mais oui, clairement cela a lancé un nouveau terme dans ce milieu particulier.
La position officielle de l'équipe GIMP
Il y a plusieurs points:
Notoriété existante du nom
Le premier point — le plus important — est que le logiciel est vraiment vraiment connu sous ce nom. On parle de millions d'utilisateurs. On n'a pas vraiment de stats, mais par exemple à l'époque où le binaire Windows était distribué sur Sourceforge, on avait apparemment entre 4 et 7 millions de téléchargements par version pour Windows. C'était à l'époque 2.8. Avec la sortie de 2.10 et les énormes efforts faits depuis, c'est probablement bien plus maintenant.
Je sais que Flatpak à lui seul a presque 100.000 téléchargements unique pour la dernière version, en notant que Flatpak est un pouillième des téléchargements Linux, qui sont eux même un pouillième des téléchargements totaux.
Tout ça pour dire que changer de nom, ce n'est pas rien. Ça ne se fait pas sur un coup de tête. Beaucoup de grosses entreprises avec des moyens formidables se sont cassés les dents dans du rebranding. Et dans tous les cas, cela demande un gros engagement "marketing" sur plusieurs mois, voire années. Or on n'a clairement pas ces moyens chez GIMP en terme de nombre de contributeurs ou d'argent à dépenser.
Personnellement je pense qu'on devrait au moins implémenter un système de vérification de version (pas de mise-à-jour automatique, mais au moins une vérification sur internet qui avertit quand on utilise pas la dernière version avec un lien à cliquer pour mettre à jour). Cette vérification serait bien sûr désactivable et surtout même avec option de compilation (car inutile pour les binaires installés par systèmes avec mise-à-jour, typiquement les distribs Linux). Cela permettrait aux gens qui mettent à jour très irrégulièrement les logiciels de retrouver un GIMP qui aurait changé de nom même des années après.
Hormis ce type de système, ou même plus, changer de nom serait totalement irresponsable envers les gens qui se retrouverait avec un logiciel non à jour et sans possibilité de trouver de la doc.
Le nom complet: GNU Image Manipulation Program
Le second point est que le nom n'est pas "gimp", ou "Gimp", mais bien "GIMP": il s'agit d'un acronyme et vous êtes libres d'utiliser le vrai nom pour ne pas à avoir à prononcer GIMP: GNU Image Manipulation Program.
Notons aussi qu'il n'y a pas d'article devant depuis GIMP 2.4, soit depuis 12 ans maintenant. Ce n'est donc pas "The GIMP" comme on le lit parfois mais bien "GIMP" tout court (je ne sais pas pourquoi l'article a été retiré mais je me dis que c'était peut-être justement pour s'éloigner de l'historique Pulp Fiction? Je n'étais pas là à l'époque…).
Ensuite bien sûr que "GIMP" est écrit ici et là, mais il est alors clair que ce n'est pas une insulte, ni rien du genre. C'est un acronyme.
Une évolution dans le bon sens
On dit aussi souvent que si vous faites une recherche web "gimp", vous ne tombez que sur des résultats en rapport avec le logiciel en première page (essayez! Me croyez pas sur parole). Ça ne parle pas de handicap, ni de sado-masochisme. Déjà cela rejoint le problème de la notoriété du logiciel que l'on casserait avec un rebranding mais ça veut aussi dire que notre logiciel a fait complètement dévié le sens premier de ce mot, qui était peut-être en effet insultant dans un sens plus ancien. De nos jours, parler de GIMP, même parmi des anglophones natifs, la plupart des gens pensent au logiciel. Beaucoup de gens disent donc qu'on a redéfini ce mot en lui donnant une connotation positive, et c'est une très bonne chose.
L'idée serait donc de se battre contre les mauvais usages d'un mot, non en donnant du poids aux sens négatifs du terme, ce qui donne surtout du pouvoir à ces mauvais usages, mais bien en les réutilisant dans des sens positifs. Beaucoup pensent donc que c'est quelque chose à encourager et par conséquent affirment qu'un renommage ne serait pas forcément une bonne idée.
Les autres arguments
Y a plein d'autres arguments contre l'idée du changement de nom. Déjà, comme je le disais, beaucoup de natifs eux-même affirment ne jamais avoir entendu cette insulte qui serait vraiment datée, et clairement dès que le sujet est abordé, il y a des gens dans tous les sens (on peut vraiment pas parler d'unanimité). On n'a aucune stats en vrai de l'usage de ce terme dans son sens insultant. Là on changerait donc un nom qui a 24 ans d'ancienneté, basé sur les dires de quelques personnes sans preuve concrète.
Ensuite y a la problématique du langage. Tout le monde n'est pas natif-anglais! Or même en parlant très bien anglais, la plupart des gens à travers le monde n'ont aucune idée des sens secondaires de "gimp", aiment le logiciel et le nom, et se demandent donc pourquoi ils devraient le changer pour satisfaire des anglophones.
D'ailleurs qui peut réellement prétendre faire un nom qui n'est offensant dans aucun langage du monde (par exemple certaines personnes relevaient que "dust" veut dire "idiot" en norvégien apparemment)? Ah! On me souffle dans l'oreillette que Glimpse a cette prétention. Je cite leur FAQ:
Alors soit ces gens sont de véritables génies méconnus, soit ce sont de fieffés menteurs. Tous les langages du monde? Sérieusement?
Y a aussi le fait que l'un des arguments principaux (en fait à la base, le seul argument) du problème était que ce terme offenserait les handicapés. Or à ce jour, je ne crois pas avoir vu (mais je suis loin de suivre tous les forums de près) le moindre handicapé confirmant cette affirmation. Par contre on a vu l'inverse. D'ailleurs même dans le rapport de bug d'origine, je citais le contributeur qui a pris part et répondait directement à une question "Are the developers members of the community who are called gimps? pour dire ben oui, au moins un l'est. Sa réponse est resté sans suite (mais avec quelques downvotes des gens qui n'aimaient pas qu'un contributeur puisse être handicapé apparemment! Un peu le monde à l'envers quand on nous accuse ainsi d'être insultant envers les handicapés). Donc à ce jour, il n'y a pas vraiment de preuve sûre que ce serait vraiment considéré comme un terme insultant par les handicapés.
Anecdote supplémentaire: un journaliste a fait un article sur ce fork (on notera que l'auteur est américain, né aux US et qu'il dit aussi qu'il ne connaissait pas non plus le sens péjoratif de "gimp" avant de tomber sur ce fork) a trouvé un projet d'une compagnie de danse américaine avec 4 danseurs handicappés et appelé "The Gimp project". Il soulève donc encore une fois que ce terme ne semble pas utilisé péjorativement ou mal pris par tous les handicapés en tous cas. Là encore une fois, on parle de plusieurs cas de natifs de la langue anglaise.
On notera aussi que ces personnes (du fork) affirment que les gens dans l'administration ou les universités/écoles américaines ne veulent pas utiliser GIMP à cause du nom. D'une part, on sait que c'est faux en règle générale. On a parfois des retours de gens qui l'utilisent en école américaine. On sait même que la NASA utilise (de temps en temps, y a des tweets ou similaire, souvent avec des cartes de satellites ou autre, et parfois ils citent GIMP). On sait aussi que certaines entreprises américaines proposent GIMP dans leur bibliothèque de logiciels autorisés/téléchargeable par le personnel (je me souviens d'au moins un retour à ce sujet qui nous disait que ce logiciel ne posait aucun problème pour leur entreprise US et qu'il était installable officiellement).
Ensuite oui, peut-être que certaines écoles/administrations refusent. Ceci dit, plusieurs fois quand une telle affirmation a été faite, on a demandé si la personne pouvait nous faire parvenir un document expliquant un refus par rapport au nom (et pas une autre raison), etc. À ce jour, on n'a jamais eu de retour. J'aimerais vraiment connaître le détail de ces histoires, pas du "et si", ni du "on m'a refusé, c'est forcément à cause du nom".
Je noterai enfin qu'en France par exemple, il n'y a aucun problème de ce côté là. Aryeom a enseigné GIMP à l'université (publique) en 2018-2019, et elle va redonner un cursus en 2019-2020. Elle a aussi fait un séminaire GIMP et animation au CNRS. Mais bon là c'est juste l'argument du langage: le fait que "GIMP" ne pose aucun problème en français. Mais c'est toujours un argument important car il n'y a pas que l'anglais dans le monde (certains semblent l'oublier).
La position
officielleofficieuse de l'équipe GIMP (bis repetita)En plus des points plus hauts, qui sont ceux de la FAQ de GIMP, il y a en fait d'autres choses, qui ne sont pas écrites dans la FAQ mais qui sont discutées sur IRC.
À ce jour, et pour autant qu'on le sache, personne n'est absolument contre un renommage. Je l'ai dit plus haut: ce n'est juste pas un truc à faire à la légère. C'est le principal problème. On se lève pas un matin en se disant "tiens, si je renommais GIMP"? Les gens derrière ce fork n'ont clairement aucune idée des implications et du travail derrière la maintenance d'un logiciel si complexe, et surtout des responsabilités qui viennent avec. Ben oui, on s'est créé des obligations! Même si on le fait pour nous et pour s'amuser, on est aussi conscient qu'on doit faire les choses avec un minimum de compatibilité et de respect des gens. Que ce soit ne pas casser une interface de programmation (pour les plug-ins) entre versions mineures et sans prévenir (des années en avance avec des avertissements de dépréciation à la compilation ou à l'exécution!), ne pas retirer des fonctionnalités même si on ne les utilise pas nous-même, ou autre chose, on fait vraiment attention.
Là pour le nom, je le disais plus haut, on ne perd pas juste la notoriété du nom, mais on fait se perdre les gens! Les gens qui chercheraient sur internet et ne retrouveraient plus GIMP (car il aurait changé de nom, et peu suivent les nouvelles des logiciels au quotidien), les gens qui ne peuvent plus mettre à jour et se retrouvent avec des failles dans une vieille version (car ils ne savent pas qu'il y a eu renommage ni où trouver le logiciel renommé), les gens qui cherchent de la doc et ne trouveraient plus 2 décennies de documentation et de livres publiés dans le commerce car ils ne sauraient pas que le logiciel X s'appelait GIMP juste quelques années auparavant. Etc.
Donc revenons à ce que je disais: personne n'est contre un renommage et on en a discuté plus d'une fois (et ce, bien avant ce rapport de bug qui a provoqué ce fork). À ce jour, notre idée favorite serait de fournir 2 versions de GIMP: GIMP et un autre nom (possiblement "GNU imp", qui pourrait se traduire par le lutin GNU et permettrait un bon jeu de lettres en gardant finalement la même base de lettres, mais sans jamais écrire "GIMP" seul). Peut-être même avec un seul installeur qui offrirait le choix des versions (nom originel ou nom "pour toute la famille/l'entreprise").
L'un des contributeurs a même essayé de faire un petit preuve-de-concept pour du renommage qui serait capable de renommer même les chaînes de caractère traduisible sans faire double de travail pour les traducteurs.
Voilà, c'est donc à quel point on n'est absolument pas hostile à une solution qui pourrait satisfaire tout le monde, bien au contraire. On est conscient du passif historique du nom (qui nous a été légué, on le rappelle) et même si on doute que la situation soit aussi horrible que ce que ces personnes affirment (GIMP est aussi beaucoup utilisé au Royaume Uni, aux US et dans tous les autres pays anglophones), on n'est pas contre une évolution. Mais ça doit être bien fait. Et ça prend du temps.
Mais alors pourquoi ces gens ont-ils forkés?
Le fork
Je vais donc raconter comment s'est passé le fork! Une personne a donc ouvert un rapport de bug (en fait en écrivant ça, je me suis rendu compte que le rapport a été rendu non visible par un admin GNOME, donc hormis ceux avec un compte GNOME, vous ne pourrez pas le lire malheureusement) pour changer le nom tard en soirée (soirée pour l'Europe de l'ouest du moins, ce qui est le fuseau horaire des principaux contributeurs de GIMP, dont moi; ce qui n'est pas un problème en soi… sauf que…), et en même temps a posté le lien sur plusieurs des gros sites de discussions (Hacker News, cross-posté sur plusieurs forums Reddit, dont le Linux, d'autres sites dont j'ai aucune idée, et surtout certains réseaux sociaux, etc. Apparemment on a été très attaqué sur la "communauté" Mastodon, paraît-il; d'ailleurs je me préparais justement à installer un serveur Mastodon pour notre association et j'ai mis en pause suite à cela, car j'ai pris peur de nous jeter dans la gueule du loup; ça m'a pas donné envie quoi 😕), clairement donc avec l'optique de rameuter des gens pour faire du forcing (enfin j'ai du mal à voir une autre raison à faire quelque chose comme ça).
Au final, le lendemain, au réveil, j'ai découvert un nouveau rapport de bug avec… 140 messages écrits dans la nuit (le rapport s'est arrêté à 187 messages quand un des admins de GNOME a décidé de fermer les commentaires, sans compter 5 messages dans un second rapport identique que quelqu'un a cru bon de faire pour appuyer la demande)! En plus comme j'ai configuré pour recevoir tout en email, imaginez ma belle boîte aux lettres électronique envahie ce matin là de 140 emails avant même mon premier café. Notons aussi qu'on ne parle pas de centaines de personnes, hein. D'un rapide coup d'œil, je dirais qu'il doit y avoir eu 10 personnes au plus qui ont participé et ont écrit tous ces messages.
Dans cette cohue, j'ai choisi de ne même pas participer. C'est un peu comme si y avait une manif de gens violents devant votre porte, criant tous en même temps des choses diverses et inintelligibles, pas forcément nombreux mais bruyants, et en tous cas, ça ferait suffisamment peur pour que votre première réaction ne soit sûrement pas de vous dire: je vais aller dehors et me mettre au milieu de la meute pour discuter calmement avec ces gens qui vont bien sûr répondre posément à mes arguments construits.
Non, Mitch, notre mainteneur, a eu la seule réaction possible dans une telle situation: il a fermé le rapport comme il aurait fermé sa porte à clé si des gens criaient devant sa porte. Franchement, même si on était 100% pour le changement de nom, y a pas d'autre chose à faire dans ce cas.
Notons qu'il n'y a eu aucune autre réaction d'aucun autre développeur (sauf Tobias qui a déclaré être lui-même boiteux, comme expliqué plus haut).
Néanmoins les gens s'emballent sur les méchants développeurs de GIMP. Puis au final, certains ont fait le fork. Ok pourquoi pas!
En tous les cas, c'est un début assez triste pour un logiciel qui veut se placer dans une optique "inclusive". Parce que ce qu'ils ont fait, si ce n'est pas considéré comme du harcèlement (187 messages en moins de 24h par une poignée de personnes, forçant au final un admin GNOME à intervenir), je me demande ce qui l'est.
Honnêtement j'ai même beaucoup hésité à écrire ce commentaire ici car ces gens ont montré ne vraiment pas être civil et clairement faire du ciblage de gens à attaquer. Et j'aimerais pas devenir une telle cible. Le harcèlement peut vraiment faire des ravages dans les contributeurs de logiciels libres et j'aimerais vraiment éviter en être victime.
Pour info, aucun des "développeurs" du fork n'a jamais contribué la moindre ligne de code à GIMP (à notre connaissance). Ce sont des parfaits inconnus jusqu'à ce jour, bien que certains étaient des contributeurs à d'autres projets GNOME a priori.
Par contre ils aiment bien dire partout qu'on est des gros méchants qui ne respectons pas les handicapés (y en a même qui ont annoncé vouloir reporter GIMP comme ne respectant pas le Code of Conduct de GNOME de par son nom insultant pour nous chasser de la plateforme; et après on nous parle d'inclusion…), et aussi que notre code est mauvais (ça je l'ai pas trop vu moi-même, il paraît que c'est les choses qui se disent dans leur canal de discussion; j'ai pas poussé le vice jusqu'à m'y connecter moi-même!). D'ailleurs ils disent dans leur fork qu'ils vont changer l'interface pour enfin implémenter des fonctionnalités beaucoup demandés, comme si c'était pas ce qu'on fait déjà au quotidien ou qu'on aurait refusé (pour info, on n'a jamais refusé de code de qualité pour aucune fonctionnalité; on a même intégré pas mal de code problématique en passant énormément de temps à corriger quand l'idée est bonne; quant à implémenter nous-même: on n'est pas des esclaves et on peut avoir nos propres priorités; ne pas implémenter quelque chose ne veut pas dire être contre, ni même qu'on ne l'implémenterait pas un jour; juste on ne l'implémente pas maintenant parce qu'on implémente autre chose qui nous botte plus d'abord).
Je rappelle qu'on est parfaitement conscient de plein de choses à améliorer et ça fait pas mal d'années qu'on fait que ça (améliorer). On a même un wiki officiel où on note pas mal de résultats de discussions, de spécifications, etc. au sujet du redesign progressif du logiciel. D'ailleurs ces gens en sont conscients et connaissent ce wiki, mais ils continuent à faire comme si on ne veut rien améliorer.
Mais bon soit, ils veulent parler technique! Ben techniquement, le fork ne nous impressionne pas. Je compte 8 commits en août, et c'est essentiellement des changements mineurs, genre README, ou mettre les dépendances en submodule (ils connaissent pas
pkg-config?). Pour comparaison sur GIMP master: 499 commits, 989 files changed, 111265 insertions(+), 71558 deletions(-) si mon git-fu est correct; et je parle de trucs super cool genre une méga-amélioration de l'API des plug-ins, la prise en charge de Python 3, JavaScript, Lua pour les plug-ins, et du travail en cours pour l'agrandissement automatique de calques, voire à terme des calques infinis. Ça ce sont les trucs principaux qui furent en chantier ce mois-ci chez GIMP, plus les machins en branche, genre l'animation comme fonctionnalité de base du logiciel.En gros ils ont l'air d'avoir du mal avec le code (et c'est normal, ça fait 7 ans, et je découvre toujours des choses!).
Alors si on regarde leurs rapports de bug, on voit qu'ils ont changé leur plan: ils ont décidé qu'ils allaient faire leur propre GUI dans un langage de script (en cours de choix) en parallèle à leur modification de GIMP. Uhuh. 🙄
Donc l'idée c'est que le code est trop compliqué pour eux (ce qui veut dire qu'il est mauvais, bien sûr!) et donc on se donne encore plus de travail!
Par contre, en parallèle, ils ont déjà créé un site web, et surtout une page Patreon. Je parle du jour même du fork. Leur première action, avant même d'avoir quoi que ce soit à montrer, c'est de demander des sous! J'oserais qualifier cela d'indécent.
J'adore aussi que dans leurs news régulières, ils arrêtent pas de dire qu'ils avancent énormément. Non parce que soyons sérieux, n'importe qui qui sait lire un log de développement peut voir qu'il n'y a pas grand chose à se mettre sous la dent (genre apparemment ils ont changé le thème par défaut, des trucs du genre). Et ils vont régulièrement sur les sites de news pour faire parler d'eux. En marketing, ils sont forts. Ça oui.
Mais personnellement pour moi, ils ont cumulé tout ce qu'il ne faut pas faire dans un rapport de bug, et tous les comportements à ne surtout pas avoir en société pour un travail commun agréable. Si on devait faire un livre sur "Comment contribuer à un logiciel libre", leur action pourrait être cité comme la liste de tout ce qu'il ne faut surtout pas faire.
D'ailleurs le jour où on fera finalement le renommage (ou la solution intermédiaire pour mettre tout le monde content), je refuserai d'avoir affaire à eux s'ils veulent essayer de faire comme s'ils en étaient l'origine (ce qui n'est pas le cas, soyons clair). Je ne fais pas du libre pour avoir du drame et ne veut pas travailler avec des personnes si malveillantes.
Voilà, c'est mon avis, et un peu celui de tous les dévs de GIMP, je pense.
Non. Ils sont venus, ont gueulés, nous ont pas laissé en placer une (c'était impossible dans ce type de conditions, comme dit plus haut), puis sont repartis tout heureux d'avoir pu prouver à quel point on est des méchants qui aiment insulter les handicapés.
Il n'y a absolument pas à s'inquiéter de ce point de vue là. Comme je l'ai dit précédemment, absolument aucune de ces personnes n'avait jamais contribué à GIMP, et je doute qu'ils le fassent jamais, même après un renommage officiel. Et comme j'ai dit, je suis pas sûr de vouloir avoir affaire à eux (en vrai, je suis un peu plus raisonnable que ça — j'exagère exprès — bien sûr que je regarderai un patch s'il est intéressant, mais j'attends d'eux qu'ils ne soient plus aussi violents si ce jour arrive).
Pour info, on a rien contre les forks. En soi, un fork n'est pas forcément mauvais. On a déjà essayé d'inviter les créateurs de certains forks. Par exemple, j'ai personnellement fait une invitation officielle au créateur de GIMP-painter pour venir discuter à Libre Graphics Meeting; ça inclue défraiement du transport d'où que cette personne soit dans le monde, ainsi que du logement pour 10 jours, ce qui permet aussi de faire un peu de tourisme, et même une bonne partie des repas étaient payés. Malheureusement cette personne n'a pas répondu. Un fork intéressant, idéalement on aimerait bien sûr que la personne derrière nous rejoigne et qu'on fasse un super logiciel ensemble, mais on est pas du tout contre dans l'absolu si cette personne préfère continuer dans son coin. Toutes nos invitations sont sans obligation (bien sûr, on invite en espérant pouvoir discuter, trouver une entente et pouvoir travailler ensemble, mais y a pas de contrat "si tu acceptes l'invitation, tu dois faire ci ou ça", c'est juste basé sur l'espoir d'avoir un bon feeling en se rencontrant).
De manière générale, chez GIMP, on a une vision assez communautaire du logiciel. Par exemple, on considère n'avoir aucun concurrent tout simplement car on n'est pas dans une telle logique de "concurrence". Ainsi on invite aussi régulièrement (ce qui inclue les défraiements) des développeurs darktable, ou même des contributeurs GNOME qui font des trucs cools autour du graphisme sous Linux, et cette année, on a invité le mainteneur actuel de MyPaint car il fait vraiment des trucs cools et on veut vraiment l'encourager (notamment car MyPaint semble dans une situation peu stable dernièrement et ce serait vraiment dommage si ça s'arrêtait), ce qu'on refera sûrement d'ailleurs. Moi je pense que tous ces supers logiciels peuvent vivre ensemble et quand certains crachent sur les autres, ce sont ces choses qui m'attristent.
Ce fork en particulier par contre, "Glimpse", il a été hostile du début à la fin. Et leur communication (plus active que le développement) est entièrement basée sur "dire du mal de GIMP et de son équipe", tout en affirmant le contraire dans des communiqués (genre dans la FAQ encore une fois, ils affirment être "de bons citoyens du Logiciel Libre").
Pour nous aussi, mais surtout pour tout ce que j'ai dit jusque là. Ensuite je ne cherche pas à suivre particulièrement ce qu'ils font, mais c'est assez dur de ne pas suivre un peu, car ils font vraiment campagne à fond contre nous, donc on les voit un peu partout et forcément on se met à cliquer des liens. 😕
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ergonomie
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Choix tablette graphique. Évalué à 8. Dernière modification le 26 août 2019 à 15:33.
Tout à fait. Si vous passez ~ 8h par jour, 5 jours par semaine, le coup plié, à dessiner sur papier sur un bureau, les problèmes sont les mêmes.
En fait c'est le même problème que celui de travailler sur un ordinateur portable, sans écran externe (ou simplement être sans cesse sur son téléphone ou sa tablette). On a le cou sans cesse tordu et ça pèse sur la colonne vertébrale. C'est juste mauvais pour le corps.
L'image vient d'un des premiers résultats sur le problème sur site de nouvelle quelconque, avec droits à surgicaltechnology.com apparemment
Alors selon les personnes, on peut le faire pendant des années sans problème. Voire certains vont peut-être parvenir à bosser une vie entière à temps plein sur ordinateur portable sans aucun problème. Je ne sais pas. Mais cela reste à déconseiller et beaucoup ont des problèmes médicaux rapidement.
Ensuite on peut dessiner sur une table à dessin/d'architecte, c'est mieux mais cela reste peu optimal (on continue à s'incliner, moins mais tout de même).
Origine: Wikimedia Commons, CC BY-SA 3.0 par Thamizhpparithi Maari
Le chevalet est effectivement idéal car le dessin se retrouve presque vertical, à hauteur de visage, donc on peut enfin se tenir droit. Ensuite comme certains le note, ce n'est pas adapté à toutes les techniques, et implique de dessiner/peindre sur support solide (ou bien de rajouter un plan solide derrière le support souple — par exemple papier tenu sur planche de bois avec des pinces pour faire tenir).
Origine: Wikimedia Commons, domaine public par Mrs Scarborough.
À ce moment, un autre problème se pose: la main est constamment en l'air, et non posée sur un bureau. Imaginez devoir travailler en tapant sur un clavier en l'air => ça fatigue.
Ceci dit, Aryeom me dit qu'en peinture, il y a des techniques pour ne pas trop s’abîmer. Elle a appris (comme probablement toute personne ayant appris le dessin professionnellement) à utiliser le bras, et non le poignet (ce qui est l'origine de gros problèmes de santé, ce que les gens qui tapent beaucoup au clavier connaissent bien aussi), tout en gardant les épaules peu contractées. C'est fatigant et ça implique de se reposer sur les muscles du bras. Mais cela reste la meilleure position pour le dessin de longue haleine. Néanmoins Aryeom note aussi qu'il reste un gros problème spécifique au dessin sur tablette-écran et qu'on ne retrouve pas avec les supports physiques. Dans la technique suscitée, qui utilise le bras et non le poignet, on va garder le poignet droit (si on casse le poignet, ça n'a plus de sens) avec le pinceau ou crayon tenu en l'air (mine en haut, comme si on tenait un marteau; cette comparaison vient de moi! Ahahah). Ce n'est pas pour tous les dessins, mais par exemple pour dessiner les grandes lignes. Or cette technique n'est plus vraiment possible sur tablette où on dessine avec un stylo. Pour dessiner ainsi sans casser le poignet, c'est possible même avec des crayons car les dessinateurs les taillent en longueur (je déconseille de tailler vos stylets numériques 😛 qui sont quand même vendu ~100€ pour les modèles pro! 😱 Je déconne pas). Sur ce point, le dessin sur ordinateur a donc bien un vrai souci d'ergonomie pour la santé des peintres numériques, car on sollicite trop le poignet, malgré les techniques de dessin classiques enseignées depuis des siècles. C'est un retard sur le dessin physique.
Sinon pour revenir à notre cas en particulier, on a succombé à la tentation de la tablette écran. On n'avait jamais eu ça jusque là, et il nous fallait essayer, même si on savait que ce n'était pas idéal ergonomiquement, ce qu'on disait déjà dans des vieux commentaires ici. Bon on a pris directement une grosse tablette-écran (24") parce que je pense que ça réduit les risques, justement parce qu'il est possible de changer l'inclinaison de cette tablette bien plus facilement (donc on peut se retrouver dans une situation proche du chevalet). Les petites tablettes écrans sont probablement le pire, car elle sont toujours posées sur le bureau (avec éventuellement un petit angle), jamais en face de soi.
Malheureusement l'expérience n'est pas terrible, comme craint. Notamment le support écran de Wacom coûte une fortune mais est super pas ergonomique (ironie, ils l'ont appelé "Ergo stand") parce qu'il a bien une position haute et une position basse pour lesquelles on peut changer l'inclinaison, mais il manque une position intermédiaire.
On voit bien le problème sur cette photo, où Aryeom s'était résignée à la position basse avec forte inclinaison, ce qui reste une position de travail toujours courbée (on est plus dans la situation "table à dessin" que "chevalet"):
Origine: Compte Twitter de ZeMarmot
Depuis ils ont fait un nouveau support écran qui a l'air bien plus flexible. À essayer… si on avait les sous… 😞
Comme Aryeom a des soucis au dos/épaules et est allée voir le kiné plusieurs semaines à cause de cela, on a cherché des alternatives. Dernièrement elle semble être relativement satisfaite d'une nouvelle position où elle met l'écran en vertical (en fait c'est surtout qu'ainsi elle obtient une sorte de position intermédiaire, par contre elle perd en dimension horizontale):
Origine: Compte Twitter de ZeMarmot
Le kiné aussi lui dit que c'est une bien meilleure position.
En conclusion, il faut rappeler que ces métiers du dessin sont de toutes façons des métiers très contraignants pour le corps. C'est aussi le cas pour les métiers non numériques, sur papier, etc. Ensuite selon le métier exact, ce sera pire ou non. Certains seront plus ou moins statiques (ici, c'est complètement statique: elle doit être à son bureau). Aussi certains métiers de design vont demander des choses plus diverses (on dessine moins), mais en animation, hors les périodes de pré-prod (script, storyboard, etc.), on est surtout dans du dessin pur et dur à la chaîne.
Donc la conclusion, c'est probablement qu'y a pas de solution miracle, mais faut surtout essayer de trouver le meilleur compromis.
Notons que j'ai aussi remarqué, en regardant des photos de bureaux d'autres dessinateurs, que certains utilisent les tablettes-écrans, même grandes, à plat, comme si ce n'étaient pas des écrans, en regardant un second écran (ce qui pallie aussi au gros problèmes des tablettes écran de mauvaise qualité colorimétrique, ce qui est malheureusement souvent le cas). Cela permet de travailler droit, en posant sa main (moins fatigant donc, même si le problème du poignet se pose toujours beaucoup), et j'imagine que le fait que la tablette est aussi un écran est utile des fois, quand on veut dessiner des détails. Je ne sais pas, c'est une supposition. Je ne suis pas certain en fait à quel point c'est avantageux (ou simplement un luxe inutile) d'avoir une tablette-écran dans ce cas, et pourquoi ne pas simplement se limiter à une tablette normale.
Bien sûr le problème principal de ce choix ergonomique est le coût. Ces tablettes écran coûtent déjà une fortune. Les bons écrans graphiques pro coûtent aussi super chers. Sans compter qu'il faut alors un grand bureau pour mettre tout ça… 😓
P.S.: beaucoup de choses dites ici sont aussi valable, dans une plus ou moins grande mesure, à tous les métiers de bureau, et en particulier sur ordinateur. Les tendinites, les problèmes de main, de dos, de cou/épaule, etc. se retrouvent dans tous ces métiers.
P.S.: je me permets de rappeler que je ne fais que paraphraser/rapporter les connaissances et expériences d'Aryeom. Je ne suis pas dessinateur moi-même. Des erreurs peuvent éventuellement se glisser ici ou là même si je crois avoir plutôt bien réussi à rapporter les infos.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Quelles solutions ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien Du choix des couleurs des résistances pour le matériel informatique, invisibles aux Daltoniens !. Évalué à 6.
Je suis d'accord que son article est pas très constructif.
Comme d'autres ont notés dans diverses réponses: ça n'existe pas! En tous cas, pas à ma connaissance.
Déjà parce que distinguer les couleurs, c'est pas facile (en général). Même chez les non-daltoniens! Que ce soit à cause de la lumière ambiante (ou éblouissante, ou au contraire trop faible, ou lumière fortement teintée, etc.), ou bien simplement par aptitude/entraînement ou simple différence entre chaque personne. Il m'arrive régulièrement de ne pas distinguer des différences entre certaines couleurs sans être daltonien.
Ensuite parce que même chez les daltoniens (ce qui a aussi été dit), y a plusieurs types de daltonisme. Wikipedia déjà m'en cite 7! Et ce sont des daltonismes vachement différents (je vais montrer plus bas).
Les "solutions" donc?
Utiliser la position dans les standards, comme le propose Benoît Sibaud plus haut, me semble en effet une très bonne idée. D'ailleurs c'est marrant mais dans d'autres pays, on utilise parfois d'autres couleurs pour les feux de circulations, voire on utilise les mêmes couleurs mais appelés différemment. Au Japon/Corée, le vert, ils disent souvent qu'il est bleu par exemple! Comme quoi, la couleur n'importe pas trop dans ce cas comparé à la position.
Ensuite (ce qui a aussi été dit, notamment par toi-même): utiliser les formes/dessins. C'est bien pour certaines choses, mais de même que pour les couleurs (même pour ceux avec vision "standard"), cela a ses limites, je trouve. Hormis si c'est pour reconnaître juste quelques cas différents.
Ou même tout simplement écrire! En toutes lettres, compréhensibles par tous (même les non-voyants si c'est dans un format parsable par une machine).
Enfin d'après moi, il n'est absolument pas gênant d'avoir des versions non-lisibles par un groupe à handicap, du moment qu'on a une alternative. Par exemple, le cas Arduino plus haut me semble totalement mauvais à partir du moment où:
On s'en fiche que c'est pas le cas ailleurs. C'est le cas ici, donc il n'y a aucun problème à cette image selon moi. On ne va pas s'arrêter de faire de jolis images aux jolies couleurs (voire aux couleurs réelles ici) parce que certains handicaps ne permettent pas de les voir idéalement! Du moment qu'il y a une alternative, c'est ok.
De même que les non-voyants ne nous demandent pas de ne plus faire d'images, simplement d'y ajouter un alt texte compréhensible, ou de ne plus faire de vidéos, mais d'avoir soit une audio adéquate (bon si c'est un documentaire par exemple, pour une fiction, c'est plus dur!), soit des sous-titres parsables.
De même que les sourds ne nous demandent pas d'arrêter les vidéos non plus, mais ils veulent des sous-titres (avec bruitages inclus si possible).
Etc. etc.
Il est donc important de considérer les daltoniens, mais pas en essayant d'adapter toute couleur à tous les daltonismes possibles (ce qui me paraît impossible), mais bien en ayant des alternatives.
Pour les codes couleurs des résistances, cela me paraît complexes, mais je pense que simplement écrire en toute lettre me paraîtrait l'alternative la plus simple et la plus infaillible (au moins aux daltoniens; pour les non-voyants, c'est encore autre chose). Ce serait écrit en petit, mais après tout, les électroniciens ici disent utiliser une loupe, ou tout simplement un ohmmètre (et rien qu'avec cet instrument, finalement qui s'intéresse aux codes couleurs?).
Enfin, si vraiment vous faites une image avec des couleurs que vous voulez absolument différenciables pour tous, tout logiciel d'imagerie a des outils pour simuler différents handicaps de couleur. GIMP et Scribus au moins le permettent (pour 3 des types de daltonisme: protanopie, deutéranopie et tritanopie; Scribus a aussi l'option "Full color blindness", je suis pas sûr, mais ça correspond peut-être à l'achromatopsie; tous ces mots savants venant de Wikipédia!).
Les résultats sont différents cependant entre Scribus et GIMP. Je ne sais pas vraiment qui a raison. En fait j'ai l'impression que Scribus implémente l'absence totale de certains récepteurs alors que GIMP implémente seulement une insensibilité partielle (ex: Protanopie vs. Protanomalie, cf. toujours Wikipédia).
Voilà à quoi ressemble le tableau des bandes couleurs de l'article avec les simulations de daltonisme de GIMP et Scribus:
La conclusion à tout cela est qu'il n'y a pas de réponse miracle et trop de différences entre les gens et les déficiences visuelles de base. Donc je doute qu'il ait de réponse magique "quelles couleurs choisir?"
Par contre, toujours avoir des versions alternatives qui reviennent aux bases, l'une des bases étant l'écriture selon moi, car cela peut se comprendre avec la plupart des handicaps si on a les outils adaptés (qu'on soit sourd, non-voyants, daltonien, etc. si c'est écrit dans un format standard, il doit y avoir moyen de vous faire passer l'info).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment assurer un mécénat de qualité ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Appel à projet libre pour la campagne de mécénat 2019 de Code Lutin. Évalué à 3.
Ben non. S'il y a partage de copyright en GPL, personne ne peut changer la licence. Ça en reviendrait à avoir le droit de décider pour le travail d'autrui.
Cela n'est possible que si les changements des autres détenteurs de droits sont suffisamment petits pour ne pas être considérés comme une œuvre de l'esprit originale. En gros si les autres contributeurs ont juste contribué des corrections de bugs simples ou des changements vraiment triviaux. Donc ils pourraient ne pas être considérés co-auteurs par un juge.
Alternativement celui qui voudrait changer la licence devrait soit se débarrasser de fonctionnalités contenant du code d'autrui soit en réécrire l'implémentation.
C'est bien pour cela que les changements de licence sur les gros projets copyleft (GPL, etc.) sont si complexes (à dessein!) et la raison pour laquelle des organismes développant du Libre demandent parfois de signer des contrats de cession de droits d'auteur (pour pouvoir à tout moment relicensier, notamment pour des entreprises qui voudraient faire du double licence).
Personnellement je suis un des gros détenteurs de droits sur GIMP (même si c'est juste quelques pourcents en relatif, ça reste beaucoup en absolu) et j'ai absolument aucun droit d'en changer la licence. Même le mainteneur qui détient vraiment plus de droits après plus de 20 ans à développer GIMP ne pourrait relicensier. Et c'est bien!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: .
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.10 : « c’est dur de colorier ! ». Évalué à 8.
Tout à fait! Ma formulation était clairement un peu hasardeuse et cette phrase résume bien ce que j'entendais dans mon commentaire:
Le travail est techniquement le soutien au développement de G'MIC (qui est d'ailleurs aussi un logiciel Libre, et pas des moindres, rappelons le!) et c'est bien ce que je fais. Cela a simplement été fait de manière qu'on s'y retrouve tous, notamment moi aussi dans mes buts personnels (ZeMarmot et GIMP), mais "développer GIMP" n'est pas le but de mon poste en effet. C'est seulement un effet collatéral non négligeable. 🥳
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Plusieurs questions
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNU Guix version Un‐Point‐Zéro. Évalué à 3.
Ok.
C'est un runtime GNOME. À ce jour, y a au moins 3 runtime majeurs: Freedesktop (assez simple avec peu de dépendances), KDE et GNOME (tous deux basés sur le runtime Freedesktop auquel ils ajoutent des dépendances assez classiques dans les logiciels KDE ou GNOME). Ils sont bien sûr défini quelque part:
Ensuite oui dans un runtime, y a très probablement plus que nécessaire. Ça part évidemment du principe qu'un runtime est utilisé par de multiples applications et permet au contraire de partager la charge (construction des dépendances, téléchargements, espace disque, maintenance et mises à jour, etc.). Mais bien entendu si GIMP est le seul flatpak installé, ça aura l'effet inverse (ça fait installer beaucoup inutilement).
Les mainteneurs de ces runtimes chez GNOME, KDE, etc.
C'est un cas particulier car GIMP utilise encore GTK+2. Il y a encore pas si longtemps, GTK+2 était inclus dans le runtime GNOME, et on avait pas besoin de le définir dans le manifest/compiler dans notre flatpak. Ça a changé avec la version 3.30 du runtime, où ils ont décidé de ne plus inclure la version 2. Ça a du sens si on considère que la plupart des logiciels n'utilise plus GTK+2 qui est vraiment en fin de vie, et donc ça sert à rien de l'avoir par défaut.
Dans le cas cité, oui, retirer GTK+2 du runtime a un prix. Dès que quelqu'un aura au moins 2 applications basés sur GTK+2, alors il y aura duplication. Je pense personnellement que les mainteneurs du runtime ont retiré GTK+2 un chouille trop tôt, car il y a encore plusieurs applications très répandues basées sur GTK+2 (ne serait-ce que GIMP, qui est tout de même le flatpak le plus téléchargé de tout le dépôt flathub).
Ensuite c'est toujours une décision difficile à évaluer: quand retirer une vieille dépendance pour essayer de pousser les développeurs d'application à se mettre à jour?
Mais dans le cas d'une dépendance qui est dans le runtime dont un flatpak dépend, il existe en une unique version pour tous les logiciels basés dessus.
Notre flatpak stable est ainsi un exemple typique d'un logiciel avec une longue histoire et un peu de dette technique. Ainsi on doit se taper en effet l'ajout de GTK+2 mais aussi d'autres technos liées, comme ibus-gtk2 ou webkitgtk (v2!), du Python 2 (et pygtk 2). Notre flatpak de développement est bien plus simple (GTK+3, Webkit récent, etc. dispos dans le runtime GNOME).
Pareil pour flatpak. Un runtime est constitué d'un ".Platform" et d'un ".Sdk". Le ".Sdk" comprend en addition les dépendances de compilation et n'est pas téléchargé par les gens qui n'ont que besoin d'exécuter.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Gimp support
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.10 : « c’est dur de colorier ! ». Évalué à 9.
Malheureusement ce n'est pas nous qui décidons cela. Très peu d'associations du libre (même les plus grosses) ont obtenu cela. 🙄
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Plusieurs questions
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNU Guix version Un‐Point‐Zéro. Évalué à 3. Dernière modification le 25 mai 2019 à 13:25.
Avec flatpak aussi c'est possible. :-)
Ce résultat de commande indique le commit actuel du flatpak de GIMP (avec le message de commit, ici "Update to GEGL 0.4.16.") ainsi que le commit parent (le dépôt flathub garde une dizaine de versions précédentes de chaque paquet). Il est possible de remonter dans les vieux commits:
Et enfin si je veux, je peux installer une vieille version de GIMP:
flatpak update --commit=5c8a3dc204a12d4695c5bb7e98ea3b3862d78e52c1cf0f9b021c1dae836ecc95 org.gimp.GIMPPour info, je veux pas avoir l'air de faire mon lourd à toujours vous comparer avec flatpak. C'est simplement que c'est le seul aussi système de paquet/conteneur que je connais bien. Donc j'essaie juste de comprendre les différences entre guix et flatpak parce que je connais pas grand chose d'autre dans cette catégorie. Bien sûr je pourrais aussi juste tester guix mais bon… comme tous, mon temps est limité, et je peux pas prendre trop de temps maintenant pour suivre de longues instructions d'installation (j'ai bien regardé le lien donné, mais quand j'ai vu la longue série de commande pour l'installation dite binaire, je me suis dit "un autre jour"; désolé!), j'espérais plutôt un truc basique (🛌 lazy mode). Alors j'essaie d'avoir déjà une première idée de base juste en discutant. ;-)
Et pour le coup, d'ailleurs, je suis toujours pas sûr des différences, hormis que guix recompile localement par défaut avec installations binaires optionnelles (avec flatpak, c'est l'inverse; c'est très facile de recompiler un flatpak: ça se fait en une commande à partir du fichier manifest, mais par défaut on privilégie une installation d'un binaire sur un dépôt).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Plusieurs questions
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNU Guix version Un‐Point‐Zéro. Évalué à 2.
Dans flatpak, on utilise aussi juste un manifest qui dit où trouver le tarball (avec un checksum pour vérifier) ou bien un dépôt (avec un commit). Si c'est un projet qui utilise un des systèmes de compilation classique (autotools, CMake, meson…), on dit quel système c'est et c'est bon. Éventuellement on peut ajouter des options à appliquer à l'étape de compilation.
Ça me semble plus proche de guix tel que tu le décris que de docker. :-)
J'ai cherché un peu dans votre dépôt, le manifeste de GIMP me semble être ça, celui pour flatpak est ça.
C'est assez similaire! :-)
Ah ok, donc un
guix installrecompile le paquet par défaut. C'est pas idéal selon moi pour les utilisateurs finaux. Fournir des binaires devrait être la norme pour un système de paquets (avec bien sûr la possibilité de reconstruire le paquet pour comparaison binaire, reproductibilité, etc. C'est très cool, je dis pas que ça devrait pas être possible, je parle juste point de vue de celui qui veut juste installer GIMP). Je dis ça, j'adore Gentoo (je l'ai utilisé quelques années en distrib principale). Mais de nos jours, je veux juste pas me prendre la tête, faire confiance à des gens et ne recompiler moi-même que les logiciels que j'ai besoin de hacker. Ensuite ce n'est que mon avis et mon conseil (qui vaut ce qu'il vaut, c'est à dire pas forcément grand chose) aussi pour que cette technologie prenne sur le grand public. 😛À moins bien sûr que guix est destiné aux développeurs seulement, mais je crois comprendre que vous voulez aussi que ce soit considéré comme un système de paquets pour tous.
Ok. C'est intéressant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Nouvelle version ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.10 : « c’est dur de colorier ! ». Évalué à 6.
Oui ce sont des améliorations par rapport à 2.10.8. Depuis GIMP 2.10.0, on autorise de nouvelles fonctionnalités, même lors de sorties macro. Et on s'en prive pas! :)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Gimp support
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.10 : « c’est dur de colorier ! ». Évalué à 10.
Quand tu donnes à "GIMP", tu donnes de l'argent pour une utilisation communautaire. En gros GIMP n'existe pas. Il n'y a pas vraiment d'entité derrière, ce pourquoi GNOME nous sert aimablement d'entité parapluie. L'argent donné à GIMP sert donc notamment à défrayer nos rencontres annuelles (à Libre Graphics Meeting en particulier) et à financer diverses actions communautaires. Comme GIMP a des rentrées décentes de donation, nous redistribuons aussi pas mal. Par exemple, on est l'un des rares projets qui est capable de défrayer complètement ses contributeurs à Libre Graphics Meeting, et tous les ans, on héberge aussi gratuitement des contributeurs d'autres projets (je me souviens de gens de GNOME Photo, de la fondation GNOME, de Kdenlive, etc.). Comme on considère cet évènement (Libre Graphics Meeting toujours) comme important pour l'écosystème du graphisme libre, on l'a sorti plusieurs fois de la panade en donnant des sous (parfois beaucoup), notamment pour les années où l'organisation n'avait pas assez pour payer ce qu'elle devait; et même au moins une fois (de ce que j'en sais), on a payé le défraiement de voyage d'une majorité des contributeurs, tout projet confondu. Enfin très régulièrement, GIMP offre un évènement communautaire à l'ensemble du Libre Graphics Meeting (genre une soirée dans un bar, avec tournée aux frais de GIMP!).
En anecdote, y a aussi eu une année où l'organisation avait mal géré l'enregistrement vidéo, et on allait se retrouver sans traces des confs, ce qui aurait été très dommage. On avait donc acheté une caméra vidéo (aux frais de GIMP, à l'arrache) pour au moins enregistrer communautairement les conférences (de mémoire, un truc du genre); et cette année notamment on finance encore l'enregistrement des conférences en vidéo.
Bon je connais pas tous les détails car je n'ai pas géré l'argent de GIMP jusque là (donc pardonnez moi si j'ai dit une bêtise sur une des anecdotes, ce n'est pas impossible; mais ça donne l'idée de comment l'argent de GIMP peut être utilisé, de toutes façons), mais c'est en gros l'usage qui est fait des donations. C'est vraiment un usage communautaire car on estime que le graphisme Libre, c'est pas que GIMP et qu'on doive aussi aider les autres projets. Note que ce n'est pas quelque chose dont on fasse particulièrement la pub (à tel point que même moi, au cœur du projet, je ne me tiens pas au courant des détails). On est juste content d'aider. :-)
Un autre usage non négligeable est l'achat de matériel pour les contributeurs (moins fréquent que l'usage communautaire qui est annuel, pour le coup).
Donc est-ce qu'on touche des sous? C'est utilisé pour nous faire nous rencontrer annuellement, mais cet argent n'est pas pour nous personnellement, non. Ça ne m'a jamais permis de vivre par exemple. GIMP ne peut pas nous donner de sous, ni en particulier faire de salaire (pas d'entité, je rappelle).
Quand tu donnes directement aux développeurs, là oui tu es sûr que cet argent va aux développeurs pour leur travail. Ensuite nous ne sommes que 2 développeurs (sur 4, si on considère les 4 gros développeurs de GIMP/GEGL/babl qui font la majorité du travail) qui ont organisé une vie professionnelle autour du Libre: moi (avec le projet ZeMarmot, c'est le côté GIMP même, et à ce jour, je suis historiquement le troisième plus gros contributeur de GIMP en nombre de commits) et Øyvind Kolås (le mainteneur de GEGL). Donc ça ne finance pas tout le monde (certains ne cherchent pas à être payés pour GIMP, comme le mainteneur qui a un emploi autre et ne contribue que dans son temps libre). Mais par contre, ça crée de vrais salaires (je ne sais pas comment le mainteneur de GEGL s'est organisé, mais de notre côté, l'association LILA crée de vraies fiches de paie pour financer le film ZeMarmot, et donc pour le développement de GIMP; donc là oui, on en vit, clairement).
En conclusion, donner au projet GIMP, c'est pour l'aspect communautaire du projet. Donner à un contributeur (ou au projet qui le chapeaute, ZeMarmot dans mon cas), tu nous finances nous directement. Ça nous permet de vivre. C'est bien simple, il n'y aurait pas le projet ZeMarmot, je n'aurais jamais été en capacité de faire ce que j'ai fait jusque là. J'aurais probablement dû trouver un job "alimentaire" quelconque et aurait contribué un pouillème de ce que j'ai contribué à ce jour. Je n'aurais pas non plus été remarqué par le CNRS qui n'aurait alors pas décidé de m'engager personnellement, avec accord de principe que mon travail serve essentiellement dans les intérêts parallèles du CNRS (tester/implémenter des algorithmes et promouvoir le travail de recherche du CNRS) et de ZeMarmot/LILA (améliorer GIMP, le Libre en général et aider à notre travail de graphisme/animation). C'est à dire que le CNRS paie en ce moment du développement dans GIMP, avec de l'argent public, tout ça parce que ZeMarmot est devenu suffisamment visible pour leur faire de l'œil.
Donc j'ai envie de te dire que c'est bien de donner à LILA/ZeMarmot, mais forcément je prêche pour ma paroisse. C'est donc totalement biaisé. :P
Disons que c'est de l'argent direct pour du développement concret dans GIMP, surtout que le projet ZeMarmot est encore loin d'être stable et on n'est jamais complètement sûr si le projet sera en capacité de continuer, même un an de plus. C'est un équilibre plus que précaire et assez dur pour les nerfs.
Il y a aussi un autre aspect très positif dans le développement qu'on fait à LILA: on aime améliorer les logiciels libres dans une démarche concrète. On fait un vrai projet, avec des vrais pros du graphisme. On ne développe pas pour développer sans se demander si notre code est utile ou même simplement utilisable. Quand je fais de la merde, je peux assurer que notre artiste me le dit directement que mon super code, dont j'étais trop fier, est juste pas utilisable dans la vraie vie. Et donc je cherche des solutions, j'essaie de faire une interface adapté, de revoir mes a-priori, et ainsi de suite. Perso c'est un truc que j'adore. C'est pas de la "preuve de concept". C'est une preuve d'utilisation. C'est là où je pense que notre association, LILA, est vraiment super utile pour faire de GIMP un logiciel pro. Et c'est dans nos statuts de faire de vrais projets (libres eux-même, nos films étant visibles par tous sous licence Creative Commons by-sa, et même les données téléchargeables quand le projet finit, cf. par exemple nos données pour le film Peertube qu'on a fait pour Framasoft). On a mis les projets en premier dans nos objectifs, dans les statuts d'association, c'est fait exprès. C'est ainsi d'après nous qu'on fait les meilleures avancées (on ne crée/promeut pas le logiciel libre pour lui-même mais bien parce qu'il est utile, utilisable et utilisé).
Ensuite soyons clair, c'est aussi super important de donner à GIMP en tant que projet communautaire. C'est grâce à ça que je suis devenu un gros développeur moi-même. La première fois qu'on m'a invité au Libre Graphics Meeting (alors que j'avais juste une petite série de patchs à mon actif et était donc un petit contributeur), j'ai trouvé ça super cool. Puis ça m'a permis de rencontrer les autres et de sympathiser, ce qui a renforcé l'aspect "entre potes". Sans ça, je suis persuadé que je n'aurais pas décidé de m'impliquer davantage (à l'époque, je faisais juste des patchs par ci par là à divers projets en fonction de problèmes que je rencontrais, c'est tout; en l'occurrence, j'avais eu des bugs dans GIMP et avais juste décidé de les corriger pour mon utilisation propre; jamais je n'aurais imaginé être un jour l'un des développeurs principaux de GIMP, et l'un de ceux qui font les décisions cruciales sur la direction du projet), puis de co-créer le projet ZeMarmot pour faire un film qui me plait tout en développant du Libre, etc. Donc l'aspect communautaire est aussi super important. Ça fidélise les développeurs et la communauté, ça développe les échanges et les relations amicales, ça donne de l'importance à toutes les contributions, même les petites, etc.
Simplement je me fais moins de souci de ce côté là, car je sais que GIMP a pas mal de fonds, n'a pas de problèmes financiers (et n'en aura sûrement pas dans le futur non plus), alors que nous, on galère un peu. J'aimerais beaucoup qu'on atteigne enfin un jour un état financier stable pour notre projet, qui puisse financer non seulement mon développement et le travail de notre réalisatrice, mais aussi d'autres développeurs et d'autres artistes, quitte à reverser nous-même dans l'aspect communautaire au besoin.
Voili voilà. J'espère que c'est plus clair. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Plusieurs questions
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNU Guix version Un‐Point‐Zéro. Évalué à 4.
1) Quels sont les similitudes et différences avec les technos flatpak ou snap? Genre vous parlez d'environnement indépendants, de conteneurs, etc. C'est du sandboxing avec des permissions, etc.?
En outre y a-t-il un serveur/dépôt Guix de référence? Quand on fait un
guix searchouguix install, ça installe depuis un dépôt unique? Quelqu'un peut créer son propre dépôt? Qui crée les paquets?J'aurais bien testé un
guix install gimpmaisguixne semble pas dispo sur Fedora. ;-(2) À croire que ça s'adresse à moi! 😛
Bon perso j'installe les dépendances de GIMP en quelques minutes et j'ai mon propre outil pour me créer mes environnement de développement (
crossroad). Je me crée mes builds de GIMP indépendants en quelques secondes. Mais c'est intéressant de voir des alternatives. On aimerait bien en savoir plus sur ce que fait ceguix environment gimp. Notamment ça semble dire que ça installe aussi toutes les dépendances pour pouvoir compiler GIMP (ce que ne fait pas mon outil). Pour le coup, je veux bien plus de détails. On reste un peu sur sa faim!Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Inscriptions
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Le Libre Graphics Meeting 2019 fin mai à Sarrebruck. Évalué à 4.
Pour compléter: historiquement l'inscription n'est pas obligatoire à LGM. Néanmoins s'inscrire en avance permet aux organisateurs d'avoir une idée du nombre de personnes qui seront présentes et ainsi de s'organiser (mieux) en conséquence. 🙂
Et oui, les confs sont en anglais. Je me souviens de cas où des locaux ont fait des confs dans la langue locale, mais cela reste des cas exceptionnels et ces confs ont eu peu de succès à cause de cela (car beaucoup de non-locaux ne pouvaient tout simplement pas comprendre, pas parce que ce n'était pas intéressant), donc la norme reste plutôt de tout faire en anglais.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Entropie
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Améliorer la définition d'une photographie.. Évalué à 6.
Je crois que vous vous prenez tous la tête. Bien sûr que ces réseaux de neurones n'ont pas plus d'informations sur la "réalité" de l'image. Mais c'est quoi la réalité? En photographie, ou en imagerie artistique de manière générale, le but est d'avoir une bonne image finale. Quand ce sont des images représentants la réalité, le terme employé généralement est "crédibilité". On veut surtout une belle image crédible, pas forcément réaliste.
Pour en revenir donc à la demande initiale, Stinouff vous dit qu'il a testé ce site et que ça lui a donné des bons résultats, et vous venez tous lui faire la leçon que c'est pas possible de créer des informations qui n'existent pas alors qu'il a eu des résultats probants, là en vrai devant ses yeux! Et oui, vous avez raison dans la théorie (on ne crée pas de l'information à partir de rien), mais dans la pratique, ces algorithmes basés sur des réseaux de neurone y arrivent bien. Certes ces données créées viennent de l'apprentissage avec d'autres images. Certes ce n'est donc "pas la réalité". Mais même l'image originelle est-elle la "réalité"? J'ai lu suffisamment d'articles de photographes ou vu de confs de photographes qui expliquent que la photographie n'est pas la réalité pour affirmer que "non", ce n'est pas la réalité (au point qu'il y a des articles Wikipedia sur le sujet!). La photographie n'est pas la réalité donc déjà à la base, vous basez votre argumentation sur quelque chose de fragile. :-D
Perso je n'ai pas testé ce site car je n'ai pas envie de faire un compte et d'y balancer plein de photos persos, mais je n'ai pas de doute que c'est possible d'agrandir en gardant un résultat crédible. Les algos dits de "Super Resolution" sont très à la mode depuis plusieurs années, y a pleins de papiers de recherche sur des solutions diverses et a priori l'usage de réseaux de neurones sont une des solutions communes. Vous pourrez voir plein d'exemples sur des centaines d'articles sur le web qui montrent des résultats parfois impressionnants. Ça peut donner des résultats crédibles dans certains cas, c'est un fait. Faites juste une recherche sur le sujet.
Bon et maintenant pour faire une réponse à Stinouff: malheureusement, je ne crois pas qu'il existe une solution libre simple à mettre en place à l'heure actuelle pour la super résolution. En tous cas, pas dont j'ai entendu parler. :-/
En fait de ce que j'en ai compris, ce qui marche le mieux pour l'instant, c'est les réseaux de neurones, avec beaucoup de couches. On en arrive à avoir un modèle qui fait plusieurs GB. Pour une application de bureau, plusieurs GB à garder en mémoire juste pour faire tourner son algorithme (plus l'OS, le programme, l'image d'entrée, de sortie, etc.), c'est assez contraignant. Sans compter l'espace disque. Imaginez si GIMP par exemple faisait 10GB à l'installation sur votre disque (et si on se mettait à avoir plusieurs filtres utilisant des réseaux de neurones, ça pourrait grimper vite). Ce serait un problème!
Voilà, donc de ce que je comprends, ce serait le principal problème à ces algorithmes de nos jours. Technologiquement ce n'est pas forcément très complexe, et les papiers de recherche sont en général publics, donc implémentables. En plus on a des logiciels libres pour entraîner des réseaux de neurones (on lit parfois sur le sujet sur linuxfr). Donc y a pas grand chose techniquement qui empêcherait d'avoir ça si ce n'est que ce n'est pas pratique à utiliser. Et ça explique pourquoi la plupart des implémentations de nos jours sont des gens qui font tourner leur réseau sur un serveur qui ne fait que traiter des images à travers ce modèle, avec un business model consistant à faire payer les gens pour y uploader leur photos et obtenir un résultat.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Exemples concrets?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 10.
Hmmm… tout de même avec toutes les précautions que j'ai prises, cette réponse arrive quand même à être pas mal sur la défensive! Je pense avoir suffisamment expliqué que j'étais ouvert aux nouveautés. Et dire que j'aime bien/suis efficace avec
gitne signifiait absolument pas que je ne veux pas de Pijul ou que ce n'est pas pour moi. Si c'est le cas, aurais-je vraiment écrit un super long message super diplomatique qui m'a pris du temps?Peut-être serais-je encore plus efficace avec Pijul, qui sait! Ce n'est donc pas antithètique (être efficace avec git vs. Pijul est pour moi? Aucun rapport, fils unique!). 😛
Ok j'avais loupé ça, c'est intéressant, merci. L'exemple aurait mérité d'être recopié avec un joli formatage dans la dépêche, en bien placé. D'un seul coup on comprend beaucoup mieux et tu te serais évité pas mal de discussions, je pense!
C'est pour moi 100 fois plus explicatif que tous les mots mathématiques ou que les détails sémantiques (genre définir prouvé "scientifiquement" vs "mathématiquement"; désolé mais bon… 😛).
Encore une fois, un exemple concret ne serait pas de refus (tes 3 points ne sont pas des exemples concrets pour expliquer un tel usage). En un exemple, le coup de l'associativité est devenue concrête en 2 minutes de lecture (évitant ainsi de longs débats sur linuxfr). Ça vaudrait le coup de faire pareil avec la commutativité, non? :-)
Tiens là par exemple j'ai vraiment du mal à comprendre ce que tu me dis. Comment la branche peut-elle être rebasée sans demande explicite? Comment sait-elle sur quelle autre branche elle doit l'être? Et si je veux pas rebaser? Enfin bon là comme ça, ça me paraît juste magique. Ensuite y a sûrement une logique que je ne pige pas. D'où: un exemple concret serait utile.
Mais tu le retires-retires? Il n'est plus disponible du tout, plus de trace dans l'historique (genre pas comme un
git revertoù tu annules l'action du commit sans retirer dans l'historique)?C'est tout de même assez tendancieux de permettre la réécriture à volonté (pour les branches publiques, notamment communément celle appelée "master" dans
git). Et ce n'est pas seulement car on casse l'historique dansgit(les hashs de commit qui ne sont pas cassés dans Pijul, j'ai bien compris cette partie!), mais bien aussi car réécrire l'histoire, c'est perdre des informations. Aussi les gens avec un vieux hash de commit ne peuvent plus le retrouver. Les seuls cas considérés comme acceptables sont normalement lorsqu'on a "commité" des infos méga-confidentielles par erreur (et encore… en général si on a fait ça, il faut surtout considérer que c'est trop tard cas on ne sait pas qui en a pris connaissance; donc réécrire l'histoire ne sert en général à rien, même dans ce cas, à part limiter les dégâts éventuellement le temps de changer les infos fuitées à la source).C'est un truc que tu as répété plusieurs fois dans tes commentaires. Et c'est aussi écrit dans la page "Why Pijul". Mais ça veut dire quoi concrêtement une "vraie représentation interne des conflits", pour nous autres simples développeurs qui veulent juste versionner nos sources?
⚠ Je ne te demande pas de me le réexpliquer avec d'autres mots, et surtout pas des termes mathématiques! ⚠
Encore une fois, un exemple concret vaut tous les discours. Genre un copier-coller du résultat d'un conflit de merge, et comment il est corrigé par le développeur qui utilise Pijul (genre le workflow avec les diverses commandes Pijul; qu'est-ce que le dév voit dans ses fichiers? comment les modifie-t-il? etc.). Ça, je pense que je comprendrais. :-)
(et cette fois j'ai bien regardé si j'ai pas loupé un lien sur la page "Why Pijul? qui donne un tel exemple; et il me semble que non, ou alors c'est bien caché!)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Exemples concrets?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 10. Dernière modification le 27 avril 2019 à 17:09.
Coucou,
J'ai vachement hésité avant d'écrire ce commentaire car je vois bien que vous êtes un peu sur la défensive. Je le comprends, c'est pas facile d'être sans cesse comparé par des gens qui comprennent pas votre techno à une autre techno plus connue (bon en même temps, c'est un peu votre faute aussi; vous lancez la discussion/comparaison dès le second paragraphe de l'article et dès le début du lien "Why Pijul"! Donc on a l'impression que votre principal atoût vient de la comparaison avec
git). Mais c'est justement ça le prob. On comprends pas suffisamment pour appréhender l'avancée technologique.Quand d'autres demandent des exemples, c'est pas pour vous prendre en défaut donc le prenez pas mal. En tous cas moi c'est pas le cas donc je réitère la question posée par d'autres: pourrait on avoir des exemples concrets ? J'ai bien vu les multiples réponses à cette question mais il me semble qu'aucune ne répond vraiment. On veut vraiment un exemple bête et méchant de la vraie vie.
Genre vous donnez 2 patchs (avec explicite diff) et vous montrez comment
gitle gère différemment (et surtout mal dans un cas) selon l'ordre (puisque l'un des points de vos algos est que l'ordre ne change pas le résultat contrairement à git). Puis vous montrez que pijul lui le fait bien dans tous les cas.Autre exemple: un merge de 2 patchs qui génère un conflit avec git alors que pijul donne le résultat attendu sans conflit.
Ou bien d'autres exemples qui correspondent mieux aux problèmes résolus par Pijul (les miens sont peut-être mauvais mais justement c'est parce que j'ai du mal à comprendre; en tous cas en lisant plus haut, c'est ce que je comprends être les 2 gros problèmes réglés pas Pijul).
Clairement je trouve ça intéressant. Comme tout le monde j'ai eu mes emmerdes avec des conflits de merge foireux dans git, etc. Aussi je suis complètement techno-agnostique.
gitmarche plutôt bien et j'en suis globalement content mais si demain un truc fait 10 fois mieux, j'aurai aucun remords à changer. Pourquoi pas?!Donc je suis vraiment en train de demander naïvement des détails pour comprendre Pijul.
Car les algos prouvés scientifiquement c'est cool mais au final c'est pas ce que je vois en tant que dev de base. Me dire que "les patchs commutent" ou "sont associatifs", j'ai beau avoir fait des maths et comprendre plus ou moins ce que ça veut dire dans un contexte de système de versionnement, j'ai quand même du mal à voir ce que ça m'apporte concrètement pour mon boulot de dév au quotidien. D'ailleurs je pense faire partie des gens qui savent plutôt bien utiliser git et pourtant j'en connais pas les algos (comme vous l'expliquez très bien dans d'autres commentaires que la plupart des gens ne savent pas comment ça marche en interne; c'est vrai. Ça nous empêche pas de l'utiliser suffisamment efficacement pour nos besoins au quotidien). Ce qui prouve que l'usage final compte beaucoup (même si évidemment les algos aussi; et je suis parfaitement conscient à quel point ça doit être frustrant pour des chercheurs d'avoir l'impression que peu s'intéressent à la beauté de votre algo! J'en suis désolé!). Je fais partie de ces ingés simples qui font plutôt des implémentations pratiques d'algo d'ailleurs (en ce moment je bosse même pour le CNRS pour implémenter des algos dans GIMP). Je suis sûrement pas le meilleur dev du monde mais je pense pas être trop mauvais non plus. Donc je me dis que si je trouve pas ça si "intuitif", c'est que ça l'est peut-être pas autant que vous semblez le croire (ce qui ne veut pas dire que c'est mauvais pour autant!).
Et oui je me rends bien compte que je marche sur beaucoup d'œufs dans mon commentaire (ce qui le rend super long) mais c'est parce que j'ai l'impression qu'à chaque fois que quelqu'un compare à git ou vous demande des exemples, vous vous sentez attaqués. Franchement c'est pas le cas. Pour parler de mon cas personnel, je trouve juste sincèrement l'explication floue. J'ai l'impression que vous présentez une super techno du futur mais que je comprends rien à ce qu'elle apporte (de mieux que ce qui existe) en vrai… Hormis d'être une techno du futur!
Donc j'essaie d'y aller le plus diplomatiquement possible pour m'éviter de me prendre vos foudres ou que vous vous sentiez insultés. J'espère que ça marche, que vous le prendrez donc pas mal et m'apporterez des exemples concrets!
Merci! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Microsоft.com, Faϲebook.com
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche confusable-homoglyphs : une bibliothèque pour gérer les caractères qui se ressemblent. Évalué à 10.
Alors ça sûrement pas. C'est la pire des réponses au problème qui pourrait être faite. Et malheureusement c'est le genre de réponses qui est souvent faite par certains développeurs des pays occidentaux et ça explique probablement en partie le peu d'intérêt des logiciels libres dans pas mal de pays (en tous cas, dans les pays extrême-orientaux, je peux attester que le libre est très anecdotique par exemple). De nos jours, pas mal de trucs se sont vachement améliorés heureusement, mais par exemple pendant longtemps, les difficultés pour installer les méthodes d'entrée pour langue non européennes rendaient évident que des barrières étaient créées dès l'installation d'un OS libre.
Donc pour bien revenir au sujet, non pas tout le monde n'utilise les caractères latin (encore moins le sous-ensemble ASCII) et il n'y a aucune raison pour l'imposer au monde entier.
Ainsi si on prend les exemples:
Αlaskaest problématique, oui, mais parce que le reste des lettres est dans l'alphabet latin et surtout "Alaska" est un nom propre en anglais.Mais si maintenant le mot était
Αλάσκα(qui apparemment veut dire Alaska en grec, cf. Wikipédia) alors leΑ(alpha majuscule grec) est attendu et ce serait leAASCII qui serait problématique, et possiblement utilisé pour tromper autrui (pas forcément, notez bien, mais "possiblement").Ensuite on pourrait imaginer des cas où mélanger les alphabets/syllabaires peut être acceptables, que ce soit pour des jeux de mots ou du character art (beaucoup utilisent des scripts non locaux pour leur forme, j'en ai repéré sur linuxfr même, au fil des ans). Ou simplement on pourrait imaginer un franco-grec avec un prénom composé (un nom français, un grec, ça ne me paraît pas improbable), etc. Donc ce n'est pas forcément un problème simple à résoudre. Mais si on veut gérer ces problèmes, c'est par ce type de réflexion et pas en disant "tout en ASCII". On est dans un monde Unicode, et c'est une avancée, pas de retour en arrière SVP! :P
De mémoire, il me semble qu'il existe même plusieurs RFCs qui évoquent ce type de problèmes (notamment pour la problématique des noms de domaine acceptables), et ce sur de nombreuses pages (je peux assurer qu'aucune de ces RFC ne dira juste "utilisez tous ASCII", surtout en s'adressant à des pays dont la langue n'utilise pas les caractères latins!).
Sinon, et pour parler un peu de la librairie de l'article, en jetant un œil au README du dépôt, il semblerait que cette bibliothèque gère certains trucs intéressants. Déjà je vois les notions de mixed script, etc. J'ai pas cherché beaucoup plus loin, mais ça a l'air correct d'un rapide coup d'œil. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Outil très sympa mais...
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche mat2, version Web. Évalué à 8.
Même si tu as un source code, tu ne peux jamais être certain que le code qui tourne sur le serveur est celui dont tu as le source code… hormis la parole de celui qui a installé. Mais les promesses n'engagent que ceux qui y croient.
Si toi par contre, tu installes le logiciel sur ton serveur, alors bien sûr, tu peux (techniquement, ça ne veut pas nécessairement dire que tu vas le faire, mais au moins c'est possible) être sûr qu'il n'y a aucune porte dérobée… hormis si tu en rajoutes une toi-même bien sûr! Et dans ce cas, la situation se renverse.
C'est le principe de "Software as a Service".
La conclusion est que ce message s'adresse aux gens qui utilisent le service web (qui n'ont pas de preuve autre que la parole de l'admin), pas à ceux qui l'installent (lesquels peuvent savoir si les photos sont gardées). Et ce logiciel dit donc aux gens de rester critique et de ne pas croire aveuglément n'importe qui. C'est pas parce qu'on vous dit une chose que c'est nécessairement vrai. Donc évitons de balancer nos photos de nu si on veut être sûr qu'elles se retrouvent pas n'importe où.
Je trouve un tel message plutôt une bonne idée. Mais comme tu le montres, il faut peut-être un peu de background pour en comprendre tout le sens.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: WebP : pas que la compression
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Firefox 65. Évalué à 8.
C'est historique. Bien sûr qu'à ce jour, GIF a plus d'outils. Et ça sera toujours le cas tant que des plateformes accepteront GIF (le jour où les plateformes se mettront à accepter WebP ou APNG et refuser GIF, la tendance pourra commencer à s'inverser).
Mais WebP commence à être bien pourvu en terme d'outillage tout de même. Ça reste la conclusion. Et GIMP notamment peut aisément générer des WebP animés. :-)
Ensuite je parlais d'APNG car à ce jour, c'est le principal autre remplaçant possible dans cette niche (bon y a MNG aussi qui est le format standardisé et justement la raison pour laquelle le patch APNG n'est pas accepté upstream dans libpng; mais ce format a complètement loupé son entrée de manière étonnante, en étant quasi pas pris en charge dans les navigateurs), même si j'étais bien conscient que tu n'en parlais pas. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: WebP : pas que la compression
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Firefox 65. Évalué à 10. Dernière modification le 01 février 2019 à 15:13.
Depuis presque 10 mois (sortie de GIMP 2.10.0), bien plus longtemps si on compte les versions de développement. :-)
Ce fut aussi annoncé sur linuxfr.
En fait au contraire, l'outillage est la raison pour laquelle je donne un avantage à WebP, par exemple comparé à APNG (alors que pour la visualisation, APNG semble avoir plus de pénétration, car dans son cas, le seul navigateur majeur sans prise en charge semble être Microsoft Edge, qui a récemment annoncé passer au moteur de Chrome, donc qui pourra lire WebP à terme).
Le truc, c'est que WebP a une bibliothèque bien maintenue alors que pour visualiser APNG, y a un fork de libpng (en fait juste un patch) que divers navigateurs semblent embarquer. Or cela est un problème pour beaucoup de logiciels libres (on n'a pas trop envie d'embarquer un fork, ce qui en plus revient à le maintenir).
Prendre en charge WebP (que ce soit en lecture ou en écriture) au contraire, ça se fait en quelques appels de fonction. Et en cas de problème, c'est simple de rapporter un bug ou d'envoyer des patchs (je l'ai déjà fait, équipe réactive). Alors qu'APNG, c'est un projet obscur sur Sourceforge qui distribue un patch. On trouve des dizaines de forks qui ont appliqué diverses versions de ce patch un peu partout.
Et comme on peut s'y attendre, très peu de distributions (aucune que je connaisse en fait, mais j'ai vu cette affirmation quelque part, reference needed!) ne l'appliquent (je rappelle, ça ne crée pas un libapng, ça patch direct
libpng). Ce qu'il faut pour une vraie adoption, c'est une vraie librairielibapngdans son propre espace de domaine.Donc non, pour WebP, au contraire, l'outillage est son point fort. En Libre, que ce soit GIMP, ffmpeg, ImageMagick, la plupart des gros projets prennent en charge nativement et sont capables de générer des animations WebP très aisément.
De même pour beaucoup des gros logiciels propriétaires, soit nativement soit par plug-in.
Aucun problème d'outillage 🛠️! :-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: WebP : pas que la compression
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Firefox 65. Évalué à 10.
En plus du fait que webp propose la transparence (notamment partielle, pas juste une transparence binaire) comme tu le notes, y a aussi la prise en charge d'animation.
Ça en fait un remplaçant des plus sérieux au format GIF (pour une plus petite taille de fichiers, on a des animations de meilleure qualité d'image, et de la transparence partielle).
Sauf erreur, de nos jours, le seul navigateur majeur (qui a au moins quelques pourcentages de part de marché) sans prise en charge est Safari. C'est le seul blocage qui pourrait empêcher certains de ne plus utiliser le format GIF au profit de WebP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]