Jehan a écrit 1652 commentaires

Avec vos histoires d'écritures rapides, je pense qu'il est possible que vous passiez à côté du véritable intérêt de l'abstraction et de l'expressivité d'un langage moderne : la relecture de code.
[…]

Tout ce que tu dis est vrai, mais ma conclusion reste vraie: doit-on passer des années à passer une majeure partie du code de GIMP en un autre langage (et arrêter toute autre innovation pendant ces quelques années) pour être un peu plus rapide ensuite? C'est ça la vraie question.

Si je comprends bien, le projet GIMP vit sa vie à son rythme et n'a pas nécessairement un besoin prégnant de drainer une marée de développeurs mais lorsqu'on se trouve dans une situation où l'attractivité du projet est centrale, les outils et les langages deviennent stratégiques.

Encore faut-il le prouver que cela va soudainement "drainer une marée de développeurs". Qui sait, peut-être cela pourra-t-il même en repousser d'autres, parmi les développeurs actuels, au contraire?

Je regarde des exemples comme MyPaint (dont l'UI est justement en Python), j'ai pas particulièrement l'impression qu'ils ont particulièrement plus de contributeurs que nous que nous, et en tous cas sûrement pas suffisamment pour justifier des années de travail.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Oui mon petit avis sur ColorHug fait partie des choses que j'aurais volontiers revu et changé si j'avais su que cet article allait paraître 2 ans plus tard! En fait de nos jours, je serais beaucoup plus dur avec ColorHug. À chaque fois, il fait vraiment des calibrations bien trop dans le rouge. Ce n'est pas utilisable.
On m'a prêté un Spyder 5 pro et la différence de réussite de calibration est flagrante.

Ensuite je ne regrette pas forcément de l'avoir acheté. Je me dis que j'ai financé et encouragé la recherche pour de l'OpenHardware en colorimétrie. En outre, comme tu dis, je suis tout à fait conscient que la base de données des écrans est probablement le vrai problème. Idéalement il faudrait calibrer à partir des données de quelqu'un (une matrice de correction) qui a calibré le même écran avec un spectrophotomètre, or comme la base de données de matrices est créée par la communauté (et que les spectrophotomètres sont chers, donc rares)… on se retrouve avec un problème de taille de communauté à atteindre pour commencer à alimenter des données pertinentes.
D'ailleurs maintenant Richard Hughes travaille sur un spectromètre OpenHardware, le ColorHug+. C'est cool.

Mais soyons franc, on ne peut pas vraiment conseiller un ColorHug à n'importe quel quidam de nos jours. Il aurait l'impression de se faire arnaquer. À part s'il tombe pile sur l'un des écrans qui a une matrice disponible; dans ce cas, c'est un petit chanceux.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Oui je comprends bien. :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

J’ai un peu l’impression que si tu as été facilement intégré c’est que tu t’es parfaitement fondu dans le moule

Je sais pas trop comment prendre cette remarque. Faut-il forcément un moule? Ça peut pas être simplement que le mainteneur était simplement un mec assez réceptif et accueillant aux nouveaux contributeurs qui font du code de qualité, comme je l'ai dit? C'est impossible à imaginer et faut forcément une autre raison?

si 80% du code c’est de l’ui, c’est une proportion assez gigantesque.

C'est une approximation au doigt mouillé, mais oui, surtout à partir de 2.10 puisqu'une majeure partie du traitement d'image est maintenant dans GEGL. Ensuite il reste des choses implémentée dans GIMP car GEGL n'est pas encore assez rapide à ce jour, notamment la peinture avec des brosses.

Mon impression c’est qu’il y a pas mal de boilerplate et que c’est assez verbeux.

En effet, notamment tout le côté GObject. Mais bon ce problème s'applique surtout lorsqu'on souhaite créer une nouvelle classe. Et à ce moment, il suffit de faire du copier-coller intelligent. Pas la fin du monde.

Ça se prête moyen au prototypage rapide d’idée. Mon impression c’est que c’est pas hyper efficace (et qu’en utilisant d’autres techno on pourrait ptete diminuer significativement le nombre de ligne de code, potentiellement)

Oui tu as sûrement raison. Mais passer 5 ans supplémentaires (compte le nombre de lignes de code dans GIMP. Parler de plusieurs années pour un tel chantier, je ne crois absolument pas que ce soit exagéré) pour passer tout le code à un autre langage pour finalement pouvoir prototyper rapidement, c'est… contre-productif!
Parfois il vaut mieux être un peu moins efficace (parce qu'on doit faire des copier-coller lorsqu'on crée une nouvelle classe, ce qui arrive une fois tous 36 du mois) tout le temps que bloquer tout pendant des années pour être un peu plus efficace dans quelques années.

Vous utilisez des interface genre glade ? Comment vous développez en fait ?

Certains ont utilisé glade pour des plugins, je crois. Mais majoritairement non. On code la GUI. Peut-être qu'avec GIMP 3, ça pourrait être intéressant d'utiliser un peu plus Glade (car à ce jour, avec GTK+2, c'est compliqué puisque Glade suit GTK+).

J’ai l’impression qu’à ce niveau d’UI çà devient important de se poser la question de la pertinence des technos concernant l’UI.

Dans un de mes derniers jobs en startup, y a quelques années, on avait un site en PHP au dessus d'un framework. Certains décident qu'il faut faire un truc méga moderne, en créant une plateforme custom Python, un site "mobile-first" et autres termes hypes et à la mode. Moi je dis que c'est probablement une erreur de tout refaire et qu'il vaut mieux améliorer la plateforme existante incrémentalement. Au final toute l'équipe bosse comme des fous pendant 3 ou 4 mois… avant que le manager décide un beau jour de tout annuler (tant de mois de travail perdu!) car il se rend compte qu'on est en train de se tirer une balle dans le pied.

Parfois il faut savoir faire preuve d'un peu d'humilité et se dire que oui, on n'a pas le meilleur framework, les meilleures technos, le truc le plus moderne et hype, qu'on n'est plus forcément à la mode (alors qu'on l'était 2 ans plus tôt), mais que non, c'est pas une raison pour sans cesse revenir en arrière afin d'être toujours en tête de la mode. Il vaut mieux sans cesse aller de l'avant. On a quelque chose qui marche, améliorons le plutôt que sans cesse revenir sur ses choix technologiques ou "se poser la question de la pertinence des technos concernant l’UI".
Bien sûr, on peut le faire, on le fait sans cesse (on arrête pas de mettre à jour plein de choses), mais il y a des limites à ce qu'il est possible de faire sans que ça ne devienne une sorte de bête course à la mode des technologies nouvelles.
Je vais dire un secret: tout projet qui commence à avoir quelques années n'est plus à la mode!

Vous avez sérieusement étudié la question ou vous attendez qu’un contributeur fasse tous le taf’ avant ? (ce qui me semble assez irréaliste, en fait, faudrait se préparer à forker au cas ou au bout du compte c’est rejeté)

C'est irréaliste quand c'est quelqu'un d'autre mais réaliste quand c'est ceux déjà là? J'ai du mal à comprendre la logique. Nous aussi sommes des gens comme les autres! (on pourrait faire une manif avec des bannières: "Non à la ségrégation des GIMPers", "Les développeurs de GIMP ont des droits aussi", "On n'est pas des aliens, on est des êtres humains comme vous"…) :D

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

ça vaut ptete le coup que les anciens s’y mettent.

Encore une fois, c'est toujours plus facile à dire quand on met le travail d'autrui dans la balance plutôt que le sien.
Perso j'ai une todo list personnelle qui ne fait que se remplir plus que se vider. J'ai déjà suffisamment de trucs que je veux faire pour ne pas avoir à faire des choses pour lesquelles je ne vois pas l'intérêt. Pour moi, le C fonctionne très bien.
Ensuite oui, si quelqu'un fait un patch génial demain qui passe toute la GUI en Python. On teste, ça marche génial et je me rends compte que c'est effectivement plus facile de faire une GUI. Ok. Je suis pas contre a priori. Mais non, moi, là maintenant, j'ai plein de trucs bien plus importants à faire.

C'est là ce qu'il faut comprendre. Chacun est libre et on est très ouvert aux nouvelles contributions, mais on n'est pas aux ordres de quelqu'un qui arrive d'on ne sait où et est persuadé que son idée est forcément la meilleure et bien plus importante que quoi que puisse être nos priorités personnelles. Et donc on doit "bien sûr" tout laisser tomber et "s'y mettre".

Certe c’est un coût mais pas un coût de maintenance en soi

C'est sérieux ou c'est une blague? Tout code a un coût de maintenance, d'autant plus élevé si c'est un code récent ou important (et changer entièrement la GUI sur un logiciel qui est principalement une GUI, c'est donc très très très élevé).

développer du GTK en C c’est un risque aussi

En quoi c'est un risque? GTK+ est développé en C. A priori on aura moins de risque en développant en C qu'à travers un wrapper quelconque.

ça n’attire pas des masses, à juste titre.

C'est toi qui le dis. Aux dernières nouvelles, C reste l'un des langages les plus utilisés au monde, d'autant plus parmi les plus gros projets.

On peut d’ailleurs noter qu’il y a des concurrents à The Gimp de nos jour

GIMP (pas The Gimp) n'a pas de concurrent. On n'est pas en compétition et on ne cherche pas à l'être. On vit très bien avec les autres (même si eux ne vivent pas forcément bien avec nous, mais perso, je ne comprendrai jamais le besoin d'animosité dont font preuve certains) et on leur souhaite tout le bonheur du monde.

il y eut un culte du C que l’équipe actuelle composée de pas mal de vieux de la vieille connaissent bien et qu’ils ont pas des masses envie de payer le coût du changement.

Bof. J'ai vraiment appris le C en contribuant à du code libre (c'est à dire que l'université, c'était des cacahuètes). J'ai pas de culte du C personnellement et vis très bien la contribution sur d'autres logiciels en divers langage (C++, Python, parfois même PHP, et par ci par là un peu de ci ou de ça). Je suis complètement langage-agnostique.
Et quand bien même ce serait vrai pour certains des autres, et alors? Ils sont tous bénévoles et ont passé des années (20 ans pour les plus anciens) à donner du code pour GIMP en C, et on va leur reprocher de faire de la résistance au changement? Non seulement je trouverais cela fort de café, mais en plus il suffit de lire l'interview de Mitch pour voir que c'est pas vrai. Par exemple il montre clairement qu'il a été intéressé par Rust.

Mais encore une fois, être intéressé par un langage récent n'est absolument pas une raison suffisante pour faire une migration de tout un programme (qui a 21 ans d'accumulation de code) sur un coup de tête. Je comprends même pas comment cela peut ne pas être évident.

