Cet article est la traduction d’un premier entretien avec les mainteneurs, développeurs et utilisateurs de GIMP, entretien initié et réalisé par Jehan et paru sur GIMP.org le 1ᵉʳ mars 2017 sous licence CC-by-SA.
D’autres devraient suivre que nous nous ferons un plaisir de vous signaler et pourquoi pas de traduire !
Sommaire
Présentation
GIMP est un logiciel libre, mais c’est avant tout des gens : ceux qui le créent et ceux qui créent avec… Nous n’avons aucune statistique précise et sommes fiers de ne pas collecter vos données personnelles. Mais nous savons (grâce à certains sites qui ont enregistré des statistiques réduites au fil du temps) qu’il s’agit d’un logiciel largement utilisé, par des millions d’utilisateurs à travers le monde. Ne serait‐ce pas chouette de rencontrer quelques‐unes des personnes qui contribuent à faire vivre ce projet ?
Certains pensent que derrière GIMP, il y a une grosse entreprise. Ça n’est pas le cas. GIMP a toujours été développé par un petit groupe hétéroclite de contributeurs, disséminés de par le monde. La plupart sont bénévoles et aucun n’y travaille à temps plein. Faisant moi‐même partie du groupe, j’ai voulu initier une série d’entretiens avec les nombreuses et exceptionnelles personnes que j’ai rencontrées depuis mes débuts de contributeur GIMP. Quoi de mieux que de commencer avec notre propre dictateur éclairé, mainteneur de GIMP et le plus important développeur : Michael Natterer, dit « mitch ».
Cet entretien s’est tenu le vendredi 3 février 2017 vers 3 h du matin, devant une cheminée et après une journée d’implication pendant la Wilber Week. Parmi nous, plusieurs membres de l’équipe GIMP, dont Michael Schumacher (schumaml (S)) et Øyvind Kolås (pippin (P)), qui ont aussi participé aux questions.
Mitch. L’homme. Le mythe. La légende.
La raison du rejet probable de votre modification.
Jehan : Salut Mitch ! En quelques mots, quelles sont les prévisions pour le futur de GIMP ?
Mitch : Le portage vers GEGL est réalisé dans la 2.10. Ensuite, ce sera le portage GTK+ 3, qui devra aller aussi vite que possible. Nous n’avons prévu que peu de fonctionnalités pendant le portage GTK+ 3.
J : Quelles sont tes fonctionnalités préférées de la 2.10 ?
M : La profondeur accrue du codage des couleurs, la prévisualisation des filtres directement sur le dessin… Je ne me rappelle plus les fonctionnalités de la 2.8 [pour les comparer], car je ne l’utilise jamais.
J : Tu utilises plutôt la 2.10 ?
M : Oui.
J : Utilises‐tu souvent GIMP ?
M : Principalement pour tester mes développements, mais aussi pour réaliser des cartes postales que je vends dans le magasin familial. Je l’utilise seulement pour ça.
Mainteneur de GIMP
J : Comment as‐tu commencé à bidouiller GIMP ?
M : Il y avait du code pour enregistrer les raccourcis clavier définis par l’utilisateur, pour les actions des menus. Ce code prenait mal en compte les caractères non alphanumériques et on ne pouvait utiliser le trait d’union comme raccourci clavier. J’ai donc écrit le code qui permettait de correctement analyser cette chaîne de caractères. C’est mon premier correctif GIMP en 1997 ou 1998.
J : Comment en es‐tu devenu le mainteneur ?
M : J‘ai assassiné le précédent mainteneur. Il est désormais dans ma cave, dans des boîtes.
Schumaml : As‐tu déjà rencontré les auteurs originels (Spencer Kimball et Peter Mattis) ?
M : Non. Quelqu’un les a déjà vus ?
S : Ils t’ont déjà contacté ?
M : Oui, ils m’ont envoyé quelques extensions que j’ai acceptées. Néon, photocopie et dessin au crayon. C’était environ dix ans après avoir quitté le projet, l’un d’entre eux est venu vers moi et m’a dit « Eh Mitch, j’ai codé trois extensions, elles sont ici. » Tout était parfait, je les ai donc acceptées telles quelles et elles sont toujours là.
Récemment, elles ont été réimplémentées avec GEGL, mais les nouvelles versions donnent des résultats différents, donc les anciennes extensions sont toujours disponibles dans le menu.
J : Pourquoi continues‐tu à travailler sur GIMP ?
M : Très bonne question. [il rit] Je ne sais pas. Peut‐être pour vous ? Parfois c’est chiant. Pourquoi tu continues, toi ?
J : Moi ? Pour le fun.
M : Pour s’amuser, oui, mais parfois ce n’est pas marrant et on le fait tout de même.
Des GIMPeurs à Montserrat.
J : Comment verrais‐tu GIMP dans les vingt prochaines années ?
M : Ça va probablement finir comme un tas de bits pourrissant dans un coin. Cependant je pensais probablement la même chose il y a vingt ans, alors qui sait ?
… et bidouilleur
J : Que penses‐tu du logiciel libre ?
M : C’est le choix d’avenir, mais il faut utiliser le logiciel à disposition et, pour certaines activités, on peut ne pas avoir d’autre choix qu’utiliser une solution qui n’est pas tout à fait libre.
Par exemple [montrant Nomis en train d’essayer de faire marcher une étiqueteuse via une distribution GNU/Linux], en utilisant le pilote propriétaire, ça fonctionnerait.
* : [rires]
J : Quel est ton système d’exploitation, ta distribution, ton bureau ?…
M : Debian Sid, GNOME 3.
J : Mais, tu t’en plains souvent.
M : Parce que c’est de la merde. Ce n’est pas parce que vous avez le [logiciel le] moins merdique que ça n’est pas de la merde. Comme autotools. C’est de la merde, mais c’est la meilleure merde que nous ayons. Il n’y a pas un seul logiciel qui ne soit pas merdique, sauf peut‐être le logiciel le plus simple, qui fait une chose et seulement une.
J : Quel est ton environnement de développement ou l’éditeur de texte de ton choix ?
M : La console et Emacs
J : Comment aimes‐tu bidouiller ?
M : Ça dépend. Parfois j’ai besoin de silence et parfois d’une pièce pleine de monde.
J : Tu as ton propre magasin. Mais on voit passer tes modifications tout le temps. Développes‐tu quand tu as du temps libre dans ta librairie, quand aucun client ni employé ne te sollicite ?
M : Vraiment peu. La plupart du temps, je développe pendant la soirée, ou bien j’enregistre pendant la journée les modifications faites la nuit jusqu’à 2 h du mat’. Si je me dis « Je ferais mieux d’aller dormir avant d’enregistrer ça », alors j’attends d’être au lendemain, réveillé, pour vérifier encore une fois avant d’enregistrer la modification.
Mais je n’ai pas le temps de travailler 5 h en continu sur GIMP pendant mon temps de travail.
J : Tu ne dors jamais ?
M : Pas vraiment, non.
S : Quel moyen utilises‐tu pour communiquer au nom de ou dans le projet ?
M : IRC et IRC
pippin : Sur quel ordinateur as‐tu commencé à coder ?
M : C’était un Schneider CPC, un modèle très proche de l’Amstrad. Vers 15 ou 16 ans…
S : Comment as‐tu écrit ton premier « hello world » ?
M : En BASIC évidemment. Mes langages de programmation sont BASIC, assembleur, Pascal, Modula-2 et C, dans cet ordre singulier. ☺ Plus quelques autres langages, à l’université, dont tout le monde se fiche. ☺
J : Est‐ce que tu développes sous influence ?
M : Toujours ! C’est la seule manière de coder.
XKCD de circonstance, par Randall Munroe ; traduction par Sophie, Philip et Antoine ; Creative Commons By-NC 2.5
GIMP : présent
J : Bon, tous les logiciels sont pourris, mais dans la liste des logiciels merdiques, GIMP ne s‘en sort‐il pas trop mal ?
M : Je l’espère, mais à l’évidence GIMP est pourri. Nous ne sommes qu’une poignée de bénévoles qui font le travail qu’une société ferait avec des centaines d’employés rémunérés.
J : Mais parfois nous faisons les choses plutôt bien, non ?
M : Bien sûr, mais personne ne peut s’en assurer. On peut rarement consacrer le temps et l’énergie nécessaire à rendre une extension parfaite. Ça arrive parfois, mais généralement on nous balance un code et ça en reste là… Dix ans plus tard, on jette un œil au code et on se dit « mon dieu, c’est horrible ». Il peut arriver, rarement, qu’un contributeur maintienne son code dans la durée, mais on ne peut sérieusement s’attendre à ce que tous les contributeurs le fassent, puisque tout le monde est bénévole.
S : Y a‐t‐il quelque chose que tu aimerais faire plus dans le projet, en dehors du développement ?
M : Dans GIMP ? Non, c’est chouette de coder. Je suis content de ne pas avoir plus d’administratif à faire.
S : Quand la 2.10 sera‐t‐elle publiée ?
M : Roh, mais va chier ! La réponse est « va chier ». Pour confirmation, j’ai bien dit : « va chier ». Quand ce sera prêt.
S : C’est prévu pour cette année [2017, N. D. T.] ?
M : Ben, oui.
J : C’est donc enfin un engagement ?!
* : et, là, tout le monde se marre.
GIMP : futur
S : Il y a ces rumeurs, comme quoi l’interface graphique pourrait utiliser Python et le cœur, le C.
M : Python pour l’interface utilisateur. N’importe quoi ! Pourquoi ça ?
S : Ça fait partie des discussions que nous avons eues.
M : Oui, mais par le passé certains voulaient utiliser JavaScript. L’année d’avant c’était Java, encore un an avant c’était ceci et l’année suivante cela. Maintenant ils ont tous disparu.
De tous ceux qui disaient « Je veux utiliser ceci ou cela » et « C’est vraiment de la merde, utilisons JavaScript », aucun ne fait encore partie du projet, donc…
S : Tu ne vois donc aucun changement majeur concernant GIMP dans un futur proche ?
M : Prochainement, vraiment non, parce que nous devons absolument publier les prochaines versions. À moins, bien sûr, que n’arrive une modification très bien réalisée et qui ne nécessite pas des semaines de discussions et de multiples aller‐retour de négociation sur la façon dont les choses devraient être faites.
Sur l’utilisation d’autres langages de programmation : pourquoi pas ? Par exemple, Rust. Il se peut qu’il y ait des trucs plus simples pour l’interface utilisateur, mais ce genre de décision, sur une base de code de la taille de GIMP, ne peut se prendre en fonction du « dernier truc à la mode ».
Par exemple, regardez le bordel avec JavaScript. Est‐ce vraiment mieux ? Juste pour la facilité ? Facile veut simplement dire que plus d’ignorants pourront écrire du code, et il y a déjà assez d’ignorants. Rendre plus facile ne veut pas dire rendre meilleur. Arrogant, mais vrai.
S : Autre chose que tu voudrais changer ?
M : Oui, un paquet, du moment que je n’ai pas à faire tout le boulot, j’ai déjà bien suffisamment à faire [il rit].
Vous pouvez devenir le mainteneur de n’importe quel composant. S’il vous plaît. Enlevez‐moi du boulot. Chaque contributeur doit être conscient que s’il fait un très bon travail, il peut prendre en charge sa partie.
J : C’est un bon point à rappeler.
M : Si tu le fais bien, tu peux donc prendre en charge la partie sur laquelle tu travailles. Ça a toujours fonctionné comme ça.
S : Il n’y a pas besoin d’obtenir ta bénédiction ?
M : Je ne bénis personne. [il rit]
J : GTK+ vient de GIMP. Que penses‐tu de GTK+ à l’heure actuelle ?
M : Ils sont devenus fous, mais ils font aussi du super bon boulot. Seulement, je ne comprends pas certaines de leurs décisions.
D’un autre côté, regarde les courriels que nous recevons. Les gens disent exactement la même chose de GIMP : « Les développeurs de GIMP ont‐ils perdu l’esprit ?! ». J’ai été pendant longtemps impliqué dans GTK+ et les gens pensaient que j’étais fou, ce qui était (et est) probablement vrai. En somme, tout va bien entre GTK+ et GIMP, je me réserve juste le droit de me plaindre.
S : Donc, GIMP 3 c’est avec GTK+ 3 ou 4 ?
M : Ils viennent juste de démarrer le travail sur GTK+ 4.x, donc ça ne va pas arriver demain.
P : Cela ne ferait pas de mal de passer soudainement à GIMP 4 au lieu de GIMP 3.
M : En effet. S’ils finissaient dans quelques semaines, on démarrerait GIMP 4 sur‐le‐champ. Pourquoi pas. Ce serait marrant. [il rit] Ou GIMP 5 !
J : GIMP 10 ?
M : GIMP X !
Questions diverses
S : Si tu te trouves à discuter de GIMP avec des gens qui ne connaissent pas ton implication dans le projet, est‐ce que tu te présentes comme le principal développeur de GIMP ?
M : Seulement s’ils commencent à dire des conneries ou s’il y a des choses à clarifier. C’est déjà arrivé, bien entendu. Une fois, un mec voulait me convertir à GIMP et j’ai dû lui dire : eh, ça n’est pas la peine. C’était dans un contexte grand public.
J : Qui est Wilber ?
M : Personne ne le sait. Wilber est un GIMP.
S : Sur quel matos particulier aimerais‐tu voir marcher GIMP ?
M : Ce truc super de Microsoft (un Surface Studio), il y a une très bonne vidéo en ligne et ça semble exceptionnel avec le tactile et toutes les interactions. C’est une pub comme Apple faisait avant et maintenant c’est Microsoft, c’est un peu étrange. La vidéo YouTube officielle donne très envie d’en avoir une.
S : Quel conseil aimerais‐tu donner à tous ceux qui voudraient contribuer ? Que faut‐il faire et ne pas faire ?
M : Écouter les conseils et être persévérant. Ne pas lâcher l’affaire parce quelqu’un dit « cette modification n’est pas tout à fait bonne », la plupart du temps elle ne l’est pas. Ma première modification dans GIMP a été immédiatement annulée.
S : Je crois que tu as aussi annulé ma première modif.
M : Oui, c’est un peu une tradition. Tout le monde fait des erreurs dans sa première modif et elle est alors annulée. C’est de bon aloi.
S : Donc ne pas avoir peur des erreurs ?
M : Exactement. À moins que l’erreur ne menace le destin de l’humanité, ou quelque chose du genre. C’est improbable.
* : Merci pour cet entretien.
M : De rien !
Mitch à l’œuvre
Les images de cet article sont de Antenne et sous licence CC-by-SA.
# Vrai
Posté par gasche . Évalué à 10.
C'est très vrai, cette interview. On retrouve bien dans ces propos les réactions des gens qui ont été mainteneurs pour un moment… et qui ont conservé le sens de l'humour.
# autotools
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Qu’est-ce qui vous lie tant que ça à autotools ?
[^] # Re: autotools
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
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
./configure20 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):
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 demake distet encore moins demake distcheck, 2 commandes super importantes. Il faut donc les implémenter soi-même.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 ]
[^] # Re: autotools
Posté par Le Gab . Évalué à 4.
Blender a migré à CMake après un passage par SCons et ça marche plutôt très bien.
Je suis pas dev C/C++ mais bon, cela me semble être une bonne démonstration. :)
[^] # Re: autotools
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
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 ]
[^] # Re: autotools
Posté par liberforce (site web personnel) . Évalué à 7.
Et Meson ? Emanuelle Bassi, un des mainteneurs de GTK+ a commencé à sérieusement se pencher dessus en portant graphene à Meson. GStreamer builde 10× plus vite sous Windows et 2,5× plus vite sous Linux depuis sa migration de autotools à Meson. Avec son backend Ninja (utilisable aussi dans CMake) pour remplacer make la gestion des dépendance a l'air plus simple, et il n'a pas les trucs sales et confus de CMake pour la gestion des listes et des séparateurs. Sa logique est d'utiliser les options pertinentes par défaut aussi (gcc -Wall par exemple est actif de base). Mais il est vrai que meson utilise aussi un fichier externe pour la cross-compilation.
Bref, tout ça pour dire que les autotools ne sont plus une fatalité. Meson n'est pas forcément encore 100% mature, mais s'il l'est assez pour un projet comme GStreamer, c'est tout de même quelque chose à regarder pour le jour où vous en aurez mare de CMake et des autotools. En attendant, tu peux utiliser CMake avec le backend Ninja.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 10 mars 2017 à 23:01.
Ce commentaire a été supprimé par l’équipe de modération.
# Paradoxe
Posté par Thomas Douillard . Évalué à 2.
Très sympa comme interview, j’aime le détachement et le sens de l’humour dont il fait preuve.
Un truc me fait tilter : d’un côté il semble preneur de toute personne qui pourrait lui virer du boulôt, mais d’un autre il se la joue élitiste en parlant des gens qui ont à un moment tenté d’insérer des technos « à la mode » pour lesquelles c’est probablement plus simple de trouver des compétences. Ça n’aurait pas aussi tendance à diminuer la qualité et à faire fuir les contrbuteurs de maitenir les choses plus « difficiles » ?
[^] # Re: Paradoxe
Posté par Wawet76 (site web personnel) . Évalué à 10.
Bah un souci c'est que quelqu'un qui arrive pour introduire une techno à la mode puis qui ne reste pas maintenir le truc, ça n'enlève pas du boulot. Ça en ajoute…
Pour un logiciel qui a plusieurs dizaines d'années et qui compte exister encore longtemps, je trouve ça normal de ne pas trop succomber aux sirènes de la mode. Je trouve l'avis du type interviewé assez pertinent sur ce point.
[^] # Re: Paradoxe
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
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 ]
[^] # Re: Paradoxe
Posté par Thomas Douillard . Évalué à 2.
Mmm parler « d’excuse » dans le cadre d’un projet bénévole me surprend un peu. Comme tu le dis plus haut, c’est un projet bénévole, pas comme si il fallait chercher des excuses pour ne pas avoir rempli un contrat avec contreparties.
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 ?
[^] # Re: Paradoxe
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
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.
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 ]
[^] # Re: Paradoxe
Posté par Thomas Douillard . Évalué à 3.
J’y suis sans doute allé un peu fort. 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
Cela dit j’ai quand même une remarque (ou une question) : si 80% du code c’est de l’ui, c’est une proportion assez gigantesque. Du coup, faire ça en C avec Gtk, je comprend que ça prenne du temps. Mon impression c’est qu’il y a pas mal de boilerplate et que c’est assez verbeux. Ç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)
Vous utilisez des interface genre glade ? Comment vous développez en fait ? J’ai l’impression qu’à ce niveau d’UI çà devient important de se poser la question de la pertinence des technos concernant l’UI. Comment vous voyez les choses de ce côté là ? 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é)
[^] # Re: Paradoxe
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
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?
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.
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.
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.
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+).
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!
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 ]
[^] # Re: Paradoxe
Posté par Guillaume Denry (site web personnel) . Évalué à 8. Dernière modification le 09 mars 2017 à 08:22.
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.
En effet, en programmation, on passe une grosse partie du temps (la plus grosse ?) à relire du code (pour le comprendre ou le comprendre à nouveau) plutôt qu'à en écrire. C'est pour ça que je préfère m'intéresser à des langages qui permettent une meilleure lisibilité plutôt que ceux qui me facilitent la vie pour l'écriture. Quand les deux sont là, c'est encore mieux.
Je suis originellement un programmeur C, et si à une époque, j'ai pu louer les mérites d'une lib comme GTK (car elle permet par exemple de façon assez élégante de faire un peu polymorphisme), je pense que j'aurais maintenant pas mal de difficultés à "rentrer" dans une IHM écrite en C depuis que je connais autre chose. A une époque, j'étais très branché Qt qui a l'avantage de se concentrer sur une sous-partie de C++, maintenant, je pense en particulier aux langages fonctionnels comme Elm.
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.
[^] # Re: Paradoxe
Posté par Thomas Douillard . Évalué à 3.
Voilà, je pense que tu as mieux réussi à exprimer ce que j’avais derrière la tête que moi :)
[^] # Re: Paradoxe
Posté par Jehan (site web personnel, Mastodon) . Évalué à 8.
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.
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 ]
[^] # Re: Paradoxe
Posté par Thomas Douillard . Évalué à 2.
Ben typiquement utiliser glade dans l’interface ce serait pas une révolution, permettrait une migration incrémentale et faciliterai certains trucs (y compris pour les non codeurs).
[^] # Re: Paradoxe
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
(l'emphase est de moi)
Héhé, mais c'est justement le point central ici, comment juger si le gain sera d'être juste "un peu plus rapide ensuite" et non pas d'être plus efficace, d'offrir un contexte de programmation plus agréable ?
Et puis le plus important; on est ici dans un rapport entre développeurs qui n'est absolument pas guidé par l'urgence impérieuse de vendre un produit, de devoir attirer une masse critique d'utilisateurs de telle sorte que des gens puissent en vivre. Non, ici les gens font ce qu'ils aiment et façonnent le projet comme ils l'entendent, suivant leurs propres contingences, donc dans la phrase "doit-on passer des années à passer une majeure partie du code de GIMP en un autre langage", le "doit-on", on peut bien se demander quel en serait le moteur ? En passant, ta question est assez biaisée, car tu en conclus d'emblée qu'on ne peut travailler sur des refondations sans arrêter immédiatement aussitôt toute innovation à côté.
Mais en fait, j'ai presque envie de ne plus continuer à débattre de ce sujet, car je trouve que c'est stérile, mais pas dans le mauvais sens du terme, tu es un très bon interlocuteur et très pertinent et surtout quelqu'un qui fait et participe, ce que je ne suis pas vraiment ces temps ci :)
C'est juste que débattre de tout ça n'a qu'un intérêt relatif ; si quelqu'un voulait vraiment un GIMP programmé dans un autre langage, il se retrousserait les manches et commencerait d'abord à bâtir de nouvelles fondations dans le langage de son choix, puis élaborerait probablement une stratégie pour pouvoir utiliser un maximum de fonctionnalités du GIMP traditionnel pour permettre de les migrer ensuite progressivement, tout en essayant de convaincre un maximum de personnes de l'intérêt de sa démarche (ou bien, soyons réaliste, il serait tenté par créer un nième nouveau projet, d'ailleurs…). Mais cette impulsion, dans ce type de projet non gouverné par le pognon et la survie, ça vient justement des gens qui font. Et les gens qui composent GIMP sont comme tous les autres, s'ils voient un truc qui suscite leur intérêt, ils n'auront aucun intérêt à le rejeter d'un revers de la main, j'en suis convaincu.
J'ai un peu de mal à percevoir la pertinence de cet exemple : on parle ici d'un projet qui n'a ni l'envergure, ni l'ancienneté ni la notoriété de GIMP. En conclure que le fait qu'ils aient moins de contributeurs que vous donne une indication sur l'intérêt d'utiliser Python me semble un peu étrange :)
[^] # Re: Paradoxe
Posté par betonniere (site web personnel) . Évalué à 2.
Il me semble que Photoshop est écrit en C++. Sait-on si ils envisagent de migrer vers un autre langage ?
[^] # Re: Paradoxe
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Le C++ est il me semble un langage très très utilisé dans les outils comme Photoshop, Maya, etc.
Quel serait l'intérêt d'Adobe d'utiliser autre chose ?
[^] # Re: Paradoxe
Posté par gpe . Évalué à 4.
En quoi le contexte de programmation en C n'est pas agréable ? Avec la multitude d'outils qui existe autour de ce langage je trouve au contraire que c'est agréable de faire du C.
J'ai essayé de faire du Python mais je n'ai vraiment pas accroché mais bon ça fait presque 30 ans que je fais du C. Ceci explique peut-être cela?
[^] # Re: Paradoxe
Posté par liberforce (site web personnel) . Évalué à 4.
Bin on peut faire du GTK+ dans plein de langages. C'est pas parce que la bibliothèque est en C que le code applicatif doit l'être: on fait du GTK en C++ (gtkmm), python (pygobject), Rust, etc.
Ensuite, sur la question de la réécriture à partir de rien d'un projet en C évoqué par Jehan: le langage Rust permet de faire de la réécriture par morceau. C'est ce que fait Federico Mena Quintero (co-fondateur de GNOME, mainteneur de librsvg) avec la librsvg qu'il migre petit bout par petit bout du C vers le Rust depuis octobre dernier. C'est un langage particulièrement adapté au parsing de fichiers, parce qu'il t'assure à la compilation une bonne gestion de la mémoire (pas de double free, pas de fuite mémoire), favorise le parallélisme… Alors oui, c'est un peu la "mode" mais si Firefox et librsvg s'y mettent, il y a peut être de (bonnes) raisons, et pas juste de l'effet de mode…
[^] # Re: Paradoxe
Posté par Thomas Douillard . Évalué à 1.
Remplace «moule» par «culture de projet» si le mot te gène. Toute projet avec une communauté à sa culture de projet. Ça va des aspects techniques à des valeurs partagées - je t’ai vu récemment parler de méritocratie par exemple, la volonté d’ouverture, «talk is cheap, show us the code» (je subodhore) … Tu bs juste l’impression qu’il n’y a pas de moule parce que tu es tellement déjà dedans que tu t’en rend pas compte :p
C’est pas une critique en soi, faut juste en avoir conscience. J’ai tendance à penser qu’une véritable ouverture doit aussi passer par la réinterrogation de ce paradigme, quand c’est nécessaire.
[^] # Re: Paradoxe
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
Bon écoute, je vais arrêter la discussion là. Si vraiment tu as envie de croire qu'il y a forcément un "moule" ou une "culture de projet" (ou n'importe quel terme que tu préfères) et si ça te paraît invraisemblable de penser que peut-être l'équipe de GIMP est simplement faite de gens disparates et ouverts aux autres et aux contributeurs, bon bah… fais toi plaisir.
Je vais quand même finir en te donnant ma vision: nous sommes tous super différents dans cet équipe (dans certains cas même des "extrêmes" assez opposés). Y a vraiment pas de "culture". Tu n'es pas obligé de croire mon affirmation et tu peux penser ce que tu veux (sans même nous connaître, mais apparemment cela ne te gêne pas).
D'ailleurs mon intro d'interview n'est pas écrite au hasard, quand je commence par "GIMP est un logiciel libre, mais c’est avant tout des gens". Car oui, on est des gens, pas un bloc unique tous pareils. C'est le cas de la majorité des groupes (tous même?!), et croire en une sorte de "moule", c'est le premier pas vers une théorie du complot. Mais non, y a pas de ça. Y a pas de grand complot GIMP. On est juste des individuels qui se rassemblent car on a une occupation commune à un moment de notre vie (mais tous avec un but différent qui nous y a conduit par divers chemins). Si c'est impossible à imaginer pour toi, tant pis. C'est dommage.
Je suis à peu près sûr que je n'ai jamais parlé de méritocratie. Ou alors j'étais bien bourré (et je veux bien un lien de l'endroit où j'aurais osé sortir un tel terme). Je n'aime pas du tout ce genre de mots touts faits qui ne véhiculent pas forcément exactement l'image que je souhaite. Éventuellement si je devais utiliser un tel mot, ce serait plutôt une sorte de faire-cratie (si un tel mot pouvait exister), c'est à dire que les gens qui font… sont ceux qui font (wouhou!)! Ce qui est déjà bien différent. Et encore, même un tel terme, je ne veux pas l'utiliser car je suis sûr que je ne serai plus entièrement d'accord avec moi-même si j'y réfléchissais bien. Ce sera donc la première et dernière fois.
Prière donc s'il te plaît de pas mettre des mots dans ma bouche, surtout quand ce sont des mots que justement je ne dis jamais et qui n'expriment aucunement ma pensée.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Paradoxe
Posté par Thomas Douillard . Évalué à 0.
Effectivement, ce mot a été employé dans ce journal et tu a posté dedans : https://linuxfr.org/users/igor--2/journaux/le-libre-et-l-experience-utilisateur pbr contre c’est effectivement pas toi qui l’a employé, mea culpa. Par contre tu commentes dans le sens « on regarde ce que tu fais et pas ce que tu es », sens pour lequel on pouvait entendre une start-upeuse utiliser le mot « méritocratie » hier dans les médias (pour dire « on doit pas payer / assiger des taches en fonction du genre toussa) et accorder les droits de mainteneurs à ceux qui font du bon code, d’où ma confusion.
Cela dit mon but n’était pas de dire que l’équipe de Gimp n’était pas ouverte.
[^] # Re: Paradoxe
Posté par Thomas Douillard . Évalué à 2.
Rajout au «toussa» parce qu’il est bien trop tard pour modifier mon commentaire : _payer / assigner des taches … donner les droits d’écriture sur le dépôt _
[^] # Re: Paradoxe
Posté par Thomas Douillard . Évalué à 1.
Ben si tous le truc repose sur une seule personne effectivement, mais si c’est pour recoder l’interface d’une part ça vaut ptete le coup que les anciens s’y mettent. Certe c’est un coût mais pas un coût de maintenance en soi, c’est un coût d’apprentissage initial. Après pour la maintenance, faut choisir la bonne techno. C’est un risque, mais bon développer du GTK en C c’est un risque aussi … ça n’attire pas des masses, à juste titre. On peut d’ailleurs noter qu’il y a des concurrents à The Gimp de nos jour, alors qu’on l’a longtemps présenté comme une potentielle « killer feature ». Faut-il en déduire que des gens ont préféré relancer d’autres projets plutôt que de contribuer au phare ? Je n’irai pas jusque là parce qu’il y a plein de raison potentielles (et que c’est pas forcément un mal en soi), mais c’est pas impossible que le côté technologies employé ait joué (typiquement GTK vs. Qt)
J’aurai plutôt tendance à analyser ça en terme de culture de projet / générationnelle qu’autre chose : 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. 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.
Mais c’est ptete juste moi qui me fait un flim (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)
[^] # Re: Paradoxe
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
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".
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é).
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.
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.
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.
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.
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.
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 ]
[^] # Re: Paradoxe
Posté par Thomas Douillard . Évalué à 3.
Il n’y a ni animosité ni volonté d’insulte dans mes messages. Juste un questionnement. Et rassure toi, je suis simple utilisateur de Gimp et je n’ai aucune volonté de proposer de recoder l’interface en angularjs :p
[^] # Re: Paradoxe
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
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 ]
[^] # Re: Paradoxe
Posté par betonniere (site web personnel) . Évalué à 7.
Un énorme coût pour rien alors et de plus pour aucun gain fonctionnel. Gardons à l'esprit qu'un compilateur possède quand même quelques vertus dont celle d'offrir un niveau de vérification dont on aurait du mal à se passer sur des logiciels de cette taille.
C'est tout bête, mais le choix du langage est aussi une question d'échelle (pas que, mais aussi). Python est génial (je pèse mes mots), je l'adore même, mais passée une masse critique de code, le coût de maintenance peut aussi se retourner contre lui. Avec GIMP on est clairement dans ce schéma.
? Moi aussi, je ne comprends pas.
# Surface studio
Posté par zmendoza . Évalué à 0.
La vache, c'est vrai qu'elle est bluffante la vidéo sur le Surface Studio!
C'est un vrai bidule ça ou bien un bon gros vapor(hard)ware?
Ca serait bien la première fois que Microsoft me donne envie :)
[^] # Re: Surface studio
Posté par claudex . Évalué à 3.
Tu peux l'acheter, ce n'est pas un produit confidentiel. https://www.microsoftstore.com/store/msusa/en_US/pdp/Surface-Studio/productID.5074015900
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Surface studio
Posté par zmendoza . Évalué à 0.
Bon, à 3000 $ je suis pas prêt de passer le pas mais j'aime bien le concept. C'est vrai que c'est le genre de truc qu'on aurait attendu plutôt de la part d'Apple !
# Merci
Posté par Nicolas Chevallier (site web personnel) . Évalué à 2.
Merci pour la traduction de cet interview, c'est toujours intéressant de lire et mettre un visage sur un projet (surtout comme GIMP)
# Petite faute
Posté par Lucas . Évalué à 1.
Interview intéressante. Une petite faute d’accord à signaler cependant :
[^] # Re: Petite faute
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.