Jehan a écrit 1652 commentaires

PS : il y a des entreprises du libre qui payent des boites de comm' pour ce genre de petit film.

Ben si tu en croises, ne pas hésiter à leur demander de nous contacter (on ne souhaite pas faire de com' en activité principale, mais clairement pour vivre, on serait content de travailler sur des projets tiers de temps en temps). On est juste très nul pour notre propre marketing.

Donc si tu connais des entreprises qui veulent monter un projet de communication, ne pas hésiter à les envoyer vers nous: https://libreart.info/en/contact

👍

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

Plus pragmatiquement, il me parait assez "osé" d'exclure les bonnes pratiques des autres logiciels.

On ne les exclut absolument pas. On les prend en compte. Mais comme tu le dis pour toi-même, leurs paroles ne sont pas paroles d'évangile non plus (et ce quel que soit le logiciel, même des très connus, car ce sont aussi des gens comme toi et moi; d'ailleurs si on devait jouer à ce jeu là, il est très vraisemblable que GIMP ait bien plus d'utilisateurs qu'énormément de gros du marché; la seule différence étant qu'on ne le vend pas). De même que mes paroles non plus. 🙂
En gros, on n'exclut rien, ça ne nous empêche pas pour autant de garder un esprit critique. 😉

Quoiqu'il en soit, merci encore pour les retours et les échanges. C'était intéressant.

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

Tout à fait. C'est du quasi 100% Aryeom. Du design des personnages, aux idées détaillées, dessin, coloriage, animation, réalisation, etc.

En données de départ, Framasoft avait juste donné le texte brut. Et en références, ils ont dit qu'ils aimaient bien la vidéo de Mastodon et le concept des "petits mondes" dedans, à partir de quoi Aryeom a extrapolé sa propre vision de petits mondes. Ce furent les bases de réflexion pour cette animation.

En plus, au départ on espérait plus de collaboration pour l'écriture, mais au final on a un peu fait ça en mode carte blanche car les divers correspondants de Framasoft ont tous eu des évènements personnels pile à ce moment, donc y a eu un quasi silence radio de 10 jours.

P.S.: ah et en données de fin, c'est Framasoft qui a enregistré la voix et qui a choisi la musique (on a ensuite juste normalisé tout cela et fait un édit simple pour combiner audio et vidéo; était-ce nous qui avons fait l'ajout de son ou Framasoft directement? Je suis même plus sûr).

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

(N’empêche que si c'est plus lisible, je ne vois pas pourquoi s'en passer).

La remarque, c'était surtout histoire d'avoir une comparaison juste. Un screenshot, c'est toujours avec la taille de police du preneur d'image, éventuellement même souvent downscalé davantage histoire de prendre moins de place sur une news, etc.
Au final, quelque soit l'UI choisie, les polices auront la même taille donc faut juste pas faire porter la comparaison sur ce point. 🙂

Oui. Dans ce cas, je n'ai juste pas l'impression sauf si l'utilisateur est parti boire une dizaine de café entre le moment ou il a choisi le calque sur lequel appliqué l'ombre portée et le moment où il commence à tripoter les réglages.

Je sais pas sur quelle complexité d'image tu travailles, mais nous on est souvent dans la centaine de calques. Et tous les autres pros que je connais/rencontre (beaucoup à force des années) disent travailler assez rapidement avec des dizaines de calques. Il est toujours bon que les fenêtres d'effet rappellent sur quel calque on est en train de travailler. Ce que tu as maintenant fait, c'est bien.

Oui. Rien n’empêche de "l'émuler" ou même de gérer le cas stylet en utilisant le principe "shuttle wheel". Une roue / joystick virtuel qui gère non pas une position mais une vitesse.
En quelques mots, le principe est que quand on se décale peu du widget, les valeurs augmentent (ou diminuent) de 0.1 toutes les secondes, si on s'éloigne encore, de 0.2 etc etc.
Pas évident à décrire mais utilisé dans les logiciels vidéo pour avancer/reculer avec plus ou moins de précisions/vitesse simplement.

Oui j'ai déjà vu ce type de widget basé à la position, je suis pas fan personnellement (ensuite on peut s'habituer à tout, alors pourquoi pas). Mais puisque tu as testé le mode de modification lente du widget de curseur maintenant (en tous cas, c'est ce que tu sembles dire plus bas), tu peux constater que c'est un concept entièrement similaire. C'est toujours basé sur du mouvement par contre, pas juste la position comme tu le décris mais hormis cela, c'est le même but et tout aussi utile. Ça permet des changements très précis, exactement comme tu le dis. Et c'est bien pour ce genre de choses (pas seulement ça, mais entre autre) que notre widget est particulier et que nous n'allons sûrement pas revenir à des widgets standards! 😛

Honnêtement j'ai parfois l'impression quand même que si un autre logiciel fait pareil (ou un concept similaire, car ce que tu décris est totalement équivalent au final), d'un seul coup c'est bien. 🙄 Je pense que c'est pour cela que beaucoup ici ne semblent pas apprécier tes retours (moi je les apprécie quand même et fait juste fi de cette sensation; compétence gagnée d'années de lecture de rapports de bug et de support technique!) car je ne suis pas sûr moi-même à quel point tu regardes GIMP objectivement. Pas une seule fois tu as dit qu'on fait un truc bien; là notamment on fait exactement le genre de trucs que tu décris et tu dis que c'est très pratique pour changer une valeur avec précision (ce qu'on explique depuis le début), et pourtant tu continues à vouloir retourner à des curseurs basiques et moins précis.
J'essaie quand même de prendre en compte tes idées objectivement mais ça gâche un peu le retour.

Néanmoins cela reste différent de la roulette de souris, c'est pas une émulation. La roue a elle-même d'ailleurs ses propres modes de changements lents ou rapides.

De plus, quitte à aller plus loin sur le support du stylet, il faudrait envisager les systèmes radiaux (menu, widgets…)

Ça c'est une autre question. On a des projets sur le feu dans ce sens, mais c'est encore autre chose. 🙂
À part si tu veux dire que si on clique sur un curseur linéaire avec un stylet, il pourrait devenir un curseur radial le temps du changement. C'est une idée intéressante.

Pour un widget de texte dans une interface de saisie, j'aurai tendance à suivre le comportement usuel de sélectionner le texte lors du focus afin de pouvoir taper directement sans avoir à effacer (ou double cliquer).

Quand je retestais hier, je me suis posé la question si ça pouvait pas être utile, en effet. Pas besoin de changer tout le widget de curseur et revenir à des vieux curseurs basiques pour faire un tel changement.

NDLR : pourquoi présupposer que je n'utilise pas GIMP ? Si c’était le cas, j'aurai pas pris le temps de lire la dépêche, participer aux discussions et encore moins réfléchir, créer un mockup pour aller de l'avant.

Tu noteras que ce n'est pas ce que j'ai dit. Je t'ai dit de tester ce filtre Drop Shadow et ce curseur opacité en particulier par rapport à ta remarque sur le non-besoin de précision pour un curseur "opacité (slider original de 0 à 2)" qui m'a un peu étonné. J'ai moi aussi retesté cet effet en écrivant ces commentaires.
Ensuite je dois bien avouer m'être quand même posé la question sur ta fréquence d'usage de GIMP par rapport notamment à cette remarque en effet, ainsi qu'à tes méconnaissances du fonctionnement du curseur de GIMP, mais je me suis retenu de faire la remarque justement (bénéfice du doute). 😛

400 pas pour l'opacité, me semble overkill, je n'ai pas demandé non plus à fixer la largeur max du slider, on a le droit de redimensionner aussi la fenêtre.

Bien sûr. Et on peut aussi la redimensionner avec notre curseur, ce n'est pas le problème. Mais pourquoi donc vouloir rendre le curseur moins précis par défaut en disant qu'on peut redimensionner de toutes façons pour plus de précision, plutôt que le rendre précis dès le départ et en plus on peut aussi le redimensionner pour encore plus de précision?

Ensuite je sais pas pourquoi tu t'obstines sur ce nombre de "400 pas". C'est pas 400 ni 100, ou 1000. C'est un nombre flottant continu encore une fois, qui peut donc prendre n'importe quelle valeur permise par le format binaire sous-jacent. Et donc oui, tu veux avoir le max de précision possible avec le curseur (même si tu peux aussi changer avec un nombre explicite au clavier, le changement curseur permet un changement intuitif plus simple avec prévisualisation).

D'ailleurs je viens de retester le Drop Shadow à l'instant, histoire de vérifier l'utilité de la précision (tu vois, moi aussi je teste et re-teste les effets, et je t'invite aussi d'ailleurs à retester, ce qui n'insinue en rien sur ton utilisation de GIMP; moi je l'utilise tous les jours, et ça m'empêche pas de retester des trucs 100 fois). J'ai fait des changements inférieurs à 0,1 avec le modificateur de lenteur, et je peux affirmer que j'ai vu des différences (subtiles parfois, mais en graphisme, une différence subtile peut faire un monde; et encore j'ai un écran de merde, alors avec un écran de graphiste, ça serait plus…).

Ce dont tu parles est noté dans l'article et tu as vraisemblablement testé la nouvelle version du widget.

J'ai fini par comprendre.

[Mention spéciale à ceux qui me sont tombés dessus en se référant à ce comportement (haut et bas du widget), et qui s'emballe car ca serait une sacrée régression de le perdre.
Pas de bol, c'est déjà viré par la nouvelle version! ]

Attention néanmoins, ça n'est pas viré. Déjà il y a toujours possibilité de retrouver l'ancien design par une option dans les préférences pour ceux qui sont vraiment en manque (ça nous permet aussi de tester un nouveau design et de pouvoir revenir en arrière ou tweaker une nouvelle version après d'éventuels retours).
Ensuite et surtout, ce nouveau widget a toujours toutes les possibilités de l'ancien. Notamment il y a encore la modification lente de valeur. Au lieu d'utiliser le haut/bas, ça utilise le bouton secondaire, c'est à dire le bouton droit, avec alternative modificateur clavier (pour les souris 1-bouton).

Le but était d'allier les remarques qu'on avait notamment sur la hauteur excessive de l'ancien design avec notre curseur avancé.

Le "reset" n'est il pas un "undo" de toutes les modifications?

Si tu veux, mais de là à dire que c'est la même chose, c'est osé. 1000, c'est plein de 1 additionnés ensemble, mais ça reste 2 nombres très différents.

D'ailleurs ici justement un undo pourrait être très intéressant (supposons qu'on fasse un changement et on aime pas, mais on veut revenir 2 ou 3 changements avant; ben on peut pas sauf à avoir soit mémorisé les valeurs ou enregistré un preset). Ça reste très différent donc d'un reset, même si c'est de la même famille.

Je suis d'accord avec toi. Mais tu ne peux pas mettre Aide, Réinitialiser, Valider et Annuler à la même sauce.

Le bouton "Aide" est le seul où je veux bien être d'accord avec toi. Mais encore une fois (on se répète), ça reste une régression de GUI si on passait de texte à icône, et comme la place est vraiment pas ce qui manque dans cette boîte de dialogue, je suis pas sûr à quel point c'est conseillé.

Right Aligned Text : Only use right aligned text in special cases like form labels_

Tu noteras qu'ils ne disent pas qu'il faut utiliser l'alignement à droite dans ces cas, mais que c'est le seul cas acceptable.

Ca y est le "il faut absolument une interface neutre" est enterré?

? Comme tu aurais pu t'en douter, c'était justement un exemple de ce qu'il ne faut surtout plus faire. Un autre temps, d'autres mœurs comme on dit. Bon là c'est un exemple particulier de skin et ça me faisait marrer donc j'ai montré ça, mais même l'interface par défaut de ce logiciel, certes plus soft, restait néanmoins très custom. À l'époque, les logiciels venaient avec leurs propres couleurs (criantes! Beaucoup de vert, jaune, rouge, etc. par défaut dans Winamp), leurs propres polices, etc.

On ne fait plus ça en développement logiciel moderne. Et encore moins dans un logiciel pro.

Alors, il est temps de "layouter" comme les OS, d'utiliser les widgets du système, la polie du système, les couleurs du système…

Tout à fait, quand c'est possible, c'est idéal. Malheureusement le faire en cross-plateforme, c'est pas facile surtout pour les widgets/layouts. Donc on doit faire des concessions, et on utilise des toolkits (certains toolkits d'ailleurs essaient de s'approcher le plus possible du système, malheureusement ce n'est pas toujours un succès). Et puis surtout un logiciel avancé doit aussi pouvoir créer des widgets personnalisé. Comme beaucoup dans la vie, faut choisir un milieu qui permette d'avancer sans se bloquer.

Pour les couleurs, on en a déjà parlé. C'est particulier parce que c'est un logiciel d'imagerie. Et puis certains systèmes n'ont pas vraiment ce concept de thème (ou pas aussi utilisable), donc faut s'adapter à ça aussi.

Pour les fontes, fort heureusement, c'est facile. Ensuite c'est GTK qui gère ça pour nous, je sais pas à quel point il récupère tout bien ou pas, mais on s'en occupe pas. Et si on a un problème pour l'intégration système, on remonte à GTK.

Cependant, si on "fait parler" le bugtracker de GIMP, on a pour le tag "User Interface" : 640 ouverts, 309 fermés.

Pas sûr ce que tu essaies d'en déduire? Moi je dirais que ça veut dire qu'on s'en sort plutôt super bien et qu'on a traité énormément de sujets "user interface" en peu de temps (en plus on a très récemment changé de bugtracker).

Alors que si on regarde l'ensemble : 2197 ouverts, 2861 fermés.
Les ratios ne reflètent pas une priorité.

??? Y a pas que l'interface dans la vie. Déjà y a les bugs à proprement parler. Comme tu peux t'en douter, c'est ce qu'on va trouver le plus dans un bugtracker, et comme tu aurais vraiment dû t'en douter: oui entre un bug critique et une évolution d'interface, le bug a priorité. Genre 20× prioritaire même. Personne ne s'en cache. C'est aussi ça qui fait la stabilité assez exemplaire d'un logiciel comme GIMP (y a eu quelques commentaires élogieux à ce propos sous ce journal d'ailleurs).