Du coup ils ont ptete assez mal reçu les gens qui ont proposé des chagemnts de ce côté. Qui du coup ne seraient pas hyper enthousiastes à l’idée de rester sur ce projet et sont ptetp parti vers d’autres aventures avec des technos plus actuelles.

Y a beaucoup de "peut-être" et de conditionnel. Ça m'a pas l'air très recherché. Si tu trouves une seule de ces propositions, je veux bien un vrai lien. Et pour moi "proposition", ça veut dire au moins une tentative de patch minime en "preuve de concept" au minimum; parce que juste demander aux autres de coder sa super idée (et si ils le font pas, alors ça veut dire qu'on reçoit mal les gens), c'est du vent. Encore une fois, on n'est pas aux ordres de chaque individu et de leurs lubies du moment.

le scénario est cependant assez crédible si on prend la peine de faire de l’archéologie de vieux trolls sur ce site et donc du libre en général

Si tu le dis… Donc à partir de trolls sur le site linuxfr, on peut en déduire comment ça se passe chez GIMP? Intéressant…

De toutes façons, je ne saurais dire comment ça se passait avant. Je ne suis dans le projet que depuis fin 2012, et pour moi, tout s'est super bien passé. On m'a dit qu'il fut un temps où certains gros contributeurs étaient beaucoup moins agréables. Alors pourquoi pas! Peut-être que tu trouverais des trucs pas reluisants dans le passé. Je ne saurais dire.
Mais ça ne change rien au présent. Je sais comment moi je réagis là maintenant à quelqu'un qui me dit qu'il faut passer toute la GUI de GIMP en Python (ou autre langage à la mode) et que si je le fais pas, alors c'est de la résistance au changement ou bien que ça veut dire que je reçois mal les propositions de changement. Ou autre faribolerie.
Non, proposez un patch fonctionnel, qui casse pas GIMP et on en discute. Nous demander de faire du travail non payé et nous insulter si on le fait pas (par contre vous, de votre côté, ne ferez rien sinon nous dire de "s'y mettre"), je sais pas, c'est une sorte d'esclavage du libre, un truc comme ça? :P

Enfin voilà, je sais pas si je fais bien passer le message. Et j'essaie de le faire le plus gentillement du monde. J'aimerais bien que vous arriviez à vous mettre à notre place. :P

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Mmm parler « d’excuse » dans le cadre d’un projet bénévole me surprend un peu.

Exactement. Pourtant c'est la logique de pensée de beaucoup. GIMP est un projet bénévole qui marche entièrement volontairement: les faiseurs décident. Pourtant on trouve plein de gens qui ont besoin d'excuse, alors qu'on s'en fiche: tu fais ou tu fais pas. On n'en veut à personne si ils ne font pas, et on comprends complètement les autres priorités de la vie. Par contre les critiques du type "Je fais pas car c'est en C, mais si c'était en Python, je ferais, alors obéissez moi, faites une GUI en Python et alors seulement je contribuerai (peut-être)", ce serait une excuse pour ne pas agir soi-même (si vraiment c'est ce qu'ils veulent). Or on n'a rien demandé, on demande pas aux gens de s'excuser ni même de faire quoi que ce soit. On peut pas nous reprocher que certains non-contributeurs se sentent obligés d'avoir des excuses.

Bon ceci dit, je n'ai jamais vraiment suivi ces discussions sur l'utilisation d'un autre langage ou je les ai loupées. Donc je crois pas que ce soit si prédominant que ça. Mais ce genre de remarque est vrai pour plein de fonctionnalités.

J’ai l’impression que vous mettez pas mal la pression avant de considérer que quelqu’un fait partie de l’équipe. Ça peut être contre-productif, non ?

Euh… en quoi? Si quelqu'un nous demande de faire un changement profond en changeant le langage de 80% du code de GIMP, et qu'on lui dit "ok propose quelque chose (c'est à dire du code, des patchs!) si tu penses que c'est vraiment mieux", on met la pression sur les contributeurs? J'espère que c'est une blague. On n'est pas aux ordres de chaque gars qui a une idée de changement pour techno à la mode (déjà que je trouve pas le temps pour implémenter tous les trucs que moi je veux faire).

Sérieusement, la raison pour laquelle je suis resté dans GIMP est justement parce qu'ils ont été une des équipes de logiciel libre parmi les plus ouvertes que j'ai jamais vues. J'ai contribué régulièrement par ci par là à pas mal de projets. Jusque là, je faisais des patchs quand je tombais sur un bug dans un programme que j'utilisais, espérais qu'ils soient intégrés, puis passais mon chemin après avoir fait intégrer les quelques patchs que je souhaitais. Dans certains projets même, mes patchs n'ont jamais été revus (malgré des relances), puis ont été oubliés (même par moi). C'est la vie. Je n'ai jamais mal pris même cela ni n'en veut à personne.

GIMP, j'ai commencé par quelques patchs tout simples (aussi bien sur GIMP même que babl et GEGL) sur le bugtracker, comme d'habitude. Puis au bout d'à peine 1 ou 2 mois, Mitch me dit un jour, en substance "attend là t'es chiant, tu me donnes trop de travail et en plus tes patchs sont tous bien écrits, je te donne les droits d'écriture". Franchement c'était la première fois qu'un projet tiers me donnait des droits d'écriture si vite (bon je les avais eu aussi sur mrxvt, et pareil, l'équipe était super cool, donc peut-être seconde fois). Dès le départ, je me suis donc senti super bien accueilli. C'est très agréable. Un ou 2 mois plus tard encore (à peine quelques mois après mes premiers patchs), GIMP m'invite à Libre Graphics Meeting pour la première fois (trajet et logement payé). Je ne connaissais pas l'évènement à cette époque. Je me suis donc retrouvé à Madrid et ai rencontré tout le monde pour la première fois (aussi). Ils étaient cool, et Mitch en particulier est un gars assez relax et simple.

Depuis je me fais un point d'honneur de faire pareil. J'essaie de faire que les contributeurs se sentent bien et vite. Dès qu'on a des séries de contributions de qualité, qui durent un peu, je demande à ce que la personne ait les droits d'écriture pour qu'il se sente accepté et sa contribution reconnue.

Même les non-développeurs, on fait tout pour qu'ils se sentent reconnus et on les invite très régulièrement aux évènements (quand on y pense, c'est dur de tenir à jour une liste de contributeurs; il peut donc arriver qu'on oublie d'inviter quelqu'un), avec les mêmes avantages que les développeurs. Par exemple Patrick David, qui fait beaucoup dans la communauté et depuis nous a fait un nouveau site web, etc. Au prochain LGM, j'ai invité Americo Gobbo, un peintre qui fait beaucoup de choses avec GIMP et propose plein de choses, fait des rapports de bugs, des posts sur le web… Dernièrement il a commencé à proposer des changements de GUI. On lui a donné un login sur le wiki pour les formaliser. Malheureusement ses changements ne sont pas implémentés ou même beaucoup discuté par manque de temps développeur. C'est pour cela que je l'ai invité pour qu'on puisse en discuter tous ensemble, et qui sait, si on débloque du temps et de l'intérêt chez les développeurs, on pourra peut-être améliorer l'UI de GIMP sur plein de choses. Au moins, en discuter est déjà une avancée.
Les rapporteurs de bug aussi, on le fait savoir lorsqu'ils font vraiment le genre de rapports qui font avancer les choses. Typiquement lui, il traîne encore sur notre chat et il débusque régulièrement des bugs à corriger.

Franchement j'ai du mal à voir où on peut voir de la "pression". Moi perso j'ai vécu que de l'ouverture. Bien sûr, parfois certains ont un franc parler qui peut être mal compris par certains. J'ai aussi eu au moins un clash avec quelqu'un, mais c'est le genre de choses qui arrivent entre humains et depuis ça va mieux. Ce qui importe, c'est de ne pas garder de rancœur et d'en parler (même si le ton monte parfois), et aussi savoir accepter les différences (certaines qu'on peut ne pas apprécier mais on n'est pas là pour essayer de changer les autres; il faut savoir travailler ensemble). Ça c'est pour dire qu'on n'est pas chez les bisounours, et tu ne trouveras aucune équipe sans certains clashs de temps en temps après quelques années. Ce qui est important, c'est de voir ce qui se passe "après". Est-ce des gens capables de passer outre leur fierté perso pour aller de l'avant? Chez GIMP, c'est ce que j'ai vu.

GIMP? Globalement c'est une équipe ouverte et compréhensive.

Oui, on a une revue de code stricte et on accepte que du code de qualité (ce qui ne veut pas dire qu'on refuse le reste, ça veut dire qu'on revoit le code et explique quoi changer, et comment; parfois on le fait nous-même au bout d'un moment). Et on ne change pas tout un pan du code pour une nouvelle technologie à la mode sur demande. Par contre, on accepte volontiers à la discussion les patchs de qualité qui nous proposent de faire ça.
Si pour quelqu'un, ça veut dire "mettre la pression". Alors on a vraiment des définitions différentes.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Oui comme je dis, CMake est un très bon système de build (même si je lui préfère les autotools pour plein de raisons, certaines citées plus haut).

Scons par contre… je comprends pas quel intérêt ont bien pu lui trouver les gens qui l'ont choisi pour un projet. À ce jour, je n'ai vu aucun système de build de qualité en Scons.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Exactement. D'ailleurs c'est exactement ce qu'il dit dans l'interview.

C'est d'autant plus important dans ce cas que GIMP, c'est genre 70 ou 80% de GUI (d'autant plus maintenant que la plupart du traitement graphique est externalisé dans GEGL). Donc changer de langage pour la GUI, ça veut dire quelqu'un qui fasse un patch (ou une série de patchs incrémentaux) pour passer une majeure partie du code sous Python, sans perdre une seule fonctionnalité, puis nous prouve que c'est mieux ("c'est à la mode" n'est pas une preuve).

Le truc, c'est que personne dans GIMP n'est vraiment anti-nouvelles idées. On va les "challenger", ça oui. Et ça peut donner l'impression qu'on est contre. Mais ce n'est pas le cas. On a seulement besoin d'être sûr, ou au moins de voir que la personne de l'autre côté est elle-même sûre d'elle-même (car des personnes vont en effet sortir des trucs en suivant des effets de mode, mais dès qu'on parle technique, y a plus grand chose) et ont des arguments. En un sens, même si on voit pas l'intérêt nous même (mais on ne voit pas non plus de bloqueur, c'est à dire notamment, ça ne casse pas d'autres choses), mais si quelqu'un fait tout le boulot, est super impliqué, persistent et actif, on pourrait accepter pas mal de fonctionnalités.

Dernier point, particulièrement vrai pour une fonctionnalité si majeure: il faudrait que la personne derrière ce changement soit un contributeur très actif et qu'on ait une semi-certitude (on a jamais de certitude complète) qu'il ne va pas se barrer une fois le changement effectué, disparaître de la circulation en laissant la chose non maintenue et toute bugguée.

Ce n'est absolument pas une décision simple à prendre en 2 minutes.

Pour finir, personnellement je ne vois vraiment pas ce qu'il y a de dur en C et en quoi Python rendrait les contributions plus simples et/ou meilleures. Si quelqu'un n'est pas capable de faire un bon code de GUI en C, je vois pas pourquoi cette personne serait soudainement capable de le faire en Python.
Note que je ne parle pas d'être débutant. Les erreurs sont tout à fait acceptées. Nous avons une revue de code vraiment de qualité et le code de GIMP est "globalement" de très bonne qualité (ensuite oui, on trouve toujours des horreurs ici ou là! Parfois on les a faites nous même dans un moment de faiblesse ou quand on était moins expérimenté. Parfois d'autres gens qui ont disparu depuis… C'est la malédiction de tout code de 20 ans et de cette taille! Mais globalement, pour avoir vu beaucoup de code horrible dans d'autres projets, celui de GIMP est assez exemplaire). Un débutant peut faire un très bon code, avec des erreurs de débutant, et on les corrigera, que ce soit en C ou en Python. Je ne vois pas la différence.
Donc l'assertion "Ça n’aurait pas aussi tendance à diminuer la qualité" reste vraiment à prouver.

Et je dis ça, j'apprécie aussi Python. J'ai quelques projets en Python moi-même. Mais dire que le C est ce qui empêcherait de contribuer à C, ça ressemble plus à une excuse qu'autre chose. Je ne suis absolument pas certain que les gens qui disent ça se mettraient à contribuer soudainement du bon code si ça passait à Python.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Ben… Tu cites la raison dans ton message! :-)
Certes c'est de la merde. C'est complexe, c'est parfois même tordu. Mais ça reste le mieux au niveau système de build.

La seule autre alternative un peu sérieuse que je connaisse est CMake. Ils font des choses mieux, mais d'autres choses moins bien.
D'ailleurs par endroits, j'ai un peu cmake-ifié notre autobuild. Notamment j'ai fait en sorte que notre script de compilation finisse et liste l'ensemble des dépendances manquantes plutôt que s'arrêter à chaque fois (obligeant à relancer le ./configure 20 fois, en installant les dépendances une par une lors d'un nouveau build; quelle perte de temps). C'est un des trucs confortables de cmake (de manière générale, cmake produit des sorties de terminal plus agréable que les autotools).

Par contre, là où CMake est problématique est qu'ils ne cherchent pas vraiment à suivre un "standard" de compilation (autotools suivent les GNU Coding Standards):

• Par exemple, pour cross-compiler, il faut un fichier toolchain séparé, alors que le concept même de toolchain est déjà plutôt standardisé. C'est d'autant plus idiot qu'au final, on utilise le même fichier toolchain pour quasiment tous les projets (puisque c'est standardisé, comme je disais). Mais ça veut dire aussi que certains projets qui ne comprennent pas les besoins de standardisation peuvent rajouter des options et rendre les choses compliquées inutilement (bon tu vas me dire, on peut aussi le faire avec les autotools, mais disons que la façon d'aborder est différente: autotools standardise par défaut, sans rien faire, et autorise à tout tweaker après coup; CMake ne fait rien par défaut, donne une liberté totale, en autorisant donc à suivre les standards si on veut, ce qui pousse les développeurs moins expérimentés à faire des choses inutiles). Avec les autotools, tout build correctement créé autour d'un code lui aussi générique est automatiquement portable sur toute plateforme, sans rien faire ni changer une ligne.
• De même, certaines cibles vraiment basiques ne sont même pas implémentées par défaut et c'est aux développeurs de les créer à la main (avec tous les problèmes et bugs que cela va créer). Par exemple, pas de cible "uninstall" par défaut dans un projet CMake! On doit le faire à la main alors que c'est totalement automatisable (on retire la même liste de fichiers que ce qu'on a installé). Un vrai problème pour moi. De même pas de make dist et encore moins de make distcheck, 2 commandes super importantes. Il faut donc les implémenter soi-même.
• Et ainsi de suite.

Bon CMake reste très bon; je maintiens même des projets qui utilisent CMake, et ne prévois absolument pas de changer. Cependant au final autotools a beaucoup de points qui en font la "meilleure merde" qu'on ait.
Quant aux autres systèmes de build (génériques, je parle pas de systèmes pour langage particulier qui parfois sont OK), c'est en général mauvais. Mais je vais pas non plus prétendre connaître tous les systèmes de build.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Il me semble que j'utilise soit "Subtitle Editor", soit "Gnome Subtitles" pour éditer/créer des sous-titres. Ça marche bien.

Par contre je n'ai jamais eu à incruster. En général, les plateformes vidéos ont une option pour uploader des sous-titres, et ça permet de gérer à l'international (alors qu'incruster, ben tu limites à une seule langue tierce et en plus tu rend la vidéo potentiellement moins attrayante pour ceux qui n'ont pas besoin de sous-titre…). Donc je ne saurais conseiller sur ce point.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Oui, il ne faut pas prendre ma critique trop mal. Disons que c'est une critique dite "constructive", dans le sens où ce serait bien que la prochaine fois, une procédure de relance par email (qu'on est libre d'ignorer, mais au moins y aura eu tentative de rameuter les contributeurs de l'époque) soit mise en place pour ce types de cas particuliers.
Je suis un contributeur assez régulier de linuxfr mais je ne peux pas constamment vérifier la liste de toutes les dépêches en rédaction.

J'ai repêché une bonne partie du texte de celle-là ; il avait sauté dans des modifications de trop grande envergure.

En effet. Justement c'était une des dernières choses dont je me rappelais de cette dépêche. Un jour, je reviens sur la page de rédaction et le texte a complètement disparu. Il me semble qu'à l'époque, j'ai demandé sur le chat à la personne qui l'avait initiée ce qu'il se passait, et il me disait qu'il prévoyait une refonte, ou une découpe en plusieurs dépêches de taille plus petites (lesquelles ne sont jamais venues, il me semble), ou quelque chose comme cela. Cela empêchait donc de contribuer davantage et d'en améliorer le texte. Les contributions se sont retrouvées bloquées. J'en étais resté là personnellement.

Enfin bon, je dis cela car je vois mon nom plusieurs fois dans la dépêche, avec cette idée de micro-revue de chaque logiciel, qui je pense est toujours une bonne idée, mais j'aurais probablement édité massivement mes revues. Et là c'et vrai que j'en suis assez moyennement content. Ça m'a surpris de la voir paraître ainsi, on va dire. Un peu comme si un patch buggué, en cours et que j'ai noté comme un "proof-of-concept" à ne surtout pas intégrer tel quel, se retrouvait accepté et intégré dans un logiciel.

Mais bon, c'est pas la fin du monde non plus. :P
Et ce n'est pas à prendre comme une critique acerbe. Je précise, au cas où. ;-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Cf. l'interview. ;-)

Plus sérieusement ceci dit, c'est justement le moment de bosser sur GTK+3 puisqu'il est maintenant stable. Je pense que GTK+4 ne sera pas considérée comme stable avant 2 ans (si je me souviens bien de la news sur le changement de version. À moins que ce fut 3 ans?). Tu vas me dire, le temps de sortir GIMP 3, les 2 ou 3 ans seront passés. Mais en fait, j'aimerais pouvoir accélérer les rythmes de sortie drastiquement (en tous cas, si je parviens à en vivre, c'est l'un de mes buts).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Le but me semble donc justement de laisser l'utilisateur décider ce qui est bien pour lui, totalement.

Tout à fait. Avec un mode de fenêtrage unique, on pourra faire tout ce qu'on peut déjà faire avec les 2 modes, et plus.

Exemple typique de problème: quelqu'un aime le simple fenêtrage, mais les images ne peuvent pas être détachées. On ne peut donc avoir deux images côte-à-côte. Seul le multi-fenêtrage le permet.
En fait, en y repensant, les différences entre le simple et multi fenêtrage ne sont pas si grandes et sont très artificielles. Il n'y a aucune raison d'avoir 2 modes. Il faut juste une flexibilité du fenêtrage de manière générale.

Il faut laisser le maximum de choix à l'utilisateur plutôt que de décider ce qui est bien pour lui soi, non?

Le simple et multi-fenêtrage sont justement des choix qui ont été faits pour les gens. Si on veut laisser un vrai choix, il ne faut plus de modes de fenêtrage.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

des boîtes à outils masquables (qui se transforment en "onglet" sur les côtés lorsque non utilisés et apparaissent lorsque la souris passe dessus)

Perso, j'ai toujours détesté les trucs qui "bougent tout seul", se cache ou apparaissent, etc. juste au passage de la souris. Parce que ça apparaît tout le temps quand je ne le veux pas, et c'est le meilleur moyen de cliquer là où on ne le veut pas. Par exemple, j'ai désactivé l'apparition de l'overview dans GNOME en mettant la souris en haut à gauche, car je trouve cela énervant au plus haut point.
Ensuite c'est personnel, car de toutes évidences, ce type de GUI auto-apparente est utilisé dans plein de logiciels.

Par contre, oui l'idée est intéressante, mais je choisirais donc un clic de souris sur l'onglet plutôt qu'un simple survol, personnellement.

Aussi connais-tu le raccourci Tab (équivalent du menu "Windows" > "Hide Docks") qui permet justement de cacher et afficher l'ensemble des docks au simple clic d'un bouton?

je pense que c'est le meilleur compromis entre le fenêtrage unique "à la Photoshop" et le "multi-fenêtre habituel de Gimp que certains critiquent (un peu trop).

En fait le multi-fenêtrage a son fan-club aussi. En général, ceux qui aime le multi-fenêtre ne supportent pas le simple fenêtrage. Personnellement mon but est d'arrêter la différenciation entre multi et simple fenêtrage. Il ne faut qu'un seul mode de fenêtrage qui permette de mélanger les deux logiques: rassembler les fenêtres en une, mais en séparer seulement certaines, etc.
En fait on a ça partiellement pour les docks qui peuvent déjà être séparés dans une fenêtre différente même en mode simple fenêtrage. Mais la boîte à outil ne le peut pas. Ni les images qui sont forcément en onglet.

Pour moi, cela n'a aucun sens de maintenir une différenciation totalement artificielle entre ces 2 modes.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

Je pense que mes commentaires y sont pour grand chose dans ta remarque, et je suis d'accord. Déjà à l'époque, quand j'ai fait ces commentaires, j'espérais lancer les gens à en faire plus. Le but était d'aller au delà de la description marketing qui veut tout et rien dire. Ceci dit, certains commentaires étaient déjà un peu basés sur des expériences un chouille ancienne à l'époque, alors maintenant!

Ceci dit, je pense qu'aucun de mes commentaires ne va dans le syndrome "ça plante et j'ai pas réussi à faire ça, donc pas terrible". Mes échecs sont toujours recherchés et j'ai en général vérifié la fonctionnalité en ouvrant (ou trouvant) des rapports de bugs. Quant aux plantages récurrents, pour moi c'est rédhibitoire.

Ceci dit, d'après moi, ce fut une erreur de publier cette news ainsi sans au moins revoir un minimum son contenu (ou contacter les nombreux contributeurs de l'époque pour leur proposer une revue avant publication). J'aurais probablement eu beaucoup de choses à revoir, même dans mes propres contributions de l'époque.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Oui je suis d'accord. Je trouve ça triste que la façon dont l'article est tourné, on a l'impression que seuls ces tablettes fonctionnent sous Linux. C'est malheureusement assez représentatif du développement sous Linux (plein de logiciels s'appellent Wacom-quelque-chose alors qu'ils ne sont plus Wacom-spécifique), et de la prise en charge des tablettes en règles générales (même sous Windows, ou MacOS; Wacom a simplement un quasi monopole du matos graphique).

