Bon, comme quoi ça sert d'avoir tous ces commentaires pour te dire que c'est pas une bonne présentation: je prévoyais absolument pas de lire (je ne sais pas si c'est la présentation, ou juste le fait que je lis rarement ce types d'articles), mais en lisant les commentaires ici, j'ai décidé de jeter un œil à ton essai.
Bon ben je ne suis pas d'accord avec les prémisses du problèmes, ni avec les "solutions".
Prémisses du problème
So just fork the project, write the feature, propose it, done.
Done? No!
This lone cowboy approach is a recipe for frustration!
Ben… si. Ce que tu appelles cette approche "cowboy solitaire", c'est exactement ce qu'il faut faire selon moi. Je pense que tu compliques en sur-pensant un problème simple.
Et la raison pour cela est (j'ai l'impression) que tu ne contribues peut-être pas pour les bonnes raisons. Tu dis jamais vraiment pour quoi tu contribues, alors je vais supposer (peut-être à tort) que tu contribues pour contribuer car plus tard, quand tu parles de ton cas concret avec ton plugin gradle, tu expliques que tu as ouvert des pull requests dans divers projets pour leur faire utiliser. En fait donc rien n'allait pas bien dans ces projets hormis le fait qu'ils n'utilisaient pas ton plugin?!
En fait, le "pourquoi on contribue" est tout simplement LA source des contributions. Faut pas chercher plus loin. Tu parles de ses "Rock-Star Ninja Developers". Aucun ne se pose le type de questions que tu poses (et tous emploient l'approche que tu as nommé "cowboy solitaire"). Ils savent juste pourquoi ils contribuent. Certains, car c'est leur boulot. D'autres car c'est leur projet perso. Beaucoup, comme moi, car on utilise et simplement on a des bugs ou on veut des fonctionnalités. Énormément de développeurs viennent nous voir chez GIMP avec comme premier message "Je veux contribuer à GIMP, vous pouvez me dire sur quoi je peux coder?". Déjà ça part super mal. Tellement mal que je n'ai pas vu UN SEUL contributeur de ce type qui a réellement fourni un patch au final, de mémoire.
Un contributeur qui donne quelque chose de concret est uniquement les dits "cowboys solitaires" qui ont un besoin, le patche et fournissent le patch. Simple.
Ceux là, on en voit régulièrement dans GIMP. Bien sûr, des fois on discute la fonctionnalité ou son implémentation, mais en général on arrive à une solution.
Pourquoi? Parce que déjà si la fonctionnalité (ou la correction de bug) était nécessaire pour cette personne, y a de grandes chances que ça le soit pour d'autres, donc les chances de la voir acceptée est grande aussi. En plus elle sera probablement mieux codée car la personne l'utilise vraiment (et donc verra les bugs oubliés).
Personnellement c'est bien simple, de ma vie, je n'ai contribué que pour des choses qui m'étaient nécessaires. Et encore j'arrive pas à tout faire. Si je pouvais physiquement faire plus, j'ai 1000 autres patchs à créer à 100 autres projets! Alors je comprends pas les gens qui posent la question "que faire?" qui mène à la question "comment contribuer à un projet libre?". Qui n'a jamais eu un bug ou un crash d'un logiciel qu'on utilise beaucoup? Qui n'a jamais pensé "Ah ce serait cool si je pouvais faire ça"?
C'est bien simple, le jour où tu auras un besoin, aucune de ses questions ne se posera plus. Tu corrigeras pour toi et tu enverras le patch. Et c'est bien tout!
Comment contribuer?
Bon maintenant que j'ai établi que les prémisses sont problématiques et que la question qui est la base du reste de la discussion est la mauvaise, on pourrait arrêter là. Mais soit, admettons qu'on veuille quand même poser cette question étrange: comment contribuer?
Les problèmes?…
Les problèmes cités sont:
The project is not maintained anymore.
Bon ça peut arriver. Tu peux regarder les logs et si y a rien depuis longtemps, on peut se poser des questions (même si ça veut juste dire qu'y a pas de développement actif, mais il peut y avoir maintenance minimale quand même). Ensuite est-ce grave? Comme je l'ai dit, la prémisse est mauvaise si tu contribues sans avoir besoin. Si c'est pour juste histoire d'avoir ton nom dans une liste de gens, bon ça sert à rien de contribuer. Si tu utilises, ben tu fais ton patch, tu l'envoies quand même (sans grand espoir peut-être, mais une fois fait, autant envoyer; au pire ça servira peut-être à quelqu'un d'autres même si c'est jamais inclus), et tu utilises pour toi, tout content car tu as corrigé ou amélioré un logiciel que tu utilises!
Éventuellement s'il s'agit d'un logiciel qui a un certain intérêt clair, tu peux en reprendre la maintenance. Je l'ai fait pour quelques logiciels, en général en mode "maintenance seulement". C'est à dire que je prends les patchs des gens, je les applique, je mets à jour le strict minimum pour le système de compilation au besoin. Travail minimum mais je m'arrange que le logiciel reste au moins utilisable, compilable et pas trop buggué (car, je répète: moi aussi j'utilise! Ou du moins j'utilisais quand j'ai contribué).
Dans de tels cas, je serais d'ailleurs heureux de pouvoir en passer la maintenance à quelqu'un en gardant le code à flot jusqu'à ce que quelqu'un qui souhaite s'impliquer plus que moi débarque (par exemple je maintiens Tiny Segmenter de cette façon, où je fais en gros une release par an avec un unique patch que quelqu'un d'inconnu m'envoie de temps en temps).
The maintainer is not interested, he has different goals than you.
Ça arrive. C'est chiant surtout si tu veux vraiment cette fonctionnalité, et rien n'est pire que de maintenir ton fork perso juste pour toi. Mais bon, c'est la vie!
Je fais plein de trucs tout le temps, et ça mène pas toujours à quelque chose de concret (je parle même pas de développement, mais dans ma vie en générale).
There was a 5 times easier way to implement the same thing.
[…]
Tous les autres problèmes cités sont juste des problèmes de développement. Je vois pas le problème du tout. Oui, il se peut qu'on te demande de revoir ton patch. Et alors? :-)
On n'a jamais dit que le développement d'application était un truc facile et que l'implémentation de nouveau code se fait toujours en une fois. :P
Franchement j'ai du mal à voir les problèmes dans ta liste!
Solution?
Alors là on est à un point où on est pas d'accord sur les prémisses, puis sur la liste de ce qui est ou non un problème. Donc je pense que ça sert à rien de continuer en citant aussi tes solutions (ton "MVP"). Mais il va sans dire que je crois absolument pas que ce soit une solution à quoi que ce soit.
Attention je dis pas que ce que tu dis est mauvais et qu'il faut pas parler avec les mainteneurs d'un programme! Juste que clairement ce que tu sembles indiquer comme une sorte de recette magique n'en est absolument pas une selon moi.
Bon allez, juste une citation quand même:
Most importantly, obtain the permission for working on the change before you actually spend the time on it.
Alors ça c'est super sensible. D'un côté, si ce que tu vas faire va te prendre beaucoup de temps (genre au moins 2 semaines à temps plein!), alors oui il vaut peut être mieux de s'assurer que ce sera intégré.
Néanmoins ne disions nous pas qu'on développe aussi pour nous?! Si c'est une fonctionnalité que tu veux vraiment vraiment, est-ce vraiment perdu si tu peux au moins utiliser cela même si c'est refusé upstream? C'est pas une question réthorique, mais une vraie question à faire au cas par cas sur chaque projet. Je le disais plus haut, maintenir un fork perso quand le projet principal évolue beaucoup (et qu'on veut aussi bénéficier des évolutions) n'est pas quelque chose que je conseille à la légère. Mais dans certains cas, ça peut valoir le coup.
Ensuite et si le développeur comprends mal ta proposition et refuse (alors qu'il aurait accepté en voyant le vrai patch)? Et s'il a trop de boulot et ne lit pas ton message avant 6 mois (quand tu as déjà abandonné depuis longtemps et es passé à autre chose)? Et si ça engage des discussions avec des trolls où on se met à faire du "bikeshedding" avant même que la moindre ligne de code utile soit produite?
Perso je demande jamais, ou presque (en fait, quand je demande, c'est plus quand c'est vraiment pas prioritaire, que je sais que de toutes façons je le ferai pas tout de suite car je peux pas faire du temps pour ça, ou quand j'espère que quelqu'un d'autre me prendre l'idée que je mets par écrits et le fera avant moi). Je fais, j'envoie et j'oublie.
Éventuellement si on me demande des changements, je reçois de toutes façons un email de notif, je reviens sur mon code quand je peux faire un peu de temps, je change, je pousse et oublie encore.
Obtenir permission, c'est plus une perte de temps et de motivation qu'autre chose. Je suis plus en maternelle quand je demandais permission à la maîtresse pour tout et rien. Le pire qui puisse arriver, c'est que mon patch ne soit pas accepté. J'aurais alors utilisé quelques heures ou jours pendant lesquels je me suis cependant bien amusé à lire du code et le comprendre, et au final j'aurais un changement que je peux quand même utiliser moi-même (ce qui était le principal but, je le rappelle).
Et ma "solution"?
Allez pour ne pas laisser ce commentaire sur une note négative, je vais quand même laisser ma "méthode". Notez les guillemets car c'est un peu présomptueux de parler de solution ou de méthode. Je pense pas qu'une telle chose existe, et ça va dépendre des gens aussi.
Mais voilà, ça se résume en 3 mots: persévérance, compréhension et bienveillance
Persévérance
Dans persévérance, on pourrait aussi mettre patience. De manière générale, ne pas s'attendre à une inclusion éclair d'un patch. Alors ça peut arriver, mais juste ne pas s'étonner quand ça n'arrive pas. Je le disais, c'est pour cela qu'en général je fais, j'envoie, j'oublie. Forcément si on reste devant sa boîte email à attendre une notification de réponse, ça ne peut être qu'une mauvaise expérience dans beaucoup de cas et on peut facilement se mettre à étiqueter un projet comme "non maintenu" même quand il l'est.
Par contre il faut aussi savoir revenir sur un patch. En général je conseille d'attendre quelques mois. Genre si 2 ou 3 mois après un envoi de patch, il n'y a pas de réponse, alors faire une petite relance, poli et gentille. On sait jamais, le mainteneur a peut-être vu, puis a oublié. Ça arrive.
Puis répéter, régulièrement, toujours agréablement et poliment. Note que je n'ai même pas besoin de garder une liste de mes patchs en attente, puisque j'utilise les choses que je patche, donc je m'en rappellerai forcément un jour (genre dans 2 mois, je lance tel programme et utilise telle fonctionnalité, et "tiens j'ai jamais eu de nouvelle de ce patch" vient tout seul).
En fait dans les rares patchs que j'ai faits et qui n'ont pas été intégrés, certains sont parce que j'étais jeune et ne savais pas encore à l'époque qu'il fallait savoir insister un peu (je me souviens d'un de mes patchs pour une cool fonctionnalité sur mplayer par exemple; je n'avais jamais eu de réponse puis j'ai oublié même si j'ai moi-même utilisé mon patch pendant des années; de nos jours, dans mpv, la fonctionnalité que j'avais implémenté existe, implémentée par quelqu'un d'autre).
Il n'y a pas de mal à insister un peu, du moment qu'on le fait agréablement (je me répète sur le côté poli/agréable, mais c'est important). Ça ne gêne personne ni n'est jamais mal pris.
Compréhension
Compréhension du problème bien sûr, ça c'est le boulot du développeur. Mais surtout compréhension des gens. Savoir ce qu'autrui veut, comprendre ce que l'autre dit et pourquoi il aime ou non, et essayer si possible de faire des compromis (pour éviter le problème du fork perso à maintenir) quand il apparaît que sa proposition initiale ne sera pas intégrée (du moins pas comme tel). "Discuter" (dans le contexte d'une discussion sur un patch), en général ça veut dire "comprendre ce que l'autre veut et comment faire pour qu'on ait tous les deux ce qu'on veut".
Aussi comprendre l'humain et pourquoi quelqu'un ne répond pas vite par exemple. Ou bien ne pas prendre mal si on a l'impression de recevoir une réponse un peu sèche (peut-être l'était-elle, peut-être était-ce juste une incompréhension de l'écrit). La plupart des situations peuvent être désamorcées en essayant de comprendre autrui et de réagir de manière appropriée.
En gros avoir de l'empathie.
Bienveillance
Ça peut sembler une répétition des 2 points précédents, et c'est vrai que tout se mêle un peu, mais c'est vraiment important alors ça mérite son propre point. Quoi qu'on fasse, essayer de le faire posément et avec bienveillance. C'est pas toujours facile. Il arrive à tous de se mettre en colère quand certains sont vraiment insupportables. Mais parfois se faire un peu violence et même avec les gens très désagréables, il faut essayer de rester poli. Dans tous les cas, rien ne viendra jamais d'une guerre ouverte et d'une dispute.
Voilà. Donc avec ces quelques points bien respectés, non seulement tu te poseras même plus la question de "comment contribuer?" car ça viendra tout seul, mais en plus la plupart des patchs seront intégrés sans trop de problèmes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pourquoi mettre cette option au niveau de l'envoi (et même avant l'envoi en fait!)?
Quand quelqu'un envoie plusieurs fichiers, Lufi ne peut-il pas générer un lien par fichier ainsi qu'un lien qui permet de télécharger l'ensemble des fichiers d'une même session d'un seul coup? En gros pas besoin d'option, simplement proposer l'ensemble des possibilités avec des liens bien visibles/compréhensibles après coup.
Je trouve aussi que ce serait une bien bonne idée, et une meilleure implémentation de la dite idée.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est simplement la syntaxe glob (et ça n'a vraiment rien de nouveau).
C'est bien simple: quasi toute commande (sous Linux du moins) qui propose un système de reconnaissance d'expressions le fait soit en glob, soit en expression régulière. Souvent les deux d'ailleurs (find a -name/-iname/-path/-ipath, etc. en glob et -regex/-iregex en expressions régulières).
C'est aussi pourquoi un manuel ne va pas lister les constructions possibles, il suffit de dire que c'est un "glob pattern" (ceci dit, je viens de jeter un coup d'œil sur le man de find et ils parlent de "shell pattern" partout, sous-entendant "glob pattern", sauf à un endroit où ils disent bien "glob pattern") et les gens peuvent se renseigner sur la syntaxe ailleurs.
Et oui Bash ne comprend par défaut que le glob en effet (ce pourquoi ils disent "shell pattern", mais ce n'est pas une simplification correcte, car rien ne dit que d'autres shells ne travaillent pas en expression régulière; d'ailleurs même bash a en fait une prise en charge possible avec =~).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Cependant y a une petite incohérence ici, car ça ne fonctionne pour voir la liste des options qu'une fois le projet configuré avec succès une fois. Ce qui est ironique quand parfois on doit pouvoir configurer les options pour justement permettre le succès de la configuration!
On est donc forcé de se coltiner le fichier meson_options.txt avec son éditeur pour lister les options. Il existe une demande de fonctionnalité pour permettre d'obtenir la liste des options depuis un appel de commande (issue 2402). C'est un petit recul (même si la lecture d'un fichier bien tenu rend la chose moins terrible).
L'interface ncurses à la ccmake serait aussi une bonne alternative (dans les projets CMake, je ne configure quasi que comme cela) mais c'est aussi en demande de fonctionnalité (comme indiqué dans la dépêche).
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 écran HiDPI ce qui fait que les textes affichés sont un peu petits (donc JMPP pour les lire :D j'ai pas trouvé de réglage pour les info-bulles…). La sortie de xdpyinfo indique :
dimensions: 5120x1800 pixels (990x348 millimeters)
resolution: 131x131 dots per inch
Hmmm… Tu voulais probablement dire que tu as un grand écran, mais sûrement pas HiDPI (au passage, c'est HiPPI, le terme que tu cherches, à part si ton écran est en fait une imprimante qui imprime 24 pages par seconde :P).
131 PPI, c'est une densité tout à fait moyenne.
On considère généralement un écran comme haute densité environ à partir des 180 PPI (disons que la valeur basse-basse-basse si vraiment tu veux être le plus inclusif/marketing, c'est 160). GNOME utilise la valeur 192 (i.e. GNOME double toutes les tailles si la densité est au dessus de cette valeur). Et encore, même dans ces zones de densité, c'est considéré peu dense par beaucoup. On a déjà eu des rapports de bug de gens avec des écrans à 200+ PPI qui disaient que les icônes étaient trop grandes!
Ensuite dans ton cas, c'est un écran énorme, voire une télé peut-être, et je me dis que tu la regardes de loin, contrairement à un écran d'ordi sur lequel tu bosses. C'est peut-être pour cela que tu trouves cela petit (et prouve bien d'ailleurs que la densité d'écran ne peut pas être le seul critère pour déterminer si on double/triple ou pas les éléments d'UI (textes, icônes, images, etc.).
Bon ensuite je fais juste mon chieur en pinaillant sur des détails techniques. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tu devrais quand même attendre la réponse du dév. Comme je le disais, même quelques semaines d'attente, c'est pas trop demander dans le respect d'autrui (mon premier point plus haut: "l'autre a aussi une vie"), d'autant plus pour un tel sujet (prendre son bébé de ses bras, c'est pas rien).
Même si son texte paraît en effet assez-clairement anti-communautaire, on sait jamais! Et il vaut toujours mieux régler une situation pacifiquement que de s'embourber dans une guerre.
Je le disais aussi, un fork, c'est énormément de boulot, il faut en être conscient. Et tu parles de "5 développeurs", mais je pense pas que tu les aies déjà. Et c'est pas sûr que tu les aies jamais. Toi même disais que tu n'avais pas plus de temps que cela, et j'ai l'impression qu'hormis cette fonctionnalité de vision annuelle, tu n'as pas forcément plus de besoin pour l'instant. Je me trompe?
Alors quand le projet a été abandonné par ailleurs, c'est autre chose. Tu peux te permettre de le reprendre avec un taux de contribution faible (ce sera toujours plus qu'avant). Je maintiens quelques projets de la sorte où je fais quasi aucun développement, mais je les maintiens en vie, et surtout j'inclus des patchs si on m'en envoie (ce qui arrive peu pour des projets à faible visibilité).
Mais là on parle d'un projet activement développé, simplement de façon non-communautaire. Ça veut dire que soit ton fork risque au final d'être "derrière" le projet principal en terme de fonctionnalités et corrections de bug, soit vous devrez passer un temps fou pour backporter tous les changements d'un coup à chaque sortie (à ce que j'ai compris, il fait juste un seul commit public par sortie, avec tous les changements mélangés).
En fait ça me fait penser à la situation de Cinelerra qui n'est absolument pas enviable, avec 3 versions! Y a les auteurs originels (on sait même pas si c'est une personne seule ou plusieurs) qui développent toujours, mais dans leur coin, sans se soucier des forks (je crois qu'ils récupèrent même pas leurs changements — dites moi si je me trompe!) et uploade juste une archive des sources une fois de temps en temps pour chaque sortie. Y a une version communautaire qui essaie de rajouter des fonctionnalités tout en ré-intégrant le code de la version originelle à chaque sortie (donc les projets doivent dévier au fur et à mesure, rendant sûrement la version communautaire de plus en plus difficile à maintenir). Et enfin y a une 3ème version, j'ai jamais compris pourquoi! Enfin bon c'est le bordel quoi (rien que ça, ça donne pas envie d'essayer; je saurais pas quelle version tester), personne se parle, et au final il suffit de voir que Cinelerra n'est plus intégré dans presque aucune distribution, c'est la galère rien que pour installer. Ils ont bien encore leur petite communauté et fans (je croise encore des gens une fois de temps en temps dans des confs qui me disent utiliser ça; c'est fou) mais bon presque personne de nos jours ne le conseille. Quand on pense qu'y a 10-15 an, cet éditeur vidéo était dans toutes les distributions et était l'éditeur que tout le monde conseillait pour de l'édition vidéo sérieuse, c'est méga triste quoi.
Ma conclusion, c'est donc: attends la réponse, mais si vraiment il est confirmé que cette personne ne veut pas de patchs tels que le tien et est allergique à la collaboration, veux-tu vraiment t'embourber dans une telle situation?
Il me semble que les programmes de comptes personnels ne manquent pas. Et d'autres seront sûrement bien plus ouverts aux patchs. Ou alors c'est un type de logiciel bancaire particulier et y en a peu des comme ça? Ou celui-là est vraiment vraiment meilleur que les autres? Pourquoi s'accrocher à ce logiciel en particulier?
J'essaie vraiment juste de comprendre en quoi ce logiciel mériterait que tu veuilles aller jusqu'à un tel fork. Mon but n'est pas de te décourager. Si vraiment tu es méga motivé et as la foi, tu as tout à fait le droit et je te souhaite un bon développement (de même qu'à l'auteur originel d'ailleurs). Mais bon c'est à bien peser. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai aussi reporté l'erreur et immédiatement après, je ne vois plus d'alerte. Est-ce que ça ne la montre plus localement seulement, pas même en changeant de navigateur (genre pour mon adresse IP?)? Ou bien y a juste un seuil et il suffit que quelques personnes reportent une erreur pour débloquer un site?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je vais donner un autre point de vue, qui est complètement le cul entre 2 chaises. Mais c'est vraiment comme cela que je vois la contribution au logiciel libre.
Mais s'il souhaite vraiment collaborer au projet, alors je préfère qu'on en discute ensemble avant qu'il se mette à coder.
Alors d'un côté, tu as totalement raison. Si quelqu'un te file un méga-patch de centaines/milliers de lignes pour une grosse fonctionnalité dont tu ne veux pas, c'est dur de le rejeter (pour plein de raisons). Mais pour garder une cohérence au projet, ben des fois, faut bien.
Ceci dit, de l'autre côté, la personne essaie parfois de contacter, et se retrouve sans réponse pendant des jours, voire des semaines. Le truc, c'est que c'est totalement normal. On est des êtres humains, on fait des choses parfois en dehors du code. Et même si on devait coder quotidiennement à temps plein, ça ne signifie pas pour autant qu'on est obligé de répondre à toute question à la minute. On a une vie quoi.
Cependant la personne qui demande a aussi une vie. Attendre des jours, des heures même souvent, c'est dur quand on a une idée qu'on veut développer! On se met à le faire dans sa tête, on y passe des heures à y penser (qu'on a l'impression de perdre et on se dit qu'on aurait déjà bien avancé si on s'était mis directement à coder). Bien sûr, on pourrait/devrait juste poser la question et passer à autre chose en attendant la réponse (si même elle arrive). Mais l'humain est pas si rationnel et quand on a une idée en tête, c'est souvent pas si simple de "passer à autre chose".
En outre, du côté des mainteneurs, on entend très souvent la fameuse "Je suis développeur, je peux aider, vous m'expliquez ce que je dois faire?". Le truc, c'est que c'est pas si simple. D'ailleurs c'est peut-être même symptomatique d'un développeur à l'expérience limité de demander cela, comme s'il s'attendait à ce qu'on puisse lui décrire un logiciel énorme de tête en quelques minutes dans le détail. Car c'est le détail qui importe (bon bien sûr, on peut en faire dire de tête le nom de pas mal de fichiers ou fonctions et où plus ou moins précisément doit se passer tel ou tel changement, mais y a des limites quand même); oui je peux décrire la structure globale de GIMP en quelques minutes, mais une description si globale en général est inutile pour un développeur qui veut implémenter un truc précis. Il espère donc que tu lui dises où et quoi changer. Mais si on vérifie cela, on a déjà fait la moitié du boulot nous-même et on y a passé pas mal de temps.
Donc quand on donne juste une description simple, soit le contributeur potentiel comprend et il fait, soit (et c'est 90% des cas), il abandonne au bout d'un moment (et peut-être se dit que les dévs sont pas cool, ils aident pas les nouveaux, alors forcément…).
Là où je veux en venir, c'est qu'une demande qui vient avec un patch vaut 1000 propositions d'aide. C'est concret, c'est là, on sait tout de suite à quoi s'attendre (au niveau qualité du code notamment et on a une idée de ce qu'on pourra demander ou non à cette personne), etc. La proposition d'aide, notre réponse est invariablement "c'est cool, on attend le patch!" sans pour autant y mettre un espoir fou. On sait que dans beaucoup de cas, ça ne viendra pas. Je me rappelle même une fois une personne nous avoir dit avoir reçu un financement pour une fonctionnalité (j'ai retrouvé le ticket). Ce fut la première et dernière fois qu'on a entendu parler de lui.
Et en ce sens d'ailleurs, l'auteur du journal a très bien fait. Proposer un patch fonctionnel est la meilleure chose à faire quand on veut vraiment une fonctionnalité. C'est ce que j'ai appris au fil des ans, et désormais quand je veux vraiment quelque chose, je ne me pose pas la question: je la code moi-même. Attendre les autres mène rarement à l'obtention de la fonctionnalité (et ce, même si les développeurs du logiciels sont d'accord sur la fonctionnalité sur le principe; ça ne leur crée pas du temps magiquement ni ne la met en haut de leurs priorités: s'ils n'en estimaient pas eux-même le besoin au préalable, accepter qu'un autre puisse en avoir le besoin — et ce faisant accepter que cette fonctionnalité vaut le coup — ne change pas leur propre besoin).
Donc mon conseil aux contributeurs, c'est: oui bien sûr, discuter, c'est toujours bien! Mais ça ne veut pas dire que vous ne devez pas prendre un peu les devants. Les bons mainteneurs apprécient si vous avez un peu d'indépendance et que vous fassiez une implémentation dès le début. C'est la meilleure intro en tant que contributeur.
Par contre, oui, il faut être conscient que ça ne veut pas dire pour autant que votre patch sera accepté. Peut-être qu'il nécessitera juste des corrections. Peut-être que le mainteneur ne sera pas d'accord avec certains choix et qu'il faudra faire des compromis. Peut-être même (le pire des cas) que votre patch sera au final rejeté après avoir passé plein de temps pour coder et pour ensuite discuter et défendre la fonctionnalité. Ça arrive. Ça m'est aussi arrivé, et pas qu'une fois (même si globalement cela reste rare! Si vous êtes un bon développeur avec de bonnes idées, peu de mainteneurs refuseront tous vos patchs sans y penser à 2 fois, en tous cas pas les bons mainteneurs).
Mais vous savez quoi? C'est la vie! C'est pas une spécificité du développement logiciel. Dans plein de trucs dans la vie, il m'est arrivé de gâcher mon temps, en faisant ceci ou cela qui s'est avéré inutile ou refusé, ou autre. C'est chiant, mais bon. C'est pas la mort! On passe à autre chose.
En gros, la conclusion, c'est: que vous soyez mainteneur ou contributeur, soyez conscients que vous parlez avec des êtres humains:
L'autre a aussi une vie, il n'est pas votre esclave, et notamment son temps ne vous est pas réservé (donc les réponses peuvent prendre du temps notamment).
Il peut faire des erreurs aussi; par exemple même oublier de répondre! Donc le relancer n'est pas mal pris, du moment que c'est pas en insistant lourdement tous les jours, cf. point précédent. Je considère souvent que relancer après 2 ou 3 semaines est une bonne moyenne. Répondre à un email ou un message de rapport après quelques semaines n'est absolument pas rare. On met un sujet dans un coin de notre TODO liste pour "plus tard", puis on répond quand on peut. Après quelques semaines sans réponse, on peut cependant se dire que la personne a peut-être oublier.
Il peut avoir des priorités différentes que vous (et c'est ok). Il faut savoir l'accepter et mettre en valeur les compromis.
On a un développeur qui a fait quelques patchs (de très mauvaise qualité technique d'ailleurs, donc énormément de temps de revue) pour GIMP et qui plusieurs fois nous dit des trucs genre "ce que je déteste le plus, c'est de perdre mon temps" dès qu'on se met à discuter ses patchs (pas pour les rejeter, mais réellement pour les discuter afin d'arriver au meilleur choix, qu'on ne sait pas forcément). Non seulement c'est très passif-agressif, met directement la discussion sur une mauvaise ambiance, mais en plus c'est oublier que nous aussi on existe. Nous non plus n'aimons pas perdre notre temps. Qui aime cela?
Mais on fait ce qu'on fait pour aboutir au meilleur logiciel ensemble, pas pour "perdre du temps". Si quelqu'un ne comprend pas ça, autant ne pas faire de logiciel libre.
Je comprends qu'un utilisateur puisse faire des modifications pour son propre usage (les licences libres servent à ça). Mais s'il souhaite vraiment collaborer au projet, alors je préfère qu'on en discute ensemble avant qu'il se mette à coder. En ce moment, par exemple, j'ai trois contributions pour Sozi que je ne souhaite pas intégrer : une parce qu'elle n'est pas complète, une qui s'apparente à un bricolage et qui mériterait d'être réécrite, et une autre parce qu'elle me semble incohérente avec la philosophie du projet.
Alors je le disais, il faut savoir refuser certaines contributions inadéquates. Ensuite sans plus de détails, je ne peux pas dire si c'est le cas des contribs que t'as reçue. Ceci dit, il faut aussi savoir demander à un contributeur à corriger son code pour le voir intégrer (cas de 2 des 3 contributions: demande au premier de compléter son patch, et au second de le refaire proprement).
Souvent aussi il faut savoir prendre de son temps pour faire faire fleurir les contributions. Je l'ai déjà dit, je fais beaucoup de revue de code dans GIMP. Mais soyons clair, la majorité de ce que je relis et corrige ne m'intéresse pas personnellement (ni pour notre projet ZeMarmot). Mais j'en vois l'intérêt pour d'autres et pour l'amélioration de GIMP en général. Si on devait refuser tous les patchs dès que le contributeur n'est pas capable de mieux, alors GIMP aurait genre moitié moins de fonctionnalités. La plupart du temps, on repasse derrière les patchs pour les peaufiner (et ce, même si la fonctionnalité ne nous intéresse pas personnellement!). Et d'autres repassent aussi derrière moi. Et ainsi de suite.
C'est aussi ça qui fait la qualité d'un logiciel libre: on n'est pas tout seul avec notre code et nos propres limitations.
Perso je n'aime pas tous les choix faits dans GIMP et j'en ai discuté plus d'un. Mais si je contribue, c'est parce que ce qu'on fait tous ensemble, j'aurais été incapable de le faire seul (de même pour les autres contributeurs). Et ça j'en suis très conscient. On a un logiciel extrêmement cool et puissant parce qu'on a travaillé ensemble, on a tous compromis ensemble.
Donc j'espère que tu ne refuses pas des fonctionnalités juste parce qu'elles ne t'intéressent pas. Ce serait tout de même un peu triste.
Bien sûr si la fonctionnalité a pour effet de rendre d'autres fonctionnalités moins bonnes, c'est une autre histoire. Mais ce n'est pas le cas de la plupart des fonctionnalités.
Je comprends qu'un utilisateur puisse faire des modifications pour son propre usage (les licences libres servent à ça).
Perso notre build de GIMP local utilisé pour ZeMarmot a quelques petites différences, mais très mineures. Ce sont quelques détails qui ont été refusés dans GIMP (pour de bonnes raisons, même si je suis pas d'accord). J'en ai pas fait une maladie et je vais sûrement par forker GIMP (de manière publique j'entends) pour cette raison. Mais on garde ces différences au strict minimum.
Notre but n'est pas d'avoir notre propre GIMP mais d'améliorer le GIMP de base. Ne serait-ce que pour la qualité. C'est bien simple: presque tout ce que j'ai codé est d'autant mieux car d'autres gens sont passés derrière et ont aussi amélioré.
D'ailleurs l'un de mes buts dans GIMP est d'améliorer considérablement l'API et ses possibilités justement pour ne plus avoir de GIMP patché en local du tout. Je veux pouvoir transformer nos quelques différences de code en dur en plug-ins à la place.
Le truc, c'est aussi que maintenir un fork, c'est aussi un travail de dingue. Il faut le faire si vraiment tu n'as aucun choix (ou que tes différences sont vraiment minimes). Alors c'est vrai que c'est bien que ce soit possible, mais ce n'est absolument pas le plus intéressant dans les licences libres, selon moi. La possibilité d'un fork personnel est seulement une manière de rendre le pire cas "moins pire" (toujours d'après moi). :-)
Bon y a aussi les forks après abandon d'un projet par exemple, ou d'autres types de fork qui sont totalement différents. Je parle du cas du fork sans raison profonde, genre juste "comme ça je fais ce que je veux".
L'autre problème que je rencontre parfois, c'est qu'une fois la nouvelle fonctionnalité ajoutée, les contributeurs disparaissent et on se retrouve tout seul pour maintenir leur code.
C'est effectivement une réalité, et la majorité des cas. Ensuite, je le rappelle (cf. plus haut): les contributeurs aussi ont une vie et des priorités. On peut leur demander d'aider mais on peut pas leur en vouloir s'ils refusent. J'ai personnellement contribué à des dizaines de projets (voir OpenHub et c'est loin d'être exhaustif!) et GIMP est le premier (hormis ceux que je maintiens ou ai créés) sur lequel je suis resté. Je ne pourrais pas humainement participer activement à tous les projets auxquels j'ai envoyé un patch.
Ça ne m'empêche pas de vouloir une fonctionnalité ailleurs et de la coder de temps en temps, mais oui le mainteneur doit être conscient que ça ne veut pas dire que je signe un contrat avec mon sang pour rester à ses côtés jusqu'à ma mort.
En tant que mainteneur de projet libre, c'est quelque chose à accepter. Ensuite bien sûr tu peux vouloir un projet petit et simple à maîtriser et qui prenne peu de temps en refusant de le rendre communautaire. C'est un choix et chacun est libre de le faire. Ensuite faudra pas espérer que son projet s'envole vers des sommets. On peut pas tout avoir. Bien sûr, pour beaucoup de gens, ce n'est pas ce qu'ils veulent. S'ils font le choix en plein conscience, c'est bien.
Personnellement je pense que ce n'est pas mauvais d'accepter de lâcher un peu prise parfois. D'ailleurs si les gens ne restent pas, c'est parfois aussi car certains mainteneurs peuvent garder trop de mainmise sur leur projet.
Au contraire, les plus gros projets ont des co-mainteneurs (voire ont changé de mainteneur à plusieurs reprises), et même quand parfois le créateur est resté depuis le début, cela ne l'a pas empêché de prendre des sous-mainteneurs (comme le noyau Linux) à tel point que dernièrement on a eu plusieurs exemples de tels mainteneurs qui essaient de rendre le projet encore plus indépendant d'eux (je pense bien sûr à Linus Torvalds et Guido Van Rossum).
La chose qui m'a fait rester sur GIMP? Très rapidement le mainteneur m'a attribué sa confiance. Au bout d'un mois ou 2, après plusieurs patchs, Mitch me dit en gros "tu fais chier avec tous tes patchs, ils sont tous bien, tiens prends toi un accès en écriture à git comme ça je gagne du temps". Franchement ça m'a impressionné. Je me suis dit "Waw juste comme ça, je peux pousser mes commits dans GIMP?". Il m'a donné sa confiance et j'ai d'autant plus fait gaffe à ce que je poussais et pendant longtemps je continuais à demander des revues de code avant de pousser dès que ce n'était pas totalement trivial. Au final je suis le plus gros développeur de GIMP sur la dernière année. Ce fut une très bonne leçon et j'essaie de l'appliquer aussi maintenant: dès que quelqu'un fait du code de qualité évidente et qu'il reste un peu, c'est le moment où faut "l'accrocher" avant qu'il aille voir ailleurs. Je lui propose donc d'avoir son accès en écriture. :-)
Alors soyons clair, ça marche pas tout le temps. Même ainsi, beaucoup de contributeurs disparaissent au bout d'un moment. Mais ça vaut le coup d'essayer.
Dans tous les cas, je ne suis pas seul à maintenir le code. On n'est pas beaucoup, mais je suis pas seul. Et c'est passé par le fait que le mainteneur (et tous les sous-mainteneurs) a su donner sa confiance aux gens et surtout a lâché un peu du lest. Il accepte qu'il ne sait pas tout, que certains sont de très bons développeurs (voire meilleurs que lui), qu'ils ont aussi de bonnes idées, que le logiciel peut servir à plus que ce dont lui se sert, etc.
En fait, le logiciel libre et/ou communautaire, quand c'est bien fait, je pense que ça peut faire de nous des bons philosophes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui. Cet article essaie de se la jouer neutre officiellement, mais sa tournure montre clairement que le journaliste est carrêment pour cette loi, genre "on reprend le contrôle du web". C'est marrant car ils ont vraiment joué sur cet aspect "David contre Goliath" dans le marketing pour cette loi, genre d'un côté les méchantes "tech sociétés" et de l'autre les "pauvres petits artistes". Alors qu'en vrai, y avait effectivement notamment ces grosses sociétés du web, mais de l'autre côté, c'était surtout les grosses sociétés d'ayant-droits.
En fait avec cette loi, ce qui pourrait se passer:
Les grosses sociétés du web? Ben soit éventuellement elles retirent leurs agrégateurs (par ex. Google News) de l'Europe. Ça avait déjà été fait par exemple en Belgique, qui était même allé plus loin, et finalement les journaux se sont rendus compte que ne pas être présent sur Google News, c'est pas terrible pour le business. Soit les grosses sociétés du web se plie aux règles et paient les droits (ce fut la fin de l'affaire belge quand tout le monde a compris que Google News, c'est pas si mal finalement). Pour Google (et autres grosses boîtes du genre), ces droits sont rien du tout au final.
Quant aux filtres d'upload, Google et consort mettront en place les dits filtres (ça prendra juste quelques jours, après tout, c'est pas comme s'ils avaient pas des milliers de développeurs et admins faits pour, hein!).
Pour les très gros médias et grosses sociétés de droits d'auteur spécialisés dans la recherche de droits (avec des équipes spécialisés dont c'est le boulot à temps plein), c'est une aubaine et ils vont se faire des pépettes en or (qu'ils pourront sainement redistribuer aux salariés qui en ont le plus besoin, et puis si on se plaint que c'est pas si juste, on peut toujours virer la personne en lui versant d'autant plus; c'est logique, on vire quelqu'un pour avoir profité du système, autant partir en profitant encore plus, comme ça au moins la critique est doublement méritée!).
Les "artistes" et autres créateurs de leur côté, ben ils touchaient des cacahouètes avant, et ils continueront à… toucher des cacahouètes. On notera les superbes communiqués de presse que nous envoient d'ailleurs les sociétés de droits d'auteur précédemment citées, par exemple ici l'ADAMI (cliquez pour voir en plus gros):
On nous rassure donc avec des "Ce vote est une première étape capitale vers une rémunération juste et proportionnelle à l’exploitation de votre travail sur Internet", bien sûr! On y croit tous!
Par contre, même si on touchera toujours autant de rien, on aura de plus en plus de mal à faire diffuser nos œuvres. Non parce que tu comprends, si tu joues Jean-Sébastien Bach et le met sur un site, on pourra venir t'expliquer que ça appartient à Sony Music Global et donc ton partage se verra interdit (je le disais plus haut: les grosses plateformes n'auront aucun mal à implémenter les filtres… d'ailleurs ce cas de Bach est un cas déjà réel qui s'est produit sur Facebook). Et va y pour te plaindre et essayer de débloquer ton œuvre et ton compte (ah oui parce que les filtres, ben c'est pas des humains!).
Pire! Si jamais tu arrives au final à faire entendre raison à un humain du support de la plateforme et à faire diffuser ton œuvre, après un parcours du combattant, et qu'elle se retrouve même partagée! Youhou! Tu te dis que toi aussi, tu vas pouvoir commencer à te faire des pépettes en droits d'auteur! Que nenni! Tu n'as pas les équipes de SACEM ou Adami, tu auras bien du mal à savoir qui diffuse ton œuvre, et à part si tu fais que ça de ta journée (plutôt que jouer au piano!), ben tu pourras demander aucun sous. Et par défaut, les équipes d'ayant-droit vont toutes attribuer les droits à Sony Music de toutes façons (car ils utiliseront les mêmes logiciels pour détecter les ayant-droits que les filtres anti-upload, bien sûr!).
Tu l'auras compris: dans un cas comme dans l'autre (que tu sois affilié ou non), biiiip, tu perds!
Quant aux petites plateformes et sites, parlons en! Eux, avec leurs 2 employés (qui ont heureusement appris à créer un site en 24h avec une formation Pôle Emploi! C'est des as!) ou 5 bénévoles (après le boulot et le week-end), ça leur prendra un peu plus que quelques jours de développement pour un résultat… disons que déjà que si Facebook et Youtube auront des faux-positifs à foison (prédiction du jour comme déjà confirmé), je pense qu'on pourra juste jamais rien uploader en paix sur un petit site communautaire (soyons clairs, une petite entreprise ou asso voudra pas prendre trop de risque avec la loi et fera des filtres plus bloquants que l'inverse)!
De toutes façons, on le sait bien, hein. Internet, c'est Google et Facebook. Le reste, c'est le "Darknet" et c'est rempli de méchants terroristes!
Alors résumons: les gros médias et sociétés de droits? Ils vont se faire plein de brouzoufs! Les grosses boîtes du web? Bah, une petite épine dans le pied, on a perdu une bataille, passons et réfléchissons simplement au prochain moyen de se faire du blé avec vos données perso. Les créateurs? Vous touchez déjà 50€ par an, maintenant ce sera 51€, youhou! Vous êtes riches! Par contre faut pas vous imaginer pouvoir créer en dehors du système en uploadant vous-mêmes, passez par les gros médias SVP (faites nous confiance…)! Les petites plateformes? Bandes de pirates (avec des crochets et des bandeaux sur les yeux), crevez! Laissez les vrais boîtes gérer toutes les œuvres publiées!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
L'argent de GIMP est utilisé uniquement pour les frais communautaires. Par exemple, cela permet aux contributeurs de se rencontrer une fois par an (frais de transports et d'hébergement) à Libre Graphics Meeting, voire à Wilber Week (si on en réorganise) pour une semaine de hacking.
Il est aussi déjà arrivé régulièrement que GIMP aide financièrement d'autres projets libres ou des évènements (en particulier Libre Graphics Meeting qui a parfois eu du mal à joindre les deux bouts si GIMP n'avait pas été là pour sauver les meubles).
Cela peut aussi être utilisé si on a besoin de faire des autocollants ou un kakémono (l'an dernier, un contributeur a participé à une conf aux US et a fait faire un kakemono GIMP ainsi), ou autre chose du genre.
Enfin cela peut être utilisé pour du matos.
Par contre, cela n'est pas utilisé pour des salaires (ce qui est le plus coûteux et au final le plus nécessaire). GIMP n'a pas de structure pour embaucher. Ceci dit, le projet pourrait sûrement donner à LILA, ce qui servirait à payer des salaires dans une structure. Mais certains contributeurs trouvent que donner cet argent de cette façon ne serait pas juste pour certains contributeurs bénévoles qui font aussi beaucoup, etc.
Personnellement je trouve cette logique peu constructive et serait (bien évidemment) heureux si cet argent pouvait nous servir pour rendre viable les tentatives de professionnaliser nos contributions à GIMP. Mais bon, je suis clairement parti pris et je ne veux pas créer une mauvaise ambiance autour de questions financière.
À la place, je dis clairement aux gens: si vous voulez financer du développement dans GIMP, vous pouvez donner à LILA; si vous voulez financer la partie communautaire, nos réunions bénévoles, etc. alors donnez à GIMP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Les captures d'écran montrent de vieilles interfaces, les photos du hardware antédiluvien, le texte est vieux et mériterait une revue, plein de fonctionnalités sont absentes. Etc. etc.
On accepte aussi des tutos (sous licence libre seulement, comme le manuel) récent et de qualité: https://www.gimp.org/tutorials/
Je suis pas sûr de comprendre. GIMP a déjà un concept de répertoire utilisateur vs. répertoire système pour les plug-ins, et ce depuis très longtemps.
Ensuite sous Windows, je pense que le répertoire système serait $PREFIX/lib/gimp/2.0/plug-ins/ ($PREFIX étant là où GIMP est installé).
Mais non ce n'est absolument pas nouveau et ce n'est pas de cela dont je parle ici. Je parle juste d'une nouvelle organisation des plug-ins, où on demande de mettre chacun dans son propre répertoire afin d'éviter la pollution de DLLs apportés par un plug-in tiers.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On avait déjà publié nos rapports, mais c'est vrai qu'on l'a pas fait dernièrement. LILA est une micro asso et c'est vraiment dur de tenir tout à jour dans les temps. Mais c'est noté. On va essayer de faire les choses au plus carré (en fait, ça a toujours été notre but de faire le plus carré et transparent; j'ai un peu honte qu'on y arrive même pas!). Tu as entièrement raison de dire que ce type de transparence est important.
Quoiqu'il en soit, les donations vont à ce jour principalement dans la production de ZeMarmot. C'est notre seul gros projet à ce jour (notez qu'on ne serait pas contre d'autres projets en parallèle si des gens cherchent une structure dans l'Art Libre pour développer leur projet; mais à ce jour, y a pas vraiment, même si y a eu un peu). LILA fait des salaires intermittents en bonne et due forme.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est quand même très récent. Le redressement d'image est sorti dans la 2.10.4, soit début juillet. En 2 mois, je pense qu'il est impossible de connaître tout GIMP.
Je travaille sur le code de GIMP depuis 6 ans, et je découvre sans arrêt des trucs. Aryeom travaille quotidiennement dans GIMP, toute la journée (du matin au soir, en continu… enfin hors pause et éditions vidéos, etc. ;p), et c'est pareil. Toutes les 2 semaines, y a un "quoi on peut faire ça? C'est cool!".
Alors que tu n'aies pas trouvé une fonction par hasard en 2 mois, ça me semble absolument pas étonnant. Et franchement je doute qu'on puisse attribuer ça (ou en déduire) un problème ergonomique quelconque sur l'emplacement de la fonctionnalité. :P
GIMP fait partie de ces outils pour professionnels, vraiment très complets et avec des fonctionnalités tellement nombreuses qu'il faudrait des jours à ne faire que ça pour toutes les essayer et comprendre leur utilisation (et encore même là, ça veut pas dire qu'on verrait immédiatement un usage concret immédiat). Ce n'est pas forcément un mal. On me demande pas de connaître le moindre rouage de mon hardware et tout le code source de mon système d'exploitation pour l'utiliser (cela ne m'empêche pas d'être un développeur décent, je pense). Pourtant je suis sûr que je ferais des choses extraordinaires si je connaissais tout sur tout. ;-)
Quant au fait que l'outil de mesure s'appelle ainsi, perso je le vois un peu comme une sorte de règle, et même si la fonction première est en effet de mesurer, l'utiliser pour remettre droit me paraît au contraire une évolution des plus naturelles (cf. les règles niveau à bulle).
Quant aux repères, comme quelqu'un le note, on peut afficher des grilles, on peut aussi utiliser des guides de canevas, et enfin l'outil de rotation lui-même a une fonctionnalité de guides qui peuvent avoir divers formats (règle de 3, de 5, diagonales, etc.). Voir les options de l'outil de rotation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Quelqu'un peut-il corriger "東京で住んでいる" en "東京に住んでいる"?
C'était pas Tokyo mais Paris (et j'ai fait exprès de le laisser en alphabet plutôt que katakana, histoire de montrer l'orientation mixte).
Quoiqu'il en soit, en cherchant sur le web, il semblerait en effet que 'で' est moins utilisé/utilisable, car ce n'est pas une action. Quoique apparemment certains japonais disent (sur des forums) utiliser habituellement 'で' dans une telle phrase, mais il apparaît tout de même que ce n'est en effet pas du japonais littéraire.
Perso la phrase me paraissait grammaticalement correcte, mais bon… c'est pas comme si je parlais bien japonais! :P
Je note tout de même que tu me demandes carrêment de corriger la capture d'écran. Ahahah! Désolé, je vais pas perdre une seconde là-dessus (le but, c'était de montre l'orientation mixte; objectif atteint!). :P
Tu es d'ailleurs la première personne à me faire la moindre remarque sur cette erreur.
Sinon, dépêche intéressante, mais j'aurais aimé savoir ce que ça veut dire, "redressement d'image".
Ce n'est peut-être pas le bon terme. Comme souvent, quand je traduis mes dépêches GIMP de l'anglais vers le français, je vérifie s'il y a déjà une traduction (en gros, je regarde le fichier fr.po des traductions de l'interface en français). Il n'y en avait pas pour "straighten" (et toujours pas d'ailleurs, je viens de regarder). Alors j'ai traduit comme je pouvais. Même maintenant je continue à pas trouver ça si mal d'ailleurs, faute de mieux.
Mais je suis ouvert à des propositions (pas que ça serve à grand chose; je suis pas dans l'équipe des traducteurs et n'ai donc pas mon mot à dire de toutes façons).
Comme quoi, il semblerait que je parle mal le français ET le japonais! C'est la fin! ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Déjà un peu d'explication du problème pour bien comprendre. Windows cherche les DLLs dans cet ordre:
Le répertoire où se trouve le binaire
le répertoire courant
les divers répertoires système
enfin les répertoires listés dans le PATH.
Pour le binaire principal gimp-2-10, c'est facile car il suffit de mettre toutes nos DLLs dans le même répertoire $PREFIX/bin/. Elles seront toujours trouvées en premier.
Le problème est pour les plug-ins qui sont dans $PREFIX/lib/gimp/2.0/plug-ins/ et lorsque ces plug-ins souhaitent utiliser certaines des bibliothèques livrées avec GIMP (qui sont donc dans $PREFIX/bin/).
On pourrait simplement mettre les librairies à côté de chaque plug-in, mais cela signifierait dupliquer les bibliothèques un certain nombre de fois. Et en plus ça ne permettrait plus aux plug-ins tiers de profiter des biblios livrées. Donc ce n'est pas acceptable.
À la base, on rajoutait donc $PREFIX/bin au début du PATH (qui est spécifié dans un script de lancement). Mais si jamais une application installe une DLL (que nous utilisons, mais dans une version incompatible) dans un répertoire système, alors cette DLL est trouvée avant et les ennuis commencent.
Une autre solution à laquelle je pensais est de jouer avec le répertoire courant (le faire pointer sur $PREFIX/bin) mais il se trouve que si SafeDllSearchMode est activé (apparemment une valeur de la base de registre), le répertoire courant est soudainement cherché après les répertoires système aussi! Donc ça marcherait plus (enfin surtout ça dépendrait de la configuration de l'OS).
La solution est donc d'utiliser SetDllDirectoryW() pour donner la priorité à $PREFIX/bin, et pour être précis le mettre entre le répertoire du binaire (permettant aux plug-ins de bypasser nos biblios au besoin) et les répertoires système. C'est donc une solution au niveau du code.
Un cas supplémentaire que nous avons corrigé dans 2.10.6 fut les plug-ins 32-bit lancé dans un environnement 64-bit. Dans ce cas, on doit leur donner un répertoire différent avec des versions 32-bit de nos bibliothèques (on le met dans $PREFIX/32/bin par défaut, mais j'ai mis un flag pour changer ce répertoire à la compilation). Je détecte donc le bitness d'un plug-in avant de le lancer et lui assigne le bon répertoire de bibliothèques avec SetDllDirectoryW().
Un nouveau cas dont j'ai récemment pris connaissance (et pas encore corrigé) est les plug-ins scripts lancés par un interpréteur 32-bit sur environnement 64-bit (si le script utilise des bibliothèques compilées). Dans ce cas, on devra détecter le bitness de l'interpréteur.
Par exemple notre installeur embarque seulement Python en 32-bit (je ne suis pas sûr pourquoi). Donc des scripts python un peu complexe qui utilise des biblios C risquent de ne pas fonctionner.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Dans votre article, si je veux vous soutenir GIMP c'est pour des projets tierces (la marmotte, tout ça…).
Ce projet tiers est ce qui permet de contribuer à GIMP et a fait de moi l'un des plus gros développeurs de GIMP ces dernières années (même le plus gros selon le décompte).
C'est simple, sans ZeMarmot, pas de GIMP. Je contribuerai alors sûrement à d'autres logiciels libres, selon mes autres besoins, mais je n'ai pas besoin de GIMP personnellement plus que ça (enfin régulièrement, je découpe, redresse, rend plus net, etc. des photos; mais pour cette utilisation basique, GIMP est déjà largement au niveau). Là on en a vraiment besoin, dans un projet professionnel, au quotidien 8h par jour.
(0) On a besoin qu'il soit stable. Quand on faisait les premiers tests avec Aryeom Han, GIMP crashait pour un rien (c'était vers 2012). Ça foutait la honte. Mes premières années de contribution, j'ai corrigé beaucoup de crashs (de mémoire, y en avait en utilisant une tablette graphique; y en avait aussi des supers mauvais lorsqu'on utilisait un IME, en particulier avec le coréen, dans l'outil texte, et plein d'autres dont je me souviens même plus) et autres problèmes de stabilité. Bon j'en corrige encore régulièrement, mais GIMP est devenu beaucoup plus stable.
(1) Toujours dans la recherche de stabilité, on a besoin de pouvoir aisément débugger et parer aux problèmes (qui arrivent sur tous logiciels même les plus stables). Donc j'ai implémenté une sauvegarde des images au moment du crash (pour ces bugs survivants qu'on n'a pas encore corrigés!), et GIMP propose maintenant au lancement suivant de tenter une récupération des images qui étaient en cours d'édition, ainsi qu'un système de débug qui génère automatiquement des backtraces, non seulement pour les crashs, mais aussi utilisables lors de WARNING et CRITICAL en cours d'utilisation (permet d'améliorer le logiciel en découvrant des bugs plus subtils). C'est l'une de mes fonctionnalités fétiches. Le nombre de bug qu'on a pu corriger depuis que j'ai implémenté cette fonctionnalité est impressionnant. Corriger des bugs est devenu simple, et les gens nous envoient désormais des rapports de bugs utiles, même lorsqu'ils ont aucune idée de ce qu'il s'est passé, qu'ils savent pas du tout parler anglais ni écrire des rapports de bug bien formés.
(2) On rajoute des fonctionnalités. Dernièrement je travaille beaucoup sur tous les détails pour les écrans haute densité de pixel (l'écran principal de travail d'Aryeom ne l'est pas pourtant, mais je sais qu'on y viendra; autant préparer GIMP en amont). Le système d'extension indiqué plus haut bien sûr me semble important. Nous aussi on utilise quelques plug-ins, mais très peu. Franchement c'est impossible de savoir ce qui existe et ce en quoi on peut faire confiance. Et surtout chercher, installer et faire marcher des vieux plug-ins peut être une vraie galère (et pourtant je suis développeur, c'est dire!).
Dans les quelques années passées, j'ai été responsable de plusieurs autres fonctionnalités, et je travaille à d'autres fonctionnalités encore (comme l'animation, comme on sait ici).
(3) On fait de la revue de code. Ça paraît bien moins sexy, mais c'est primordial. L'histoire de GIMP est parsemée de fonctionnalités sympas qui ont été perdues car personne n'a eu le temps de les vérifier. Je ne jette la pierre à personne: ça prend un temps fou. Dans cette sortie par exemple, l'écriture verticale n'aurait probablement jamais été intégré sans moi (je suis allé chercher le contributeur, j'ai fait la revue, les tests, les commentaires sur chacune de ses modifications; en tout j'y ai passé quelques heures).
Même le Marathi, j'ai vu un email perdu sur la liste de discussion des traducteurs auquel personne ne répondait; le problème est que cette langue n'avait plus de coordinateurs. J'ai donc essayé de relancer à la place des traducteurs (qui allait sûrement abandonner à un moment donné) et de leur donner espoir pour ne pas les décevoir (un espoir qui a abouti!).
Le redressement horizontal, j'ai retrouvé un vieux patch perdu dans le bugtracker et très basique. J'ai fait de la revue, retravaillé au dessus (car il n'était pas vraiment utilisable en l'état); Ell a fait de même ensuite. Et maintenant ça fait une super fonctionnalité.
Dans le passé, je me souviens bien de la recherche d'action (une de mes fonctionnalités préférées!). J'y ai passé un temps considérable. Le patch était cool, mais écrit par des étudiants. J'y ai passé de très nombreuses heures à corriger ce qui devait l'être, à rendre la fonctionnalité vraiment utilisable simplement, et à l'améliorer énormément. Maintenant je pourrais pas faire sans!
Pour info, dans GIMP, on a des règles stricts et du code de très bonne qualité globalement (bien sûr plus localement, on trouve beaucoup d'horreurs ici et là, comme dans tout gros code). Donc la revue est primordiale. On fait pas comme certains logiciels qui acceptent tout et n'importe quoi.
(4) On fait évoluer la politique interne. Je suis celui notamment qui a poussé depuis plusieurs années (tous les ans, à chaque fois qu'on se rencontrait au Libre Graphics Meeting) pour une nouvelle politique de sortie permettant de sortir des versions macros avec de nouvelles fonctionnalités (plutôt qu'attendre 6 ans encore pour une sortie majeure!). Et voilà, maintenant tous les mois, GIMP sort avec des fonctionnalités cool. Les gens se disent maintenant que GIMP est super actif, et on se met à avoir plus de contributions (j'ai l'impression; mais ça peut aussi être simplement car on a sorti 2.10, ou autres raisons).
(5) On a créé et on maintient le flatpak pour que les linuxiens aient GIMP facilement et rapidement à chaque sortie (GIMP est maintenant dispo sous Linux à chaque sortie avant toutes les autres plateformes!).
Et sûrement plein d'autres choses.
Ensuite soyons clair: je ne souhaite pas mettre tous les éclairages sur ZeMarmot uniquement. En particulier le mainteneur, Mitch, fait un travail de dingue, connaît le code de GIMP et ses rouages bien mieux que moi. Sans parler de Ell, un alien venu d'ailleurs, qui nous optimise GIMP aux petits oignons (avec du code d'excellente qualité) depuis qu'il est arrivé. Je ne suis pas seul (heureusement!), et on a tous les 3 une grosse part dans le succès de GIMP.
Mais clairement je ne pense pas que ce soit exagéré d'affirmer que le projet ZeMarmot a vraiment contribué largement à propulser GIMP dans une nouvelle ère. On travaille sur GIMP pour un vrai projet, au quotidien (oui je me répète) et ça vaut énormément de contributions aléatoires sans but. C'est un peu une symbiose de l'artiste et des outils. Chacun a besoin de l'autre.
Si avec cela, ce n'est pas suffisant, alors je ne sais pas ce qui l'est. Je rappelle qu'on est officiellement associé à GIMP d'ailleurs (bien sûr même! Je suis un dév majeur). Même le site web gimp.org suggère de donner directement à ZeMarmot sur la page donation, ainsi que dans ses news régulières (comme la dernière news dont cette dépêche sur Linuxfr est plus ou moins une traduction un peu retravaillée). J'aurais du mal à voir comment ça pourrait être plus limpide. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On sait pas trop non plus. J'ai aussi vu passer des trucs vite fait, mais rien qui dit clairement "c'est bon, tout va bien". Ils font pas beaucoup de communications, c'est dommage.
J'aime beaucoup Liberapay, mais tant qu'on n'a pas de message clair comme quoi ils sont à nouveau dans la course, on peut pas vraiment donner le lien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tu me reprends sur la distinction entre manager et gérer ? :)
Tu parles du fait que c'est de la gestion d'extension dans GIMP? Si oui, bien sûr que là on parle de gestion (c'est même le titre), mais il s'agit du fait d'installer, désinstaller, mettre à jour et afficher des infos sur des extensions. C'est la partie côté cliente.
Ça veut pas dire qu'on gère l'extension au sens de vraiment s'en occuper. Si elle est bourrée de bugs, si elle marche pas même, c'est pas notre problème au delà de fournir des outils (pas immédiatement, mais probablement rapidement) pour que les gens puissent indiquer une extension qui fonctionne ou pas sur telle ou telle version de GIMP. Et si l'extension n'est pas maintenue, on ne s'en occupera pas plus.
Je dirais que c'est notre problème si on découvre des malware et là oui, on intervient et on vire l'extension. À ce moment, quand il y a intention malfaisante évidente (ou grosse faille de sécurité très dangereuse), il est évidemment de notre responsabilité de réagir. Mais ça s'arrête là. C'est en ce sens là qu'on ne gère pas les extensions (côté serveur) au delà de proposer aux gens de les héberger.
Ça se discute. Tu pensais faire des revues pour les brosses par exemple ? Ce sont des vecteurs d'attaque eux aussi. On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox et c'est régulièrement un vecteur d'attaque.
Les données inertes (brosses, images splash, thèmes, icônes, dégradés, etc.) ne subiront en effet pas de revue préalable, contrairement aux données exécutées (plug-ins) qui doivent être évidemment validées avant d'être diffusées.
Ensuite bien sûr que des vecteurs d'attaques peuvent exister avec des données inertes. Cela a toujours existé et existera toujours. On a tous entendu parler de failles permettant d'exécuter du code caché dans des images par exemple.
Néanmoins cela n'est pas un comportement normal, et ainsi dire "On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox" est faux, en tous cas pour le type de fichiers que tu cites (brosses) ou que je cite (images) [bien sûr, il existe des fichiers avec du code fait pour être exécutés, comme les fameuses macros de traitement de texte; de tels fichiers doivent donc être considérés comme du code]. Donc non, charger une bosse ou une image n'est pas la même chose qu'exécuter un programme. Ce sont des données inertes faites pour une utilisation donnée, pas pour exécuter du code tiers. Quand cela arrive, c'est un comportement anormal, autrement dit un bug (le plus souvent dans le logiciel, parfois dans le format lui-même) et qui doit alors être corrigé.
Aussi cela n'a rien à voir avec les extensions. Ce type de bug, quand il existe, existerait déjà dans GIMP et pourrait déjà se produire. Les extensions ne sont qu'un conteneur supplémentaire (ajoutant un peu de sémantique au contenu, indiquant de quoi il s'agit, un nom, une description, des liens annexes, une version, etc.).
Alors c'est pas si simple, je sais que ce n'est même pas le début du projet, mais ça rend publique toute une politique et ça vous expose à du bad buzz (grand publique ou de communauté), des discussions interminables, etc.
Les haters ont toujours existé et existeront toujours. Je le sais bien, je parle moi-même régulièrement sur Linuxfr de cela. Soyons clair, ça me touche et c'est dur. Mais je ne vois pas en quoi faire ou non des extensions pourrait changer quoi que ce soit à cela.
En fait par rapport aux comportements inadéquats, ma politique perso est de rester neutre (si possible, parfois c'est dur de tenir) et d'expliquer aux gens justement ce que je disais: GIMP est un logiciel libre, le logiciel libre, ça ne marche pas comme ils semblent le penser. En plus on n'est pas une entreprise, et on développe de façon volontaire. Et non, on ne réagit pas bien aux menaces et insultes. Par contre on est heureux d'aider les gens agréables, et tout ce qu'on demande, c'est que ces gens comprennent aussi ce qu'il en est, et qu'on contribue principalement bénévolement, souvent sur du temps libre.
Eh ben, tu me croiras peut-être pas, mais être clair (et poli) désamorce pas mal de situations. Les gens se rendent compte qu'ils ont un peu été des malotrus, se calment, parfois même (ça arrive!) s'excusent.
Ensuite oui, ça n'est pas du 100%. Et certains sont juste là pour haïr, comme je disais. On ne peut rien pour cela. Mais encore une fois, je vois pas le rapport avec les extensions. Ces personnes trouveront de quoi redire pour chaque nouvelle fonctionnalité qu'on apportera. On va quand même pas s'arrêter d'améliorer nos logiciels pour ces gens là! En tous cas, perso, c'est pas pour eux que je développe. :-)
est-ce que les développeurs auront suffisamment la foie pour ne jeter l'éponge ?
Je crois que tu cherches des problèmes là où y en a pas. :-)
Pourquoi qui que ce soit jetterait l'éponge pour quelques aigris? Si ça devait arriver, crois moi, ça serait arrivé y a trèèèès longtemps (comme tout gros logiciel connu, on collectionne quelques aigris).
Au pire du pire, si vraiment ça se passait super mal, on pourra toujours arrêter notre système d'extensions tiers (et n'héberger que nos propres extensions, voire un choix très restreint d'extensions sélectionnées au cas par cas, comme quelqu'un le propose plus haut). Perso je trouverais cela un peu dommage, mais si on devait en arriver là, c'est pas la mort.
Soyons clair, je ne pense pas qu'on en arrivera là. Je vois aucune raison à cela.
Ah oui, et:
bad buzz
Encore une fois, du vocabulaire de startup hipster. On s'en fout du "bad buzz". Je dirais même qu'on vit dans un monde où cela n'existe pas. Il y a des gens sympas, des gens moins sympas, ça s'arrête là. Si ce prétendu grand méchant bad buzz devait avoir eu raison de nous, ça serait arrivé y a très longtemps.
Je préfère t'avertir de mes craintes, pour que tu sois moins surpris si (malheureusement) ça arrive.
Merci beaucoup de t'inquiéter pour nous.
Je pense perso que tu te fais du mouron pour rien. :P
Si le type de problème dont tu parles devait arriver, je pense pas que ce soit parce qu'on ait ajouté un système de gestion d'extension dans GIMP. Ahahahah!
Sur ce, j'arrête de répondre sur cette news. J'ai un peu l'impression de trop l'accaparer en hors-sujet là, alors que c'est censé parler de ce super logiciel qu'est G'Mic. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Nos installeurs contiennent la version 32 et 64-bit et installent la version appropriée. C'est écrit juste sous le bouton de téléchargement. Donc prends simplement l'installeur unique et ça te mettra la bonne version.
ou en fait uniquement pour Windows >=7
Ça oui par contre. C'est pas qu'on veut pas prendre en charge de plus vieux Windows, mais on n'a quasi aucun dév Windows (approximativement 0) alors on fait ce qu'on peut. Prendre en charge de vieilles versions veut dire plus de boulot car on doit contourner des problèmes de manières plus compliquées (même si des versions récentes ont peut-être amené des solutions simples).
Notre ligne directrice pour savoir si on prend en charge un OS (Windows ou macOS), c'est que cette version de l'OS doit au moins être encore pris en charge par son éditeur. Windows XP, y a plus de support depuis avril 2014 (d'après Wikipédia) et on parle quand même d'un système sorti en 2001, soit y a 17 ans!
Il est peut-être temps de mettre à jour. Et si le matériel est juste trop ancien, on peut mettre un Linux avec bureau léger. Ou si vraiment on est nostalgique des vieilles années et qu'on veut garder l'OS d'époque absolument (faire attention à l'accès internet, etc. dans ce cas), ben on prend sur soi et on garde aussi les vieux logiciels (y compris GIMP 2.8). :-)
Enfin bon, tout cela pour dire qu'il n'y a pas vraiment de solutions miracle, désolé. On peut pas prendre en charge indéfiniment un système, surtout si même son éditeur ne veut plus le prendre en charge. Ce serait vraiment se tirer une balle dans le pied.
Je veux bien le compiler, mais c'est possible de le compiler en 32 bits pour XP (et un CPU Pentium3) avec Visual Studio (MSVC), ou faut obligatoirement utiliser un autre système de build ?
Tout est possible. Ensuite je crois que la plupart des gens qui compilent GIMP pour Windows le font depuis un Linux (même notre build officiel est cross-compilé, il me semble). Donc ce sera clairement cela le plus simple.
Et je suis pas certain que ce build fonctionnera de toutes façons. Ne pas prendre en charge Windows XP, ça veut surtout dire qu'on a peut-être (probablement) utilisé des APIs Windows qui n'existaient pas encore dans XP. Donc tu te retrouveras à devoir patcher le code en fonction des parties qui poseront problème. Si tu le fais sans perte de fonctionnalité ni rendre le code surcompliqué (et avec un code propre), on veut bien le patch (on n'est pas absolument contre Windows XP, on ne le prend pas officiellement en charge, c'est tout).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Quand tu gère des extensions du deviens responsable au moins en parti d'elles.
On ne les gèrera pas. On les hébergera. Mais oui tu as raison quand même qu'on aura notre part de responsabilité.
Actuellement rien ne cloisonne les extensions, donc tu veux faire de la revue et le build chez toi.
Même si GIMP lançait des sandbox, la revue et compilation doivent être faites de notre côté. Héberger aveuglément un binaire d'inconnus complets est une aberration.
C'est la raison pour laquelle les plug-ins compilés ne seront pas acceptés tant qu'on n'aura pas l'infra. Certains bénéficieront d'exception évidente comme G'Mic. C'est expliqué dans mon article.
C'est super comme idée, mais je crains que ça ne consomme toute ton énergie (je serais heureux de me tromper !)
Je ne prévois pas de gérer le site. Je suis développeur pas animateur de communautés. Nous avons une très grosse communauté avec des gens très actifs et même pas mal plutôt techniques. Des gens comme Pat David et Elle Stone seront parfaitement capables de gérer le quotidien (et de sélectionner les futur modérateurs si le contenu grossit vite).
Aussi on pourra y aller lentement. Si les gens sont pas contents du temps de revue, ce n'est pas notre problème. L'un des énormes avantages que l'on a est qu'on n'essaie pas de faire du business. Nos actions ne sont pas dirigées par des contraintes économiques. Ça rend GIMP très résistant aux problèmes car personne ne peut nous forcer à rien ni nous presser.
Bon j'arrête là. Cette dépêche est au sujet de G'Mic pas de GIMP! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Non ce n'est pas envisageable. De même que notre installeur Windows ne contient pas G'Mic (pas plus que tout autre plug-in tiers), ni notre DMG pour macOS.
Les builds officiels de GIMP ne contiennent (et ne contiendront toujours) que les plug-ins core de GIMP, c'est à dire ceux maintenus par les développeurs de GIMP. On a déjà bien suffisamment de boulot (avec très peu de développeurs) pour ne pas non plus se donner plus de travail. En outre si quelqu'un fournit un paquet, il est de-facto responsable de son contenu (or on ne développe/maintient pas G'Mic). Pour G'Mic, c'est un logiciel suffisamment complexe et élaborée pour qu'on se rende bien compte que si David venait à arrêter demain (on touche du bois pour que ça ne soit pas le cas!), on ne serait pas à même de le maintenir à sa juste valeur.
Donc non, on ne peut pas.
De même que David, je pense qu'il préfère garder l'indépendance dans ses sorties, etc. et ne pas dépendre de nos choix de sortie.
La tendance est plus à la création d'un système d'extension (voir ma news pour GIMP 2.10.6 qui devrait être publiée d'ici quelques jours) qui permettra d'installer facilement G'Mic et autres plug-ins, tout en laissant les développeurs de ces plug-ins en garder la main complète. Tout le monde y gagne. Et je sais, de source sûre, que David aime l'idée. ;-)
D'ailleurs une fois que cela sera en place, il est même possible que certains des plug-ins core actuels puissent devenir des extensions à leur tour (toujours maintenus par nous, mais avec un rythme de développement parallèle), ce qui permettrait des menus moins touffus de fonctions que peu de monde utilisent par exemple. À voir…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Perso je pense que la prévisu sur canevas serait super utile, même pour les traitements lents.
Pour ma part, je trouve donc que l'idée d'adopter systématiquement une prévisualisation on-canvas n'est pas excellente.
La prévisualisation n'a pas à être activée par défaut. ;-)
Il vaut mieux dans ce cas pouvoir effectuer les traitements plutôt sur de petites portions d'images pour prévisualiser le résultat.
GIMP donne aussi la priorité au rendu de la partie visible à l'écran, et le mipmapping aide aussi beaucoup si un zoom (avant ou arrière) est fait. Et je sens que les choses vont s'améliorer encore dans le futur pour optimiser la sensation de fluidité (ou du moins de pas avoir une expérience trop désagréable), même avec des traitements lents.
L'édition non-destructive aura a priori le même genre de limitations.
Ce sera clairement utile pour l'édition non-destructive également. Faire un changement dans les paramètres d'un effet peut te prendre 10 minutes, mais dans tous les cas, tu devras le refaire (ton effet). Dans le cas de l'édition non destructive, au moins tu pourras voir les paramètres utilisés précédemment et repartir de là. Dans le cas de l'édition destructive, tu as intérêt à avoir bien gardé une copie du calque d'origine et tu ne sais même pas l'ensemble des traitements faits, et avec quels paramètres, à part si tu les as notés bien consciencieusement (ce que certains font dans le nom du calque par exemple).
Pour moi, il n'y a rien d'équivoque là. Mais je crois qu'on a déjà eu cette discussion et qu'on pourra encore l'avoir à l'avenir. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
j'ai aussi souvenir d'un dev' de chez GNOME ou GIMP, je ne sais plus, assez imbus de lui-même, qui ne donnait pas spécialement envie d'utiliser GIMP
Je ne contribue que depuis (relativement) récemment, c'est à dire depuis 2012. Mais il paraît que certains des anciens contributeurs de l'époque d'avant n'étaient pas très cool, voire peut-être même un peu toxique. Mais ce n'est que du "on dit" car je ne les ai pas connus.
En tous cas, de nos jours, ce n'est plus le cas. :-)
[HS]Vous ne faites plus de lives ZeMarmot ? J'y passais de temps en temps même s'il n'y avait pas grand monde, c'était reposant de regarder quelqu'un dessiner. Après j'imagine que monter tout le setup pour si peu de résultat était peut-être un peu frustrant.[/HS]
On a un peu mis en pause pour diverses raisons. Déjà y a le côté technique. Le logiciel de streaming (libre) faisait quand même beaucoup souffler la machine (qui a déjà beaucoup à faire quand on fait de l'animation), voire était plutôt instable (cela nécessite OpenGL 3.2, ce qui veut dire qu'on doit installer les pilotes Nvidia proprio, et même là, ce n'est pas parfait). Le pire n'est pas seulement que ça plantait parfois, mais qu'il arrivait à faire freezer la session graphique de temps en temps. OBS Studio est cependant très connu et une référence a priori chez les gens qui font du live, même s'ils savent pas que c'est libre. Y a peut-être quelque chose à configurer mieux. Et aussi j'ai cru comprendre que la version Linux est moins stable de manière générale. À voir…
Ensuite oui, y avait pas tant de monde, et on se disait que ça valait pas forcément le coup.
Mais surtout, Aryeom a eu une petite période de blues ces derniers mois (je l'ai déjà dit, l'un comme l'autre, on se pose beaucoup de questions; on nous dit constamment que GIMP peut lever beaucoup de financement participatif, mais dans les faits, notre financement est faible), voire un petit burnout. Donc elle a préféré continuer à travailler sans les lives. Mais là je lui ai montré ton message, et elle se dit qu'il faut peut-être les recommencer. On verra!
P.S.: ne pas hésiter à laisser un message si on reprend les lives. Ça fait toujours plaisir et ça donne moins l'impression de faire un direct dans le vide. Faut pas donner tous les mercis qu'à moi. Y aurait rien de tout cela sans Aryeom non plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# J'ai lu, je ne suis pas d'accord
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal The Minimum Viable Pull-request. Évalué à 10. Dernière modification le 08 novembre 2018 à 13:16.
Sommaire
Bon, comme quoi ça sert d'avoir tous ces commentaires pour te dire que c'est pas une bonne présentation: je prévoyais absolument pas de lire (je ne sais pas si c'est la présentation, ou juste le fait que je lis rarement ce types d'articles), mais en lisant les commentaires ici, j'ai décidé de jeter un œil à ton essai.
Bon ben je ne suis pas d'accord avec les prémisses du problèmes, ni avec les "solutions".
Prémisses du problème
Ben… si. Ce que tu appelles cette approche "cowboy solitaire", c'est exactement ce qu'il faut faire selon moi. Je pense que tu compliques en sur-pensant un problème simple.
Et la raison pour cela est (j'ai l'impression) que tu ne contribues peut-être pas pour les bonnes raisons. Tu dis jamais vraiment pour quoi tu contribues, alors je vais supposer (peut-être à tort) que tu contribues pour contribuer car plus tard, quand tu parles de ton cas concret avec ton plugin gradle, tu expliques que tu as ouvert des pull requests dans divers projets pour leur faire utiliser. En fait donc rien n'allait pas bien dans ces projets hormis le fait qu'ils n'utilisaient pas ton plugin?!
En fait, le "pourquoi on contribue" est tout simplement LA source des contributions. Faut pas chercher plus loin. Tu parles de ses "Rock-Star Ninja Developers". Aucun ne se pose le type de questions que tu poses (et tous emploient l'approche que tu as nommé "cowboy solitaire"). Ils savent juste pourquoi ils contribuent. Certains, car c'est leur boulot. D'autres car c'est leur projet perso. Beaucoup, comme moi, car on utilise et simplement on a des bugs ou on veut des fonctionnalités. Énormément de développeurs viennent nous voir chez GIMP avec comme premier message "Je veux contribuer à GIMP, vous pouvez me dire sur quoi je peux coder?". Déjà ça part super mal. Tellement mal que je n'ai pas vu UN SEUL contributeur de ce type qui a réellement fourni un patch au final, de mémoire.
Un contributeur qui donne quelque chose de concret est uniquement les dits "cowboys solitaires" qui ont un besoin, le patche et fournissent le patch. Simple.
Ceux là, on en voit régulièrement dans GIMP. Bien sûr, des fois on discute la fonctionnalité ou son implémentation, mais en général on arrive à une solution.
Pourquoi? Parce que déjà si la fonctionnalité (ou la correction de bug) était nécessaire pour cette personne, y a de grandes chances que ça le soit pour d'autres, donc les chances de la voir acceptée est grande aussi. En plus elle sera probablement mieux codée car la personne l'utilise vraiment (et donc verra les bugs oubliés).
Personnellement c'est bien simple, de ma vie, je n'ai contribué que pour des choses qui m'étaient nécessaires. Et encore j'arrive pas à tout faire. Si je pouvais physiquement faire plus, j'ai 1000 autres patchs à créer à 100 autres projets! Alors je comprends pas les gens qui posent la question "que faire?" qui mène à la question "comment contribuer à un projet libre?". Qui n'a jamais eu un bug ou un crash d'un logiciel qu'on utilise beaucoup? Qui n'a jamais pensé "Ah ce serait cool si je pouvais faire ça"?
C'est bien simple, le jour où tu auras un besoin, aucune de ses questions ne se posera plus. Tu corrigeras pour toi et tu enverras le patch. Et c'est bien tout!
Comment contribuer?
Bon maintenant que j'ai établi que les prémisses sont problématiques et que la question qui est la base du reste de la discussion est la mauvaise, on pourrait arrêter là. Mais soit, admettons qu'on veuille quand même poser cette question étrange: comment contribuer?
Les problèmes?…
Les problèmes cités sont:
Bon ça peut arriver. Tu peux regarder les logs et si y a rien depuis longtemps, on peut se poser des questions (même si ça veut juste dire qu'y a pas de développement actif, mais il peut y avoir maintenance minimale quand même). Ensuite est-ce grave? Comme je l'ai dit, la prémisse est mauvaise si tu contribues sans avoir besoin. Si c'est pour juste histoire d'avoir ton nom dans une liste de gens, bon ça sert à rien de contribuer. Si tu utilises, ben tu fais ton patch, tu l'envoies quand même (sans grand espoir peut-être, mais une fois fait, autant envoyer; au pire ça servira peut-être à quelqu'un d'autres même si c'est jamais inclus), et tu utilises pour toi, tout content car tu as corrigé ou amélioré un logiciel que tu utilises!
Éventuellement s'il s'agit d'un logiciel qui a un certain intérêt clair, tu peux en reprendre la maintenance. Je l'ai fait pour quelques logiciels, en général en mode "maintenance seulement". C'est à dire que je prends les patchs des gens, je les applique, je mets à jour le strict minimum pour le système de compilation au besoin. Travail minimum mais je m'arrange que le logiciel reste au moins utilisable, compilable et pas trop buggué (car, je répète: moi aussi j'utilise! Ou du moins j'utilisais quand j'ai contribué).
Dans de tels cas, je serais d'ailleurs heureux de pouvoir en passer la maintenance à quelqu'un en gardant le code à flot jusqu'à ce que quelqu'un qui souhaite s'impliquer plus que moi débarque (par exemple je maintiens Tiny Segmenter de cette façon, où je fais en gros une release par an avec un unique patch que quelqu'un d'inconnu m'envoie de temps en temps).
Ça arrive. C'est chiant surtout si tu veux vraiment cette fonctionnalité, et rien n'est pire que de maintenir ton fork perso juste pour toi. Mais bon, c'est la vie!
Je fais plein de trucs tout le temps, et ça mène pas toujours à quelque chose de concret (je parle même pas de développement, mais dans ma vie en générale).
Tous les autres problèmes cités sont juste des problèmes de développement. Je vois pas le problème du tout. Oui, il se peut qu'on te demande de revoir ton patch. Et alors? :-)
On n'a jamais dit que le développement d'application était un truc facile et que l'implémentation de nouveau code se fait toujours en une fois. :P
Franchement j'ai du mal à voir les problèmes dans ta liste!
Solution?
Alors là on est à un point où on est pas d'accord sur les prémisses, puis sur la liste de ce qui est ou non un problème. Donc je pense que ça sert à rien de continuer en citant aussi tes solutions (ton "MVP"). Mais il va sans dire que je crois absolument pas que ce soit une solution à quoi que ce soit.
Attention je dis pas que ce que tu dis est mauvais et qu'il faut pas parler avec les mainteneurs d'un programme! Juste que clairement ce que tu sembles indiquer comme une sorte de recette magique n'en est absolument pas une selon moi.
Bon allez, juste une citation quand même:
Alors ça c'est super sensible. D'un côté, si ce que tu vas faire va te prendre beaucoup de temps (genre au moins 2 semaines à temps plein!), alors oui il vaut peut être mieux de s'assurer que ce sera intégré.
Néanmoins ne disions nous pas qu'on développe aussi pour nous?! Si c'est une fonctionnalité que tu veux vraiment vraiment, est-ce vraiment perdu si tu peux au moins utiliser cela même si c'est refusé upstream? C'est pas une question réthorique, mais une vraie question à faire au cas par cas sur chaque projet. Je le disais plus haut, maintenir un fork perso quand le projet principal évolue beaucoup (et qu'on veut aussi bénéficier des évolutions) n'est pas quelque chose que je conseille à la légère. Mais dans certains cas, ça peut valoir le coup.
Ensuite et si le développeur comprends mal ta proposition et refuse (alors qu'il aurait accepté en voyant le vrai patch)? Et s'il a trop de boulot et ne lit pas ton message avant 6 mois (quand tu as déjà abandonné depuis longtemps et es passé à autre chose)? Et si ça engage des discussions avec des trolls où on se met à faire du "bikeshedding" avant même que la moindre ligne de code utile soit produite?
Perso je demande jamais, ou presque (en fait, quand je demande, c'est plus quand c'est vraiment pas prioritaire, que je sais que de toutes façons je le ferai pas tout de suite car je peux pas faire du temps pour ça, ou quand j'espère que quelqu'un d'autre me prendre l'idée que je mets par écrits et le fera avant moi). Je fais, j'envoie et j'oublie.
Éventuellement si on me demande des changements, je reçois de toutes façons un email de notif, je reviens sur mon code quand je peux faire un peu de temps, je change, je pousse et oublie encore.
Obtenir permission, c'est plus une perte de temps et de motivation qu'autre chose. Je suis plus en maternelle quand je demandais permission à la maîtresse pour tout et rien. Le pire qui puisse arriver, c'est que mon patch ne soit pas accepté. J'aurais alors utilisé quelques heures ou jours pendant lesquels je me suis cependant bien amusé à lire du code et le comprendre, et au final j'aurais un changement que je peux quand même utiliser moi-même (ce qui était le principal but, je le rappelle).
Et ma "solution"?
Allez pour ne pas laisser ce commentaire sur une note négative, je vais quand même laisser ma "méthode". Notez les guillemets car c'est un peu présomptueux de parler de solution ou de méthode. Je pense pas qu'une telle chose existe, et ça va dépendre des gens aussi.
Mais voilà, ça se résume en 3 mots: persévérance, compréhension et bienveillance
Persévérance
Dans persévérance, on pourrait aussi mettre patience. De manière générale, ne pas s'attendre à une inclusion éclair d'un patch. Alors ça peut arriver, mais juste ne pas s'étonner quand ça n'arrive pas. Je le disais, c'est pour cela qu'en général je fais, j'envoie, j'oublie. Forcément si on reste devant sa boîte email à attendre une notification de réponse, ça ne peut être qu'une mauvaise expérience dans beaucoup de cas et on peut facilement se mettre à étiqueter un projet comme "non maintenu" même quand il l'est.
Par contre il faut aussi savoir revenir sur un patch. En général je conseille d'attendre quelques mois. Genre si 2 ou 3 mois après un envoi de patch, il n'y a pas de réponse, alors faire une petite relance, poli et gentille. On sait jamais, le mainteneur a peut-être vu, puis a oublié. Ça arrive.
Puis répéter, régulièrement, toujours agréablement et poliment. Note que je n'ai même pas besoin de garder une liste de mes patchs en attente, puisque j'utilise les choses que je patche, donc je m'en rappellerai forcément un jour (genre dans 2 mois, je lance tel programme et utilise telle fonctionnalité, et "tiens j'ai jamais eu de nouvelle de ce patch" vient tout seul).
En fait dans les rares patchs que j'ai faits et qui n'ont pas été intégrés, certains sont parce que j'étais jeune et ne savais pas encore à l'époque qu'il fallait savoir insister un peu (je me souviens d'un de mes patchs pour une cool fonctionnalité sur mplayer par exemple; je n'avais jamais eu de réponse puis j'ai oublié même si j'ai moi-même utilisé mon patch pendant des années; de nos jours, dans mpv, la fonctionnalité que j'avais implémenté existe, implémentée par quelqu'un d'autre).
Il n'y a pas de mal à insister un peu, du moment qu'on le fait agréablement (je me répète sur le côté poli/agréable, mais c'est important). Ça ne gêne personne ni n'est jamais mal pris.
Compréhension
Compréhension du problème bien sûr, ça c'est le boulot du développeur. Mais surtout compréhension des gens. Savoir ce qu'autrui veut, comprendre ce que l'autre dit et pourquoi il aime ou non, et essayer si possible de faire des compromis (pour éviter le problème du fork perso à maintenir) quand il apparaît que sa proposition initiale ne sera pas intégrée (du moins pas comme tel). "Discuter" (dans le contexte d'une discussion sur un patch), en général ça veut dire "comprendre ce que l'autre veut et comment faire pour qu'on ait tous les deux ce qu'on veut".
Aussi comprendre l'humain et pourquoi quelqu'un ne répond pas vite par exemple. Ou bien ne pas prendre mal si on a l'impression de recevoir une réponse un peu sèche (peut-être l'était-elle, peut-être était-ce juste une incompréhension de l'écrit). La plupart des situations peuvent être désamorcées en essayant de comprendre autrui et de réagir de manière appropriée.
En gros avoir de l'empathie.
Bienveillance
Ça peut sembler une répétition des 2 points précédents, et c'est vrai que tout se mêle un peu, mais c'est vraiment important alors ça mérite son propre point. Quoi qu'on fasse, essayer de le faire posément et avec bienveillance. C'est pas toujours facile. Il arrive à tous de se mettre en colère quand certains sont vraiment insupportables. Mais parfois se faire un peu violence et même avec les gens très désagréables, il faut essayer de rester poli. Dans tous les cas, rien ne viendra jamais d'une guerre ouverte et d'une dispute.
Voilà. Donc avec ces quelques points bien respectés, non seulement tu te poseras même plus la question de "comment contribuer?" car ça viendra tout seul, mais en plus la plupart des patchs seront intégrés sans trop de problèmes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: multifichier
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Lufi 0.03 (journal bookmark). Évalué à 3.
Pourquoi mettre cette option au niveau de l'envoi (et même avant l'envoi en fait!)?
Quand quelqu'un envoie plusieurs fichiers, Lufi ne peut-il pas générer un lien par fichier ainsi qu'un lien qui permet de télécharger l'ensemble des fichiers d'une même session d'un seul coup? En gros pas besoin d'option, simplement proposer l'ensemble des possibilités avec des liens bien visibles/compréhensibles après coup.
Je trouve aussi que ce serait une bien bonne idée, et une meilleure implémentation de la dite idée.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Motifs…
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Firefox 63. Évalué à 5.
C'est simplement la syntaxe glob (et ça n'a vraiment rien de nouveau).
C'est bien simple: quasi toute commande (sous Linux du moins) qui propose un système de reconnaissance d'expressions le fait soit en glob, soit en expression régulière. Souvent les deux d'ailleurs (
finda-name/-iname/-path/-ipath, etc. en glob et-regex/-iregexen expressions régulières).C'est aussi pourquoi un manuel ne va pas lister les constructions possibles, il suffit de dire que c'est un "glob pattern" (ceci dit, je viens de jeter un coup d'œil sur le man de
findet ils parlent de "shell pattern" partout, sous-entendant "glob pattern", sauf à un endroit où ils disent bien "glob pattern") et les gens peuvent se renseigner sur la syntaxe ailleurs.Et oui Bash ne comprend par défaut que le glob en effet (ce pourquoi ils disent "shell pattern", mais ce n'est pas une simplification correcte, car rien ne dit que d'autres shells ne travaillent pas en expression régulière; d'ailleurs même bash a en fait une prise en charge possible avec
=~).Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Options
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 10. Dernière modification le 08 octobre 2018 à 19:47.
Cependant y a une petite incohérence ici, car ça ne fonctionne pour voir la liste des options qu'une fois le projet configuré avec succès une fois. Ce qui est ironique quand parfois on doit pouvoir configurer les options pour justement permettre le succès de la configuration!
On est donc forcé de se coltiner le fichier
meson_options.txtavec son éditeur pour lister les options. Il existe une demande de fonctionnalité pour permettre d'obtenir la liste des options depuis un appel de commande (issue 2402). C'est un petit recul (même si la lecture d'un fichier bien tenu rend la chose moins terrible).L'interface ncurses à la
ccmakeserait aussi une bonne alternative (dans les projets CMake, je ne configure quasi que comme cela) mais c'est aussi en demande de fonctionnalité (comme indiqué dans la dépêche).Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: chmod ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Zero-K, le jeu de stratégie temps-réel libre. Évalué à 5.
Hmmm… Tu voulais probablement dire que tu as un grand écran, mais sûrement pas HiDPI (au passage, c'est HiPPI, le terme que tu cherches, à part si ton écran est en fait une imprimante qui imprime 24 pages par seconde :P).
131 PPI, c'est une densité tout à fait moyenne.
On considère généralement un écran comme haute densité environ à partir des 180 PPI (disons que la valeur basse-basse-basse si vraiment tu veux être le plus inclusif/marketing, c'est 160). GNOME utilise la valeur 192 (i.e. GNOME double toutes les tailles si la densité est au dessus de cette valeur). Et encore, même dans ces zones de densité, c'est considéré peu dense par beaucoup. On a déjà eu des rapports de bug de gens avec des écrans à 200+ PPI qui disaient que les icônes étaient trop grandes!
Ensuite dans ton cas, c'est un écran énorme, voire une télé peut-être, et je me dis que tu la regardes de loin, contrairement à un écran d'ordi sur lequel tu bosses. C'est peut-être pour cela que tu trouves cela petit (et prouve bien d'ailleurs que la densité d'écran ne peut pas être le seul critère pour déterminer si on double/triple ou pas les éléments d'UI (textes, icônes, images, etc.).
Bon ensuite je fais juste mon chieur en pinaillant sur des détails techniques. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Oui : contactez-moi d'abord
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Forker ou ne pas forker ?. Évalué à 6.
Tu devrais quand même attendre la réponse du dév. Comme je le disais, même quelques semaines d'attente, c'est pas trop demander dans le respect d'autrui (mon premier point plus haut: "l'autre a aussi une vie"), d'autant plus pour un tel sujet (prendre son bébé de ses bras, c'est pas rien).
Même si son texte paraît en effet assez-clairement anti-communautaire, on sait jamais! Et il vaut toujours mieux régler une situation pacifiquement que de s'embourber dans une guerre.
Je le disais aussi, un fork, c'est énormément de boulot, il faut en être conscient. Et tu parles de "5 développeurs", mais je pense pas que tu les aies déjà. Et c'est pas sûr que tu les aies jamais. Toi même disais que tu n'avais pas plus de temps que cela, et j'ai l'impression qu'hormis cette fonctionnalité de vision annuelle, tu n'as pas forcément plus de besoin pour l'instant. Je me trompe?
Alors quand le projet a été abandonné par ailleurs, c'est autre chose. Tu peux te permettre de le reprendre avec un taux de contribution faible (ce sera toujours plus qu'avant). Je maintiens quelques projets de la sorte où je fais quasi aucun développement, mais je les maintiens en vie, et surtout j'inclus des patchs si on m'en envoie (ce qui arrive peu pour des projets à faible visibilité).
Mais là on parle d'un projet activement développé, simplement de façon non-communautaire. Ça veut dire que soit ton fork risque au final d'être "derrière" le projet principal en terme de fonctionnalités et corrections de bug, soit vous devrez passer un temps fou pour backporter tous les changements d'un coup à chaque sortie (à ce que j'ai compris, il fait juste un seul commit public par sortie, avec tous les changements mélangés).
En fait ça me fait penser à la situation de Cinelerra qui n'est absolument pas enviable, avec 3 versions! Y a les auteurs originels (on sait même pas si c'est une personne seule ou plusieurs) qui développent toujours, mais dans leur coin, sans se soucier des forks (je crois qu'ils récupèrent même pas leurs changements — dites moi si je me trompe!) et uploade juste une archive des sources une fois de temps en temps pour chaque sortie. Y a une version communautaire qui essaie de rajouter des fonctionnalités tout en ré-intégrant le code de la version originelle à chaque sortie (donc les projets doivent dévier au fur et à mesure, rendant sûrement la version communautaire de plus en plus difficile à maintenir). Et enfin y a une 3ème version, j'ai jamais compris pourquoi! Enfin bon c'est le bordel quoi (rien que ça, ça donne pas envie d'essayer; je saurais pas quelle version tester), personne se parle, et au final il suffit de voir que Cinelerra n'est plus intégré dans presque aucune distribution, c'est la galère rien que pour installer. Ils ont bien encore leur petite communauté et fans (je croise encore des gens une fois de temps en temps dans des confs qui me disent utiliser ça; c'est fou) mais bon presque personne de nos jours ne le conseille. Quand on pense qu'y a 10-15 an, cet éditeur vidéo était dans toutes les distributions et était l'éditeur que tout le monde conseillait pour de l'édition vidéo sérieuse, c'est méga triste quoi.
Ma conclusion, c'est donc: attends la réponse, mais si vraiment il est confirmé que cette personne ne veut pas de patchs tels que le tien et est allergique à la collaboration, veux-tu vraiment t'embourber dans une telle situation?
Il me semble que les programmes de comptes personnels ne manquent pas. Et d'autres seront sûrement bien plus ouverts aux patchs. Ou alors c'est un type de logiciel bancaire particulier et y en a peu des comme ça? Ou celui-là est vraiment vraiment meilleur que les autres? Pourquoi s'accrocher à ce logiciel en particulier?
J'essaie vraiment juste de comprendre en quoi ce logiciel mériterait que tu veuilles aller jusqu'à un tel fork. Mon but n'est pas de te décourager. Si vraiment tu es méga motivé et as la foi, tu as tout à fait le droit et je te souhaite un bon développement (de même qu'à l'auteur originel d'ailleurs). Mais bon c'est à bien peser. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ou tout simplement
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le broutage "sûr". Évalué à 4.
J'ai aussi reporté l'erreur et immédiatement après, je ne vois plus d'alerte. Est-ce que ça ne la montre plus localement seulement, pas même en changeant de navigateur (genre pour mon adresse IP?)? Ou bien y a juste un seuil et il suffit que quelques personnes reportent une erreur pour débloquer un site?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Oui : contactez-moi d'abord
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Forker ou ne pas forker ?. Évalué à 10.
Je vais donner un autre point de vue, qui est complètement le cul entre 2 chaises. Mais c'est vraiment comme cela que je vois la contribution au logiciel libre.
Alors d'un côté, tu as totalement raison. Si quelqu'un te file un méga-patch de centaines/milliers de lignes pour une grosse fonctionnalité dont tu ne veux pas, c'est dur de le rejeter (pour plein de raisons). Mais pour garder une cohérence au projet, ben des fois, faut bien.
Ceci dit, de l'autre côté, la personne essaie parfois de contacter, et se retrouve sans réponse pendant des jours, voire des semaines. Le truc, c'est que c'est totalement normal. On est des êtres humains, on fait des choses parfois en dehors du code. Et même si on devait coder quotidiennement à temps plein, ça ne signifie pas pour autant qu'on est obligé de répondre à toute question à la minute. On a une vie quoi.
Cependant la personne qui demande a aussi une vie. Attendre des jours, des heures même souvent, c'est dur quand on a une idée qu'on veut développer! On se met à le faire dans sa tête, on y passe des heures à y penser (qu'on a l'impression de perdre et on se dit qu'on aurait déjà bien avancé si on s'était mis directement à coder). Bien sûr, on pourrait/devrait juste poser la question et passer à autre chose en attendant la réponse (si même elle arrive). Mais l'humain est pas si rationnel et quand on a une idée en tête, c'est souvent pas si simple de "passer à autre chose".
En outre, du côté des mainteneurs, on entend très souvent la fameuse "Je suis développeur, je peux aider, vous m'expliquez ce que je dois faire?". Le truc, c'est que c'est pas si simple. D'ailleurs c'est peut-être même symptomatique d'un développeur à l'expérience limité de demander cela, comme s'il s'attendait à ce qu'on puisse lui décrire un logiciel énorme de tête en quelques minutes dans le détail. Car c'est le détail qui importe (bon bien sûr, on peut en faire dire de tête le nom de pas mal de fichiers ou fonctions et où plus ou moins précisément doit se passer tel ou tel changement, mais y a des limites quand même); oui je peux décrire la structure globale de GIMP en quelques minutes, mais une description si globale en général est inutile pour un développeur qui veut implémenter un truc précis. Il espère donc que tu lui dises où et quoi changer. Mais si on vérifie cela, on a déjà fait la moitié du boulot nous-même et on y a passé pas mal de temps.
Donc quand on donne juste une description simple, soit le contributeur potentiel comprend et il fait, soit (et c'est 90% des cas), il abandonne au bout d'un moment (et peut-être se dit que les dévs sont pas cool, ils aident pas les nouveaux, alors forcément…).
Là où je veux en venir, c'est qu'une demande qui vient avec un patch vaut 1000 propositions d'aide. C'est concret, c'est là, on sait tout de suite à quoi s'attendre (au niveau qualité du code notamment et on a une idée de ce qu'on pourra demander ou non à cette personne), etc. La proposition d'aide, notre réponse est invariablement "c'est cool, on attend le patch!" sans pour autant y mettre un espoir fou. On sait que dans beaucoup de cas, ça ne viendra pas. Je me rappelle même une fois une personne nous avoir dit avoir reçu un financement pour une fonctionnalité (j'ai retrouvé le ticket). Ce fut la première et dernière fois qu'on a entendu parler de lui.
Et en ce sens d'ailleurs, l'auteur du journal a très bien fait. Proposer un patch fonctionnel est la meilleure chose à faire quand on veut vraiment une fonctionnalité. C'est ce que j'ai appris au fil des ans, et désormais quand je veux vraiment quelque chose, je ne me pose pas la question: je la code moi-même. Attendre les autres mène rarement à l'obtention de la fonctionnalité (et ce, même si les développeurs du logiciels sont d'accord sur la fonctionnalité sur le principe; ça ne leur crée pas du temps magiquement ni ne la met en haut de leurs priorités: s'ils n'en estimaient pas eux-même le besoin au préalable, accepter qu'un autre puisse en avoir le besoin — et ce faisant accepter que cette fonctionnalité vaut le coup — ne change pas leur propre besoin).
Donc mon conseil aux contributeurs, c'est: oui bien sûr, discuter, c'est toujours bien! Mais ça ne veut pas dire que vous ne devez pas prendre un peu les devants. Les bons mainteneurs apprécient si vous avez un peu d'indépendance et que vous fassiez une implémentation dès le début. C'est la meilleure intro en tant que contributeur.
Par contre, oui, il faut être conscient que ça ne veut pas dire pour autant que votre patch sera accepté. Peut-être qu'il nécessitera juste des corrections. Peut-être que le mainteneur ne sera pas d'accord avec certains choix et qu'il faudra faire des compromis. Peut-être même (le pire des cas) que votre patch sera au final rejeté après avoir passé plein de temps pour coder et pour ensuite discuter et défendre la fonctionnalité. Ça arrive. Ça m'est aussi arrivé, et pas qu'une fois (même si globalement cela reste rare! Si vous êtes un bon développeur avec de bonnes idées, peu de mainteneurs refuseront tous vos patchs sans y penser à 2 fois, en tous cas pas les bons mainteneurs).
Mais vous savez quoi? C'est la vie! C'est pas une spécificité du développement logiciel. Dans plein de trucs dans la vie, il m'est arrivé de gâcher mon temps, en faisant ceci ou cela qui s'est avéré inutile ou refusé, ou autre. C'est chiant, mais bon. C'est pas la mort! On passe à autre chose.
En gros, la conclusion, c'est: que vous soyez mainteneur ou contributeur, soyez conscients que vous parlez avec des êtres humains:
On a un développeur qui a fait quelques patchs (de très mauvaise qualité technique d'ailleurs, donc énormément de temps de revue) pour GIMP et qui plusieurs fois nous dit des trucs genre "ce que je déteste le plus, c'est de perdre mon temps" dès qu'on se met à discuter ses patchs (pas pour les rejeter, mais réellement pour les discuter afin d'arriver au meilleur choix, qu'on ne sait pas forcément). Non seulement c'est très passif-agressif, met directement la discussion sur une mauvaise ambiance, mais en plus c'est oublier que nous aussi on existe. Nous non plus n'aimons pas perdre notre temps. Qui aime cela?
Mais on fait ce qu'on fait pour aboutir au meilleur logiciel ensemble, pas pour "perdre du temps". Si quelqu'un ne comprend pas ça, autant ne pas faire de logiciel libre.
Alors je le disais, il faut savoir refuser certaines contributions inadéquates. Ensuite sans plus de détails, je ne peux pas dire si c'est le cas des contribs que t'as reçue. Ceci dit, il faut aussi savoir demander à un contributeur à corriger son code pour le voir intégrer (cas de 2 des 3 contributions: demande au premier de compléter son patch, et au second de le refaire proprement).
Souvent aussi il faut savoir prendre de son temps pour faire faire fleurir les contributions. Je l'ai déjà dit, je fais beaucoup de revue de code dans GIMP. Mais soyons clair, la majorité de ce que je relis et corrige ne m'intéresse pas personnellement (ni pour notre projet ZeMarmot). Mais j'en vois l'intérêt pour d'autres et pour l'amélioration de GIMP en général. Si on devait refuser tous les patchs dès que le contributeur n'est pas capable de mieux, alors GIMP aurait genre moitié moins de fonctionnalités. La plupart du temps, on repasse derrière les patchs pour les peaufiner (et ce, même si la fonctionnalité ne nous intéresse pas personnellement!). Et d'autres repassent aussi derrière moi. Et ainsi de suite.
C'est aussi ça qui fait la qualité d'un logiciel libre: on n'est pas tout seul avec notre code et nos propres limitations.
Perso je n'aime pas tous les choix faits dans GIMP et j'en ai discuté plus d'un. Mais si je contribue, c'est parce que ce qu'on fait tous ensemble, j'aurais été incapable de le faire seul (de même pour les autres contributeurs). Et ça j'en suis très conscient. On a un logiciel extrêmement cool et puissant parce qu'on a travaillé ensemble, on a tous compromis ensemble.
Donc j'espère que tu ne refuses pas des fonctionnalités juste parce qu'elles ne t'intéressent pas. Ce serait tout de même un peu triste.
Bien sûr si la fonctionnalité a pour effet de rendre d'autres fonctionnalités moins bonnes, c'est une autre histoire. Mais ce n'est pas le cas de la plupart des fonctionnalités.
Perso notre build de GIMP local utilisé pour ZeMarmot a quelques petites différences, mais très mineures. Ce sont quelques détails qui ont été refusés dans GIMP (pour de bonnes raisons, même si je suis pas d'accord). J'en ai pas fait une maladie et je vais sûrement par forker GIMP (de manière publique j'entends) pour cette raison. Mais on garde ces différences au strict minimum.
Notre but n'est pas d'avoir notre propre GIMP mais d'améliorer le GIMP de base. Ne serait-ce que pour la qualité. C'est bien simple: presque tout ce que j'ai codé est d'autant mieux car d'autres gens sont passés derrière et ont aussi amélioré.
D'ailleurs l'un de mes buts dans GIMP est d'améliorer considérablement l'API et ses possibilités justement pour ne plus avoir de GIMP patché en local du tout. Je veux pouvoir transformer nos quelques différences de code en dur en plug-ins à la place.
Le truc, c'est aussi que maintenir un fork, c'est aussi un travail de dingue. Il faut le faire si vraiment tu n'as aucun choix (ou que tes différences sont vraiment minimes). Alors c'est vrai que c'est bien que ce soit possible, mais ce n'est absolument pas le plus intéressant dans les licences libres, selon moi. La possibilité d'un fork personnel est seulement une manière de rendre le pire cas "moins pire" (toujours d'après moi). :-)
Bon y a aussi les forks après abandon d'un projet par exemple, ou d'autres types de fork qui sont totalement différents. Je parle du cas du fork sans raison profonde, genre juste "comme ça je fais ce que je veux".
C'est effectivement une réalité, et la majorité des cas. Ensuite, je le rappelle (cf. plus haut): les contributeurs aussi ont une vie et des priorités. On peut leur demander d'aider mais on peut pas leur en vouloir s'ils refusent. J'ai personnellement contribué à des dizaines de projets (voir OpenHub et c'est loin d'être exhaustif!) et GIMP est le premier (hormis ceux que je maintiens ou ai créés) sur lequel je suis resté. Je ne pourrais pas humainement participer activement à tous les projets auxquels j'ai envoyé un patch.
Ça ne m'empêche pas de vouloir une fonctionnalité ailleurs et de la coder de temps en temps, mais oui le mainteneur doit être conscient que ça ne veut pas dire que je signe un contrat avec mon sang pour rester à ses côtés jusqu'à ma mort.
En tant que mainteneur de projet libre, c'est quelque chose à accepter. Ensuite bien sûr tu peux vouloir un projet petit et simple à maîtriser et qui prenne peu de temps en refusant de le rendre communautaire. C'est un choix et chacun est libre de le faire. Ensuite faudra pas espérer que son projet s'envole vers des sommets. On peut pas tout avoir. Bien sûr, pour beaucoup de gens, ce n'est pas ce qu'ils veulent. S'ils font le choix en plein conscience, c'est bien.
Personnellement je pense que ce n'est pas mauvais d'accepter de lâcher un peu prise parfois. D'ailleurs si les gens ne restent pas, c'est parfois aussi car certains mainteneurs peuvent garder trop de mainmise sur leur projet.
Au contraire, les plus gros projets ont des co-mainteneurs (voire ont changé de mainteneur à plusieurs reprises), et même quand parfois le créateur est resté depuis le début, cela ne l'a pas empêché de prendre des sous-mainteneurs (comme le noyau Linux) à tel point que dernièrement on a eu plusieurs exemples de tels mainteneurs qui essaient de rendre le projet encore plus indépendant d'eux (je pense bien sûr à Linus Torvalds et Guido Van Rossum).
La chose qui m'a fait rester sur GIMP? Très rapidement le mainteneur m'a attribué sa confiance. Au bout d'un mois ou 2, après plusieurs patchs, Mitch me dit en gros "tu fais chier avec tous tes patchs, ils sont tous bien, tiens prends toi un accès en écriture à git comme ça je gagne du temps". Franchement ça m'a impressionné. Je me suis dit "Waw juste comme ça, je peux pousser mes commits dans GIMP?". Il m'a donné sa confiance et j'ai d'autant plus fait gaffe à ce que je poussais et pendant longtemps je continuais à demander des revues de code avant de pousser dès que ce n'était pas totalement trivial. Au final je suis le plus gros développeur de GIMP sur la dernière année. Ce fut une très bonne leçon et j'essaie de l'appliquer aussi maintenant: dès que quelqu'un fait du code de qualité évidente et qu'il reste un peu, c'est le moment où faut "l'accrocher" avant qu'il aille voir ailleurs. Je lui propose donc d'avoir son accès en écriture. :-)
Alors soyons clair, ça marche pas tout le temps. Même ainsi, beaucoup de contributeurs disparaissent au bout d'un moment. Mais ça vaut le coup d'essayer.
Dans tous les cas, je ne suis pas seul à maintenir le code. On n'est pas beaucoup, mais je suis pas seul. Et c'est passé par le fait que le mainteneur (et tous les sous-mainteneurs) a su donner sa confiance aux gens et surtout a lâché un peu du lest. Il accepte qu'il ne sait pas tout, que certains sont de très bons développeurs (voire meilleurs que lui), qu'ils ont aussi de bonnes idées, que le logiciel peut servir à plus que ce dont lui se sert, etc.
En fait, le logiciel libre et/ou communautaire, quand c'est bien fait, je pense que ça peut faire de nous des bons philosophes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Conclusion étrange
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Directive sur le droit d’auteur adoptée. Évalué à 10.
Oui. Cet article essaie de se la jouer neutre officiellement, mais sa tournure montre clairement que le journaliste est carrêment pour cette loi, genre "on reprend le contrôle du web". C'est marrant car ils ont vraiment joué sur cet aspect "David contre Goliath" dans le marketing pour cette loi, genre d'un côté les méchantes "tech sociétés" et de l'autre les "pauvres petits artistes". Alors qu'en vrai, y avait effectivement notamment ces grosses sociétés du web, mais de l'autre côté, c'était surtout les grosses sociétés d'ayant-droits.
En fait avec cette loi, ce qui pourrait se passer:
Les grosses sociétés du web? Ben soit éventuellement elles retirent leurs agrégateurs (par ex. Google News) de l'Europe. Ça avait déjà été fait par exemple en Belgique, qui était même allé plus loin, et finalement les journaux se sont rendus compte que ne pas être présent sur Google News, c'est pas terrible pour le business. Soit les grosses sociétés du web se plie aux règles et paient les droits (ce fut la fin de l'affaire belge quand tout le monde a compris que Google News, c'est pas si mal finalement). Pour Google (et autres grosses boîtes du genre), ces droits sont rien du tout au final.
Quant aux filtres d'upload, Google et consort mettront en place les dits filtres (ça prendra juste quelques jours, après tout, c'est pas comme s'ils avaient pas des milliers de développeurs et admins faits pour, hein!).
Pour les très gros médias et grosses sociétés de droits d'auteur spécialisés dans la recherche de droits (avec des équipes spécialisés dont c'est le boulot à temps plein), c'est une aubaine et ils vont se faire des pépettes en or (qu'ils pourront sainement redistribuer aux salariés qui en ont le plus besoin, et puis si on se plaint que c'est pas si juste, on peut toujours virer la personne en lui versant d'autant plus; c'est logique, on vire quelqu'un pour avoir profité du système, autant partir en profitant encore plus, comme ça au moins la critique est doublement méritée!).
Les "artistes" et autres créateurs de leur côté, ben ils touchaient des cacahouètes avant, et ils continueront à… toucher des cacahouètes. On notera les superbes communiqués de presse que nous envoient d'ailleurs les sociétés de droits d'auteur précédemment citées, par exemple ici l'ADAMI (cliquez pour voir en plus gros):
On nous rassure donc avec des "Ce vote est une première étape capitale vers une rémunération juste et proportionnelle à l’exploitation de votre travail sur Internet", bien sûr! On y croit tous!
Par contre, même si on touchera toujours autant de rien, on aura de plus en plus de mal à faire diffuser nos œuvres. Non parce que tu comprends, si tu joues Jean-Sébastien Bach et le met sur un site, on pourra venir t'expliquer que ça appartient à Sony Music Global et donc ton partage se verra interdit (je le disais plus haut: les grosses plateformes n'auront aucun mal à implémenter les filtres… d'ailleurs ce cas de Bach est un cas déjà réel qui s'est produit sur Facebook). Et va y pour te plaindre et essayer de débloquer ton œuvre et ton compte (ah oui parce que les filtres, ben c'est pas des humains!).
Pire! Si jamais tu arrives au final à faire entendre raison à un humain du support de la plateforme et à faire diffuser ton œuvre, après un parcours du combattant, et qu'elle se retrouve même partagée! Youhou! Tu te dis que toi aussi, tu vas pouvoir commencer à te faire des pépettes en droits d'auteur! Que nenni! Tu n'as pas les équipes de SACEM ou Adami, tu auras bien du mal à savoir qui diffuse ton œuvre, et à part si tu fais que ça de ta journée (plutôt que jouer au piano!), ben tu pourras demander aucun sous. Et par défaut, les équipes d'ayant-droit vont toutes attribuer les droits à Sony Music de toutes façons (car ils utiliseront les mêmes logiciels pour détecter les ayant-droits que les filtres anti-upload, bien sûr!).
Tu l'auras compris: dans un cas comme dans l'autre (que tu sois affilié ou non), biiiip, tu perds!
Alors résumons: les gros médias et sociétés de droits? Ils vont se faire plein de brouzoufs! Les grosses boîtes du web? Bah, une petite épine dans le pied, on a perdu une bataille, passons et réfléchissons simplement au prochain moyen de se faire du blé avec vos données perso. Les créateurs? Vous touchez déjà 50€ par an, maintenant ce sera 51€, youhou! Vous êtes riches! Par contre faut pas vous imaginer pouvoir créer en dehors du système en uploadant vous-mêmes, passez par les gros médias SVP (faites nous confiance…)! Les petites plateformes? Bandes de pirates (avec des crochets et des bandeaux sur les yeux), crevez! Laissez les vrais boîtes gérer toutes les œuvres publiées!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Soutenir Gimp
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 10. Dernière modification le 05 septembre 2018 à 17:42.
Ça dépend.
L'argent de GIMP est utilisé uniquement pour les frais communautaires. Par exemple, cela permet aux contributeurs de se rencontrer une fois par an (frais de transports et d'hébergement) à Libre Graphics Meeting, voire à Wilber Week (si on en réorganise) pour une semaine de hacking.
Il est aussi déjà arrivé régulièrement que GIMP aide financièrement d'autres projets libres ou des évènements (en particulier Libre Graphics Meeting qui a parfois eu du mal à joindre les deux bouts si GIMP n'avait pas été là pour sauver les meubles).
Cela peut aussi être utilisé si on a besoin de faire des autocollants ou un kakémono (l'an dernier, un contributeur a participé à une conf aux US et a fait faire un kakemono GIMP ainsi), ou autre chose du genre.
Enfin cela peut être utilisé pour du matos.
Par contre, cela n'est pas utilisé pour des salaires (ce qui est le plus coûteux et au final le plus nécessaire). GIMP n'a pas de structure pour embaucher. Ceci dit, le projet pourrait sûrement donner à LILA, ce qui servirait à payer des salaires dans une structure. Mais certains contributeurs trouvent que donner cet argent de cette façon ne serait pas juste pour certains contributeurs bénévoles qui font aussi beaucoup, etc.
Personnellement je trouve cette logique peu constructive et serait (bien évidemment) heureux si cet argent pouvait nous servir pour rendre viable les tentatives de professionnaliser nos contributions à GIMP. Mais bon, je suis clairement parti pris et je ne veux pas créer une mauvaise ambiance autour de questions financière.
À la place, je dis clairement aux gens: si vous voulez financer du développement dans GIMP, vous pouvez donner à LILA; si vous voulez financer la partie communautaire, nos réunions bénévoles, etc. alors donnez à GIMP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Transformations dans l'outil de mesure
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 7.
Ça s'appelle un manuel. ;-)
D'ailleurs si des gens veulent aider, aux dernières nouvelles, il est pas à jour.
Pour contribuer, ça se passe là: https://gitlab.gnome.org/GNOME/gimp-help
Les captures d'écran montrent de vieilles interfaces, les photos du hardware antédiluvien, le texte est vieux et mériterait une revue, plein de fonctionnalités sont absentes. Etc. etc.
On accepte aussi des tutos (sous licence libre seulement, comme le manuel) récent et de qualité: https://www.gimp.org/tutorials/
Pour contribuer (tutos ou site en général), c'est là: https://gitlab.gnome.org/Infrastructure/gimp-web
Y a plein de manières de contribuer, pas que du code. :-)
De notre côté, oui on voudrait faire plus de posts aussi, mais bon on arrive pas à faire le temps pour ça, alors…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Plug-ins et Windows
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 3.
Je suis pas sûr de comprendre. GIMP a déjà un concept de répertoire utilisateur vs. répertoire système pour les plug-ins, et ce depuis très longtemps.
Ensuite sous Windows, je pense que le répertoire système serait
$PREFIX/lib/gimp/2.0/plug-ins/($PREFIXétant là où GIMP est installé).Mais non ce n'est absolument pas nouveau et ce n'est pas de cela dont je parle ici. Je parle juste d'une nouvelle organisation des plug-ins, où on demande de mettre chacun dans son propre répertoire afin d'éviter la pollution de DLLs apportés par un plug-in tiers.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Soutenir l'un des logiciels les plus important du projet GNU !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 7.
On avait déjà publié nos rapports, mais c'est vrai qu'on l'a pas fait dernièrement. LILA est une micro asso et c'est vraiment dur de tenir tout à jour dans les temps. Mais c'est noté. On va essayer de faire les choses au plus carré (en fait, ça a toujours été notre but de faire le plus carré et transparent; j'ai un peu honte qu'on y arrive même pas!). Tu as entièrement raison de dire que ce type de transparence est important.
Quoiqu'il en soit, les donations vont à ce jour principalement dans la production de ZeMarmot. C'est notre seul gros projet à ce jour (notez qu'on ne serait pas contre d'autres projets en parallèle si des gens cherchent une structure dans l'Art Libre pour développer leur projet; mais à ce jour, y a pas vraiment, même si y a eu un peu). LILA fait des salaires intermittents en bonne et due forme.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Transformations dans l'outil de mesure
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 6.
C'est quand même très récent. Le redressement d'image est sorti dans la 2.10.4, soit début juillet. En 2 mois, je pense qu'il est impossible de connaître tout GIMP.
Je travaille sur le code de GIMP depuis 6 ans, et je découvre sans arrêt des trucs. Aryeom travaille quotidiennement dans GIMP, toute la journée (du matin au soir, en continu… enfin hors pause et éditions vidéos, etc. ;p), et c'est pareil. Toutes les 2 semaines, y a un "quoi on peut faire ça? C'est cool!".
Alors que tu n'aies pas trouvé une fonction par hasard en 2 mois, ça me semble absolument pas étonnant. Et franchement je doute qu'on puisse attribuer ça (ou en déduire) un problème ergonomique quelconque sur l'emplacement de la fonctionnalité. :P
GIMP fait partie de ces outils pour professionnels, vraiment très complets et avec des fonctionnalités tellement nombreuses qu'il faudrait des jours à ne faire que ça pour toutes les essayer et comprendre leur utilisation (et encore même là, ça veut pas dire qu'on verrait immédiatement un usage concret immédiat). Ce n'est pas forcément un mal. On me demande pas de connaître le moindre rouage de mon hardware et tout le code source de mon système d'exploitation pour l'utiliser (cela ne m'empêche pas d'être un développeur décent, je pense). Pourtant je suis sûr que je ferais des choses extraordinaires si je connaissais tout sur tout. ;-)
Quant au fait que l'outil de mesure s'appelle ainsi, perso je le vois un peu comme une sorte de règle, et même si la fonction première est en effet de mesurer, l'utiliser pour remettre droit me paraît au contraire une évolution des plus naturelles (cf. les règles niveau à bulle).
Quant aux repères, comme quelqu'un le note, on peut afficher des grilles, on peut aussi utiliser des guides de canevas, et enfin l'outil de rotation lui-même a une fonctionnalité de guides qui peuvent avoir divers formats (règle de 3, de 5, diagonales, etc.). Voir les options de l'outil de rotation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mes nyeux!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 6.
C'était pas Tokyo mais Paris (et j'ai fait exprès de le laisser en alphabet plutôt que katakana, histoire de montrer l'orientation mixte).
Quoiqu'il en soit, en cherchant sur le web, il semblerait en effet que 'で' est moins utilisé/utilisable, car ce n'est pas une action. Quoique apparemment certains japonais disent (sur des forums) utiliser habituellement 'で' dans une telle phrase, mais il apparaît tout de même que ce n'est en effet pas du japonais littéraire.
Perso la phrase me paraissait grammaticalement correcte, mais bon… c'est pas comme si je parlais bien japonais! :P
Je note tout de même que tu me demandes carrêment de corriger la capture d'écran. Ahahah! Désolé, je vais pas perdre une seconde là-dessus (le but, c'était de montre l'orientation mixte; objectif atteint!). :P
Tu es d'ailleurs la première personne à me faire la moindre remarque sur cette erreur.
Ce n'est peut-être pas le bon terme. Comme souvent, quand je traduis mes dépêches GIMP de l'anglais vers le français, je vérifie s'il y a déjà une traduction (en gros, je regarde le fichier
fr.podes traductions de l'interface en français). Il n'y en avait pas pour "straighten" (et toujours pas d'ailleurs, je viens de regarder). Alors j'ai traduit comme je pouvais. Même maintenant je continue à pas trouver ça si mal d'ailleurs, faute de mieux.Mais je suis ouvert à des propositions (pas que ça serve à grand chose; je suis pas dans l'équipe des traducteurs et n'ai donc pas mon mot à dire de toutes façons).
Comme quoi, il semblerait que je parle mal le français ET le japonais! C'est la fin! ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: dll hell
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 10.
Déjà un peu d'explication du problème pour bien comprendre. Windows cherche les DLLs dans cet ordre:
Pour le binaire principal
gimp-2-10, c'est facile car il suffit de mettre toutes nos DLLs dans le même répertoire$PREFIX/bin/. Elles seront toujours trouvées en premier.Le problème est pour les plug-ins qui sont dans
$PREFIX/lib/gimp/2.0/plug-ins/et lorsque ces plug-ins souhaitent utiliser certaines des bibliothèques livrées avec GIMP (qui sont donc dans$PREFIX/bin/).On pourrait simplement mettre les librairies à côté de chaque plug-in, mais cela signifierait dupliquer les bibliothèques un certain nombre de fois. Et en plus ça ne permettrait plus aux plug-ins tiers de profiter des biblios livrées. Donc ce n'est pas acceptable.
À la base, on rajoutait donc
$PREFIX/binau début duPATH(qui est spécifié dans un script de lancement). Mais si jamais une application installe une DLL (que nous utilisons, mais dans une version incompatible) dans un répertoire système, alors cette DLL est trouvée avant et les ennuis commencent.Une autre solution à laquelle je pensais est de jouer avec le répertoire courant (le faire pointer sur
$PREFIX/bin) mais il se trouve que siSafeDllSearchModeest activé (apparemment une valeur de la base de registre), le répertoire courant est soudainement cherché après les répertoires système aussi! Donc ça marcherait plus (enfin surtout ça dépendrait de la configuration de l'OS).La solution est donc d'utiliser
SetDllDirectoryW()pour donner la priorité à$PREFIX/bin, et pour être précis le mettre entre le répertoire du binaire (permettant aux plug-ins de bypasser nos biblios au besoin) et les répertoires système. C'est donc une solution au niveau du code.Un cas supplémentaire que nous avons corrigé dans 2.10.6 fut les plug-ins 32-bit lancé dans un environnement 64-bit. Dans ce cas, on doit leur donner un répertoire différent avec des versions 32-bit de nos bibliothèques (on le met dans
$PREFIX/32/binpar défaut, mais j'ai mis un flag pour changer ce répertoire à la compilation). Je détecte donc le bitness d'un plug-in avant de le lancer et lui assigne le bon répertoire de bibliothèques avecSetDllDirectoryW().Un nouveau cas dont j'ai récemment pris connaissance (et pas encore corrigé) est les plug-ins scripts lancés par un interpréteur 32-bit sur environnement 64-bit (si le script utilise des bibliothèques compilées). Dans ce cas, on devra détecter le bitness de l'interpréteur.
Par exemple notre installeur embarque seulement Python en 32-bit (je ne suis pas sûr pourquoi). Donc des scripts python un peu complexe qui utilise des biblios C risquent de ne pas fonctionner.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Soutenir Gimp
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 10. Dernière modification le 30 août 2018 à 12:44.
Ce projet tiers est ce qui permet de contribuer à GIMP et a fait de moi l'un des plus gros développeurs de GIMP ces dernières années (même le plus gros selon le décompte).
C'est simple, sans ZeMarmot, pas de GIMP. Je contribuerai alors sûrement à d'autres logiciels libres, selon mes autres besoins, mais je n'ai pas besoin de GIMP personnellement plus que ça (enfin régulièrement, je découpe, redresse, rend plus net, etc. des photos; mais pour cette utilisation basique, GIMP est déjà largement au niveau). Là on en a vraiment besoin, dans un projet professionnel, au quotidien 8h par jour.
(0) On a besoin qu'il soit stable. Quand on faisait les premiers tests avec Aryeom Han, GIMP crashait pour un rien (c'était vers 2012). Ça foutait la honte. Mes premières années de contribution, j'ai corrigé beaucoup de crashs (de mémoire, y en avait en utilisant une tablette graphique; y en avait aussi des supers mauvais lorsqu'on utilisait un IME, en particulier avec le coréen, dans l'outil texte, et plein d'autres dont je me souviens même plus) et autres problèmes de stabilité. Bon j'en corrige encore régulièrement, mais GIMP est devenu beaucoup plus stable.
(1) Toujours dans la recherche de stabilité, on a besoin de pouvoir aisément débugger et parer aux problèmes (qui arrivent sur tous logiciels même les plus stables). Donc j'ai implémenté une sauvegarde des images au moment du crash (pour ces bugs survivants qu'on n'a pas encore corrigés!), et GIMP propose maintenant au lancement suivant de tenter une récupération des images qui étaient en cours d'édition, ainsi qu'un système de débug qui génère automatiquement des backtraces, non seulement pour les crashs, mais aussi utilisables lors de WARNING et CRITICAL en cours d'utilisation (permet d'améliorer le logiciel en découvrant des bugs plus subtils). C'est l'une de mes fonctionnalités fétiches. Le nombre de bug qu'on a pu corriger depuis que j'ai implémenté cette fonctionnalité est impressionnant. Corriger des bugs est devenu simple, et les gens nous envoient désormais des rapports de bugs utiles, même lorsqu'ils ont aucune idée de ce qu'il s'est passé, qu'ils savent pas du tout parler anglais ni écrire des rapports de bug bien formés.
(2) On rajoute des fonctionnalités. Dernièrement je travaille beaucoup sur tous les détails pour les écrans haute densité de pixel (l'écran principal de travail d'Aryeom ne l'est pas pourtant, mais je sais qu'on y viendra; autant préparer GIMP en amont). Le système d'extension indiqué plus haut bien sûr me semble important. Nous aussi on utilise quelques plug-ins, mais très peu. Franchement c'est impossible de savoir ce qui existe et ce en quoi on peut faire confiance. Et surtout chercher, installer et faire marcher des vieux plug-ins peut être une vraie galère (et pourtant je suis développeur, c'est dire!).
Dans les quelques années passées, j'ai été responsable de plusieurs autres fonctionnalités, et je travaille à d'autres fonctionnalités encore (comme l'animation, comme on sait ici).
(3) On fait de la revue de code. Ça paraît bien moins sexy, mais c'est primordial. L'histoire de GIMP est parsemée de fonctionnalités sympas qui ont été perdues car personne n'a eu le temps de les vérifier. Je ne jette la pierre à personne: ça prend un temps fou. Dans cette sortie par exemple, l'écriture verticale n'aurait probablement jamais été intégré sans moi (je suis allé chercher le contributeur, j'ai fait la revue, les tests, les commentaires sur chacune de ses modifications; en tout j'y ai passé quelques heures).
Même le Marathi, j'ai vu un email perdu sur la liste de discussion des traducteurs auquel personne ne répondait; le problème est que cette langue n'avait plus de coordinateurs. J'ai donc essayé de relancer à la place des traducteurs (qui allait sûrement abandonner à un moment donné) et de leur donner espoir pour ne pas les décevoir (un espoir qui a abouti!).
Le redressement horizontal, j'ai retrouvé un vieux patch perdu dans le bugtracker et très basique. J'ai fait de la revue, retravaillé au dessus (car il n'était pas vraiment utilisable en l'état); Ell a fait de même ensuite. Et maintenant ça fait une super fonctionnalité.
Dans le passé, je me souviens bien de la recherche d'action (une de mes fonctionnalités préférées!). J'y ai passé un temps considérable. Le patch était cool, mais écrit par des étudiants. J'y ai passé de très nombreuses heures à corriger ce qui devait l'être, à rendre la fonctionnalité vraiment utilisable simplement, et à l'améliorer énormément. Maintenant je pourrais pas faire sans!
Pour info, dans GIMP, on a des règles stricts et du code de très bonne qualité globalement (bien sûr plus localement, on trouve beaucoup d'horreurs ici et là, comme dans tout gros code). Donc la revue est primordiale. On fait pas comme certains logiciels qui acceptent tout et n'importe quoi.
(4) On fait évoluer la politique interne. Je suis celui notamment qui a poussé depuis plusieurs années (tous les ans, à chaque fois qu'on se rencontrait au Libre Graphics Meeting) pour une nouvelle politique de sortie permettant de sortir des versions macros avec de nouvelles fonctionnalités (plutôt qu'attendre 6 ans encore pour une sortie majeure!). Et voilà, maintenant tous les mois, GIMP sort avec des fonctionnalités cool. Les gens se disent maintenant que GIMP est super actif, et on se met à avoir plus de contributions (j'ai l'impression; mais ça peut aussi être simplement car on a sorti 2.10, ou autres raisons).
(5) On a créé et on maintient le flatpak pour que les linuxiens aient GIMP facilement et rapidement à chaque sortie (GIMP est maintenant dispo sous Linux à chaque sortie avant toutes les autres plateformes!).
Et sûrement plein d'autres choses.
Ensuite soyons clair: je ne souhaite pas mettre tous les éclairages sur ZeMarmot uniquement. En particulier le mainteneur, Mitch, fait un travail de dingue, connaît le code de GIMP et ses rouages bien mieux que moi. Sans parler de Ell, un alien venu d'ailleurs, qui nous optimise GIMP aux petits oignons (avec du code d'excellente qualité) depuis qu'il est arrivé. Je ne suis pas seul (heureusement!), et on a tous les 3 une grosse part dans le succès de GIMP.
Mais clairement je ne pense pas que ce soit exagéré d'affirmer que le projet ZeMarmot a vraiment contribué largement à propulser GIMP dans une nouvelle ère. On travaille sur GIMP pour un vrai projet, au quotidien (oui je me répète) et ça vaut énormément de contributions aléatoires sans but. C'est un peu une symbiose de l'artiste et des outils. Chacun a besoin de l'autre.
Si avec cela, ce n'est pas suffisant, alors je ne sais pas ce qui l'est. Je rappelle qu'on est officiellement associé à GIMP d'ailleurs (bien sûr même! Je suis un dév majeur). Même le site web gimp.org suggère de donner directement à ZeMarmot sur la page donation, ainsi que dans ses news régulières (comme la dernière news dont cette dépêche sur Linuxfr est plus ou moins une traduction un peu retravaillée). J'aurais du mal à voir comment ça pourrait être plus limpide. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Soutenir Gimp
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 5.
On sait pas trop non plus. J'ai aussi vu passer des trucs vite fait, mais rien qui dit clairement "c'est bon, tout va bien". Ils font pas beaucoup de communications, c'est dommage.
J'aime beaucoup Liberapay, mais tant qu'on n'a pas de message clair comme quoi ils sont à nouveau dans la course, on peut pas vraiment donner le lien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 5. Dernière modification le 23 août 2018 à 18:39.
Tu parles du fait que c'est de la gestion d'extension dans GIMP? Si oui, bien sûr que là on parle de gestion (c'est même le titre), mais il s'agit du fait d'installer, désinstaller, mettre à jour et afficher des infos sur des extensions. C'est la partie côté cliente.
Ça veut pas dire qu'on gère l'extension au sens de vraiment s'en occuper. Si elle est bourrée de bugs, si elle marche pas même, c'est pas notre problème au delà de fournir des outils (pas immédiatement, mais probablement rapidement) pour que les gens puissent indiquer une extension qui fonctionne ou pas sur telle ou telle version de GIMP. Et si l'extension n'est pas maintenue, on ne s'en occupera pas plus.
Je dirais que c'est notre problème si on découvre des malware et là oui, on intervient et on vire l'extension. À ce moment, quand il y a intention malfaisante évidente (ou grosse faille de sécurité très dangereuse), il est évidemment de notre responsabilité de réagir. Mais ça s'arrête là. C'est en ce sens là qu'on ne gère pas les extensions (côté serveur) au delà de proposer aux gens de les héberger.
Les données inertes (brosses, images splash, thèmes, icônes, dégradés, etc.) ne subiront en effet pas de revue préalable, contrairement aux données exécutées (plug-ins) qui doivent être évidemment validées avant d'être diffusées.
Ensuite bien sûr que des vecteurs d'attaques peuvent exister avec des données inertes. Cela a toujours existé et existera toujours. On a tous entendu parler de failles permettant d'exécuter du code caché dans des images par exemple.
Néanmoins cela n'est pas un comportement normal, et ainsi dire "On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox" est faux, en tous cas pour le type de fichiers que tu cites (brosses) ou que je cite (images) [bien sûr, il existe des fichiers avec du code fait pour être exécutés, comme les fameuses macros de traitement de texte; de tels fichiers doivent donc être considérés comme du code]. Donc non, charger une bosse ou une image n'est pas la même chose qu'exécuter un programme. Ce sont des données inertes faites pour une utilisation donnée, pas pour exécuter du code tiers. Quand cela arrive, c'est un comportement anormal, autrement dit un bug (le plus souvent dans le logiciel, parfois dans le format lui-même) et qui doit alors être corrigé.
Aussi cela n'a rien à voir avec les extensions. Ce type de bug, quand il existe, existerait déjà dans GIMP et pourrait déjà se produire. Les extensions ne sont qu'un conteneur supplémentaire (ajoutant un peu de sémantique au contenu, indiquant de quoi il s'agit, un nom, une description, des liens annexes, une version, etc.).
Les haters ont toujours existé et existeront toujours. Je le sais bien, je parle moi-même régulièrement sur Linuxfr de cela. Soyons clair, ça me touche et c'est dur. Mais je ne vois pas en quoi faire ou non des extensions pourrait changer quoi que ce soit à cela.
En fait par rapport aux comportements inadéquats, ma politique perso est de rester neutre (si possible, parfois c'est dur de tenir) et d'expliquer aux gens justement ce que je disais: GIMP est un logiciel libre, le logiciel libre, ça ne marche pas comme ils semblent le penser. En plus on n'est pas une entreprise, et on développe de façon volontaire. Et non, on ne réagit pas bien aux menaces et insultes. Par contre on est heureux d'aider les gens agréables, et tout ce qu'on demande, c'est que ces gens comprennent aussi ce qu'il en est, et qu'on contribue principalement bénévolement, souvent sur du temps libre.
Eh ben, tu me croiras peut-être pas, mais être clair (et poli) désamorce pas mal de situations. Les gens se rendent compte qu'ils ont un peu été des malotrus, se calment, parfois même (ça arrive!) s'excusent.
Ensuite oui, ça n'est pas du 100%. Et certains sont juste là pour haïr, comme je disais. On ne peut rien pour cela. Mais encore une fois, je vois pas le rapport avec les extensions. Ces personnes trouveront de quoi redire pour chaque nouvelle fonctionnalité qu'on apportera. On va quand même pas s'arrêter d'améliorer nos logiciels pour ces gens là! En tous cas, perso, c'est pas pour eux que je développe. :-)
Je crois que tu cherches des problèmes là où y en a pas. :-)
Pourquoi qui que ce soit jetterait l'éponge pour quelques aigris? Si ça devait arriver, crois moi, ça serait arrivé y a trèèèès longtemps (comme tout gros logiciel connu, on collectionne quelques aigris).
Au pire du pire, si vraiment ça se passait super mal, on pourra toujours arrêter notre système d'extensions tiers (et n'héberger que nos propres extensions, voire un choix très restreint d'extensions sélectionnées au cas par cas, comme quelqu'un le propose plus haut). Perso je trouverais cela un peu dommage, mais si on devait en arriver là, c'est pas la mort.
Soyons clair, je ne pense pas qu'on en arrivera là. Je vois aucune raison à cela.
Ah oui, et:
Encore une fois, du vocabulaire de startup hipster. On s'en fout du "bad buzz". Je dirais même qu'on vit dans un monde où cela n'existe pas. Il y a des gens sympas, des gens moins sympas, ça s'arrête là. Si ce prétendu grand méchant bad buzz devait avoir eu raison de nous, ça serait arrivé y a très longtemps.
Merci beaucoup de t'inquiéter pour nous.
Je pense perso que tu te fais du mouron pour rien. :P
Si le type de problème dont tu parles devait arriver, je pense pas que ce soit parce qu'on ait ajouté un système de gestion d'extension dans GIMP. Ahahahah!
Sur ce, j'arrête de répondre sur cette news. J'ai un peu l'impression de trop l'accaparer en hors-sujet là, alors que c'est censé parler de ce super logiciel qu'est G'Mic. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 10.
Salut,
Nos installeurs contiennent la version 32 et 64-bit et installent la version appropriée. C'est écrit juste sous le bouton de téléchargement. Donc prends simplement l'installeur unique et ça te mettra la bonne version.
Ça oui par contre. C'est pas qu'on veut pas prendre en charge de plus vieux Windows, mais on n'a quasi aucun dév Windows (approximativement 0) alors on fait ce qu'on peut. Prendre en charge de vieilles versions veut dire plus de boulot car on doit contourner des problèmes de manières plus compliquées (même si des versions récentes ont peut-être amené des solutions simples).
Notre ligne directrice pour savoir si on prend en charge un OS (Windows ou macOS), c'est que cette version de l'OS doit au moins être encore pris en charge par son éditeur. Windows XP, y a plus de support depuis avril 2014 (d'après Wikipédia) et on parle quand même d'un système sorti en 2001, soit y a 17 ans!
Il est peut-être temps de mettre à jour. Et si le matériel est juste trop ancien, on peut mettre un Linux avec bureau léger. Ou si vraiment on est nostalgique des vieilles années et qu'on veut garder l'OS d'époque absolument (faire attention à l'accès internet, etc. dans ce cas), ben on prend sur soi et on garde aussi les vieux logiciels (y compris GIMP 2.8). :-)
Enfin bon, tout cela pour dire qu'il n'y a pas vraiment de solutions miracle, désolé. On peut pas prendre en charge indéfiniment un système, surtout si même son éditeur ne veut plus le prendre en charge. Ce serait vraiment se tirer une balle dans le pied.
Tout est possible. Ensuite je crois que la plupart des gens qui compilent GIMP pour Windows le font depuis un Linux (même notre build officiel est cross-compilé, il me semble). Donc ce sera clairement cela le plus simple.
Et je suis pas certain que ce build fonctionnera de toutes façons. Ne pas prendre en charge Windows XP, ça veut surtout dire qu'on a peut-être (probablement) utilisé des APIs Windows qui n'existaient pas encore dans XP. Donc tu te retrouveras à devoir patcher le code en fonction des parties qui poseront problème. Si tu le fais sans perte de fonctionnalité ni rendre le code surcompliqué (et avec un code propre), on veut bien le patch (on n'est pas absolument contre Windows XP, on ne le prend pas officiellement en charge, c'est tout).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 6.
On ne les gèrera pas. On les hébergera. Mais oui tu as raison quand même qu'on aura notre part de responsabilité.
Même si GIMP lançait des sandbox, la revue et compilation doivent être faites de notre côté. Héberger aveuglément un binaire d'inconnus complets est une aberration.
C'est la raison pour laquelle les plug-ins compilés ne seront pas acceptés tant qu'on n'aura pas l'infra. Certains bénéficieront d'exception évidente comme G'Mic. C'est expliqué dans mon article.
Je ne prévois pas de gérer le site. Je suis développeur pas animateur de communautés. Nous avons une très grosse communauté avec des gens très actifs et même pas mal plutôt techniques. Des gens comme Pat David et Elle Stone seront parfaitement capables de gérer le quotidien (et de sélectionner les futur modérateurs si le contenu grossit vite).
Aussi on pourra y aller lentement. Si les gens sont pas contents du temps de revue, ce n'est pas notre problème. L'un des énormes avantages que l'on a est qu'on n'essaie pas de faire du business. Nos actions ne sont pas dirigées par des contraintes économiques. Ça rend GIMP très résistant aux problèmes car personne ne peut nous forcer à rien ni nous presser.
Bon j'arrête là. Cette dépêche est au sujet de G'Mic pas de GIMP! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 10.
Non ce n'est pas envisageable. De même que notre installeur Windows ne contient pas G'Mic (pas plus que tout autre plug-in tiers), ni notre DMG pour macOS.
Les builds officiels de GIMP ne contiennent (et ne contiendront toujours) que les plug-ins core de GIMP, c'est à dire ceux maintenus par les développeurs de GIMP. On a déjà bien suffisamment de boulot (avec très peu de développeurs) pour ne pas non plus se donner plus de travail. En outre si quelqu'un fournit un paquet, il est de-facto responsable de son contenu (or on ne développe/maintient pas G'Mic). Pour G'Mic, c'est un logiciel suffisamment complexe et élaborée pour qu'on se rende bien compte que si David venait à arrêter demain (on touche du bois pour que ça ne soit pas le cas!), on ne serait pas à même de le maintenir à sa juste valeur.
Donc non, on ne peut pas.
De même que David, je pense qu'il préfère garder l'indépendance dans ses sorties, etc. et ne pas dépendre de nos choix de sortie.
La tendance est plus à la création d'un système d'extension (voir ma news pour GIMP 2.10.6 qui devrait être publiée d'ici quelques jours) qui permettra d'installer facilement G'Mic et autres plug-ins, tout en laissant les développeurs de ces plug-ins en garder la main complète. Tout le monde y gagne. Et je sais, de source sûre, que David aime l'idée. ;-)
D'ailleurs une fois que cela sera en place, il est même possible que certains des plug-ins core actuels puissent devenir des extensions à leur tour (toujours maintenus par nous, mais avec un rythme de développement parallèle), ce qui permettrait des menus moins touffus de fonctions que peu de monde utilisent par exemple. À voir…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 5.
Oui c'est malheureusement un des trucs (le flatpak de GIMP et les plug-ins) sur lesquels il faudrait bosser plus. :-/
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Aperçu
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 10.
Perso je pense que la prévisu sur canevas serait super utile, même pour les traitements lents.
La prévisualisation n'a pas à être activée par défaut. ;-)
GIMP donne aussi la priorité au rendu de la partie visible à l'écran, et le mipmapping aide aussi beaucoup si un zoom (avant ou arrière) est fait. Et je sens que les choses vont s'améliorer encore dans le futur pour optimiser la sensation de fluidité (ou du moins de pas avoir une expérience trop désagréable), même avec des traitements lents.
Ce sera clairement utile pour l'édition non-destructive également. Faire un changement dans les paramètres d'un effet peut te prendre 10 minutes, mais dans tous les cas, tu devras le refaire (ton effet). Dans le cas de l'édition non destructive, au moins tu pourras voir les paramètres utilisés précédemment et repartir de là. Dans le cas de l'édition destructive, tu as intérêt à avoir bien gardé une copie du calque d'origine et tu ne sais même pas l'ensemble des traitements faits, et avec quels paramètres, à part si tu les as notés bien consciencieusement (ce que certains font dans le nom du calque par exemple).
Pour moi, il n'y a rien d'équivoque là. Mais je crois qu'on a déjà eu cette discussion et qu'on pourra encore l'avoir à l'avenir. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Positive attitude
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 4. Dernière modification le 15 août 2018 à 18:42.
Je ne contribue que depuis (relativement) récemment, c'est à dire depuis 2012. Mais il paraît que certains des anciens contributeurs de l'époque d'avant n'étaient pas très cool, voire peut-être même un peu toxique. Mais ce n'est que du "on dit" car je ne les ai pas connus.
En tous cas, de nos jours, ce n'est plus le cas. :-)
On a un peu mis en pause pour diverses raisons. Déjà y a le côté technique. Le logiciel de streaming (libre) faisait quand même beaucoup souffler la machine (qui a déjà beaucoup à faire quand on fait de l'animation), voire était plutôt instable (cela nécessite OpenGL 3.2, ce qui veut dire qu'on doit installer les pilotes Nvidia proprio, et même là, ce n'est pas parfait). Le pire n'est pas seulement que ça plantait parfois, mais qu'il arrivait à faire freezer la session graphique de temps en temps. OBS Studio est cependant très connu et une référence a priori chez les gens qui font du live, même s'ils savent pas que c'est libre. Y a peut-être quelque chose à configurer mieux. Et aussi j'ai cru comprendre que la version Linux est moins stable de manière générale. À voir…
Ensuite oui, y avait pas tant de monde, et on se disait que ça valait pas forcément le coup.
Mais surtout, Aryeom a eu une petite période de blues ces derniers mois (je l'ai déjà dit, l'un comme l'autre, on se pose beaucoup de questions; on nous dit constamment que GIMP peut lever beaucoup de financement participatif, mais dans les faits, notre financement est faible), voire un petit burnout. Donc elle a préféré continuer à travailler sans les lives. Mais là je lui ai montré ton message, et elle se dit qu'il faut peut-être les recommencer. On verra!
P.S.: ne pas hésiter à laisser un message si on reprend les lives. Ça fait toujours plaisir et ça donne moins l'impression de faire un direct dans le vide. Faut pas donner tous les mercis qu'à moi. Y aurait rien de tout cela sans Aryeom non plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]