Et puis y a tout le reste: les nouvelles fonctionnalités, les trucs un peu à part, les bugs qui n'en sont pas, etc.

Alors 10% des rapports fermés taggués "user interface", je suis même épaté, c'est justement qu'on met ça plutôt haut sur nos listes de priorités!

1/ affichage des unités, pour le coup ça manque.

Effectivement, c'est une info utile. On montre cette info dans d'autres dialogues. Ce serait bien si on pouvait le faire ici (à vérifier néanmoins car je crois pas que GEGL nous donne cette info à l'heure actuelle; peut-être quelque chose à faire évoluer de ce côté).

2/ évolution des réglages : un réglage "Par défaut", sélectionné à l'ouverture de la fenêtre. Dès que l'utilisateur change un paramètre, cela passe en "Personnalisés". Cliquer sur le bouton "Réinitialiser" devient alors choisir dans le sélecteur "Par défaut".

Hmm… c'est une idée intéressante. Mais ça relègue néanmoins le réglage "Par défaut" à un second plan. Déjà parce qu'il n'est plus visible direct: contrairement à un bouton évident "Reset" bien visible, il faut trifouiller dans un menu combo (potentiellement bien rempli) pour y trouver un item "Par défaut". Ensuite parce que ça implique 2 clics au lieu d'un.
Franchement "Reset" est d'un usage super fréquent. Quiconque a déjà manipulé des filtres de courbes par exemple le sait bien. On a vite fait d'en avoir trop fait et de se retrouver avec des courbes imbuvables ou qui donnent un résultat qu'on veut pas. À ce moment, il vaut souvent mieux faire un reset et repartir de zéro. Hier encore, on a donné un court atelier de GIMP, donc j'assistais notre artiste. À un moment, elle montrait les courbes pour faire matcher les couleurs entre 2 calques, mais ça ne rendait pas bien. Elle a donc juste fait un reset, repris de zéro et 10 secondes plus tard, on avait de meilleures courbes.

Bon "Courbes" peut paraître un cas spécial, mais ça ne l'est pas. Beaucoup de filtres ont un paramétrage par défaut qui est plutôt un bon défaut de manière générale, voire un paramétrage neutre pour certains types de filtres (cas des courbes) en particulier où on veut partir du rendu de base. Et revenir à ce défaut est vraiment de l'usage super courant.

Donc ton idée, bien qu'intéressante conceptuellement me paraît problématique en reléguant ce besoin majeur.

Ce comportement n'est pas une invention mais décliné dans de multiples logiciels.

Pour info, même si regarder et prendre note ou comparer ce que font les autres logiciels est important, ce n'est jamais un point final en soi. Certains logiciels font certains trucs mieux que nous, et on fait mieux que d'autres sur d'autres points. 🙂

Quitte à me répéter, GIMP je l'utilise (par forcement beaucoup) et je suis d'avis que son UI est largement améliorable.

Tout à fait! GIMP est loin d'être parfait. J'aimerais tout de même ajouter que pour pouvoir améliorer un logiciel, il faut aussi savoir en repérer, prendre conscience et accepter les bons points. Il faut aussi savoir accepter les choses différentes et finalement "neutres" au niveau utilisabilité (c'est à dire que même si c'est pas ce qu'on aurait fait, ça n'en fait pas vraiment quelque chose de moins pratique). Et notamment il faut laisser les choses neutres telles quelles dans un premier temps. On ne peut pas vouloir tout changer d'un coup (c'est le meilleur moyen de ne rien changer).

Je suis pas sûr que tu fais ça beaucoup, notamment même quand tu comprends enfin des choses qu'on explique et en plus tu te rends compte que ce sont des choses faites ailleurs aussi (les fameux "autres logiciels"), tu continues à vouloir revenir à du moins bon plutôt qu'essayer d'améliorer l'existant. Je parle bien sûr ici du curseur qui a vraiment sa raison d'être (sans forcément être parfait, ce pourquoi on continue de l'améliorer et cela peut continuer) et ne doit pas être juste remplacé par un curseur basique.

J’espère que tu ne prends aucune des remarques sur le logiciel comme un dénigrement du travail accompli (qui est remarquable) ou des personnes qui travaillent dessus.

Je n'ai pas pris mal tes remarques. Elles étaient constructives et j'en appliquerai sûrement quelques points (ou un résultat suite à réflexion après ces discussions) à un moment.

Discuter, partager permet d'apprendre, de changer, de progresser (autant pour moi que pour les autres).
C'est souvent dans ces échanges que découvre des livres, des technologies, des astuces… que j'essaye de partager quand je peux. Merci donc d'avoir pris le temps.

De même, merci pour les remarques.

P.S.:

Pour une raison qui m'échappe, impossible d'inclure l'image :

Il semble y avoir un bug sur linuxfr aujourd'hui (probablement le serveur de cache?). Même les images des articles ne sont plus visibles.

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

Normalement les organisateurs de LGM enregistrent et diffuseront les vidéos, donc notre atelier inclus. Je sais pas si ce sera rapide (par le passé, certains organisateurs ont mis des mois avant de diffuser les vidéos, mais déjà c'est jamais les mêmes organisateurs locaux, et surtout là pour une fois, c'est direct un streaming, alors on peut espérer que ça soit plus rapide!…).

J'essaierai de penser à diffuser le lien si je le vois moi-même passer. 🙂

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

En clonant le repo, et en lisant le site, je comprends que c'est presque entièrement juste du descriptif, avec des évènements simplement décrits dans le fichier .godot. En gros, à part quelques scripts dans le dossier scripts/, y a quasi pas de code (ou pour être plus précis, le code est dans le moteur Godot lui même)?

Les fichiers exécutables par contre (ceux pour lesquels tu fais un speech de sécu, et tu as bien raison!) sont indépendants et ne nécessitent pas Godot par contre (pour la compilation oui bien sûr, mais pas l'exécution), j'imagine?

Pourrais-tu me dire comment tu compiles ces fichiers? Le fais-tu en graphique dans la GUI de Godot? Je suppose qu'y a aussi une méthode en ligne de commande, la connaîtrais-tu?

Je pense que ce serait cool si tu faisais un Flatpak de ton jeu sur Flathub. C'est du binaire mais déjà tu peux fermer la sandbox autant que possible (notamment je pense qu'il n'y a aucun besoin d'accéder aux fichiers, etc.), et tout le processus de compilation est à découvert donc les gens peuvent vérifier les sources et le déroulé du build. Plus besoin de speech sur la sécurité et ça reste facile à installer. 🙂

Je peux t'aider à faire ce flatpak si tu veux parce que soyons clair, j'aimerais bien jouer sans avoir à lancer Godot!

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

Comme certains s'en doutent, LGM (qui devait se dérouler à Rennes, France, en 2020) a été annulé cette année à cause des problèmes sanitaires mondiaux et reporté pour l'an prochain.

Néanmoins 3 jours avec quelques présentations et ateliers live ont été organisés à la place. C'est un LGM clairement diminué (nous, on y allait surtout pour rencontrer les gens!) mais mieux que rien, diraient certains.

En tous cas, Aryeom et moi (projet ZeMarmot) faisons un atelier d'une heure de bases de retouche dans GIMP à 17h aujourd'hui. Ce sera visible sur ce lien, et des questions peuvent être posées à travers le canal IRC (aussi donné dans le lien).

Et pour ceux qui veulent voir le programme pour les autres ateliers, c'est là: https://libregraphicsmeeting.org/2020/en/program.html

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

Un peu d'auto-pub. On remarquera qui a fait cette vidéo. 😉

Évidemment il va sans dire, c'est dessiné avec GIMP. Au niveau animation, ce fut l'occasion de tester Synfig.

Et puisque le libre, c'est pas que du logiciel, on pourra trouver l'ensemble des fichiers sources de l'animation (fichiers XCF, des rendus PNG, les fichiers d'édition Synfig et Blender) là: https://gitlab.gnome.org/Jehan/what-is-peertube/

De mémoire un chouille plus de 2 semaines de travail.

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

Ok, pour moi, c'était un peu la même chose si on voit le thème comme une couche "présentation".

Au début, en te répondant, je me suis dit que CSS permet aussi de réorganiser les objets. Par exemple typiquement beaucoup d'éléments type menu passent en tête ou bas de page sur les petits écrans au lieu d'être à côté. Clairement on n'a pas cette flexibilité dans GIMP. Peut-être qu'une application récente aurait ce type de capacité (je ne crois pas avoir vu cela avec GTK, mais je suis loin de connaître toutes les subtilités du toolkit; peut-être que GTK4 apportera des choses dans cette optique là aussi, je sais pas).

Et puis le but de cette réorganisation en général, c'est surtout de gérer des périphériques d'affichage différents, donc afficher des choses plus petits ou à des endroits plus accessibles, faire éviter de scroller horizontalement, voire cacher des infos redondantes ou peu importantes dans les cas où on a peu d'espace disponible…
C'est rarement dans le but de réorganiser pour gérer des activités différentes, ce qui demande plus que juste changer les objets de place ou de forme, mais surtout de montrer des objets différents ou mettre la priorité sur des objets différents.

Néanmoins même la réorganisation CSS a ses limites. Typiquement si on peut montrer des infos différentes dans divers cas, c'est en envoyant absolument tout, et en laissant le thème afficher ou cacher certains éléments au choix. Franchement ce n'est pas une bonne méthode de créer absolument toutes les widgets possibles, tout balancer à la couche de présentation puis la laisser se débrouiller avec. Je pense qu'on sera tous d'accord pour dire que ce serait un extrêmement mauvais design d'application.