Pour une réponse plus constructive, de ce que j'en sais, la plupart des tablettes ont une prise en charge sous Linux, mais pas forcément par défaut dans le noyau (contrairement aux Wacom, qui de par leur notoriété et aussi parce qu'y a une développeuse de l'entreprise Wacom qui contribue, ont tous les modèles — ou presque, je n'ai pas le détail — pris en charge rapidement dans le noyau Linux). Pour certaines de ces autres tablettes, il faut donc parfois installer des pilotes additionnels.
Un fil de discussion sur le forum MyPaint est assez intéressant, car en listant les tablettes qui fonctionnent, on peut voir beaucoup de cas d'usage de tablettes diverses sous Linux (attention, lire chaque post en détail, y en a pour tous les OS, c'est pas du Linux-only): https://community.mypaint.org/t/which-graphic-tablets-models-work-on-mypaint-1-2-0/269/1
On y découvre aussi pas mal de marques (certaines ne sont pas dispos en Europe ceci dit; d'autres c'est l'inverse, etc.).

Personnellement on a été beaucoup intéressé par ces autres marques, notamment pour les histoires de prix en effet (ça peut diviser par 4 ou 5 pour produit équivalent!). En plus, Wacom, malgré leur notoriété, essuie beaucoup de critiques. Il suffit de voir les avis et notes sur les sites de vente en ligne. Il n'est pas rare par exemple de voir des acheteurs renvoyer des écrans à 2000 ou 3000 € parce qu'y a des poussières sous l'écran (difficilement acceptable pour ce type de prix, en effet). Aussi la qualité colorimétrique laisserait beaucoup à désirer, c'est-à-dire que même après calibration avec les meilleures sondes du métier, la couleur est mauvaise (on ne peut confirmer ou infirmer, on n'a pas les sous pour en avoir!). En tous cas, c'est ce qu'on lit souvent en commentaire ou dans les forums. Beaucoup d'artistes disent que leur configuration habituelle est un écran Wacom pour dessiner et un bon écran autre à côté pour vérifier les couleurs. C'est assez navrant quand on voit le prix de ces écrans et le fait que leur cible est justement des graphistes! On a nous même eu quelques problèmes avec la qualité de fabrication des Wacoms. Ce problème de soudure du port USB qui doit être refait après quelques années est super classique (une recherche web remonte plein plein de résultats). Et à ce moment là, plus de garantie et un service après-vente super cher.
Je pense que leur quasi-monopole les fait peut-être un peu se reposer sur leurs lauriers. Pourquoi payer de la R&D et de la QA à essayer de faire des bons écrans/tablettes si de toutes façons, ils sont seuls sur le marché?

À côté de cela, les autres marques reçoivent de bien meilleures notes en moyenne (bien sûr l'effet moins cher joue; donc la comparaison qualitative est difficile). Mais alors qu'a Wacom de plus que les autres?
Bon déjà ils sont les seuls à avoir du très haut de gamme, en méga HiDPI, avec la petite télécommande aimantée, etc. Perso cela n'est pas absolument nécessaire pour nous. Même les boutons, beaucoup d'autres marques n'en ont pas; mais soit y a le clavier à proximité de toutes façons, soit si on travaille bien sur la GUI pour optimiser le travail avec touch+stylo, on doit pouvoir faire aussi pratique que les boutons physiques.
L'autre truc connu qu'ils sont les seuls à avoir sont les stylos sans batterie (parce qu'ils ont un brevet dessus, à ce que j'ai compris, empêchant les autres de faire de même; youhou vive l'innovation par les brevets!). Mais en lisant les commentaires nombreux ou en testant les autres stylos, on se rend compte que ce n'est pas vraiment bloquant. Les batteries ne sont pas si lourdes de nos jours, et de toutes façons, à part si vous prévoyez de ne pas dormir pendant des jours, y aura pas de problème de batterie.
Le seul truc qui a été vraiment bloquant pour nous est le "tilt". Il s'agit de la reconnaissance de l'angle du stylo (pas tous les modèles ont ça, pas les Bamboo par exemple. Mais Intuos et au dessus, si). Par exemple Aryeom typiquement va associer le tilt à la taille de la brosse et la pression à l'opacité. Je n'ai trouvé cette fonctionnalité chez aucune autre marque que Wacom (ont-il aussi un brevet sur ça?). Tous les autres n'ont que la prise en charge de la pression. De notre côté, c'est l'unique fonctionnalité qui nous empêche vraiment d'aller voir ailleurs. :-/ Une fois qu'on est habitué à utiliser toutes les fonctionnalités d'un stylo Wacom Intuos et au-dessus, il est difficile de revenir en arrière.

J'espère que ça changera bientôt, car un monopole n'est jamais une bonne chose.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Ni Gnome,

Financer GIMP ne finance pas GNOME! J'explique cela dans le premier paragraphe ici.

ni les films d'animation ne sont ma tasse de thé.

Tu n'es pas obligé de vouloir faire ou voir du film d'animation pour apprécier notre travail sur GIMP.
De mémoire, j'ai implémenté des corrections de bugs et de plantages par dizaines, notamment ai corrigé des plantages massifs sur l'utilisation de tablette graphique (avant nous, une micro-coupure de la connexion de la tablette faisait planter GIMP et MyPaint! Autant dire que ces 2 logiciels n'était pas utilisable au quotidien par des illustrateurs non masochistes…), prise en charge du standard XDG pour les fichiers de configuration, ai participé à l'intégration des brosses MyPaint, ai implémenté la peinture en symétrie, ai intégré la recherche d'action, ai lancé le travail sur les nouvelles icônes et nouveaux thèmes, ai créé le Flatpak de GIMP, fait beaucoup de correctifs et changements en rapport avec l'internationalisation (j'aime beaucoup les langues donc l'internationalisation d'application est un sujet qui me passionne) comme par exemple une vraie prise en charge des méthodes d'entrée dans l'outil texte, ai poussé à de meilleurs valeurs par défaut, ai fait des dizaines de revues de code, ai aidé à la prise en charge de webp, ai ajouté la prise en charge de la modification des options dans le système de migration des fichiers de configuration, etc.
On en fait des choses en plus de 500 commits.

Tu n'es donc pas obligé d'apprécier les films d'animation (ni voir ni faire) pour apprécier mon travail et sa portée bien au delà du sujet "animation" pure. ;-)

si en plus c'était reconnu par le fisc

Désolé. L'association LILA n'est pas une association reconnue d'intérêt général ou d'utilité publique.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Pour du 12 bits, je sais pas si y a des formats d'image qui ont cette profondeur, mais si oui, on devrait alors pouvoir exporter en 12 bits sans problème à partir d'une image de travail 16 ou 32

Le reproche qui est fait au 8bit (256 valeurs) pour la photographie ce n'est pas d'être insuffisant pour le stockage ou la visualisation en jpg, c'est de générer des "crans" dans une suite de traitement et d'obtenir un histogramme en peigne. Ce phénomène s’atténuerait à chaque augmentation de la précision, il serait moins sensible en 11bits (2048 valeurs par canal) par exemple pour le traitement, même si l'exportation finale se ferait en 8 bits.

Je sais pas trop où tu veux en venir en disant cela. Tu t'imagines bien que je sais à quoi sert de travailler en 16 ou 32 bits. D'ailleurs c'est bien pour cela que je fais la différence entre le format de travail et le format d'export dans le bout de texte que tu cites toi-même.

J'insiste sur ces valeurs intermédiaires car j'ai constaté avec la version de développement qu'en 16bits pour un fichier issu d'un 10Mpix certains traitements prennent du temps

Essaie en 32 bits, ce sera peut-être plus rapide. La seule raison de travailler en 16 bits seraient éventuellement pour des problèmes d'espace disque. Sinon autant travailler dans le format interne qui est en 32 bit.

ce n'est plus l'utilisation fluide de la 2.8, c'est vrai aussi que je n'ai pas une machine ni très récente ni haut de gamme, c'est probablement le cas aussi d'une majorité d'utilisateurs de Gimp.

Ça dépend vraiment pour quoi. Beaucoup de choses sont bien plus rapides en 2.9/2.10 qu'en 2.8 (notamment dans les effets, maintenant des opérations GEGL); mais y a aussi des choses plus lentes en effet.
Je veux aussi noter que GIMP reste un logiciel de traitement d'image pour utilisateur avancé (c'est la première cible), qui auront normalement du meilleur matériel, adapté au traitement graphique (un procédé lent par définition car ça se repose sur beaucoup de calculs). Ensuite ce n'est pas une excuse et y a évidemment des choses qu'il serait vraiment bien d'optimiser. L'amélioration ne s'arrête jamais! ;-)
Néanmoins il est bon de rappeler ce que GIMP est: un logiciel qui fait du traitement lourd et complexe. Avoir une meilleure machine si c'est une utilisation habituelle ne serait pas une mauvaise idée.

Avec des valeurs intermédiaires les inconvénients du 8bits seraient bien atténués tout en gardant une fluidité d'utilisation, et comme le 16bits ne semble pas indispensable y compris par les fabricants d'appareils photo ..

Tu veux dire proposer du 12, 14 bits, etc.? Ça ne changerait rien. Le nombre de bit ne changera pas la vitesse de calcul. Au contraire, si tu veux éviter un max les conversions, travaille en 32 bits.
Pour info, certains développeurs parmi nous veulent même se débarrasser du menu de choix des précisions pour que GIMP reste constamment dans son format optimal (32 bit float linear). La logique est que ce choix ne fait que perturber les gens qui ne comprennent pas bien comment tout cela marche, même si parfois ils croient avoir compris et vont alors faire des choix qui les desservent (et je m'inclus volontiers dans cette liste de gens, attention! Ce sont des sujets super compliqués et je veux pas te donner l'impression de te prendre ou qui que ce soit de haut. J'ai d'ailleurs récemment acquis un livre sur les couleurs pour essayer d'approfondir mes connaissances sur ce sujet). Il me semble que cette argumentation a du sens même si ce genre de choses sont encore en discussion. Personnellement je préfère que GIMP prenne ce genre de choix pour moi.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Je suis entièrement d'accord avec ppb31 ! :/

Alors soyons clair: je vous comprends tous les deux tout à fait. Si ça ne tenait qu'à moi, on aurait sorti une 2.10 en cachant toutes les fonctionnalités non finies y a plus d'un an. Mais voilà d'une, ça ne tient pas qu'à moi; de deux ça aurait été probablement une erreur quand je vois les changements de fond qui sont faits en ce moment par Mitch. On aurait sorti GIMP sans ces changements, cela aurait probablement été un très gros problème et même un boulet sur le long terme pour GIMP (car on fait attention à la compatibilité descendante, donc on doit être aussi sûr que possible de ne pas sortir avec des choses qui seront ensuite un poids à vie dans GIMP). Et c'est aussi dans ces moments-là où je suis content de pas être seul sur GIMP, du fait que ça ne tient pas qu'à moi, car je fais équipe avec plein d'autres gens compétents. :-)
C'est notre synergie qui fait de GIMP un logiciel final plutôt pas trop mal. ;-)

Et puis c'est exactement pour corriger ce problème de sortie qui prennent trop de temps qu'on allège nos règles de sorties en espérant ainsi pouvoir accélérer la sortie des majeures.

On nous fait languir et presque baisser « le soutient » (à l'instar de la garde) avec cette histoire d'un 2.9 avec du 16 bits pour les initiés… Donc à la fois oui, et non… :/

Quand je parlais que l'utilisation de la 2.9 était possible, ce n'était nullement pour dire que ça existe et que c'est sorti, donc qu'il faut simplement l'utiliser. J'ai d'ailleurs bien mis en garde sur les problèmes possibles. J'ai juste donné une alternative potentielle pour des utilisateurs avancés (car y en a pas mal sur linuxfr), au cas où ça intéresse de savoir. On est nombreux à utiliser la 2.9 en "production".
Mais oui je me rends bien compte que ce n'est pas la même chose qu'une stable et je suis bien conscient du problème de sortie. :-/

Et finalement, si tout cela ne tenait également qu'au financement ?

Tout à fait, c'est vraisemblablement le fond du problème. D'ailleurs merci encore pour y participer. ;-)
GIMP n'est pas une entreprise avec des délais à tenir, etc. C'est un projet communautaire essentiellement et on ne peut par forcer un bénévole à se dépêcher pour sortir une version dans les temps. Parallèlement nous ne sommes que 2 développeurs à vouloir essayer de vivre du logiciel libre et donc du développement de GEGL ou GIMP et le succès est mitigé pour le moment.

Donc je dirais que le fond du problème, c'est que d'un côté, y a l'image que les gens ont de GIMP (ils imaginent un gros projet avec des centaines de gars dont pas mal bossent dessus à temps plein, mais certains "saboteraient" le projet de l'intérieur) et la réalité, les faits (quelques péquins qui font ce qu'ils peuvent, la plupart en bénévoles sur leur temps libres; certains essaient de se financer, mais on n'y est pas encore).
Idéalement on arriverait à aligner la réalité à l'image (sans les parties "sabotage").

Parce que même si je comprends tout à fait ce que vous dites, ppb31 et toi, et je vois complètement votre "point de vue extérieur (utilisateur lambda non développeur)" (en reprenant les mots de ppb31), ben y a la réalité qui intervient: y a des limites à ce que quelques personnes seules dans leur coin peuvent faire. Et même si on aimerait en faire plus en se faisant payer (dans mon cas), en attendant on n'en a pas les moyens.

Enfin voilà, on fait ce qu'on peut. On espère que ça suffira et que vous apprécierez quand même!

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Justement à ce propos, il serait bien d'en savoir un peu plus sur les modes de donations (flattr ou autres) ; tout n'est pas très clair ?!

Pour GIMP? Alors déjà, comme tu le notes, oui nos fonds GIMP sont gérés par la fondation GNOME. C'est un peu comme si on avait un compte chez GNOME (et si je ne me trompe pas, ils prennent un pourcentage pour payer l'administratif supplémentaire que ça leur donne). La raison, c'est que GIMP en soi n'a pas d'entité juridique propre. C'est ce qu'on appellerait une association de fait dans les pays francophones (au moins en France et Belgique). Mais note bien que cet argent donné à GIMP va vraiment à GIMP. GNOME garde une comptabilité distincte et cet argent donné pour nous n'est absolument pas utilisé par GNOME. Il est juste gardé par eux en notre nom.

Ensuite à quoi sert cet argent? Il sert principalement à réunir les développeurs régulièrement, dans des évènements comme Wilber Week ou Libre Graphics Meeting. Cela ne paye pas directement du développement. Mais comme Pierre Jarillon le note dans un commentaire, les rencontres de développeurs restent très importantes et ne sont pas à négliger. Je ne veux surtout pas donner l'impression de vouloir minimiser cela et si c'est là où tu veux donner, merci!

Pour soutenir plus directement du développement, tu peux donner mensuellement directement à 2 développeurs seulement (c'est expliqué sur la page officielle de donation de GIMP), c'est à dire les 2 seuls développeurs en lien avec GIMP qui essaient de vivre du logiciel libre: Øyvind Kolås, le mainteneur de GEGL, et moi-même (second plus gros contributeur de GIMP après Michael Natterer, mainteneur de GIMP). Øyvind fait donc des trucs plutôt côté moteur graphique; moi je travaille plus sur l'interface graphique, l'utilisabilité, etc. J'ai aussi énormément travaillé sur la stabilité. C'est simple quand on a commencé à utiliser GIMP, en 2012, il plantait pour un oui ou pour un non. C'est d'ailleurs comme ça que j'ai vraiment commencé à contribuer (parce que j'ai commencé à corriger des bugs, puis de plus en plus) et depuis j'ai corrigé pas mal de crashs et bugs et j'aime à penser que de nos jours, on est pour beaucoup dans sa stabilité (c'est simple, on l'utilise des heures durant, tous les jours, et ça marche). Les contributions d'Øyvind et moi-même sont tout aussi essentielles et complémentaires; c'est à toi de voir ce que tu préfères financer.
Bon le financement d'Øyvind marche bien mieux que le notre, j'imagine que c'est beaucoup pour le fait que c'est parce qu'il est dans le projet depuis 13 ans, alors que nous seulement 5 ans. Et aussi qu'on est nul en marketing. Sûrement aussi que le double côté film + développement nous dessert car certaines personnes ne semblent pas vouloir payer pour un film d'animation, juste du développement logiciel. Mais pour moi, c'est essentiel, car je ne coderais pas sur GIMP autant si ça ne nous servait pas justement au quotidien. Nous sommes des contributeurs car c'est notre outil quotidien. C'est donc indissociable pour moi.

Voilà tu sais tout. Tu as donc 3 cibles de financement: le projet GIMP core (tu paieras alors tout le côté communautaire), Øyvind si tu veux financer du développement sur GEGL, et ZeMarmot pour financer du développement sur GIMP même, à un peu tous les niveaux. On peut être financé par Tipeee en euro, patreon en dollar, ou comme noté dans un autre commentaire, tu peux donner directement à l'association LILA qui est l'organisme chapeautant le projet ZeMarmot, évitant ainsi des frais de plateforme (par exemple avec un virement bancaire récurrent), avec un message expliquant que cette donation est pour le développement sur GIMP principalement.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Donc GIMP depuis 98, avec pas mal d'espoir de rattraper l’éternel Photoshop.

Juste pour être sûr qu'on se comprend, notre objectif n'est pas de "rattraper" Photoshop, ni de le copier. On fait notre propre logiciel de création graphique, aussi bien qu'on puisse et en Libre. Le but de GIMP n'a jamais été d'être un clone. Je ne dis pas que c'est ce que tu voulais dire. C'est pas très clair. Mais au cas où, je le précise car c'est un commentaire qu'on a régulièrement. :-)

Les soucis ne sont pas les fonctionnalités mais le flous éternel autour 12 et 16 bits natif. Les soucis ne sont pas les fonctionnalités mais le flous éternel autour 12 et 16 bits natif.

Il n'y a pas vraiment de flou, c'est très simple: en 2.8, y a prise en charge de 8 bits seulement, et en 2.10 y aura prise en charge 16 et 32 bits pour l'image de travail. :-)
Pour du 12 bits, je sais pas si y a des formats d'image qui ont cette profondeur, mais si oui, on devrait alors pouvoir exporter en 12 bits sans problème à partir d'une image de travail 16 ou 32.

Ensuite comme quelqu'un le note, la version de développement (estampillée 2.9) est déjà très fonctionnelle et stable au quotidien et te permettrait déjà de travailler des images en 16/32 bits. On utilise essentiellement la version 2.9 depuis plus d'un an pour le projet ZeMarmot. Maintenant soyons clair que c'est une version de développement et il peut y avoir de la casse. Pour une utilisation pro de la version de développement, il convient d'être tout de même un utilisateur éclairé au cas où les choses se passent mal. On fait gaffe, mais on ne peut absolument pas assurer une stabilité parfaite entre 2 versions de développement. Mais ça reste faisable. On le fait bien (mais évidemment en tant que développeur de GIMP, je suis un utilisateur assez éclairé aussi!).

Dractable, Krita, Blender ex.. avancent à pas de géants avec des moyens pas forcement plus important.

Vu de notre côté, on avance aussi bien, mais c'est moins visible car on ne sort pas de version avec nos avancées. Et donc oui, vu de l'extérieur, ça n'a pas l'air d'avancer et c'est frustrant, je le comprends tout à fait. D'où le problème de versionnement qu'on essaie de résoudre et dont je parle dans cette news.

Ensuite "des moyens pas forcément plus importants"… alors Darktable oui, c'est le seul de la liste où c'est vrai. Mais Blender ont leur fondation derrière qui a maintenant des moyens de plus en plus conséquents (pas encore gigantesque, mais ils font quand même des crowdfunding à plusieurs centaines de milliers d'euros, et touchent du financement européen du même ordre de grandeur, ils ont leur cloud avec abonnement, etc.), et Krita ont créé leur propre fondation et font du marketing à fond, des crowdfundings, etc.

GIMP reste essentiellement communautaire. Néanmoins il y a quelques développeurs, notamment moi, qui essayons justement de nous donner des moyens financiers. Le jour où notre financement Tipeee ou Patreon sera de quelques milliers par mois, alors oui on pourra commencer à dire qu'on commence à avoir des moyens pour développer GIMP professionnellement. À ce jour, le développement de GIMP est financé avec des cacahuètes.

Donc oui les numéros de version compte ça fait plus de 5 ans que le 3 est attendu

Qui attend le 3? On n'a même pas vraiment commencé à travailler dessus. Bien sûr, on a quelques commits de temps en temps, mais c'est minime. On maintient la branche juste assez pour qu'elle compile avec GTK+3. Et de temps en temps, on fait quelques trucs, mais c'est pas assez pour dire qu'y a du dév actif.
Le développement actif est quasi essentiellement sur la version 2.10. C'est là où les choses se passent et la seule version à attendre pour l'instant.

la 2.10 va encor donner l'impression que l'on avance à tous petit pas

Je ne comprends pas, le problème est juste une histoire de numéro? Chez GIMP, le second nombre indique une sortie majeure. 2.10 sera autant une majeure que 3.0. De même que 2.8 était une sortie majeure.
Bonne chose, mauvaise chose, je ne sais pas. Peut-être que cela changera un jour. J'ai l'impression qu'historiquement, cela suit simplement les versions de GTK+. Avec l'accélération du versionnement de GTK+, ça voudrait d'ailleurs dire que les versions de GIMP risquent d'accélérer aussi beaucoup après GIMP 3. On verra.

si GEGL est le moteur complet par défaut avec effectivement une prise en charge natif du 16 b et + politiquement ça ferrait dans les chaumières OUF !!!

Ben oui, GEGL a la prise en charge du 16 bit (même 32 bit, qui est maintenant le format natif de GIMP). C'est ce qu'on dit. Je pense que tu n'as simplement pas suivi les nouvelles de GIMP depuis… 4 ou 5 ans? ;-)
Bon bien sûr, ça implique de suivre les news de dév, puisqu'il n'y a effectivement pas de sortie de version stable. Donc je comprends l'incompréhension, pas de problème.

mais si les version avancent à tous petit pas ce la parais suspect à plus d'un

Qu'est-ce qui paraît suspect? Que GIMP est un logiciel libre développé à 99.999% par du bénévolat dans le temps libre, que personne ne bosse à temps plein, payé, et qu'on est pas un business? J'ai du mal à comprendre où tu veux en venir.

Personnellement j'aimerais bien en vivre et pouvoir faire cela (développer GIMP) à temps plein. Mais pour cela, il faut nous soutenir financièrement sur les liens du projet ZeMarmot donnés juste au dessus. Parce qu'autrement, nous dire que ça paraît "suspect" que ça avance pas plus vite, ben ça me fait juste mal au cœur. ;-(

À l'heure actuelle mon état d'esprit est le suivant: on finit notre épisode cette année et si on a pas atteint un financement acceptable pour vivre décemment (à l'heure actuelle, le financement ne paye même pas un loyer, surtout qu'on fait tout dans les règles et qu'y a des charges sociales en salaire, etc. C'est pour te dire que si y a une définition de la précarité, je rentre dedans), ben on commencera à chercher des alternatives et mon implication à GIMP en souffrira probablement drastiquement malheureusement. Et il n'y aura rien de "suspect" au fait que la rapidité de développement de GIMP diminuera beaucoup plus puisque je suis le second plus gros contributeur depuis plusieurs années. Ensuite il reste Mitch, qui fait 2 fois plus de commits que moi en ayant son propre business. Je sais pas vraiment comment il fait (enfin si, je sais; il contribue à GIMP depuis 20 ans et connaît son code bien mieux que moi, et aussi il a beaucoup plus d'expérience de développement en général que moi). Mais il est entièrement bénévole alors lui reprocher aussi de pas aller assez vite serait tout aussi aberrant.
Voilà j'espère que ça te donne une autre perspective sur le développement de GIMP et les "moyens" (assez imaginaires) que tu sembles imaginer derrière son développement.

Donc je souhaite bon courage à toutes les équipes de développent, je continuerai à promouvoir se formidable logiciel.
Bonne et belle journée à tous le monde

Merci. En tous cas, tu as l'air de bonne foi et amical (contrairement à d'autres cas; malheureusement contribuer à GIMP, c'est s'exposer à pas mal d'insultes et de haine et je suis pas toujours bien taillé pour cela; mais je travaille pour me durcir le caractère et être moins sensible à la méchanceté, car des fois ça a été dur). Mais je te conseillerais de faire attention dans ton choix de mots car ils peuvent être assez mal pris. Surtout quand justement je cherche à en vivre mais n'y arrive pas (j'ai parfois l'impression de faire des appels au crowdfunding dans le vide).
J'espère que mon explication t'aura un peu éclairé sur GIMP et son développement. :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Quelle serait la différence entre version mineure et majeure dans ce cas si les mineures ont de nouvelles fonctionnalités ?

Pour l'instant il y a quand même de grandes différences. En tous cas 2.10 avec un changement profond du moteur graphique (certes déjà en cours, mais jusqu'alors GEGL n'était utilisé que pour des trucs superficiels, maintenant c'est vraiment partout); puis 3.0 avec le passage à GTK+3, ce qui va débloquer aussi beaucoup de choses normalement, avec prise en charge améliorée des tablettes, amélioration des thèmes, route vers HiDPI, etc. Plein de choses merveilleuses et féériques qui nous sont promises. Ensuite je suis persuadé que tout ne sera pas magique et qu'il faudra travailler un peu pour y arriver, mais au moins on sera sur le chemin. Pour l'instant avec GTK+2, on est un peu contre un mur.

Mais oui peut-être qu'à terme, la différence entre une mineure et une majeure pourra s'amenuiser. Est-ce un mal? Je ne pense pas. Même le noyau Linux n'a pas vraiment de différence entre ses majeures et ses mineures. On le voit bien dans les emails de Linus pour décider les passages de majeures, en général il l'accompagne d'une blague, genre "j'ai plus assez de doigts pour compter". Et voilà on est passé sur une majeure version 4.x du noyau sur un coup de tête et un sondage sans aucune autre logique que "est-ce que vous avez envie ou pas qu'on passe à v4?"
Est-ce un problème? Je ne pense pas vraiment, surtout si ça permet de rendre le développement plus énergique (on peut sans cesse créer des nouvelles fonctionnalités attrayantes!).

Ce serait un système à la Firefox ou à la Libreoffice ?

Firefox, oui. Je ne sais pas quel système utilise LO, mais si c'est comme Firefox, alors oui aussi.

La seule chose que je voudrais faire différemment que Firefox, c'est de garder une promesse de stabilité de l'API un certain temps. Et pour ça, les versions à point restent un bon moyen simple pour reconnaître la stabilité, contrairement à un simple entier. Firefox, de ce que je comprends, c'est qu'ils cassent l'API sur un coup de tête un peu n'importe quand, et que pour un dév de plugin, il faut vraiment se tenir à jour à chaque version et lire le changelog en détail. Avec une promesse de stabilité basé sur un numéro de version, c'est facile: le premier chiffre est le même, donc mon plugin continuera à fonctionner.
Je pense que cela reste un très bon intérêt aux numéros à point.

Ensuite, je me réserve le droit de changer d'avis dans un sens ou l'autre. ;-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut !

Je ne m’attendais pas à ce que ça passe en première page. Sinon, j’aurais mieux écrit mon journal…

Dans ce cas, je tiens à préciser que lorsque je parle de « résumé des points importants », ce sont des points importants « personnels ". D’autres contributeurs ont aussi bossé sur des choses très importantes. Notamment, il y a eu un travail (qui est toujours en cours) très important sur la base de Linear is the new black par Pippin, Mitch et les contributeurs GEGL. Ce travail se base sur le principe que les images en 32 bits flottants en lumière linéaire sont le format de travail idéal.

Aussi, les modes de calques (et plein d’autres fonctionnalités) ont été revus et l’interface utilisateur mise à jour par Mitch, en se basant sur le travail précédent. Bien sûr, comme la compatibilité descendante est un besoin majeur pour nous, les anciennes implémentations de modes sont toutes présentes à vie et utilisées en chargeant de vieux documents (de sorte qu’un ancien XCF aura toujours le même rendu, même dans 10 ans)¹ mais l’interface utilisateur est faite de telle sorte que les nouveaux documents utiliseront les nouvelles implémentations (bien qu’il restera possible de trifouiller pour retrouver les anciennes). Je ne veux pas trop parler de cela en détail, car j’ai peur de dire des bêtises.

Un peintre et contributeur (de rapports de bogues, d’idées, de propositions d’amélioration…), Americo Gobbo, fait d’ailleurs pas mal de recherche sur les nouvelles possibilités de GIMP en la matière, surtout les applications directes à la peinture numérique grâce aux nouveaux modes de calques. Notamment, il peint en texturant ses brosses. Voir ses expérimentations, par exemple ça ou encore ceci ou cela… Il fait aussi quelques vidéos intéressantes sur le sujet.
Il n’était pas présent à Wilber Week (il sera à LGM, je l’ai invité au nom de GIMP car son travail est intéressant et important pour améliorer GIMP et son interface graphique), mais ses expérimentations de brosses et textures se basent directement sur des changements de code de janvier.

Lands Improvisations, par Americo Gobbo (expérimentations d’ajout de texture sur les brosses avec les modes de blend/composition)

Et c’est sans parler du travail de Elle Stone (qui n’était pas présente non plus mais est souvent sur IRC), une experte des couleurs et algorithmes, l’une des plus grosses critiques de GIMP, mais en même temps une contributrice majeure en revue de code et d’algorithme ultra‐poussé (elle n’est pas développeuse, mais elle lit le code à l’occasion et fait des correctifs algorithmiques), tests de versions de développement au pixel près, pointage de problème (on ne peut rien cacher sous le tapis avec elle !) avec force insistance, etc. Je ne comprends pas tout ce qu’elle dit car elle est très calée, mais ses revues sont de grande valeur.

On a aussi eu un contributeur (qui ne veut pas voir son nom cité) dont le trip est d’implémenter des algorithmes de recherche, et il a fait pas mal de contributions sur GEGL et aussi sur GIMP lors du Wilber Week. Il fait d’ailleurs du code de très bonne qualité. On espère qu’il restera avec nous. :-)

Il s’est donc passé pas mal de choses pendant et autour de cette Wilber Week. On était plusieurs développeurs et contributeurs sur place (et d’autres qui ne pouvaient venir, genre Ell, un contributeur majeur de ces derniers mois). Voilà, je voulais donc revenir un peu sur mon impression de compte‐rendu, qui a l’air bien terne si jamais on croit que c’est le compte‐rendu complet de Wilber Week : ça ne l’est pas ! C’était un compte‐rendu tout à fait personnel. D’ailleurs, on prévoit aussi un compte‐rendu plus global de l’évènement sur gimp.org.

C’est personnel dans le sens : je m’y suis impliqué. Pas dans le sens « le reste m’intéresse pas », bien entendu. :P
C’est super excitant ce que d’autres font en parallèle. C’est ça aussi qui est cool : travailler dans une équipe hétéroclite qui bosse sur plein de trucs différents tous très intéressants ! Franchement, je n’aimerais pas donner l’impression que Wilber Week, c’était juste pour faire un paquet Flatpak et discuter du changement de logique de version à dix personnes pendant une semaine (aussi intéressants que soient ces deux items !). Cette dépêche a peut‐être été promue un peu vite. Si j’avais su… Il aurait fallu la compléter un peu avant. :-)
Mais merci quand même ! ;-)

[1] Pour la petite histoire, sous Photoshop, pa exemple, certains fichiers identiques peuvent apparaître différemment selon qu’ils sont ouverts avec CS5 ou CS6. C’est un problème assez sérieux pour des gens qui travailleraient en équipe avec versions disparates (problème classique dans le logiciel propriétaire, car mettre à jour signifie payer une mise à jour de licence) ou simplement pour réutiliser ses vieux documents.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Je confirme, ZeMarmot a reçu un soutien très généreux de GNU Computer. Merci beaucoup! :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Par contre une version mineure n'en est plus une si des nouveautés apparaissent.

Pourquoi? C'est qu'une question de définition. Hormis le fait qu'historiquement beaucoup de projets (dont GIMP) suivaient effectivement cette définition, tu peux tout à fait redéfinir, et dire par exemple qu'une version majeure, c'est quand tu changes quelque chose de… majeur justement (comme le moteur graphique, cas de GIMP 2.10, ou le toolkit graphique, cas de GIMP 3), et une mineure, c'est le reste.

D'ailleurs, si on souhaite se rapprocher du "versionnement sémantique", utilisé massivement, surtout pour des bibliothèques (peu les logiciels finaux) libres, tu peux tout à fait rajouter des fonctionnalités dans une mineure. Ce qui importe, c'est de le faire en restant compatible avec l'existant (tant qu'on ne change pas de version majeure). GIMP fournissant aussi une API (pour les plugins), c'est le cas, ça l'a toujours été et ne changera pas: les plugins existants resteront compatibles (d'ailleurs le numéro majeur considéré pour la libgimp est le premier, comme habituellement en semver, alors que pour le logiciel GIMP, c'est le second qui fait la majeure; donc notre API est encore plus conservative que le logiciel graphique, et c'est bien).

Personnellement le type de sortie continue que je vois, on ne ferait simplement plus de différence entre majeure et mineure. Simplement on pourrait sortir sans arrêt des mises-à-jour, que ce soit avec juste un correctif, ou avec une nouvelle fonctionnalité. Comme beaucoup de logiciels font de nos jours (notamment Firefox). Je sais que ça a fait jaser à l'époque de Firefox et que les gens ont cru que c'était juste un coup marketing (pour avoir le numéro de version le plus haut possible), mais je pense que cela pourrait vraiment libérer le développement. Pouvoir sortir des nouveautés sans arrêt, dès qu'elles sont vraiment finies, c'est super. Pourquoi s'encombrer avec des règles artificielles?
Bien sûr, il faudra garder des règles de compatibilité pour les plugins tout de même. Par exemple sur Firefox justement, les problèmes sont nombreux et beaucoup d'entre nous perdent des plugins régulièrement aux mises-à-jour. ;-( Un peu plus de stabilité serait bienvenu.
Donc en un sens, on peut garder les concepts de majeures et mineures mais limiter cela aux APIs ou aux changements graphiques vraiment profonds. Et c'est un peu la direction que nous prenons avec GIMP.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]