Je n'en doute pas. Néanmoins il est rare d'apprendre le dessin directement sur support numérique (en tout cas en cursus scolaire)
Bien sûr. C'est pas ce que je voulais dire. :-)
Je pense pas qu'il soit très bien d'apprendre le dessin sur informatique directement (de même qu'en tant que dév, je suis content d'avoir fait des maths, de la physique, de l'algorithmique, etc.). La technique du dessin devrait s'apprendre sur support physique, ne serait-ce que parce que toute la base du dessin n'a pas besoin d'informatique (ce serait dommage de pas savoir dessiner sur papier!). La partie informatique, c'est juste l'apprentissage d'un outil différent, pas l'apprentissage du dessin même.
et il est toujours intéressant d'avoir un pont avec les outils traditionnels.
Oui sauf que c'est pas du tout pareil, c'est ça que je dis. On peut vouloir absolument faire un pont, parce que ça ressemble à un stylo, ça n'en fait pas un stylo classique pour autant. D'ailleurs avec ce même "stylo", on va plutôt simuler des crayons, un pinceau, un stylo-encre, pastel, fusain, ou que sais-je encore! La différence sera que sur l'ordi, on va attribuer des fonctions aux entrées (pas seulement les entrées physiques du stylo d'ailleurs; la direction du trait est aussi une entrée; Aryeom aime beaucoup l'entrée aléatoire aussi, etc.), on va jouer avec des courbes pour décider des comportements relativement aux données retournées par les entrées, etc.
Alors bien sûr, un dessinateur va en général attribuer des comportements proches de la réalité (tout en étant pas du tout réalistes pour autant, soyons clair). Par exemple, typiquement Aryeom va souvent associer la taille du pinceau au tilt (genre quand on penche un crayon, on peut dessiner gros), et/ou encore de la rotation de brosse au tilt, etc. Ce sont des trucs classiques. Mais voici par exemple un test récent qu'elle faisait pour dessiner un feuillage de conifère: https://www.instagram.com/p/BqXqXdEDWa5/
Elle a pour cela fait une brosse perso, mais aussi une dynamique appropriée. Elle peut ainsi changer des choses comme la taille des feuillages, mais aussi la couleur (pour ne pas avoir un vert uniforme) en fonction de l'entrée. Ce sont typiquement des choses qui ne marchent que sur ordi. Il n'y a pas de pont avec les outils trads dans ce cas.
Au passage, les dessinateurs numériques disent en général que c'est très différent et quand certains ne dessinent plus physiquement pendant trop longtemps, ils racontent que ça devient dur de se remettre à dessiner sur support physique. C'est un classique qu'on lit régulièrement sur des blogs de webcomics et autre notamment (et le conseil est donc de ne jamais arrêter le dessin physique pour ne pas perdre la main, même si le boulot au quotidien implique du dessin sur ordi).
Enfin bon, au tout début quand on connaît pas, c'est ok de vouloir rapprocher ça au traditionnel, mais rapidement faut savoir s'en détacher.
la rotation ou encore d'autres fonctions comme sur les stylets aérographes
Tiens t'en as de ces stylos? Perso on a jamais rencontré personne qui en ait acheté, et d'ailleurs je pense que Wacom les discontinue (ou alors ils ont juste pas encore sorti les équivalents pour les nouvelles tablettes; maintenant ils sortent le modèle "3D", qui a juste un bouton en plus! Wouhou c'est top moderne! Payer 100€ pour un troisième bouton, on n'arrête pas le progrès!).
Ceci dit, autant pour l'art pen (celui avec la rotation), ça a l'air sympa, autant l'aérographe, je me suis toujours posé la question. Au final justement ils essaient de faire les "ponts" avec les outils traditionnels mais de manière un peu bizarre (genre l'effet "aérographe", on n'a pas besoin d'un stylet qui ressemble à un aérographe pour le faire!).
Malheureusement c'est un peu la maladie de tous les appareils avec des ports soudés sur le circuit imprimé
En même temps, une fois qu'on a finalement mis à jour la tablette, on a démonté pour voir si on peut pas souder. Le port USB était vraiment attaché super fin et forcément à chaque fois qu'on tirait pour débrancher, ça tirait sur la soudure. Y a quand même des limites à ce qui est acceptable en terme de qualité de fabrication. Maintenant on a un peu peur sur toutes les tablettes Wacom que les ports nous lâchent.
Je t'avoues que je ne me suis jamais intéressé à la gamme Cintiq. Pour avoir passé énormément de temps le dos courbé sur ma planche à dessin que ce soit à plat ou sur un chevalet, le fait de pouvoir détacher la tablette du retour visuel est pour moi un gros avantage ergonomique du numérique.
Tout à fait! C'est pour cela qu'Aryeom travaillait avec Intuos jusqu'à ce jour. On pense que les petites Cintiq ne sont pas bonnes pour le corps, et surtout le dos/cou. On peut pas bosser 8h par jour en penchant le cou. En détachant la tablette du retour, comme tu dis (d'ailleurs encore une différence avec le dessin papier!), ça permet de garder le dos droit.
Maintenant qu'on a un peu de financement pour avoir des grandes Cintiq, c'est différent (enfin on espère). On peut dessiner directement sur le retour avec celui-ci bien en face, sans courber l'échine constamment. Donc on a décidé d'essayer pour une fois.
C'est clairement ça, déjà les pointes feutres c'est du bullshit qui n'apporte rien de bien concret comparé aux pointes nylon standard à part de la friction et une usure supplémentaire.
Les feutres, c'est celles toutes molles en supplément? Si oui, elle les utilisent pas. Elle n'utilise que celles classiques. Mais même celles-ci s'usent bien trop vite avec les nouveaux modèles.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est sûr que quand tu veux faire du dessin ou de la peinture numérique, un matériel qui prend en charge le tilt (l'inclinaison in french) et la rotation du stylet en plus de la pression est vraiment bien plus proche de la subtilité de gestuelle des outils traditionnels.
C'est juste une entrée en plus. Vouloir se rapprocher du dessin traditionnel n'est pas forcément une bonne idée (disons que ça rend aigri, car dans les faits, à ce jour, ce n'est pas possible!). :-)
La technique du dessin numérique a ses propres trucs et astuces, et faut vraiment voir le tilt comme juste une entrée en plus que chacun peut associer de la manière qu'on veut. Ça vaut vraiment le coup d'entendre Aryeom parler de ces sujets d'ailleurs car on découvre vraiment ce qu'est le dessin numérique. Elle a vraiment appris à maîtriser son outil pour ce qu'il est, pas comme une sorte de skeuomorphisme du dessin classique.
Wacom dégringole depuis quelques années, leur ancien matériel était bien plus solide
Y a la solidité en effet. Un grand classique qui nous est arrivé par exemple est l'entrée USB dont une soudure a lâché (et qu'ils font payer une fortune en après-vente pour réparer, si hors garantie). On a écrit un article sur le sujet, expliquant comment contourner le problème avec un chargeur de batterie de téléphone universel (le problème étant qu'il y a un kit sans fil, mais il a aussi besoin du câble pour charger la batterie; or cette batterie se trouve être de même voltage que les batteries classiques de téléphone!). Ben cet article est le hit numéro 1 sur notre site depuis qu'on l'a écrit (enfin la version anglaise surtout).
Mais si ce n'était que ça. Ils vendent des écrans tablettes depuis des années, or quasi tous leurs modèles ont des fuites de lumière aux 4 coins. Cela est acceptable quand on achète un écran à 50€, mais moins pour des écrans de 3000€.
Leurs écrans sont aussi connus pour avoir une colorimétrie mauvaise, même après calibration (encore une fois, pour des écrans de graphiste, pas terrible…) donc les professionnels ont souvent un second écran juste pour vérifier les couleurs (le Wacom étant pour dessiner seulement, pas pour la justesse des couleurs).
Aussi franchement la finesse des écrans est pas terrible. On voit énormément de grains (même sur les plus chers!).
La texture de la gamme Intuos est aussi de plus en plus rugueuse au fil des ans (les Cintiq sont un peu plus épargnés, probablement car ils ont pas bien réussi à rendre des écrans rugueux! ;p). Le discours marketing est que ça permet de se rapprocher de la sensation papier. Mais on pense qu'il y a aussi beaucoup une volonté d'user rapidement les mines des stylos (qui coûtent cher pour ce que c'est! Y a des vidéos sur le web de gens qui essaient de les remplacer par divers matériels; y avait même une vidéo qui a beaucoup tourné qui proposait d'utiliser des spaghettis! Évidemment les nouveaux modèles changent légèrement le format pour bloquer les bidouilleurs). Pour la Intuos Pro, on a d'ailleurs dû acheté un revêtement "doux" (et franchement on voit à peine la différence; ça reste vachement plus rugueux que la Intuos 5). Parler d'obsolescence programmé est pas loin.
De manière générale, les notes sur les sites de vente sont rarement excellentes.
Là où ils font leur business, c'est déjà qu'ils sont connus, et on est à peu près sûr que la boîte va pas disparaître demain. Aussi ils ont des fonctionnalités en plus, comme le tilt (pendant des années, ils étaient les seuls à avoir cette fonctionnalité). Ceci dit, certains artistes n'utilisent pas (notamment car les petits modèles n'ont pas, même chez Wacom où c'est dispo à partir des Intuos Pro, donc y a des questions d'habitude; ceux qui se mettent à utiliser prennent des habitudes). Ils font beaucoup de bruit sur le fait qu'ils sont les seuls à avoir des stylos sans batterie (car ils ont un brevet dessus, il me semble), donc moins lourd que la concurrence. Ceci dit, ceux qui testent la concurrence disent qu'un stylo un peu plus lourd, c'est pas non plus si mal.
il vaut mieux acheter un ancien modèle d'Intuos qui certes aura moins de niveaux de pression
Alors à partir d'un certain point, les niveaux de pression sont très marketing. Déjà selon les personnes, on va pas forcément utiliser les mêmes zones de pression et je vois qu'Aryeom (qui a un toucher assez doux) travaille plutôt dans les niveaux bas. Enfin c'est bien d'avoir plus de niveau que moins, bien sûr. Mais à un moment, c'est pas comme si on arrive à différencier les dits niveaux de pression quand ils sont tellement proches. :P
Franchement ils font de la course aux chiffres plutôt qu'à la qualité. On préférerait 1000 fois qu'ils améliorent la qualité graphique des écrans. Mais non, ils vont augmenter la résolution parce que c'est du nombre. C'est quantifiable: ça permet de dire "maintenant on fait du 4K". Mais en vrai, mieux vaut du QHD avec une bonne colorimétrie, sans fuite de lumière, etc. que du 4K moche. En gros, ils améliorent ce qui est quantifiable aisément pour en faire le marketing (résolution, niveaux de pression…), en priorité de la qualité plus dur à quantifier.
Wacom a des devs pour leur pilote libre libwacom.
En fait c'est le point qui fait que Wacom garde notre préférence. Ils ont des dévs payés (surtout deux, me semble-t-il) par la boîte (de nos jours, ces derniers contribuent directement au noyau, donc toute tablette est prise en charge nativement par tout Linux dans les quelques mois qui suivent la sortie). Et ça c'est vraiment cool. Peu de boîtes font ça pour un produit utilisateur final.
Bon ensuite ce n'est pas parfait car on est dans une sorte de zone grise: officiellement Wacom ne prend pas en charge Linux (sur n'importe quel site marketing, vous ne verrez jamais une mention de Linux) et en même temps, ils paient des développeurs pour cela. Un peu de schizophrénie d'entreprise, quoi! Néanmoins cela reste une bonne assurance que les choses vont pas casser pendant 3 mois (on lit quelques parcours du combattants pas enviable pour certaines autres tablettes sous Linux; même si parfois ça marche aussi très bien). Et quand on bosse professionnellement, c'est mieux. On veut pas trop de surprises. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Y a un lien "originally written" sur la fin qui a l'air d'être un reste de la VO (je pense pas que c'était visible dans l'interface d'édition, si?).
Et surtout y a un horrible mix-up des noms. Je pense que quelqu'un en modération a cru que Ell et Elle Stone sont la même personne (ce n'est pas le cas, d'où l'orthographe différente! :P), et a cru bien faire en "corrigeant" (on se retrouve alors avec un "Ell Stone", uh?!), et pire en inversant (on se retrouve carrêment avec 2 fonctionnalités attribuées à la mauvaise personne! Y a eu un switch!). Vous pouvez rétablir les noms comme l'édition soumise SVP?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Elle travaille quotidiennement avec une Wacom Intuos Pro et a une MobileStudio Pro pour déplacement (en ce moment au service après vente pour la seconde fois en un an!). On a récemment acheté une Cintiq pro (on espère qu'elle arrive demain). Par le passé, elle avait une Intuos 5, et une vieille bamboo. De manière générale, il n'y aura pas de problème à utiliser GIMP avec les tablettes Wacom (quel que soit l'OS, et sous GNU/Linux en particulier), ce pourquoi on ne change pas, malgré des prix trop élevés, un service pas vraiment à la hauteur, du matos en rade un peu trop souvent, pas mal de probs de qualité, etc. Le problème du monopole, quoi. :-/
Parallèlement y a beaucoup de nouvelles marques bien moins chères, dont on entend pas mal de bien, mais parfois avec quelques problèmes de drivers (surtout sous Linux) ou autres épreuves à surmonter. Et peu ont la prise en charge du tilt, ce qui est aussi embêtant pour nous car Aryeom utilise ça beaucoup.
Si on avait des sous ou du temps, on aimerait bien tester ces autres marques. Sur le long terme, je pense qu'on y gagnerait. Sur le court terme, on a déjà trop à faire (pour ça que ça nécessite des sous ou du temps, car même si le produit est moins cher, le temps à tester, régler les problèmes etc. C'est un risque, quoi).
P.S.: pour être sûr de bien me faire comprendre (non parce qu'en relisant, on dirait presque que je dis que ça marche qu'avec Wacom, ce qui n'est pas le cas): GIMP marche en général avec toutes les tablettes! C'est juste que lorsqu'on a des rapports avec des problèmes, c'est en général pour d'autres marques. Et souvent c'est plus des histoires de pilotes que de GIMP même. Et y a le tilt qui manque aussi chez beaucoup de concurrents et assez bloquant pour nous. Les problèmes de tablette sont rares de nos jours. C'est aussi beaucoup nous qui ne souhaitons pas nous prendre trop la tête, juste au cas où, donc on reste avec ce qu'on connaît (ce qui est pas forcément très bien!).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Hmmm… ok. J'essaie de trouver qui d'entre nous a accès au serveur gimp.org. Et le problème est que les 2 seuls qui ont (je pense) accès au serveur sont très peu actifs depuis quelques mois.
Bon comme je vais pas attendre indéfiniment (ce genre de trucs, ça peut prendre des semaines avant d'avoir une réaction), je l'ai mise sur framapic en attendant (par contre dans un an, le lien sera mort, mais j'ai essayé d'autres services, et ils acceptaient pas encore webp!).
Sinon, même si y a clairement un problème de config côté gimp.org (que l'on devra régler), je me demande si le système de cache de linuxfr ne peut pas être plus flexible en essayant tout de même de vérifier localement si c'est une image. Ça serait bien. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est un logiciel libre de graphisme. Perso la section "graphisme" me paraît aussi tout à fait appropriée. Ce n'est pas moins le "bon endroit" si vraiment c'est ça qui choque.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je suis d'accord avec les diverses réponses qui te disent de ne pas abandonner juste pour quelques commentaires. Ta dépêche comme d'autres sur Haiku sont très bien et intéressantes. Je dis qu'elles ont leur place sur linuxfr. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Hmm… j'ai relu mon commentaire et je vois que j'ai vraiment laissé passer plein de fautes (dont plusieurs vraiment embarrassant s/ses/ces/)! Je l'ai écrit d'une traite sans me relire, mais je pensais pas que ce serait si terrible. C'est ça de vieillir. :-/
Par contre je ne suis pas tout à fait d'accord sur la partie Persévérance. C'est une belle vertu, qu'il faut mieux économiser pour là où ça en vaut vraiment la peine. Le point c'est qu'à un moment donné il y a plein de projets où je peux potentiellement contribuer et je trouve important de choisir, de me concentrer sur là où je peux avoir un impact.
Ben justement tu choisis tes projets en fonction de ton besoin, pas de la situation qui fait qu'un projet sera peut-être plus complexe/long à gérer. Ou alors je sais pas trop comment tu gères tes priorités, mais c'est étrange pour moi.
D'après moi le point de persévérance est extrêmement important et il est tout aussi primordial que les deux autres points. En fait il est primordial pour toute activité humaine si tu veux pas avoir déconvenue sur déconvenue. Le truc, c'est que rien n'est facile. C'est comme ça, on n'y peut rien. Si quelqu'un vous raconte que tout est trop simple pour lui et tout lui tombe tout cuit dans la bouche, c'est simple: il ment. Donc là où ça en vaut la peine? Ben perso, je considère que tout ce que je fais en vaut la peine (sinon je le ferais pas), et donc je persévère.
Et surtout — je le disais — tout est lié. Si tu persévères, par exemple dans tes patchs, c'est aussi parce que tu es compréhensif et bienveillant. En effet si ton patch est oublié dans un coin, c'est pas parce que le mainteneur est méchant. C'est que comme toi, il a aussi une vie, et il est humain. Ainsi peut-être a-t-il oublié qu'il voulait regarder ton code plus en détail plus tard? Peut-être qu'il fait ça dans son temps libre avec peu de temps. Il vient peut-être d'avoir un nouveau né. Sa famille lui reproche peut-être de pas donner assez de temps. Tout simplement il reçoit 5 patchs par jour et il est seul à gérer le projet. Ou que sais-je encore?!
Donc quand tu persévères et rappelle (pas trop mais une fois de temps en temps) que tu veux toujours voir ton patch inclus, tu es en fait d'une grande aide. Tu montres que tu t'y intéresses et ainsi aide le mainteneur à gérer ses priorités en choisissant quels patchs regarder en premier dans le peu de temps qu'il peut/veut y consacrer.
Persévérer, c'est donc accepter le fait qu'autrui est aussi humain. C'est donc aussi comprendre l'autre et être bienveillant. Je le disais, tout est lié. Si un contributeur n'est pas prêt à comprendre cela, alors désolé mais son patch n'aura pas la priorité si on manque de temps. Il aura alors créé sa propre déconvenue.
Tes exemples sont en fait peu représentatif du problème que tu cites, car ce sont des cas qui se sont passés sans accroc (4 commentaires dans le lien que tu donnes!) avec un petit code de juste quelques dizaines de lignes. La question, c'est: comment gèreras-tu un cas où ça se passe différemment? Si tu abandonnes parce que t'as pas de réponse immédiate, faut pas t'attendre à grand chose. Et pire si tu choisis tes projets en regardant d'abord si les mainteneurs ont plein de temps libres et répondent super vite, il te reste plus tant de projets intéressants auxquels contribuer (les projets les plus intéressants ont beaucoup de patchs, et par conséquent le temps de réponse/réaction des mainteneurs est beaucoup plus long en moyenne; ce sont mes stats persos au doigt mouillé ;P).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
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 ]
[^] # Re: C'est super mais quelle est le modèle de la tablette d'Aryeom ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.8 : Wilber Kid. Évalué à 6. Dernière modification le 26 novembre 2018 à 11:42.
Bien sûr. C'est pas ce que je voulais dire. :-)
Je pense pas qu'il soit très bien d'apprendre le dessin sur informatique directement (de même qu'en tant que dév, je suis content d'avoir fait des maths, de la physique, de l'algorithmique, etc.). La technique du dessin devrait s'apprendre sur support physique, ne serait-ce que parce que toute la base du dessin n'a pas besoin d'informatique (ce serait dommage de pas savoir dessiner sur papier!). La partie informatique, c'est juste l'apprentissage d'un outil différent, pas l'apprentissage du dessin même.
Oui sauf que c'est pas du tout pareil, c'est ça que je dis. On peut vouloir absolument faire un pont, parce que ça ressemble à un stylo, ça n'en fait pas un stylo classique pour autant. D'ailleurs avec ce même "stylo", on va plutôt simuler des crayons, un pinceau, un stylo-encre, pastel, fusain, ou que sais-je encore! La différence sera que sur l'ordi, on va attribuer des fonctions aux entrées (pas seulement les entrées physiques du stylo d'ailleurs; la direction du trait est aussi une entrée; Aryeom aime beaucoup l'entrée aléatoire aussi, etc.), on va jouer avec des courbes pour décider des comportements relativement aux données retournées par les entrées, etc.
Alors bien sûr, un dessinateur va en général attribuer des comportements proches de la réalité (tout en étant pas du tout réalistes pour autant, soyons clair). Par exemple, typiquement Aryeom va souvent associer la taille du pinceau au tilt (genre quand on penche un crayon, on peut dessiner gros), et/ou encore de la rotation de brosse au tilt, etc. Ce sont des trucs classiques. Mais voici par exemple un test récent qu'elle faisait pour dessiner un feuillage de conifère: https://www.instagram.com/p/BqXqXdEDWa5/
Elle a pour cela fait une brosse perso, mais aussi une dynamique appropriée. Elle peut ainsi changer des choses comme la taille des feuillages, mais aussi la couleur (pour ne pas avoir un vert uniforme) en fonction de l'entrée. Ce sont typiquement des choses qui ne marchent que sur ordi. Il n'y a pas de pont avec les outils trads dans ce cas.
Au passage, les dessinateurs numériques disent en général que c'est très différent et quand certains ne dessinent plus physiquement pendant trop longtemps, ils racontent que ça devient dur de se remettre à dessiner sur support physique. C'est un classique qu'on lit régulièrement sur des blogs de webcomics et autre notamment (et le conseil est donc de ne jamais arrêter le dessin physique pour ne pas perdre la main, même si le boulot au quotidien implique du dessin sur ordi).
Enfin bon, au tout début quand on connaît pas, c'est ok de vouloir rapprocher ça au traditionnel, mais rapidement faut savoir s'en détacher.
Tiens t'en as de ces stylos? Perso on a jamais rencontré personne qui en ait acheté, et d'ailleurs je pense que Wacom les discontinue (ou alors ils ont juste pas encore sorti les équivalents pour les nouvelles tablettes; maintenant ils sortent le modèle "3D", qui a juste un bouton en plus! Wouhou c'est top moderne! Payer 100€ pour un troisième bouton, on n'arrête pas le progrès!).
Ceci dit, autant pour l'art pen (celui avec la rotation), ça a l'air sympa, autant l'aérographe, je me suis toujours posé la question. Au final justement ils essaient de faire les "ponts" avec les outils traditionnels mais de manière un peu bizarre (genre l'effet "aérographe", on n'a pas besoin d'un stylet qui ressemble à un aérographe pour le faire!).
En même temps, une fois qu'on a finalement mis à jour la tablette, on a démonté pour voir si on peut pas souder. Le port USB était vraiment attaché super fin et forcément à chaque fois qu'on tirait pour débrancher, ça tirait sur la soudure. Y a quand même des limites à ce qui est acceptable en terme de qualité de fabrication. Maintenant on a un peu peur sur toutes les tablettes Wacom que les ports nous lâchent.
Tout à fait! C'est pour cela qu'Aryeom travaillait avec Intuos jusqu'à ce jour. On pense que les petites Cintiq ne sont pas bonnes pour le corps, et surtout le dos/cou. On peut pas bosser 8h par jour en penchant le cou. En détachant la tablette du retour, comme tu dis (d'ailleurs encore une différence avec le dessin papier!), ça permet de garder le dos droit.
Maintenant qu'on a un peu de financement pour avoir des grandes Cintiq, c'est différent (enfin on espère). On peut dessiner directement sur le retour avec celui-ci bien en face, sans courber l'échine constamment. Donc on a décidé d'essayer pour une fois.
Les feutres, c'est celles toutes molles en supplément? Si oui, elle les utilisent pas. Elle n'utilise que celles classiques. Mais même celles-ci s'usent bien trop vite avec les nouveaux modèles.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: C'est super mais quelle est le modèle de la tablette d'Aryeom ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.8 : Wilber Kid. Évalué à 10.
C'est juste une entrée en plus. Vouloir se rapprocher du dessin traditionnel n'est pas forcément une bonne idée (disons que ça rend aigri, car dans les faits, à ce jour, ce n'est pas possible!). :-)
La technique du dessin numérique a ses propres trucs et astuces, et faut vraiment voir le tilt comme juste une entrée en plus que chacun peut associer de la manière qu'on veut. Ça vaut vraiment le coup d'entendre Aryeom parler de ces sujets d'ailleurs car on découvre vraiment ce qu'est le dessin numérique. Elle a vraiment appris à maîtriser son outil pour ce qu'il est, pas comme une sorte de skeuomorphisme du dessin classique.
Y a la solidité en effet. Un grand classique qui nous est arrivé par exemple est l'entrée USB dont une soudure a lâché (et qu'ils font payer une fortune en après-vente pour réparer, si hors garantie). On a écrit un article sur le sujet, expliquant comment contourner le problème avec un chargeur de batterie de téléphone universel (le problème étant qu'il y a un kit sans fil, mais il a aussi besoin du câble pour charger la batterie; or cette batterie se trouve être de même voltage que les batteries classiques de téléphone!). Ben cet article est le hit numéro 1 sur notre site depuis qu'on l'a écrit (enfin la version anglaise surtout).
Mais si ce n'était que ça. Ils vendent des écrans tablettes depuis des années, or quasi tous leurs modèles ont des fuites de lumière aux 4 coins. Cela est acceptable quand on achète un écran à 50€, mais moins pour des écrans de 3000€.
Leurs écrans sont aussi connus pour avoir une colorimétrie mauvaise, même après calibration (encore une fois, pour des écrans de graphiste, pas terrible…) donc les professionnels ont souvent un second écran juste pour vérifier les couleurs (le Wacom étant pour dessiner seulement, pas pour la justesse des couleurs).
Aussi franchement la finesse des écrans est pas terrible. On voit énormément de grains (même sur les plus chers!).
La texture de la gamme Intuos est aussi de plus en plus rugueuse au fil des ans (les Cintiq sont un peu plus épargnés, probablement car ils ont pas bien réussi à rendre des écrans rugueux! ;p). Le discours marketing est que ça permet de se rapprocher de la sensation papier. Mais on pense qu'il y a aussi beaucoup une volonté d'user rapidement les mines des stylos (qui coûtent cher pour ce que c'est! Y a des vidéos sur le web de gens qui essaient de les remplacer par divers matériels; y avait même une vidéo qui a beaucoup tourné qui proposait d'utiliser des spaghettis! Évidemment les nouveaux modèles changent légèrement le format pour bloquer les bidouilleurs). Pour la Intuos Pro, on a d'ailleurs dû acheté un revêtement "doux" (et franchement on voit à peine la différence; ça reste vachement plus rugueux que la Intuos 5). Parler d'obsolescence programmé est pas loin.
De manière générale, les notes sur les sites de vente sont rarement excellentes.
Là où ils font leur business, c'est déjà qu'ils sont connus, et on est à peu près sûr que la boîte va pas disparaître demain. Aussi ils ont des fonctionnalités en plus, comme le tilt (pendant des années, ils étaient les seuls à avoir cette fonctionnalité). Ceci dit, certains artistes n'utilisent pas (notamment car les petits modèles n'ont pas, même chez Wacom où c'est dispo à partir des Intuos Pro, donc y a des questions d'habitude; ceux qui se mettent à utiliser prennent des habitudes). Ils font beaucoup de bruit sur le fait qu'ils sont les seuls à avoir des stylos sans batterie (car ils ont un brevet dessus, il me semble), donc moins lourd que la concurrence. Ceci dit, ceux qui testent la concurrence disent qu'un stylo un peu plus lourd, c'est pas non plus si mal.
Alors à partir d'un certain point, les niveaux de pression sont très marketing. Déjà selon les personnes, on va pas forcément utiliser les mêmes zones de pression et je vois qu'Aryeom (qui a un toucher assez doux) travaille plutôt dans les niveaux bas. Enfin c'est bien d'avoir plus de niveau que moins, bien sûr. Mais à un moment, c'est pas comme si on arrive à différencier les dits niveaux de pression quand ils sont tellement proches. :P
Franchement ils font de la course aux chiffres plutôt qu'à la qualité. On préférerait 1000 fois qu'ils améliorent la qualité graphique des écrans. Mais non, ils vont augmenter la résolution parce que c'est du nombre. C'est quantifiable: ça permet de dire "maintenant on fait du 4K". Mais en vrai, mieux vaut du QHD avec une bonne colorimétrie, sans fuite de lumière, etc. que du 4K moche. En gros, ils améliorent ce qui est quantifiable aisément pour en faire le marketing (résolution, niveaux de pression…), en priorité de la qualité plus dur à quantifier.
En fait c'est le point qui fait que Wacom garde notre préférence. Ils ont des dévs payés (surtout deux, me semble-t-il) par la boîte (de nos jours, ces derniers contribuent directement au noyau, donc toute tablette est prise en charge nativement par tout Linux dans les quelques mois qui suivent la sortie). Et ça c'est vraiment cool. Peu de boîtes font ça pour un produit utilisateur final.
Bon ensuite ce n'est pas parfait car on est dans une sorte de zone grise: officiellement Wacom ne prend pas en charge Linux (sur n'importe quel site marketing, vous ne verrez jamais une mention de Linux) et en même temps, ils paient des développeurs pour cela. Un peu de schizophrénie d'entreprise, quoi! Néanmoins cela reste une bonne assurance que les choses vont pas casser pendant 3 mois (on lit quelques parcours du combattants pas enviable pour certaines autres tablettes sous Linux; même si parfois ça marche aussi très bien). Et quand on bosse professionnellement, c'est mieux. On veut pas trop de surprises. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Corrections
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.8 : Wilber Kid. Évalué à 3.
Cf. news originelle:
Ça c'est Ell.
Ça c'est Elle Stone.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Corrections
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.8 : Wilber Kid. Évalué à 5.
Y a un lien "originally written" sur la fin qui a l'air d'être un reste de la VO (je pense pas que c'était visible dans l'interface d'édition, si?).
Et surtout y a un horrible mix-up des noms. Je pense que quelqu'un en modération a cru que Ell et Elle Stone sont la même personne (ce n'est pas le cas, d'où l'orthographe différente! :P), et a cru bien faire en "corrigeant" (on se retrouve alors avec un "Ell Stone", uh?!), et pire en inversant (on se retrouve carrêment avec 2 fonctionnalités attribuées à la mauvaise personne! Y a eu un switch!). Vous pouvez rétablir les noms comme l'édition soumise SVP?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: ze Marmot
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Black Friday ! Fais péter ta CB. Évalué à 6.
Ah bah ça c'est cool! Merci!
Pour quiconque veut suivre ce bon conseil, on rappelle aussi le lien: https://film.zemarmot.net/fr/donate
La super promo de ZeMarmot, c'est qu'on fait du Logiciel Libre et de l'Art Libre pour le monde entier! Wouhou! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: C'est super mais quelle est le modèle de la tablette d'Aryeom ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.8 : Wilber Kid. Évalué à 10. Dernière modification le 25 novembre 2018 à 17:50.
Elle travaille quotidiennement avec une Wacom Intuos Pro et a une MobileStudio Pro pour déplacement (en ce moment au service après vente pour la seconde fois en un an!). On a récemment acheté une Cintiq pro (on espère qu'elle arrive demain). Par le passé, elle avait une Intuos 5, et une vieille bamboo. De manière générale, il n'y aura pas de problème à utiliser GIMP avec les tablettes Wacom (quel que soit l'OS, et sous GNU/Linux en particulier), ce pourquoi on ne change pas, malgré des prix trop élevés, un service pas vraiment à la hauteur, du matos en rade un peu trop souvent, pas mal de probs de qualité, etc. Le problème du monopole, quoi. :-/
Parallèlement y a beaucoup de nouvelles marques bien moins chères, dont on entend pas mal de bien, mais parfois avec quelques problèmes de drivers (surtout sous Linux) ou autres épreuves à surmonter. Et peu ont la prise en charge du tilt, ce qui est aussi embêtant pour nous car Aryeom utilise ça beaucoup.
Si on avait des sous ou du temps, on aimerait bien tester ces autres marques. Sur le long terme, je pense qu'on y gagnerait. Sur le court terme, on a déjà trop à faire (pour ça que ça nécessite des sous ou du temps, car même si le produit est moins cher, le temps à tester, régler les problèmes etc. C'est un risque, quoi).
P.S.: pour être sûr de bien me faire comprendre (non parce qu'en relisant, on dirait presque que je dis que ça marche qu'avec Wacom, ce qui n'est pas le cas): GIMP marche en général avec toutes les tablettes! C'est juste que lorsqu'on a des rapports avec des problèmes, c'est en général pour d'autres marques. Et souvent c'est plus des histoires de pilotes que de GIMP même. Et y a le tilt qui manque aussi chez beaucoup de concurrents et assez bloquant pour nous. Les problèmes de tablette sont rares de nos jours. C'est aussi beaucoup nous qui ne souhaitons pas nous prendre trop la tête, juste au cas où, donc on reste avec ce qu'on connaît (ce qui est pas forcément très bien!).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Une histoire de content-type
Posté par Jehan (site web personnel, Mastodon) . En réponse à l’entrée du suivi Linuxfr n'a pas réussi à mettre en cache une image webp. Évalué à 2 (+0/-0). Dernière modification le 25 novembre 2018 à 00:00.
Hmmm… ok. J'essaie de trouver qui d'entre nous a accès au serveur gimp.org. Et le problème est que les 2 seuls qui ont (je pense) accès au serveur sont très peu actifs depuis quelques mois.
Bon comme je vais pas attendre indéfiniment (ce genre de trucs, ça peut prendre des semaines avant d'avoir une réaction), je l'ai mise sur framapic en attendant (par contre dans un an, le lien sera mort, mais j'ai essayé d'autres services, et ils acceptaient pas encore webp!).
Sinon, même si y a clairement un problème de config côté gimp.org (que l'on devra régler), je me demande si le système de cache de linuxfr ne peut pas être plus flexible en essayant tout de même de vérifier localement si c'est une image. Ça serait bien. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Quid de la portabilité ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Publication du code de Wonderbrush. Évalué à 7.
C'est un logiciel libre de graphisme. Perso la section "graphisme" me paraît aussi tout à fait appropriée. Ce n'est pas moins le "bon endroit" si vraiment c'est ça qui choque.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Quid de la portabilité ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Publication du code de Wonderbrush. Évalué à 10.
Je suis d'accord avec les diverses réponses qui te disent de ne pas abandonner juste pour quelques commentaires. Ta dépêche comme d'autres sur Haiku sont très bien et intéressantes. Je dis qu'elles ont leur place sur linuxfr. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: 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é à 4. Dernière modification le 08 novembre 2018 à 22:11.
Hmm… j'ai relu mon commentaire et je vois que j'ai vraiment laissé passer plein de fautes (dont plusieurs vraiment embarrassant s/ses/ces/)! Je l'ai écrit d'une traite sans me relire, mais je pensais pas que ce serait si terrible. C'est ça de vieillir. :-/
Ben justement tu choisis tes projets en fonction de ton besoin, pas de la situation qui fait qu'un projet sera peut-être plus complexe/long à gérer. Ou alors je sais pas trop comment tu gères tes priorités, mais c'est étrange pour moi.
D'après moi le point de persévérance est extrêmement important et il est tout aussi primordial que les deux autres points. En fait il est primordial pour toute activité humaine si tu veux pas avoir déconvenue sur déconvenue. Le truc, c'est que rien n'est facile. C'est comme ça, on n'y peut rien. Si quelqu'un vous raconte que tout est trop simple pour lui et tout lui tombe tout cuit dans la bouche, c'est simple: il ment. Donc là où ça en vaut la peine? Ben perso, je considère que tout ce que je fais en vaut la peine (sinon je le ferais pas), et donc je persévère.
Et surtout — je le disais — tout est lié. Si tu persévères, par exemple dans tes patchs, c'est aussi parce que tu es compréhensif et bienveillant. En effet si ton patch est oublié dans un coin, c'est pas parce que le mainteneur est méchant. C'est que comme toi, il a aussi une vie, et il est humain. Ainsi peut-être a-t-il oublié qu'il voulait regarder ton code plus en détail plus tard? Peut-être qu'il fait ça dans son temps libre avec peu de temps. Il vient peut-être d'avoir un nouveau né. Sa famille lui reproche peut-être de pas donner assez de temps. Tout simplement il reçoit 5 patchs par jour et il est seul à gérer le projet. Ou que sais-je encore?!
Donc quand tu persévères et rappelle (pas trop mais une fois de temps en temps) que tu veux toujours voir ton patch inclus, tu es en fait d'une grande aide. Tu montres que tu t'y intéresses et ainsi aide le mainteneur à gérer ses priorités en choisissant quels patchs regarder en premier dans le peu de temps qu'il peut/veut y consacrer.
Persévérer, c'est donc accepter le fait qu'autrui est aussi humain. C'est donc aussi comprendre l'autre et être bienveillant. Je le disais, tout est lié. Si un contributeur n'est pas prêt à comprendre cela, alors désolé mais son patch n'aura pas la priorité si on manque de temps. Il aura alors créé sa propre déconvenue.
Tes exemples sont en fait peu représentatif du problème que tu cites, car ce sont des cas qui se sont passés sans accroc (4 commentaires dans le lien que tu donnes!) avec un petit code de juste quelques dizaines de lignes. La question, c'est: comment gèreras-tu un cas où ça se passe différemment? Si tu abandonnes parce que t'as pas de réponse immédiate, faut pas t'attendre à grand chose. Et pire si tu choisis tes projets en regardant d'abord si les mainteneurs ont plein de temps libres et répondent super vite, il te reste plus tant de projets intéressants auxquels contribuer (les projets les plus intéressants ont beaucoup de patchs, et par conséquent le temps de réponse/réaction des mainteneurs est beaucoup plus long en moyenne; ce sont mes stats persos au doigt mouillé ;P).
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 ]