Au final, pour un tel système de profils, la couche backend a aussi sa petite part à jouer (même si c'est pas grand chose non plus).

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

Tu parles de 2 choses différentes:

Vu que du monde se plaint de l'ergonomie, est-ce qu'il ne serait pas plus "simple" de fournir un moyen que chacun puisse proposer la sienne par plugin ? L'idée serait de faire des "skins" […]. Un genre de CSS pour l'application ?

Ce sont les thèmes. On a ça dans GIMP depuis très longtemps (ça existait déjà en 2.6, et je sais pas depuis quand). Dans GIMP 3, les thèmes seront d'ailleurs CSS-like.

Le thème ne change pas les widgets mais juste à quoi ils ressemblent (espaces, tailles, couleurs, décorations, images/icônes, effets, bordures, etc.).

des modes qui se concentrent sur une manière de présenter les choses différentes pour une tache ou niveau d'utilisation […] J'imagine bien un mode "débutant", un mode "photo", un mode "photo débutant", un mode "création graphique" et pourquoi pas des modes précis genre "colorisation de BD" ou "stop motion", avec un moyen simple de bascule.

Là tu parles de réorganiser complètement ta fenêtre, dans sa globalité, et par exemple montrer un différent set d'outils (je suppose) ou une liste d'ancrables différents, etc.
C'est une idée régulièrement proposée et avec laquelle on est d'accord sur le fond, mais personne n'a encore implémenté cette idée. Ça viendra peut-être un jour.

Souvent le terme utilisé pour désigner cela, c'est des "profils".

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

Merci pour la proposition, c'est intéressant.

Juste un commentaire déjà sur comment faire une bonne proposition d'interface sans créer de biais: il faut changer seulement ce que tu veux vraiment proposer.

En l'occurrence là, tu nous mets par exemple une jolie couleur de fond bleutée par exemple. Or il y a une raison pour laquelle le fond de GIMP est dans un gris neutre.
Balance l'image dans ton éditeur de pixel préféré — GIMP par exemple! 😛 — et vérifie la couleur, tu constateras que les 3 canaux (Rouge, Vert et Bleu) ont exactement la même valeur (alors que ton fond a immanquablement un canal bleu bien plus fort). Ce n'est pas un hasard. C'est parce qu'une teinte quelconque de ton environnement va tromper ton œil.
Je suis sûr que presque tout le monde ici a vu ces diverses illusions de couleur qui se baladent sur le web (tiens un des premiers liens que me donne mon moteur de recherche, au hasard). On veut éviter ça. Quand tu travailles dans l'image, tu veux évidemment éviter te "planter" dans tes couleurs.

Cherche sur le web, il y a plein d'article sur le fait qu'il faut absolument travailler avec un fond de couleur neutre (même en dehors de la partie logicielle, dans certains secteurs comme le cinéma, on va faire du color grading dans une pièce sans fenêtre et avec des murs les plus "gris neutre" possible). Ex d'un article trouvé au hasard sur le sujet.

Pourquoi je dis ça? Car déjà, tu nous fais un joli mockup dans une autre couleur de fond avec teinte bleutée, et forcément, ça pête tout de suite, bien plus que le gris chiant par défaut. Tu introduis donc un biais esthétique. On se dit "y a quelque chose", parce que tu as juste utilisé une couleur moins "ennuyeuse" que du gris (qui sera toujours ennuyeux, soyons clair, mais c'est le but d'une GUI pour un tel logiciel; si votre interface commence à vous attirer l'œil, c'est une mauvaise interface; c'est exactement ce qu'on veut pas dans un logiciel de graphisme!).

P.S.: bien sûr, par contre, les thèmes persos sont utilisables; un jour on a même vu un thème rose (véridique!). Chacun est libre de faire ce qu'il veut. Mais les thèmes par défaut seront toujours neutre (claire ou sombre, mais neutre).

Le second biais que je vois que tu as introduit est de plus grosses polices. Forcément on a tout de suite l'impression de "lire mieux" avec les 2 images côte à côte. Mais en fait, en s'attardant sur les captures, on comprends vite pourquoi: dans une capture, c'est écrit plus gros (et en plus avec les artefacts du JPEG, ça arrange rien pour la petite écriture qui subit plus les défauts de compression). C'est sûr que si j'écris tout en plus gros, on lit mieux. Tu peux te permettre de faire cela, car encore une fois, tu as travaillé sur une capture d'écran de qualité médiocre, pas sur un vrai logiciel. Forcément cette capture d'écran sait pas dans quelle résolution est ton écran, quelle est ta configuration de fontes dans l'OS, etc. Mais dans la vraie vie, la taille de police sera la même, à savoir celle qui est configurée dans ton OS pour du texte normal. Si tu configures ton OS pour avoir de gros textes, alors tu auras de gros textes. Ou tu peux le faire juste au niveau de GIMP en changeant la taille de texte au niveau du thèmes. Mais le faire au niveau de 2 captures comme comparaison de mockups, c'est un peu de la "triche", si je puis dire. Cette différence n'existe que dans ta comparaison en image.

Bon, maintenant une fois ces 2 biais bien identifiés, et en essayant d'en faire abstraction, j'ai essayé de regarder un peu ta proposition.

Pour résumer : "G", ":", "nom du layer" et "du document" sont retirés, car inutiles ou visibles et connus par ailleurs.

Comme j'ai dit dans mon précédent commentaire, les noms de calque/image sont certes des infos redondantes mais utiles. La redondance est en effet parfois très utile si elle te permet de sauver de précieuses secondes, puis minutes, puis heures en cumulé.
Je suis d'accord que l'affichage de ces infos peut être amélioré, mais les retirer est discutable (et possiblement une mauvaise idée). Cela paraît surtout une solution de facilité.

Les fonctions du preset sont dans le "…", car (à priori) pas des fonctions principales.

Ok. Pourquoi pas.

Maintenant pour le curseur, gros sujet!

Il n'y a pas de "petites flèches" dans les textfields, le support de la roulette de la souris s'y substitue bien mieux.

Pas tous les pointeurs n'ont de roulette, notamment pas les tablettes graphiques (sauf à utiliser un stylo optionnel, et encore seulement chez Wacom je crois; en plus ils n'ont même pas fait de nouvelles versions de ce stylo dernièrement, sauf changement récent, donc je pense qu'ils vont peut-être même abandonner ce design). Quand je regarde l'ordinateur de la réalisatrice de ZeMarmot, ces derniers temps, elle n'a même plus de souris branchée (uniquement le stylo).

Quand on fait un logiciel tel que GIMP, il faut que nos widgets s'adaptent à tous ces types de pointeurs (la tablette notamment est très courante, et pas seulement chez les illustrateurs), pas juste à une souris.

En testant la dernière mouture de GIMP je me suis rendu compte que le slider est encore moins pratique que je pensais, pour remplacer la valeur 10 par 15, il ne suffit pas de cliquer en taper 15, si on fait ca on se retrouve avec un comportement peu intuitif

Je comprends pas ce que tu dis. Je viens de tester, ça marche exactement comme ça.

il faut alors double cliquer sur le texte

Double cliquer permet de tout sélectionner, un comportement assez classique pour un widget de texte. Ça marche néanmoins tout à fait sans double-cliquer (on sélectionne pas tout, mais c'est ce que j'attends d'un widget de texte aussi).

et hop, fausse manip, on a vite fait d'interagir avec le slider superposé

Une fausse manip peut toujours arriver oui, mais c'est le cas pour tout. Tu peux faire des fausses manips avec ton curseur de base aussi. Je comprends pas où tu veux en venir. En tous cas, si je clique sur le texte, je peux l'éditer. Ça marche parfaitement bien.
Ensuite je dis pas que l'intéraction ne peut pas être améliorée (on peut toujours expérimenter ou réfléchir à mieux), mais n'empêche que le comportement actuel reste tout à fait attendu et fonctionnel. S'il fallait donc améliorer, cela passerait par peaufiner cette widget (comme ce qui fut fait dans 2.10.18, mais on peut sûrement faire encore mieux), pas revenir en arrière à des curseurs totalement basiques et bien moins puissants comme ceux par défaut de GTK+.
En gros une amélioration par itération.

Tu dis dans un autre commentaire:

Pour les sliders, tu t'es posé la question des valeurs? Pour une opacité (slider original de 0 à 2), tu as besoin de 400 pas?

Je comprends pas trop la remarque. Bien sûr que oui, tu as besoin du plus de précision possible. Il ne s'agit pas d'une plage de valeur entière (0, 1, 2), mais bien d'un nombre flottant entre 0.0 et 2.0. Si tu joues avec ce curseur "Opacité" du filtre Drop Shadow, tu verras que c'est un changement continu de l'effet (avec la prévisualisation instantané, c'est encore plus sympa à tester).

Donc oui, tu as carrêment besoin du plus de précision possible et donc prendre la plus grande largeur possible est extrêmement utile, comme je le disais dans mon commentaire précédent. Je crains qu'il y a beaucoup de perte de précision dans ta proposition.

Tu dis aussi ailleurs:

Bon, j'ai fini par sortir la tablette graphique, ai essayé de cliquer/glisser au stylet les parties hautes et basses des sliders X,Y,Opacité… il n'y a pas de comportement particulier. Seul bouger gauche/droite change la valeur du slider, comme pour… un slider standard…

Je crois que tu n'as pas lu l'article. Je t'ai déjà fait la remarque à ce sujet plus haut (j'ai même fait un lien interne vers la section précise qui en parle). Ce dont tu parles est noté dans l'article et tu as vraisemblablement testé la nouvelle version du widget.

Donc oui, le curseur de GIMP est un widget particulier et évolué qui va bien plus loin que les curseurs basiques de GTK+ ou autres toolkits qui sont bien plus limités.

Pour le "reset", je pense que l'icône choisie est assez "parlante".

Comme quelqu'un le note, ta proposition d'icône fait aussi penser à "Undo" même si ce type d'icône est aussi utilisé dans des cas de "Reset". C'est typiquement ce que je disais au sujet de la tendance (depuis pas mal d'années déjà) de remplacer le plus possible les icônes par du texte. Les icônes ont vraiment perdu de leur attrait chez les designers qui conseillent tous d'utiliser le plus possible du texte et le moins possible des icônes. Si tu t'intéresses vraiment au design d'application, je te conseillerais de rechercher un peu sur ce sujet. C'est même plus un sujet chaud, c'est du réchauffé, limite impensable de ne pas le savoir en design d'application. Tous les gros éditeurs de logiciels ou du web sont passés à du texte partout, dès que possible. Tiens regarde les captures du logiciel que tu nous as montré: du texte partout. Les seuls endroits où y a des icônes seulement, sans texte, c'est les barres d'outil ou des onglets, typiquement le genre d'endroit où y a trop de choses ou bien pas assez de place. Tout le reste, c'est soit texte seul, soit texte + icône.

Attention, on ne dit pas de ne jamais utiliser d'icônes. Personne ne dit ça. Mais vraiment quand on a le choix, du texte est toujours mieux. Pourquoi? C'est clair, beaucoup moins sujet à controverse ou à mésinterprétation.

Chez GTK+ par exemple, les icônes ont sont progressivement retirés depuis des années (en cherchant un peu, il semblerait que cela ait commencé avec GTK+ 3.10.0 sorti en 2013) des menus, des boutons (typiquement "OK", pas une icône ✅ ou autre dessin).

Donc je le disais déjà précédemment, pour "Reset", c'est d'après moi absolument une très mauvaise idée. Pour l'icône d'aide, bien moins usitée, éventuellement ok. Mais comme on est vraiment pas en manque de place, il me paraît bien plus approprié de garder du texte et d'être ainsi sûr de ne pas avoir d'incompréhension.

Note pour ceux qui pensent que c'est du pinaillage, les alignements verticaux permettent une lecture plus rapide

Un alignement du texte à droite (cf. ta proposition) permet-il vraiment une lecture plus rapide que l'alignement à gauche actuel? Honnêtement je sais pas, j'ai jamais rien lu qui dit ça. Mais ça me paraîtrait quand même bizarre. Je sais notamment que la justification de texte est très mauvais et déconseillé pour la rapidité de lecture par rapport à l'alignement à gauche. Ensuite j'ai jamais rien lu sur l'alignement à droite spécifiquement mais cela me paraît même pire que la justification intuitivement; mais mon intuition ne vaut rien, je dirais qu'il faudrait des études sur le sujet pour me convaincre.

En tous cas, une très rapide recherche sur le web semble aller dans le sens de mon intuition. Bon je trouve au moins un blog qui dit que l'alignement à droite est pas bon en général mais que ça peut être "relativement inoffensif" pour des textes très courts comme ici. Note bien qu'ils disent pas "plus rapide" mais juste "relativement inoffensif". En tous cas, pour l'instant, je trouve aucun article qui dit que ce sera plus rapide comme tu l'affirmes. Je reste donc très dubitatif.

Pour ce qui est des choix, polices/thèmes etc… en tant que programmateur j'ai tendance aussi à tout laisser paramétrable, mais je me rend compte au fil des années qu'il est plus productif de proposer un truc clean par défaut plutôt que de laisser tous les utilisateurs bricoler dans leurs coins.

Ça n'a rien à voir avec du "bricolage dans son coin". C'est même l'inverse. En design d'application, on en est vraiment revenu des interfaces où tout est customisé, même si c'était très fun et avec quelques projets vraiment fous (pensez Winamp et ses skins de fous). Juste pour le fun, remémorons nous l'époque fun de Winamp, ahahah:

De nos jours, on privilégie des interfaces unies, qui utilisent les configurations du système, avec un style géré au niveau de l'OS/bureau. On veut avoir à gérer le moins possible ces choses là.

La seule exception à cette règle est peut-être en effet dans un logiciel comme GIMP où on veut proposer des styles par défaut dans des couleurs neutres, un besoin qui n'existe pas dans un logiciel quelconque mais primordial pour du traitement d'image (même s'il reste possible de forcer un autre thème ou de laisser le thème de l'OS prendre le dessus). Mais pour les polices? Je vois pas pourquoi on forcerait des polices particulières.

Si l'UI devient une priorité de GIMP

L'UI a toujours été une priorité de GIMP, au moins depuis que j'y contribue pour sûr (8 ans), comme tu peux le voir avec mes réponses. Et je suis sûr que même avant, d'autres gens s'y intéressaient beaucoup (notamment un des designers GNOME les plus connus, Jimmac, est très connu pour avoir beaucoup aidé au design de GIMP à ses débuts).
On peut toujours faire mieux, bien sûr, mais l'interface n'est absolument pas laissée au hasard, comme tu sembles le croire.

En tous les cas, je suis pas vraiment convaincu par les différents points de ta proposition. Au début, ça fait joli et nouveau (une nouvelle GUI, ça fait toujours cet effet, car on est juste tellement habitué à une autre), mais une fois les biais de couleur et de taille de fonte retirés, il me semble qu'on perd pas mal en utilisabilité et efficacité (et possiblement même la lisibilité avec l'alignement à droite) sur plusieurs points.

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

Je suis plutôt d'avis que c'est l'absence de choix qui fasse perdre du temps. La règle aujourd'hui dans gimp c'est d'avoir les 2 points ? Très bien établissaient le coller une règle et indiquez que pour remettre en cause ces règles il faut de solides arguments (plus qu'une apparente inutilité ou un esthétique subjective).

Qu'est-ce qui te fait dire que ce n'est pas déjà le cas? Ce n'est peut-être pas une règle écrite (j'en sais rien, ça se trouve, elle l'est; en 25 ans, ils s'en est passé des trucs, et j'ai ai pas vécu tout à fait le tiers), mais en l'occurrence, cela est évidemment une règle implicite (comme je l'ai dit plus haut, certes pas en donnant le terme "règle"). Regarde toutes les boîtes de dialogues. Cette syntaxe est utilisée partout. Pour moi, il y a bien évidemment une règle qui est qu'on met ':' entre un label de widget et le widget lui-même quand il suit le label.

En aparté, je viens de me rendre compte pourquoi "Color" n'a pas de ':'. Les boîtes de dialogue de filtres pour des opérations GEGL sont générés automatiquement. Donc "Presets:" fait bien partie de GIMP, mais "Color" est un string de GEGL. Et en l'occurrence, c'est tout à fait normal qu'il n'y a pas ':' là car c'est un titre générique de paramètre d'opération que nous utilisons en label de widget. Il y a néanmoins des solutions. On peut rajouter le string "%s:" comme un string traductible (car toutes les langues ne gèrent pas pareil cette ponctuation, on le sait bien, c'est le cas du français). Je regarderai de plus près quand j'y penserai.

Quoiqu'il en soit, comme tu le vois toi-même, c'est pas parce qu'une règle est établie qu'on ne perd magiquement pas du temps (laisse moi te dire que j'en ai perdu du temps ici malgré cette règle bien présente, ce que j'ai dit dès la première phrase de mon premier message sur le sujet!). Il faut encore répondre aux gens comme ici et expliquer (ou alors on peut aussi ignorer et à ce moment, on nous reproche de ne pas écouter! On ne peut pas "gagner" de toutes façons à ce jeu 🙄😛).

Au passage, je vais aussi répondre à ce que tu m'as dit dans ton message précédent:

Souvent quand il y a des remarques faites sur gimp. Tu nous explique que tu t'en occupera. C'est super, mais ça me donne l'impression que tu prends les remarques comme des demandes personnelles. Ça peut très bien être quelqu'un d'autres. Je serais moins surpris qu'au lieu de généralement finir sur toi qui dit « je l'ajoute à ma todo liste » la conclusion soit « il faut l'ajouter à la todo list du projet aka il faut rapporter un bug ». Après je dis ça pour toi, hein :)

Je ne prends rien comme des demandes personnelles, mais contrairement à ce que certains semblent penser, on écoute énormément les utilisateurs (regardez le nombre de bugs ouverts et fermés quotidiennement sur notre bugtracker, ainsi que les commentaires échangés; je reçois chaque commentaire par email — pas juste des sujets choisis, absolument tous les commentaires de tous les rapports, ça fait beaucoup d'emails quotidiens — et je les lis tous, au moins en diagonal, je peux t'assurer qu'il m'est impossible d'ignorer les remarques d'utilisabilité; et je sais que plusieurs autres contributeurs font la même chose), on travaille d'ailleurs de près avec pas mal d'entre eux, on fait énormément de finition et on est très attaché à avoir une bonne interface. On est constamment en train de fignoler des détails quand ils ont du sens, même si on ne va pas forcément en faire la pub. Si on devait changer ':' quelque part, tu ne verras effectivement cela nulle part sur un article de sortie de GIMP. On y parle de nouveaux effets, d'outils qui ont des améliorations dramatiques, ou autre truc du genre, pas de "j'ai fignolé". Ne pas en parler ne veut pas dire qu'on ne fait pas constamment de la finition. Chacune de nos sorties est bourré de ces petits détails d'amélioration qu'on ne liste jamais au milieu des grands changements.

Donc oui, quand quelqu'un me fait une remarque qui a du sens (comme ici celles sur la redondance de titre ou le label de référence du calque modifié qui peut être amélioré), je la prends en compte. C'est pas prendre ça comme demande personnelle, juste du "ah oui tu as raison".
D'ailleurs quand je disais que je suis en plein dans le sujet de la sélection de calque et donc que je regarderai pour ces remarques, ce n'était ni une exagération ni une extrapolation. Ça fait vraiment 2 mois que je suis en plein dans ce sujet, ceux qui suivent le financement de notre travail et les rapports de développement le savent très bien. J'étais d'ailleurs déjà passé sur le code de ces labels de référence à des calques et me souviens bien que je m'étais posé quelques questions. Je sais que je devrai y repasser, et me poserai donc encore davantage de questions pour essayer de les améliorer.

Quant à demander à faire un rapport de bug pour ça, à part adorer la paperasse ou aimer perdre du temps, pourquoi faire? Les rapports de bug sont extrêmement utiles et même primordiaux pour plein de trucs. Mais ça ne veut pas dire qu'il faut en faire quand on peut s'en passer (en l'occurrence, je suis un des développeurs principaux, je peux m'en passer dans des cas rapides comme ici). Faire des rapports de bug pour un truc aussi mineur et évident que "retirer un titre en double" (bien que pas évident pour 2.10, je le rappelle, mais tout à fait vrai pour master où avec les Client-Side Decorations, on contrôle cette redondance), c'est juste faire perdre du temps au rapporteur, aux contributeurs qui nous aident au triage de bug, et à moi en tant que dév car j'ai déjà dit que ça pouvait être amélioré et peux le faire rapidement.
En vrai très souvent, je dis aux gens de faire des rapports de bug, mais quand (1) je sais qu'un rapport existe déjà, alors faire un duplicata de rapport n'apporte rien et fait perdre du temps; ou (2) c'est un truc simple que je vais faire et si on fait un rapport, ça va juste faire perdre du temps à discuter de choses déjà discutées, ben non dire "ah oui je vais faire", c'est justement la version où on évite à tous de perdre du temps. 🙂

Enfin bon, sincèrement je pense que ceux qui nous disent que GIMP est pas fignolé ne l'utilisent tout simplement pas tant que ça, ce qui n'est pas un problème en soi, on ne demande pas à ce que les gens doivent absolument utiliser. Mais clairement par exemple ici critiquer sur des … screenshots! Et non pas sur l'utilisation… c'est un peu bizarre (désolé Guillaume). Jamais au grand jamais il ne me viendrait d'aller critiquer un logiciel, et pire de parler d'ergonomie et de massacre en règle, à partir d'une capture d'écran (par exemple celles donnée par Guillaume qui franchement ne sont pas suffisantes pour pouvoir dire quoi que ce soit de réaliste sur cet autre logiciel; je ne m'y risquerai jamais).
Surtout quand on en vient à critiquer le rendu des fontes à partir d'artefacts de compression JPEG (et que les mêmes existent sur les screenshots censé représenter "mieux", de manière amusante).
GIMP est un logiciel utilisé professionnellement au quotidien (par nous notamment), qui a énormément de retour d'expérience (par des gens qui utilisent vraiment, pas qui regardent des captures). On en fait sans cesse des améliorations de détail et des améliorations d'ergonomie. Rien que dans cet article, on parle d'amélioration d'ergonomie majeure du widget curseur, avec un argument cité par Guillaume qui est justement corrigé dans GIMP 2.10.18, sorti y a quelques mois (puisque cette news linuxfr a du retard par rapport à la sortie officielle). Ce qui me fait dire que lorsque ce reproche a été fait par rapport à un screenshot présent, Guillaume n'a pas encore lu la news entièrement d'une part, et n'utilise vraisemblablement pas GIMP régulièrement (pas depuis plusieurs mois?) d'autre part. Je peux me planter, mais c'est l'impression que ça me donne.
Ensuite, Guillaume, tu as néanmoins fait quelques remarques pertinentes et utiles, donc je te remercie. Mais j'en profite pour pointer quelques petites incohérences dans l'argumentation, si tu me le permets. 😉

Enfin dernière remarque sur:

Il me semble que les devs de GIMP ont aussi une lourde responsabilité.

En effet, on a une lourde responsabilité, ou plutôt on se l'est créée nous même (c.a.d c'est un choix qui est fait en décidant de contribuer à GIMP). On en est tout à fait conscient. Et c'est bien pour cela que plein de choses sont bien plus compliquées qu'elle n'en ont l'air. Il y a des choses qu'on peut changer sur un coup de tête, et énormément d'autres choses qui ont l'air mineures mais sont en fait plein d'implications et de conséquences.
En outre, plein de choses ne sont pas si évidentes que les rapporteurs le croient (ou veulent le faire croire parfois).
Enfin on a aussi la responsabilité de penser en grand, penser global. On a des utilisateurs de tous pays, de toutes activités, des graphistes, des designers, des scientifiques de l'image, des illustrateurs, des animateurs, des photographes, des cinéastes, etc. etc. Beaucoup de gens ne voient que leur petit bout de la lorgnette. Ensuite quand on leur explique, beaucoup se rendent compte que ce n'est pas si simple (d'autres ne veulent pas le voir). Très peu de choses sont simples (même si elles peuvent l'être techniquement) dans le développement d'un tel logiciel. Et c'est ça notre responsabilité. Pas de faire des changements sur des coups de tête parce qu'une ou 2 personnes nous le demandent sans vraiment voir les choses dans le contexte et la globalité. Si on faisait ce genre de choses, je peux assurer que GIMP n'existerait plus depuis des années et aurait juste été devenu un point d'anecdote dans l'histoire du logiciel libre. C'est ça notre responsabilité. Et c'est si on faisait plein de changements sans réfléchir juste pour faire plaisir à quelques personnes au hasard qui commentent sur capture d'écran (et qui en fait s'en fichent donc probablement et ne s'en rendraient possiblement même pas compte au final, si elles n'utilisent pas vraiment GIMP en profondeur), c'est seulement dans ce cas qu'on faillirait à notre responsabilité.

Enfin voilà, je pense que c'est mon dernier message sur ce thread. J'y ai déjà perdu trop de temps.

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

J'ai presque l'impression de te voir lever les yeux au ciel en levant les épaules en parlant de primordial. C'est un travaille de finition c'est toujours bon à prendre même si ça n'est pas le cœur GEGL/algorithmique de gimp. Ça pourrait avoir sa place dans les bugs Newcomers du projet.

Le problème de ce type de changement, c'est que même si c'est effectivement très simple à changer, ça soulève en fait énormément de questions. Et donc non ce n'est absolument un bug qui pourrait rentrer dans la catégorie "Newcomers" (dans cette catégorie, on rentre les bugs simples et qui ne soulèvent aucune question donc ça sera aussi facilement accepté).

Déjà j'en ai soulevé une première de question: en faisant ce changement, on invaliderait vraisemblablement des dizaines de strings. C'est particulièrement un problème pour les langages qui sont peu maintenus de nos jours, car on risque d'invalider des strings qui ont des traductions depuis des années et qui risquent soudainement de se retrouver sans traductions pour les mois voire années à venir.

À partir de ce moment là, il faut aussi se poser la question sur pourquoi c'est mieux d'avoir deux points ou de ne pas en avoir. Perso j'arrive pas à voir une raison pour un choix ou l'autre. Mettre 2 points pour séparer un label et son contenu, c'est juste une syntaxe super classique. Dans le cas d'une GUI, ne pas les avoir pourrait bien sûr aussi être acceptable ceci dit. De la même manière qu'une liste de définition va souvent être affichée différemment (parfois avec ':', parfois avec le label en gras ou indenté particulièrement, etc.). Je ne vois pas de vérité absolue là-dedans et absolument rien d'évident.

Donc le rapport intérêt/problème créé est très déséquilibré pour l'instant.

Ensuite c'est typiquement le genre de problématique où une fois qu'on aura fait le changement, on pourrait avoir quelqu'un qui un mois ou un an plus tard nous dira que c'est une interface totalement inacceptable et qu'il faut mettre deux points entre le label et le widget. Et retour à la case départ (tout en ne sachant pas dire vraiment pourquoi avec ou sans ':' c'est mieux). C'est sans fin ce type de problème.

Donc non, ce n'est absolument pas un bug "newcomer" car pas un sujet évident du tout. Je ne classe pas cela dans de la "finition". Les problèmes de thèmes, les marges, des icônes plus claires, des widgets plus efficaces, des textes plus compréhensibles, etc. oui clairement ça c'est de la finition. Faut-il deux points entre un label et son widget associé? Franchement je sais pas. Par contre clairement au final, pinailler sur ce point va faire perdre beaucoup de temps à beaucoup de gens si on fait un rapport de bug et qu'on se met à discuter dessus. Donc si je devais lever les yeux au ciel, ce serait plutôt pour cette raison.

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

Ces personnes n'ont jamais contribué et sont d'ailleurs à peine identifiées.

N'est-ce pas contradictoire ? Comment être sur que ces personnes n'ont pas contribuées si elles ne sont pas identifiées ?

En fait je pense que ces personnes sont relativement bien identifiées (bon j'ai pas vérifié si les noms utilisés sont les vrais noms mais l'usage de pseudonyme serait de toute façon tout à fait acceptables et ne changerait pas le concept d'identification).

C'était clairement une enième attaque de projet libre, de renversement afin de politiser un projet qui ne l'est pas ou un geignard aka sjw qui s'emmerdait.

Source ? Je veux bien te croire, mais où sont les preuves que les intentions sont malveillantes comme tu le laisses supposer ?

Il y a eu quelques théories du fait que l'originateur du fork est un employé d'Oracle (fait noté dans divers articles) et ça a fait un peu jaser. Perso j'y accorde pas trop d'importance. Simple théorie du complot ou non, perso je m'en fous. Peut-être est-ce cela à quoi Noyal fait référence.

Nous n'avons que la version de Johan sur la manière dont cela s'est passé.

Tu as déjà dit ça plus haut et je voulais pas relever notamment car j'ai vraiment pas envie de perdre du temps à parler de ce fork. Néanmoins comme tu répètes, j'ai vite fait re-regarder mon commentaire. Tout ce que j'ai écrit est presque 100% des faits. J'ai fait extrêmement peu d'interprétation ou d'approximation. Donc tout est absolument vérifiable. Ensuite c'est vrai que le rapport a été bloqué par les admins GNOME et n'est donc visible que ceux avec un compte GNOME (ça fait quand même beaucoup de personnes). Néanmoins on sait ici que "l'internet n'oublie pas". Ce ne sont pas des infos disparues ou invérifiables pour qui veut vraiment (ne serait-ce que archive.org, j'ai vérifié, le rapport y est).

Le nombre de messages incroyable en une seule nuit (plus de 100 et quelques messages entre genre minuit et 9 ou 10h du mat notamment, avec un total de 187 messages en milieu d'après-midi quand l'admin finit par bloquer le rapport; c'est pas ma "version", c'est ce que Gitlab affiche), le fait que ces personnes ont cross-posté massivement le lien du rapport de bug sur de multiples sites (dans le rapport de bug, on retrouve quelques uns de ces liens; et si on poste le lien dans un moteur de recherche, on en trouve plus), ce qui a créé une véritable cohue de gens et notamment de disputes. En fait ils ont créé leurs propres engueulades notamment en rameutant eux-même les gens avec qui ils se sont engueulés. De manière générale, cross-poster un lien de rapport de bug pour avoir des "soutiens" n'est jamais une bonne idée pour la simple bonne raison que demander quelque chose à des volontaires en essayant de faire pression par le nombre n'est déjà pas une bonne chose. En l'occurrence ici, c'est encore pire car ils ont en plus essayé de le faire sur un sujet super controversé, donc ils se sont créé leur propre groupe "anti". Par contre ils ont utilisé ces disputes avec des inconnus comme base de leur argumentaire. Les commentaires de membres de l'équipe GIMP sont très courts, peu nombreux et essaient surtout de limiter la casse.

Les divers autres trucs que j'ai écrits sont aussi tous vérifiables. C'est vraiment bien car c'est du logiciel libre et tout se fait publiquement. Absolument rien de cette histoire ne s'est fait dans le secret.
Donc je trouve tout de même qu'appeler cela ma "version", c'est pas très pertinent. Il suffit de regarder les infos par soi-même. 🙄

Bon c'est mon dernier message sur ce fork. Sincèrement ça m'intéresse pas et j'aimerais bien qu'on évite d'en parler encore et encore en me nommant. Je regrette d'avoir répondu initialement à cette demande d'infos. Merci! 🙏

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

Merci pour les retours!
Voici quelques commentaires:

Drop Shadow (en titre), Drop Shadow en sous titre

L'un est le titre de la fenêtre, l'autre le titre du dialogue. La différence est importante car la barre de titre n'est pas contrôlée par GIMP mais par le système de fenêtre. Typiquement cela signifie que la barre de titre peut ne pas montrer le titre, être minuscule, voire être totalement absente. Cela ne dépend absolument pas de nous, mais du système de fenêtrage et de sa configuration éventuelle. Dans GIMP 2.10.x, on ne peut donc pas se reposer sur le texte dans cette barre de titre pour dire qu'il y a redondance.

Par contre, dans GIMP master, ces boîtes de dialogue sont désormais en Client-side decorations (c'est à dire qu'on est passé à un système où nous demandons au système de fenêtre de ne plus gérer la barre de titre). Dans ce cas, oui c'est une bonne remarque. Probablement devrait-on retirer le nom du filtre sous la barre de titre. Je vais regarder cela de plus près.

un machin tronqué sans raison "Drop… 27 (Untitled) : on peut pas faire mieux ?

Il s'agit du nom du calque, et entre parenthèse du nom de l'image. Ce sont des informations intéressantes pour garder une référence explicite du calque qu'on est en train de modifier.

Le numéro, je suis pas sûr, il s'agit peut-être d'un numéro unique de calque (c'est pas une info très intéressante pour la GUI, je suis d'accord; si c'est ce que je crois, c'est plutôt utile pour les développeurs de plug-in).

Le calque s'appelle "Drop Shadow". Je suis pas sûr pourquoi un nom si court est tronqué dans GIMP 2.10.14 par contre. C'est en effet une bonne remarque. Mais je constate que ce n'est pas le cas dans la version de dév. Quant au nom de l'image, en l'occurrence, celui qui a fait cette capture d'écran n'avait pas enregistré son image, donc "Untitled" est noté. On peut néanmoins discuter si l'info reste intéressante lorsque l'image n'est pas encore nommée.

Ensuite clairement ce texte référent du calque cible peut être amélioré. Ce ne serait absolument pas compliqué à changer, mais encore faut-il que quelqu'un s'y intéresse. Je n'ai jamais vu quelqu'un se plaindre de ça jusqu'à aujourd'hui. J'y jetterai sûrement un œil plus tard.

A quoi il sert ce logo à gauche?

C'est vrai que ce n'est pas très utile à l'heure actuelle car toutes les opérations GEGL ont actuellement le même logo. Et puis même de manière générale, l'intérêt d'un logo tout court est sujet à question. La mode de mettre des icônes ou logos pour tout est un peu passée. Les règles de design d'interface de nos jours tend à privilégier le texte à l'image, car le texte est beaucoup moins sujet à interprétation. C'est plus long mais aussi plus direct, plus compréhensible.
Peut-être donc en effet que le logo pourrait juste disparaître (le seul intérêt que j'y vois à l'heure actuelle est de faire un peu de visibilité à GEGL, qui est forcément un peu éclipsé par GIMP alors que ça reste un logiciel central du projet).

et la preview de 4mm x 3mm, elle sert à quelque chose en l'état?

Dans certains cas, cela peut ne pas être du tout utile, dans d'autres, cela peut être très utile, encore une fois pour suivre plus facilement le calque cible au même titre que le nom du calque. Ces informations peuvent sembler redondantes (et elles le sont), mais cette redondance est utile car quand on travaille avec beaucoup de calques, il y a toujours des moments où on perd un peu pied. Bien sûr, on retrouve très rapidement ses marques. Avec plus de repères, on les retrouve potentiellement un chouilla plus vite (et les quelques millisecondes de gagnées s'ajoutent et font des secondes, puis des minutes, etc.).

Presets : pourquoi un ":" ?

Quand je compare à d'autres champs, ils ont aussi ce ':' (regarde par exemple dans le dialogue de nouveaux calques). Donc par cohérence, ma remarque serait plutôt "pourquoi il n'y a pas de ':' après Color?".
Éventuellement on pourrait décider de ne jamais avoir de ':'. C'est à discuter et si c'est décidé, il faudrait alors changer cela partout dans l'interface. Personnellement je trouve cela tellement mineur que j'ai pas envie de perdre du temps dessus. Et j'ai pas trop d'opinion sur le sujet. Mais si quelqu'un trouve cela absolument primordial et que personne dans l'équipe n'est contre, j'accepterais un patch faisant le changement sans problème.
Le seul problème que je vois est que cela invaliderait les traductions de tous ces labels avec ':' partout dans l'interface (pas mal de dizaines vraisemblablement), pour un intérêt incertain (comme dit, j'ai pas d'opposition mais je vois pas non plus de gain d'utilisabilité) et ce serait un argument suffisamment valable pour refuser un tel changement quand même. Je sais pas, à discuter.

Icônes minuscule pas vraiment parlantes.

Le '+', je le trouve très parlant (ajout d'un preset). L'icône suivante, elle n'est pas extraordinaire, mais comme c'est la même icône pour tous les sous-menus (on la retrouve notamment sur chaque dockable), ben on sait direct que c'est une icône de sous-menu. C'est le concept de cohérence et tout utilisateur aguerri de GIMP reconnaîtra l'icône par l'usage.

Ensuite clairement les icônes sont en besoin d'amour. C'est dommage car GIMP est un outil notamment pour designers, avec des millions d'utilisateurs, mais on a très peu de contributions de designers. On accueille avec volontiers les patchs d'icônes, autant que de code, si certains ont de meilleures idées d'icônes.

X : "X" collé à gauche, marge à revoir

Pareil nos thèmes sont assez terribles dans GIMP 2.10. Et encore ils ont été revu à la dernière minute par un de nos contributeurs de longue date car la version précédente avait été un peu balancée par un contributeur occasionnel qui en a très rapidement abandonné la maintenance dans un état laissant vraiment à désirer. Mais il y a des limites à ce que notre contributeur de longue durée avait le temps ou l'envie de faire et on s'est retrouvé avec ce thème très imparfait (mais avec le mérite d'exister).

Dans la version de dév pour GIMP 3, qui a totalement changé de système de thème (CSS-like de GTK+3), on a d'ailleurs encore rien et on attend qu'un contributeur se manifeste.

Encore une fois, on a tellement d'utilisateurs designers mais aucun ne semble vouloir prendre le temps de nous aider. On rappelle que le logiciel libre, c'est nous, c'est vous. On attend les patchs. ;-)

de plus le "slider" est plus au que les autres widget.

Plus "haut", tu veux dire, j'imagine? Si oui, le problème de la place verticale assez importante que prenait ce widget a été pris en compte et c'est même dans cette news, puisque cela fut changé dans GIMP 2.10.18.

Le fait de mettre le label (X) dans le widget casse la logique de l'interface.

C'est une spécificité de longue date de ce widget custom qui a un sens. Cela permet d'avoir un widget curseur qui prend la plus grande largeur horizontale possible. Pour une sélection plus précise, avoir la plus grande largeur possible pour représenter une plage de valeurs donnée est très utile. En outre, c'est personnel, mais je trouve cela esthétiquement bien plus plaisant qu'un label à gauche et un curseur à droite.

Clipping : un combo avec un look encore différent

Ben justement ce look suit la même logique que cela du widget curseur. Si on devait pointer du doigt celui qui est incohérent dans cette capture d'écran, c'est le look du widget de couleur encore une fois (mais pour représenter une couleur, il me semblerait peu approprié d'avoir le label à l'intérieur du widget, donc en l'occurrence, c'est une incohérence qui ne l'est pas tant que ça).

Preview / Split : bizarre ce Split qui part à droite

Pourquoi cela? Je trouve pas cela bizarre du tout.

Help & reset: des icônes discrètes seraient suffisantes

Pour "Help", oui une petite icône '?' par exemple aurait pu marcher, surtout que l'usage de ce bouton est anecdotique (de manière générale, l'aide est une fonctionnalité importante mais on ne l'utilise pas sans arrêt; au bout d'un moment on n'a plus besoin de l'aide pour une fonctionnalité donnée). Sauf que justement comme je le disais plus haut, la tendance depuis quelques années est de faire disparaître les boutons avec icônes au profit de boutons avec du texte, car c'est bien moins sujet à questionnement. "Help", on comprends tout de suite. '?' aussi mais c'est surtout par force d'usage, ce qui est déjà une bonne raison, ceci dit. Toute autre icône (un livre ouvert pour indiquer un "manuel"? Autre chose?) pourrait être aussi sujet à interprétation ou discussion. Mais là en l'occurrence, il y a de l'espace, autant l'utiliser alors pourquoi se priver et risquer une incompréhension?

En tous cas, pour "Reset" par exemple, je serais totalement contre le remplacer par une icône. "Reset" est une opération importante et courante dans ce type de boîte de dialogue. Cela doit immédiatement être repérable (encore une fois, texte est supérieur à icône en matière de compréhension immédiate) pour un usage efficace.

Polices : choix : bof, rendu de police: beurk

Hmmm… Là je crois que tu es en train de commenter le rendu de la capture d'écran, vraisemblablement juste un jpeg avec forte compression et clairement pas mal d'artefacts qui vont avec faites par notre contributeur qui a fait la news.

Il n'y a rien de tout cela sur l'interface rélle (rendu de police, c'est juste le rendu de GTK+ que tu retrouves sur des centaines de logiciels). Si tu regardes tes captures de DaVinci, c'est tout aussi horrible (ça se voit pas forcément du premier coup d'œil car tes captures montrent le logiciel en entier — contrairement à la capture d'une petite boîte de dialogue de GIMP — donc les textes sont tout petits et on y fait pas attention, mais si on regarde vraiment les textes d'interface, et notamment si on ouvre la capture en taille réelle, ben les textes sont tout aussi horribles). Et je ne vais sûrement pas m'avancer à juger le rendu des polices de ce logiciel basé sur une capture d'écran. C'est normal, les captures d'écran sont presque toujours des JPEGs avec grosse compression et un rendu très mauvais car on veut pas des images qui font plusieurs MB pour juste montrer une interface (sauf bien sûr dans le cas particulier où le but particulier était de montrer un changement de rendu de fontes, ce qui n'est évidemment pas le cas ni dans les captures de GIMP ni dans celles de Davinci que tu montres). Cette remarque sur le rendu de fontes n'est donc absolument pas pertinente.

Quant au choix, c'est pareil. Il n'y a aucun choix de fontes pour l'interface dans GIMP. Ça utilise ce que ton système dit d'utiliser (hormis si tu as un thème qui sélectionne une police particulière, ce qui n'est bien sûr pas le cas des thèmes par défaut de GIMP).

Voilà en tous cas, merci des remarques. Parmi celles-ci, celles sur le titre et la référence au calque en cours de modification me semble les plus pertinentes (et je vais probablement revoir un peu ces parties là dans les jours à venir car dernièrement je suis en pleine modification des concepts de sélection de calques; quand je toucherai ces parties, je garderai en mémoire cet échange). Pour le reste, je suis soit dubitatif, soit j'ai juste envie de répéter qu'on accepte les contributeurs avec grand plaisir, notamment pour ce qui est des designs d'icône et pour le thème qui sont deux sujets toujours très problématiques chez nous et on serait heureux d'avoir des gens pour aider. 🙂

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

Salut,

Je comprends ce que tu dis, et c'est vrai que je suis de plus en plus sensible aux attaques et autres méchancetés. Alors effectivement je fais un peu Caliméro dernièrement. Je me suis fait la même remarque à moi-même avant ton commentaire.

En fait depuis que j'ai commencé à contribuer à GIMP (presque 8 ans maintenant), j'ai connu toutes sortes d'insultes, jusqu'à celles où on nous dit qu'on devrait aller mourir ou je ne sais quelle autre horreur (on en est pas arrivé aux menaces, c'est déjà ça, mais c'est pas loin). À une époque, j'ai même réfléchi à tout plaquer et abandonner le développement de GIMP ou de gros logiciels libres tout court.

Je crois que c'est un peu le lot des logiciels les plus connus, que ce soit GIMP, Firefox, Libre|OpenOffice, il y a une relation très amour-haine avec la communauté. Je crois qu'il faut s'y faire (ce qui ne veut pas dire que c'est acceptable socialement, mais probablement ça ne changera jamais) mais c'est pas facile.

Alors oui je m'en rends bien compte moi-même. Je suis un peu à fleur de peau sur certains trucs. Et c'est vrai que rmfx nous a pas non plus pissé dessus. C'était un commentaire plutôt soft, et j'ai d'ailleurs hésité avant de faire ma réponse. Mais pourquoi faut-il que sur plein de news ou forums de GIMP, on retrouve toujours quelqu'un pour nous dire que Krita c'est mieux. Je parle pas d'un article dont le but est un test comparatif fait de manière juste et détaillé par exemple (un peu comme la série comparatifs de logiciels de montage par Funix, très intéressante). Ça c'est cool. Et si c'est fait le plus objectivement possible, alors je lirai avec plaisir un tel article sur les logiciels de dessin/retouche libres par exemple. C'est juste le coup du "je viens squatter un article sur GIMP pour faire la pub de Krita en balançant juste un 'Krita c'est mieux' sans plus de profondeur" qui m'énerve.

Donc oui, rmfx, c'est vrai, tu as un peu pris pour tous les autres, une goutte d'eau d'exaspération qui a fait déborder le vase, j'avoue. Et je m'en excuse car ton commentaire n'est pas non plus insultant, juste exaspérant. 😉
J'espère que de ton côté, tu réfléchiras aussi à 2 fois la prochaine fois avant de sortir une remarque absolue comme ça à des gens qui font vraiment leur possible pour faire un truc bien, avec passion, et que tu comprends que ça n'est pas du tout agréable.

Et ok, pour le commentaire sur "normal map". Je crois que ce n'est pas encore traduit dans GIMP, et j'ai aucune idée comment ça sera traduit (je m'occupe pas du tout de ça) et je ne me rappelle plus si c'est moi qui ai traduit ça dans cet article ou un des autres rédacteurs, mais qu'importe. Je note toutefois que sur Wikipedia, ils traduisent aussi cela en "carte de normales", et que les développeurs de G'MIC — chercheurs d'un pôle Image du CNRS — ne semblent aussi avoir aucun problème avec cette traduction. Donc même si ce n'est peut-être pas la seule traduction possible (si je comprends, tu préfères "texture de normales" et oui je vois la logique sémantique aussi), je ne pense pas que ce soit faux à 100%.

De toutes façons, on n'utilise que les termes en anglais de notre côté, c'est pourquoi je m'attarde pas trop sur les traductions. Mais sur linuxfr, les admins aiment bien franciser un max (ce que je comprends très bien d'ailleurs).

Ton histoire lors de ta première rencontre avec Krita, si elle est intéressante, est fort subjective. Je n'y étais pas, donc je ne peux pas dire ce qui s'y est dit ou ce qui a été fait. Mais je n'ai que ta parole. J'aimerai bien avoir le point de vue de gens qui y étais.

Juste pour préciser, je n'ai absolument aucun problème avec Krita. Et même les gens qui m'ont fait des remarques inappropriés sur GIMP à l'époque, je n'ai pas de problème avec eux. De l'eau a coulé sous les ponts (c'était y a 7 ans!), et il me semble que ces personnes aussi ont bien évolué. Et pis ils font tous un super boulot, il n'y a rien à redire. Avec le recul, je mets cela sur de la maladresse malheureuse pour promouvoir le logiciel.
Mon histoire, c'était surtout histoire de dire qu'on va beaucoup plus loin avec de la bienveillance.

On cite aussi régulièrement Krita aux gens qui veulent des infos sur les logiciels libres pour le graphisme (dans notre activité, cela arrive souvent).

Je crois que les contributeurs ont maintenant une bien meilleure communication. Malheureusement il semblerait que la communauté du logiciel ait encore cette fâcheuse habitude de visiter les forums et articles de GIMP pour lancer des commentaires désobligeants. C'est juste très dommage et fatigant à la longue.

Les comparaisons entre logiciels, qu'elles soient flatteuses ou non, c'est aussi un bon moyen de créer de l'émulation et de progresser. Un exemple dans un autre domaine : GCC. Avant l'arrivée de LVM, c'était un truc où la marche pour contribuer avait la hauteur d'un immeuble de 50 étages, les messages d'erreur de 40km parce qu'on a oublié un ;, etc… LVM est arrivé. Architecture modulaire, claire. Message d'erreur concis. GCC s'est amélioré (enfin !).

Pour info, je n'ai rien contre les comparaisons bien faites et détaillées, comme dit plus haut. Bon ensuite bien sûr, y a la manière de les faire, un article qui conclurait en "gcc sux" et parsemé de commentaires désobligeants ne serait pas intéressant. Mais oui un article qui dit que pour cette fonctionnalité GCC fait ainsi alors que LLVM/Clang fait cela, et pourquoi on pense que ce que fait LLVM est mieux (tout en prenant aussi en compte objectivement les bons côtés de GCC), c'est définitivement intéressant.

GIMP aussi a bénéficié de comparaison avec Krita. J'ai implémenté la peinture en miroir après avoir testé cette fonctionnalité dans Krita et l'avoir trouvée très intéressante. Je n'ai aucun problème à le dire haut et fort. Ils font plein de trucs très bien dans Krita.

C'est ça une comparaison constructive: apprendre ce que les autres font mieux ou différemment pour améliorer les autres projets, ce qui s'est aussi passé avec GCC comme tu le dis bien, tester, réfléchir, complimenter même… Pas un jugement négatif à l'emporte pièce sur l'article qui parle d'un autre logiciel pour faire de la pub pour celui qu'on préfère (ça n'apporte rien).

Et quand je lis la réponse que tu as faite quant à l'existence de Glimpse sur LinuxFR, je te prie de me pardonner, mais j'ai l'impression que c'est un peu l'hôpital qui se fout de la charité, à attaquer sur ci, sur ça, sur le choix de faire leur GUI, etc…

Est-ce que tu as cliqué sur le petit bouton [^] pour voir le commentaire parent du mien que tu cites dans ton lien? Voici le lien du commentaire parent du mien.

On y lit, entre autres:

Du coup est-ce que Jehan, pourrait nous dire si ces auteurs l'ont contacté et si les modifications qu'ils proposaient n'étaient pas compatible avec le développement de Gimp ?

J'ai été explicitement nommé et appelé à commenter. Ce que j'ai donc fait. Donc comparer ceci à cela, c'est tiré par les cheveux.

Et puis, ce fork a ceci de spécial que souvent leur communication est de dire qu'ils qu'ils font mieux et que notre développement est au point mort. Forcément ça me fait réagir aussi (même si je devrais pas, et la plupart du temps, je me retiens quand même).

Mais tu ne me verras jamais faire un commentaire désobligeant sur Krita sous un article Krita. Et si Glimpse fait des articles sur leurs sorties et possiblement sur des nouveautés apportées (idéalement sans dire du mal de GIMP), je vais pas aller commenter pour dire du mal en dessous non plus.

La conclusion, c'est que oui je suis un peu un bisounours. Je sais que pour certains, c'est une insulte (d'être un bisounours) mais j'accepte celle-ci. Oui j'aime pas me battre, et j'aimerais juste faire ce que j'aime sans avoir de remarques ou d'évènements fâcheux sans arrêt. Je rêve que tous les logiciels libres prospèrent, que ce soit GIMP ou Krita, GCC ou LLVM (citez vos préférés!)…

Et je vais faire un effort pour moins être à fleur de peau et davantage ignorer les commentaires désobligeants ou exaspérants ou troll ou tout autre variante négative. 🙂

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

C'est absolument dans les cartons. En général, on dit qu'on va faire ça pour GIMP 3.2 (en fait on place cette fonctionnalité comme la fonctionnalité majeure qui ferait GIMP 3.2). Mais en fait, rien n'interdit que ça arrive avant. Des fois, je me dis que c'est juste ridicule de devoir attendre la version 3.2 et qu'il faudrait juste que je prenne quelques semaines à faire que ça, et basta. Ça pourrait alors être dans GIMP 3.0. Techniquement on a maintenant tout ce qu'il faut en base d'infrastructure. Il faut juste faire les derniers pas (qui sont parfois les plus longs), ainsi bien sûr que l'interface. Mais bon j'ai aussi tellement d'autres trucs qui sont plus prioritaires pour nous personnellement.

Peut-être que quelqu'un d'autre implémentera ça avant moi, de toutes façons. En tous cas, j'aimerais bien (comme j'ai dit, on manque pas de trucs à faire! Je me bats pas pour être le premier à implémenter quelque chose).

En outre, un truc sur lequel j'ai beaucoup réfléchi, c'est: et si on allait plus loin que des calques d'effet? Et si on avait une interface en graphe (les fameux nodes dans Blender et d'autres logiciels, surtout 3D)? On aurait soudain une telle puissance à sa disposition!
Idéalement , je pense qu'il faudrait 2 interfaces. On devrait garder l'arbre à calque (qui est un graphe déjà, mais on en masque la complexité) comme GUI par défaut qui marcherait de toutes façons dans la plupart des cas classiques, mais il devrait être possible de passer en une interface en graphe qui permettrait alors de faire bien plus et/ou avec une visualisation plus adéquate, notamment pour les effets qui peuvent avoir plusieurs entrées (ou plusieurs sorties), et pour aisément réutiliser des nœuds ou des calques, et visualiser tout cela correctement. Etc.

Enfin bon, cela fait partie de mes petits rêves fous.

En tous cas, ça arrivera, oui. C'est un de nos projets majeurs.

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

GIMP n'a plus vraiment de statut de référence depuis que Krita se révèle plus attractif pour beaucoup de gens.

J'ai hésité à répondre. En général, j'essaie de juste ignorer ces remarques qu'on trouve sur des news GIMP pour dénigrer ce dernier et faire la pub pour Krita. Mais bon allez, je nourris le troll.

Très clairement, je n'ai rien contre Krita, je leur souhaite tout le bien du monde. C'est un logiciel libre, déjà et ils font leur truc, c'est bien. Mais je comprendrais jamais pourquoi il faut toujours que dans un article parlant de GIMP, il faut absolument que quelqu'un vienne pour cracher sur GIMP et dire que Krita est mieux (on trouve la même chose dans des forums de GIMP, à croire que certains se font un plaisir de fureter sur un site de logiciel qu'ils n'aiment pas juste pour repérer les endroits où ils peuvent faire une remarque déplaisante; si bizarre comme hobby…).

Est-ce qu'on voit la même chose sur les articles de Krita? Il me semble pas (et s'il y a la même chose, c'est pareil, c'est tout aussi nul de la part de ces personnes qui feraient ça dans l'autre sens, soit dit en passant).

Ma première découverte de Krita, c'était au Libre Graphics Meeting 2013 (mon premier LGM aussi). Je connaissais pas ce logiciel avant. J'ai vu une conf, c'était super intéressant, hormis la partie dénigrement de GIMP. Franchement quand on a découvert ce logiciel, au début on était super intéressés. Un logiciel focalisé peinture et libre? C'était idéal. On s'est direct inscrit puis nous sommes allés à l'atelier de dessin Krita, très excité d'en découvrir plus. Tout était cool, excepté le constant besoin de "dire du mal de GIMP". C'était un peu fatigant (surtout que clairement à cette époque, j'étais un petit nouveau, et les gens ne se doutaient pas que nous étions là comme invités de l'équipe GIMP, notre première année; ce qui n'excuse rien soit dit en passant).

Quel est ce besoin de certains projets ou de la communauté des dits projets de faire leur promotion en crachant sur les autres logiciels (et notamment sur le plus célèbre, un peu comme le cliché où pour se faire sa place, il faut repérer le chef de bande et aller direct le détruire)? Sincèrement moi tout ce que j'espère, c'est que GIMP autant que Krita continuent leur chemin et s'améliorent, aient du succès, etc. pour les années voire décennies à venir. Tous les deux, autant l'un que l'autre! Si ces deux logiciels pouvaient devenir des logiciels majeurs et référents du monde de l'infographie 2D, et être de plus en plus utilisés dans le milieu pro notamment, je serais super heureux. Pourquoi vouloir absolument mettre des bâtons dans les roues de l'autre? Pourquoi vouloir aller polluer les articles qui parlent de l'autre logiciel pour dire que celui qu'on a choisi est mieux?
Aux dernières nouvelles, ce sont juste deux logiciels qui font clairement tous les deux des choses biens, parfois différemment (bon déjà Krita veut se focaliser sur la partie illustration, même si plus ça va, plus j'ai l'impression qu'ils se diversifient). Et je suis sûr que pour certains trucs, l'un fait clairement des choses mieux, mais pour d'autres trucs, c'est l'inverse. Il n'y a de toutes façons pas besoin d'aller faire sa pub et une comparaison absolue sur les articles ou forums des autres.

Quoiqu'il en soit, la conclusion de ma toute première rencontre avec Krita en 2013, c'est qu'au début, on était super intéressés, et j'étais prêt à bondir sur mon terminal, le soir venu, pour télécharger le dépôt de source, tester Krita et probablement donc devenir un contributeur de code de Krita si on avait le moindre besoin (comme ce qui s'est passé avec GIMP). À l'époque, j'avais à peine quelques dizaines de commits dans GIMP, je n'avais pas forcément prévu de devenir un contributeur de longue durée, le projet ZeMarmot n'existait pas (pas même en idée lointaine) et je faisais déjà des patchs dans divers projets de ci de là. Sauter sur un autre projet plus adapté ne nous auraient posé aucun problème. Sauf qu'en fin de journée, après avoir essuyé tout plein de remarques méchantes sur GIMP par les contributeurs de Krita… ben j'avais juste plus envie. Je n'ai donc pas téléchargé les sources, et n'y ai jamais contribué. Fin de l'histoire.

Si y a bien des trucs que j'aime pas, c'est la méchanceté et le dénigrement. Il y a d'autres moyens de faire valoir ses propres qualités qu'en écrasant autrui. C'est bête car l'histoire (la mienne déjà, de même que celle de ZeMarmot, mais aussi celles de Krita et GIMP; sans dire qu'on aurait totalement tout chamboulé, on a tout de même eu notre petite place dans le Libre avec des contributions non négligeables) aurait pu être tout autre si seulement les gens qui nous avaient présenté Krita avaient été bienveillants plutôt que mesquins.

Conclusion: tu préfères Krita, très bien. C'est un très bon logiciel, tu fais bien de l'aimer. Et si un jour tu fais un article sur Krita… sache que je ne viendrais pas en commentaire dire que GIMP, c'est mieux. Tu peux en être assuré. C'est ma façon de montrer mon respect envers le travail des développeurs de Krita. Je dirais même plus: si jamais je faisais un commentaire, il y a plutôt de fortes chances qu'il soit laudatif, par exemple parce que je suis impressionné par une superbe fonctionnalité qu'ils viennent d'implémenter ou pour les féliciter de quelque chose. Mais pas pour dire "ah nous on fait mieux".

Un minimum de respect du travail des autres serait appréciable, et ça ferait sûrement du monde un endroit meilleur (un tout petit peu au moins).

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

C'est parce que tu penses que ce sont des fichiers textes. Beaucoup de fichiers dans Linux ne sont pas des données stockées. Ce sont en fait des interfaces pour communiquer avec le noyau (une API). Tu as peut-être entendu parler de la fameuse philosophie "tout est fichier" avec Linux; cela ne veut pas dire que les logiciels ont des fichiers de configuration en texte ou quelque chose du genre comme certains croient souvent. C'est que les intéractions peuvent se faire aussi simplement que de la manipulation de fichiers. Mais cela reste des interfaces et ce qu'on y écrit peut être différent de ce qu'on y lit. Dans le cas de ce fichier trigger dans l'API "leds", c'est l'équivalent de 2 functions: en lisant le contenu, c'est une fonction de listing des options et aussi qui indique quelle est l'option actuellement sélectionnée; en écriture, c'est une fonction de sélection d'option.

Petite démo, si je regarde mon ordinateur, qui a un clavier rétro-éclairable:

$ cat /sys/class/leds/tpacpi::kbd_backlight/trigger
[none] usb-gadget usb-host rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock AC-online BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid disk-activity disk-read disk-write ide-disk mtd nand-disk panic wacom_battery_0-online rfkill-any rfkill-none audio-mute audio-micmute rfkill0 rfkill1 rfkill2 bluetooth-power hci0-power rfkill3 phy0rx phy0tx phy0assoc phy0radio rfkill4
$ echo audio-mute >| /sys/class/leds/tpacpi::kbd_backlight/trigger
$ cat /sys/class/leds/tpacpi::kbd_backlight/trigger
none usb-gadget usb-host rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock AC-online BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid disk-activity disk-read disk-write ide-disk mtd nand-disk panic wacom_battery_0-online rfkill-any rfkill-none [audio-mute] audio-micmute rfkill0 rfkill1 rfkill2 bluetooth-power hci0-power rfkill3 phy0rx phy0tx phy0assoc phy0radio rfkill4

Comme tu le vois, quand je lis à nouveau le fichier, il affiche toujours la liste des triggers, par contre maintenant les crochets sont autour de [audio-mute] pour indiquer que c'est l'option sélectionnée. Et maintenant mon clavier s'éclaire quand je coupe le son, ce qui bien entendu ne me sert à rien et je vais donc m'empresser d'annuler cela. Ahahah. 🤣

En cherchant sur le web, tu peux aisément trouver les diverses interfaces fichiers pour communiquer avec le noyau. Pour l'interface LED par exemple: https://www.kernel.org/doc/Documentation/leds/leds-class.txt

En dehors de /sys/, Il existe de nombreuses autres interfaces sous Linux, par exemple dans /proc/, tu as notamment l'ensemble des processus qui tournent (si tu veux faire un logiciel comme top ou ps, c'est à ça que tu dois t'intéresser), ou /dev/ pour les périphériques, etc.

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

P.S.: dans le logiciel libre aussi, parfois on ne poste pas le code immédiatement. Je viens de finalement pousser 2 mois de travail sur une grosse fonctionnalité en cours (sélection multiple des calques, des milliers de lignes de code d'un coup) sur laquelle je travaillais seul jusque là. En fait je pense que c'est ce que je vais faire maintenant avec Linuxfr, plutôt que construire l'article de rien avec tout le monde.

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

La problématique pour un auteur de voir son texte édité comme s'il s'agissait d'un logiciel.

Il n'y a absolument aucune différence avec un logiciel. Je peux t'assurer (vous assurer? J'ai tendance à tutoyer sur linuxfr! Préférez-vous le vouvoiement?) que si on me fait des remarques mal placées sur mon code, cela finit pareil. Ce n'est pas le fait de faire une remarque, mais comment elle est faite et sûrement aussi sur quoi elle porte.

Par exemple, si tu t'évertues à dépenser du temps et de l'énergie à faire une super fonctionnalité mais t'as quelqu'un qui vient et marche sur les plates-bandes sans rien comprendre et dit "mais ça sert à rien, hop poubelle" sans explication adéquate, tu seras pas content. J'ai une telle expérience notamment avec un gars qui nous aidait au design de GIMP (il était là avant que je contribue) mais il voulait tout contrôler et disait qu'aucune nouvelle fonctionnalité d'UI ne pouvait rentrer sans passer par lui d'abord (alors qu'il était devenu très peu actif depuis des années, donc clairement ce fut une période très sèche en nouvelles fonctionnalités excitantes, comme on l'imagine). À l'époque, j'étais encore un petit jeunot dans le projet, donc je disais rien. Un jour, quelqu'un a contribué une superbe fonctionnalité. Il représentait un groupe d'étudiants (en Inde, si je me souviens), et ils avaient implémenté la recherche d'action (une barre de recherche où on peut taper des mots clés pour retrouver des filtres, des outils, des actions, un peu tout, sans avoir à passer par les menus). C'est vraiment une fonctionnalité géniale et depuis son inclusion dans GIMP 2.10, je lis régulièrement cette fonctionnalité dans le top-10 des nouvelles fonctionnalités préférées des gens tellement c'est pratique (j'utilise ça tout le temps moi-même). Bien sûr, ce n'était pas passé par notre designer, mais c'est ça aussi le logiciel libre, parfois on reçoit des patchs inattendus et géniaux. Et puis c'était tellement utile que je ne pensais pas que ça ferait le moindre problème (tout le monde était d'accord). Bon bien sûr, le code n'était pas extra-ordinaire, c'était des étudiants, c'est normal. Au début on échangeait un peu avec l'étudiant à qui on faisait des revues de code et qui faisait quelques changements. Au bout d'un moment, je me suis lancé moi-même dans une large revue-correction, j'ai nettoyé le code, ai restructuré énormément toute la logique, l'ai améliorée, ai changé des comportements et ajouté des fonctionnalités. J'y ai passé des jours. À la fin c'était plus juste une bonne idée à l'état de prototype, mais une superbe fonctionnalité, stable et bien implémentée.
On se dit qu'il faut quand même passer par le designer. Dans mon esprit, je me dis qu'il va faire des remarques, des propositions, peut-être même ne pas aimer certaines choses et proposer des changements, et notamment faire une spécification écrite. C'est le jeu et ça me va bien, je changerai ce qu'il faut. Après plusieurs relances et des jours d'attente, il commence finalement à répondre en disant des trucs peu appropriés, genre que ça le rendait malade, puis il pose des questions sur la cible et d'autres trucs auxquels on essaie de répondre. Il dit beaucoup de choses qui me paraissent totalement inappropriés. Il y a dû y avoir une dizaine de personnes qui a intervenu dans la discussion et personne ne comprenait son problème avec cette nouvelle fonctionnalité (moi je soupçonne que c'est juste qu'on n'est pas passé par lui d'abord, ce qui était impossible par concept — code drop inhérent au système du logiciel libre, je le rappelle — et qu'il bloquait par égo).
Au final, le mainteneur a dû intervenir et a dit que ça rentrait dans GIMP, et puis c'est tout.

En tous les cas, ce fut une expérience particulièrement peu plaisante (pour cette personne aussi puisque ce fut son dernier échange technique avec nous, puis il a annoncé son départ quelques mois plus tard; j'en étais heureux!).

Dans mes années de code, j'en ai d'autres des histoires de commentaires déplaisants. Ça fait tout aussi désagréable que ce soit du code ou du texte. Ce n'est pas à propos de la revue ou de l'action d'autres personnes sur son œuvre. C'est comment c'est fait, pour quelles raisons, etc.

Parce qu'en parallèle, des gens qui ont touché mon code (ou mes textes), parfois très en profondeurs, y en a aussi plein des histoires et j'en suis très content. De grosses fonctionnalités ont été très largement réorganisée en un code de meilleure qualité et plus efficaces par d'autres, et quand j'ai vu le résultat, je me suis dit "waw c'est génial". C'est ça de bosser à plusieurs, on se complète, on améliore les idées et implémentations des autres. On peut aussi faire des commentaires ou être en désaccord. J'ai plein de code qui est sorti très différemment de ma proposition d'origine après revue de code. J'ai même des cas de changements qui au final furent refusés, et je comprenais la raison et l'ai accepté (même si j'étais un peu triste, c'était fait de manière tout à fait saine).

En parallèle, j'ai beaucoup apprécié l'écriture collaborative sur linuxfr. Y a des gens qui ont repéré les erreurs de français (orthographe, grammaire…), ceux qui ont francisé des choses (supporter → prendre en charge !), ceux qui ont rajouté des nouvelles idées intéressantes auxquelles je n'avais pas initialement pensées et avaient toute leur place dans l'article, ceux qui faisaient des commentaires constructifs ou qui proposaient de changer certaines tournures ou paragraphes, ceux qui aident à écrire, ceux aident à la traduction. Il y avait même ceux qui proposaient de supprimer des parties en donnant un argumentaire compréhensible et sur lequel on pouvait discuter.
Par contre, il y a aussi eu les mauvaises expériences (j'en ai eu quelques unes dernièrement sur linuxfr), de ceux qui mettent ça sur le plan personnel et commencent à t'accuser de trucs, ou qui veulent complètement changer l'esprit de ton article sans raison valable.
Le texte aussi a ses revues d'ailleurs dans le milieu professionnel. C'est notamment le rôle de l'éditeur pour un texte publié. Et s'il fait bien son boulot, ce dernier peut faire des remarques, parfois même de fond, mais de façon totalement approprié, compréhensible et qui peut être une base de discussion (puis finir ou non en changements).

Donc non, il faut arrêter de vouloir voir des différences entre le texte et le code. J'écris des choses auxquelles je tiens dans les 2 cas, j'ai mon nom attaché à ce que j'ai écrit dans les 2 cas. Et dans les 2 cas, j'apprécie (et même souhaite!) des remarques et de l'aide constructives… et les remarques/aide destructives me font souffrir dans les 2 cas. Aucune différence.

Je sais que certains voient les choses techniques comme un truc froid et détaché, mais dans la vraie vie, ceux qui font ça avec passion du moins, ils aiment leurs œuvres techniques aussi et y sont très attachés.

En conclusion:

Votre propos illustre encore la problématique. Si textes et logiciels partagent des points communs, les confondre et vouloir les traiter sans discrimination reste bien problématique.

Ce n'est pas du tout le problème. Le problème est de savoir travailler en groupe ou non. Clairement certains ne savent pas.
Une collaboration toxique n'est pas saine. Une remarque doit être constructive. Un changement majeur du travail d'autrui ne peut pas être fait à la légère. Et il ne faut pas mélanger les sentiments personnels avec une collaboration technique (le texte aussi est technique, même pour un roman), car à ce moment là, on touche aussi les autres personnellement et c'est là que ça fait mal.

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

Sommaire

• Commentaire de liens
• Pourquoi les studios passent à Blender
  • Le coût et le contrôle du développement
  • La dépendance
• Vive le logiciel libre!

Y a vraiment pas mal de choses à dire sur Blender et son histoire. Malheureusement je n'ai pas pu finir cette dépêche et l'ai laissée traîner dans l'espace de rédaction trop longtemps.

J'avais un peu perdu l'envie d'écrire cette dépêche, c'est pourquoi je l'avais laissée pourrir des mois (désolé pour ça!). La raison est que je n'étais pas d'accord avec certains édits, notamment quand on m'a retiré des paragraphes entier en me disant que c'était trop libriste, que ça diviserait les gens (notamment quand je parlais des problèmes du logiciel propriétaire, cf. plus bas dans mon commentaire) ou que sais-je encore (je ne me souviens plus des termes exacts). Si on ne peut même plus faire des articles d'opinion sur le Libre sur linuxfr.org, c'est un peu triste… ;-(
Alors je me contente de rajouter certains liens et réflexions en commentaire ci-dessous. J'avais encore d'autres sujet dont je voulais discuter, je pense, mais ça fait tellement longtemps que c'est sûrement perdu au fond de ma mémoire.

Commentaire de liens

Déjà 2 liens que j'aurais donc voulu commenter un peu plus:

• Un article sur le studio Khara (producteur du film Evangelion à venir): https://www.blender.org/user-stories/japanese-anime-studio-khara-moving-to-blender/

Ils parlent notamment du coût (problème des licences très chères des logiciels propriétaires, surtout pour des petits studios avec de multiples postes), mais aussi et surtout du fait que non seulement ils ne perdent aucune fonctionnalité nécessaire en passant à Blender, mais surtout que "Grease Pencil" a été un gros facteur de choix car Blender est le seul outil 3D à proposer un tel outil qui leur permet de dessiner en 3D comme dans un logiciel 2D et d'ajouter très facilement des détails. Donc ils disent que cela améliore la productivité et en ont fait leur outil de travail principal.

• Un petit essai sur le fait que "Blender est un logiciel libre" par Ton Roosendaal (le développeur originel de Blender et toujours à la tête de la Fondation Blender): https://code.blender.org/2019/06/blender-is-free-software/

Cela avait originellement démarré comme un fil twitter d'une dizaine de message qu'il a ensuite converti en blog post (je vous épargne le lien twitter, mais il est aisé à retrouver; c'est globalement le même texte de toutes façons).
C'est très intéressant car il indique clairement sa préférence du logiciel libre par rapport à l'open source et pourquoi cela compte. Clairement un texte que j'aurais pu écrire car je m'y retrouve complètement (et mes propres développement suivent une philosophie similaire). Notamment quand Ton dit que pour lui le logiciel libre est un moyen et non un but. C'est quelque chose que je répète aussi (exactement avec les mêmes mots d'ailleurs) depuis des années, inlassablement. Les gens ne semblent jamais vraiment accrocher à ce que cela signifie et pourtant c'est un des points principaux de ma philosophie. Qu'est-ce que ça veut dire que le LL est un moyen? Ça ne veut pas dire que cela ne compte pas. C'est l'inverse. Ça veut dire que le Logiciel Libre est pour moi tout simplement une évidence (aussi une phrase que je répète souvent!). C'est à dire que quand on fait quelque chose, le logiciel ne peut qu'être libre, tout simplement. Sinon on n'a aucun pouvoir sur ses propres outils. Et quand on n'a pas la main sur ses propres outils, alors on ne peut pas créer efficacement, voire du tout. C'est aussi un problème dans le monde du matériel de plus en plus d'ailleurs (on a tous lu ces articles sur les machines et tracteurs aux technologies propriétaires qu'on ne peut ou n'a plus le droit de réparer, etc. Il devient de plus en plus compliqué de produire quoi que ce soit).
Dans un monde idéal, le logiciel libre ne devrait pas exister et on ne devrait même pas avoir à se poser de questions sur les licences ou l'accès aux sources d'un logiciel. C'est ça ce que signifie que le logiciel libre doit être une évidence et le fait qu'il s'agit juste d'un moyen.

On voit là que pour une fois, ce n'est pas juste le "profit" ou le "marché" qui dirige un projet et c'est rafraîchissant.

Ça faisait partie des sujets que je voulais un peu développer dans cet article.

Pourquoi les studios passent à Blender

Le coût et le contrôle du développement

Je voulais aussi un peu parler du fait que de nombreux studios pensent à passer à Blender depuis des années (on avait visité quelques studios, il y a 2 ou 3 ans; notamment Cube, qui est depuis devenu un sponsor, en parlait déjà y a quelques années; de même que d'autres studios avec qui on a discuté). En général, la question des licences revient beaucoup comme une des raisons principales bien sûr. On trouve pas mal d'articles ou de dires sur le coût des licences de logiciels d'infographie pour un poste (c'est à dire par personne). On dit souvent qu'un poste professionnel coûte ainsi environ 10.000€ par an. C'est bien sûr une approximation, ça peut être moins ou plus, en fonction des logiciels utilisés et de leur nombre, etc. Mais cela donne une bonne idée du coût des logiciels propriétaires dans le milieu de l'infographie.

Maintenant imaginez juste une vingtaine de postes pour une production (ce serait une petite production, 20 personnes, c'est pas énorme, regardez n'importe quel générique de film), ça fait ~ 200.000€. Avec ça, on paye plus de 3 développeurs (j'utilise le coût de 5000€ par mois par développeur, estimation utilisée par la Blender Foundation). Donc imaginez si un studio peut économiser sur toutes ces licences en utilisant seulement des logiciels libres et utiliser cet argent pour faire évoluer le logiciel dans la direction qui leur convient (bien plus efficace que demander à un éditeur propriétaire car on contrôle directement le développement et qu'on fait jouer directement nos priorités sur les développeurs qu'on engage; donc aussi plus rapide, et moins coûteux). Même avec une production spartiate qui arriverait à payer moins de licence, ce raisonnement tient encore (même à 3 fois moins de licence, on peut payer bien 1 bon développeur à plein temps; et rien que ça, ça change tout).

La dépendance

Une autre raison est qu'on est forcément dépendant d'un éditeur de logiciel propriétaire. Cela inclue bien sûr la priorisation du développement, comme j'ai dit plus haut, mais y a aussi la concentration dans les mains de quelques gros acteurs.

Par exemple en 3D, historiquement 3DS Max et Maya étaient de gros concurrents… jusqu'à ce qu'Autodesk (développeur de 3DS Max) rachète Maya (et les autres logiciels du même éditeur). La concurrence est donc globalement absente dans les gros de la 3D propriétaire, ou du moins totalement superficielle (puisqu'on choisit entre des logiciels du même éditeur).

Puis il y a le problème de la disparition des logiciels. Bien sûr, il y a la possibilité d'un éditeur en faillite (ça peut toujours arriver, des fois, une entreprise peut avoir l'air en forme vue de l'extérieur sans pour autant l'être réellement). Puis il y a les choix de direction d'entreprise. Pour rester avec Autodesk, ils avaient fait parler d'eux par exemple en tuant Softimage, un autre logiciel 3D qu'ils avaient acheté d'Avid en 2008 et qui concurrençait aussi 3DS Max et Maya. D'ailleurs rien ne dit qu'un jour ils ne décideront pas de faire de même pour l'un des deux quand ils en auront assez de la redondance.

On connaît aussi tous la suite Adobe, très présent en infographie (bien que moins majoritaire dans la 3D même s'ils ont quelques logiciels). En info un peu plus proche temporellement, ils ont ainsi racheté Allegorithmic en 2019, une startup française qui commençait à faire parler d'elle pour la création de textures pour le travail de la 3D. Les articles qu'on trouve semblent tous excités de la nouvelle, suivant le communiqué de presse officiel (on se demande parfois s'ils font la moindre recherche ou réflexion propre), mais sur les réseaux sociaux et les forums divers et variés (là où voit vraiment les utilisateurs, professionnels et amateurs), c'est une toute autre histoire. Les gens sont globalement très mécontents. Ce sont les mêmes problèmes qui reviennent, notamment celui des licences. Allegorithmic avait une licence à vie; dans leur annonce, ils disent "When it comes to licensing, nothing changes for now. […] As we join the Adobe family, we will also unveil new and more flexible subscription offers in the coming months", et en effet quand on vérifie, leurs produits sont maintenant louable à inscription mensuelle, plus en licence perpétuelle. Puis bien sûr, il y a la peur de voir le produit disparaître à terme, comme tant d'autres logiciels rachetés.

Voilà, c'est donc le problème de ces logiciels. On est à la merci des éditeurs et de leurs sautes d'humeur et on n'a aucun contrôle sur leur devenir. Et c'est clairement une des raisons du succès de Blender ces dernières années. Les gens du milieu sont clairement de plus en plus mécontents des logiciels propriétaires au fil des années. C'est vrai pour la 3D comme pour la 2D d'ailleurs. Aryeom (réalisatrice de notre projet que vous connaissez ici, ZeMarmot) donne quelques cours de retouche/restauration numérique et d'illustration avec GIMP à l'université depuis 2 années maintenant (on est venu la chercher, ce n'était même pas prévu), et les étudiants (une classe de 3D/patrimoine et une classe infographie), de même que le directeur de la licence, en sont super contents. Je pense qu'on est en train de vivre un transfert des forces depuis quelques temps, et c'est bien!

Vive le logiciel libre!

Personnellement je vois un bel avenir pour le logiciel libre dans le milieu infographie (un milieu qui était problématique il y a encore quelques années). 🙂

Voilà pour mon petit commentaire additionnel. Désolé pour les familles tout ça si ça parle trop de Libre ou que ça divise ou je ne sais quoi encore! Là je suis dans mon propre commentaire, donc je me permets même de faire du zèle par rapport à si j'avais écrit la même chose en 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 ]

Je confirme que de notre côté aussi, on a du mal avec les éditeurs vidéos libres. Utilisateurs de Blender (pour la partie édition vidéo principalement) depuis des années, on garde néanmoins un œil sur les autres logiciels. Ces dernières années, ce fut Kdenlive qui nous a beaucoup attiré car ils ont un développement très actif et une bonne communication. En outre on a rencontré et beaucoup parlé avec des contributeurs lors des Libre Graphics Meeting (c'est d'ailleurs nous qui les avons mis en relation avec le Carrefour Numérique à la Cité des Sciences à Paris pour leur dév sprint en 2018).

En fin d'année dernière, Aryeom (la réalisatrice de ZeMarmot) a d'ailleurs passé 1 à 2 mois à tester Kdenlive extensivement. Au final elle est revenue à Blender un peu dépitée. Je ne sais plus le détail, mais Kdenlive n'était malheureusement pas au niveau pour nos besoins. Ensuite soyons très clair: elle souffre aussi beaucoup avec Blender (juste un peu moins, on va dire). Malheureusement il ne semble pas encore y avoir de vrai leader pour l'édition vidéo libre. 😕

Je ne saurais plus dire tous les problèmes, mais dans les trucs dont je me rappelle au fur et à mesure des années, y avait pas mal de problèmes avec les séquences d'image (dans l'animation, on travaille bien sûr principalement avec des séquences d'image). Je crois que les plus bloquants ont été corrigés ces dernières années. Y a aussi des choix étranges comme celui de redimensionner les images et clips aux dimensions du projet par défaut (ce qui n'est pas acceptable pour contrôler la qualité du rendu; c'est à nous de décider si on veut redimensionner quelque chose; et on peut tout à fait vouloir utiliser une image ou un clip avec une dimension particulière exprès).

Ensuite on est conscient qu'en animation, on a des besoins particuliers (travailler plus avec des séquences d'images que des clips vidéos notamment).

Enfin bon, on continue à garder un œil sur les divers projets. Mais je dois avouer que mon plus gros espoir serait en fait que notre projet soit un jour suffisamment financé pour qu'on puisse engager quelqu'un à plein temps pour contribuer au logiciel de montage de notre choix. C'est ce qu'on a fait pour GIMP et c'est ce qui marche le mieux, plutôt que d'attendre indéfiniment que quelqu'un veuille bien faire avancer les choses dans notre sens. C'est comme ça que le logiciel libre peut évoluer.

Comme toi, je félicite clairement les dévs actuels de tout leur super travail, et je comprends tout à fait que chacun a ses priorités. 🙂

Et ce n'est pas l'impression que me donnent d'autres alternatives libres à Adobe, comme Gimp, Scribus, Inkscape ou Darktable, que j'utilise beaucoup sous Linux dans mon travail ou en dehors. Leur développement m'a toujours paru suivre une logique de progression en phase avec ma pratique.

En tant que dév de GIMP, ça fait plaisir de lire cela. ;-)

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

Je suis pas du tout fan du tout de la megabar (en fait je comprends pas ce qu'elle change hormis devenir plus grosse quand activée), ou de pas mal de changements des dernières années (barre de recherche et barre d'adresse tout-en-une 😢 avec des logiques où les gens ne comprennent plus les concepts d'adresse web, jusqu'à faire disparaître le protocole ou faire des recherches par défaut si on fait une erreur dans l'adresse; je connais des gens qui ont leur propre nom de domaine et qui continuent à aller sur leur site web en passant par un moteur de recherche!).

Néanmoins l'explication donnée est tout à fait compréhensible, du point de vue développement. Avoir plein d'options, dont certaines peu utilisées, est un appât à bug et régressions car on va moins tester ces cas optionnels ou certaines combinaisons spécifiques (des bugs lorsque plusieurs options spécifiques sont activés). Plus il y a d'options, plus les combinaisons à tester explosent, c'est mathématique.

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

Ah bah ça c'est une bonne nouvelle (pour une fois, y en a peu dernièrement)!

Par contre la conclusion est un peu triste, comme quoi ils ont peut-être juste abandonné par peur du parquet californien (contre la vente) qui pourrait décider d'enquêter. Cela sous-tend de la corruption interne et ils étaient juste effrayés que cela soit découvert si enquête.

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