Nous avons la chance d’avoir quelques développeurs qui fréquentent LinuxFR.org, dont Jehan Pagès (Jehan) qui contribue à GIMP, le logiciel de retouche d’images que l’on ne présente plus et qui est en train de se faire beau en vue de la sortie de la version 2.10 (je parle du logiciel, pas de Jehan — quoique je ne sache pas précisément ce qu’est en train de faire Jehan à l’heure où je couche ces quelques lignes).
Jehan a accepté de répondre à quelques questions pour LinuxFr.org ; nous le remercions chaleureusement à la fois pour le temps consacré à cet entretien et pour son implication dans GIMP !
Bonjour, peux-tu te présenter en quelques mots ?
Je m’appelle Jehan. Ces dernières années, je me suis principalement défini comme un « vagabond » mais depuis environ un an, ce n’est plus vrai. Donc je ne sais plus trop comment me présenter autrement. Je suis un être humain. :-)
Comment définirais-tu ton rapport au logiciel libre, et comment es-tu entré en contact avec lui ?
J’étais dans une famille d’artistes, pour qui l’usage de l'ordinateur est très basique. À l’opposé donc du stéréotype du geek dont les parents sont eux-mêmes ingénieurs et qui a développé son premier logiciel à 7 ans en BASIC.
Mon premier contact avec un ordinateur fut en squattant l'Amiga de mon grand frère qui nous servait essentiellement de console de jeu, jusqu’à ce que l’alimentation crame (facilement réparable, mais on n’y connaissait rien, le vendeur de grande surface non plus et c’en est resté là : l’horreur de la société de consommation dans toute sa splendeur).
J’ai eu mon premier ordi au milieu du lycée, avec Windows, des logiciels crackés, et des jeux vidéos. En prépa j’ai rencontré un gars qui a contribué à changer ma vision de l’informatique. Il s’appelle Samuel (et fréquente LinuxFr.org sans commenter beaucoup, je crois qu’il en a marre des trolls !). Il me bassinait avec ce truc : « Linux ». Je pense que c’est la première fois que j’en entendais parler. Je ne devais même pas avoir idée qu’il existait autre chose que Windows sur PC (et Mac était juste une « autre sorte » d'ordi). Pendant un an, il m’a fait chier, mais j’ai tenu et lui disais d’arrêter de m’emmerder avec ça.
Plus tard, en fac d’info, tout était sous Linux. J’appelle Sam, je lui demande donc « un Linux ». Il me file un CD de Mandrake. J’avais le même vieil ordi depuis le lycée avec un petit disque, donc je vire Win et mets Mandrake en simple démarrage. Depuis je n’en suis pas revenu (enfin de GNU/Linux, pas de Mandrake bien sûr !). Et franchement je ne souhaite revenir à Windows comme OS principal pour rien au monde.
Avec le temps, j’ai découvert la philosophie derrière les Logiciels Libres. Et je pense que c’est ce qui m’a réellement conquis.
Au début, j’ai essayé de participer à quelques projets, avec plus ou moins de succès.
De nos jours mon rapport au LL est : si quelque chose ne me plaît pas ou est buggué, je fais un rapport de bug ; si mon rapport de bug n’a pas assez de priorité pour les développeurs, mais qu’il en a pour moi, je n’attends plus que quelqu’un le corrige. Je corrige moi-même et envoie upstream.
Quelles sont tes contributions à la future version 2.10 de GIMP ?
Déjà des contributions tierces, c’est-à-dire sur d'autres projets utilisés par GIMP (dépendances), qui ne sont pas aussi visibles, mais tout aussi importantes. En effet, des fois, les bugs qui sont rapportés viennent d’une bibliothèque tierce. Donc, on ouvre un rapport de bug sur l’autre projet. Or, suivant ma philosophie "je corrige quand j’en ai assez d’attendre les autres", il m’est régulièrement arrivé de faire un patch par-ci, par-là. J’ai ainsi contribué sur glib, GTK+, Pango, Exiv2, GExiv2, poppler, libmypaint, gettext, fontconfig, même autoconf et, bien sûr, à babl et GEGL. Et pour tous ces projets, mes patchs sont dûs au fait que je développe sur GIMP.
Pas forcément grand-chose, des fois juste des améliorations sur leurs systèmes de build. Par exemple, quand nous avons intégré GExiv2 dans GIMP, ce dernier avait un Makefile fait main et un pkg-config cassé. Je leur ai donc proposé un système de compilation à base d'autotools, ce qui a notamment permis de compiler GExiv2 pour Windows, sans même toucher à une seule ligne de code (un des développeurs m'a dit avoir été étonné, car il n’avait jamais vraiment pensé à Windows en développant jusque-là et n’avait pas la moindre idée que ce serait aussi simple de cross-compiler leur code).
Et puis l'une des corrections tierces dont je suis le plus content est dans GTK+. Jusqu'en 2013, quand on déconnectait sa tablette graphique, GIMP plantait. C'est tout con, mais c'est horripilant. La tablette est branchée en USB, et on sait tous qu'avec le câble qui se balade, ou un coup de main malencontreux, déconnecter un périphérique USB (même une micro-coupure pour un centième de seconde) n'est pas rare. Cela faisait planter tout logiciel qui gérait des tablettes sous GTK+ 2.0, car la prise en charge du branchement à chaud de périphérique n'est disponible qu'a partir de la version 3.0 de GTK+. Or, avec GIMP ou MyPaint (tous deux logiciels de dessin en GTK+2) les gens qui utilisent une tablette sont légions. Et je vous parle pas de l'horreur de perte de travail pour un peintre numérique qui ne pense pas à sauver régulièrement !
Je n'ai pas ajouté la prise en charge du branchement à chaud sous GTK+ 2 (qui n'accepte pas de nouvelles fonctionnalités, juste des correctifs), mais j'ai au moins permis de contourner le problème. Maintenant ça ne plante plus !
Ensuite GIMP à proprement parler, ce serait assez dur de lister toutes mes contributions. L'une d'elle est que je suis désormais le mainteneur du greffon de prévisualisation d'animation. Mon but est d'en faire un greffon et une UI bien plus élaborée qui permettra de faire autre chose que des GIF de chatons, mais même aussi d'utiliser GIMP pour faire de la vraie animation professionnelle. C'est un travail en cours que j'espère pouvoir présenter bientôt.
Sinon j'ai aussi fait passer GIMP aux normes des répertoires XDG, j'ai amélioré le système de migration d'une version de GIMP à l'autre, ainsi que plusieurs problèmes de localisation (l'ordre des menus pour suivre les normes d'un langage RTL, la détection du langage sous Windows, la localisation des noms de langage dans leur propre langage…), des améliorations des onglets (leur permettre d'être réordonnés, de les avoir à gauche, droite, en bas…), j'ai intégré le code d'un contributeur externe permettant d'avoir une boîte de recherche contextuelle d'action (similaire au « menu-espace » de Blender), aidé à l'intégration des brosses MyPaint comme outil GIMP, ajouté une compression zlib (plutôt que RLE jusque-là) interne dans le format XCF, etc.
Je suis aussi l'un des rares développeurs qui va parfois corriger des bugs pour Windows (j'utilise ma licence en vente-liée essentiellement pour GIMP, avec un Windows en VM). Donc j'ai corrigé plusieurs bugs spécifiques à GIMP sous win.
Et puis, bien sûr, pas mal de corrections de bugs, dont des crashs/plantages. C'est pour moi un des points les plus importants et pourtant des plus ingrats. Ingrat, car tout le monde se plaint des bugs, mais personne ne remercie jamais un développeur pour une correction de bug. Combien d'utilisateurs m'ont félicité pour la fonctionnalité de peinture en miroir ! Par contre, très peu pour la correction des crashs lors du débranchement de tablette. :/
Et pourtant, je pense que j'ai contribué à améliorer la vie de bien plus d'utilisateurs par cette correction que je ne le ferai jamais par la peinture en miroir !
Un logiciel instable (c'est-à-dire qui plante très souvent. Tout logiciel peut avoir des plantages inattendus tant qu'ils sont rares), aussi bien soit-il au niveau fonctionnalités, est mauvais. Aussi simple que ça.
Comment es-tu devenu développeur sur ce projet ?
Je suis arrivé en cours de 2.8. La première fois que j'ai montré GIMP à Aryeom, qui l'utilise maintenant quotidiennement, il n'était pas rare du tout de le voir se planter lamentablement. Donc j'ai décidé de corriger. Ce que j'ai fait.
Assez rapidement on m'a donné les droits en écriture car j'ai fourni plusieurs correctifs que Mitch, le mainteneur, a estimé de bonne qualité. Un jour, en juste 1 ou 2 mois, il m'a dit en substance : "tu me donnes trop de boulot, je te donne les droits sur le dépôt". Et c'est ainsi que je suis devenu un développeur GIMP.
Tu as fait une demande de financement par les utilisateurs pour développer la fonctionnalité « Peinture en miroir », quelle a été ta démarche ?
J'aimerais pouvoir développer plus de Logiciel Libre, c'est-à-dire être payé pour cela. Au LGM à Madrid, j'ai vu la fonctionnalité "peinture en miroir" sur Krita, et me suis dit que ce ne devait pas être trop compliqué. J'ai fait un prototype vite fait, puis un peu plus tard j'ai fait une vidéo, me disant que cela me motiverait pour la développer vraiment. En vrai je crois avoir choisi la mauvaise fonctionnalité (elle ne m'intéresse pas tant que ça. Je l'avais juste sous la main), et surtout ne pas avoir visé assez haut pour me donner envie de la faire rapidement.
Au final j'ai pris plusieurs jours sur 2/3 semaines vers mars pour l'implémenter. J'aime vraiment faire du beau code, le plus générique possible, avec une architecture solide. J'ai donc transformé le cœur logique pour la peinture dans GIMP pour qu'il soit "multi-point". Bien que par défaut, il n'y ait qu'un seul point (sous le pointeur), il est maintenant possible de peindre plusieurs points simultanément, selon toute transformation mathématique qui passe par la tête (permettant de transformer les coordonnées, mais aussi la brosse). Sur la base de ce nouveau cœur, j'ai ajouté un module de peinture en mirroir (par rapport à des axes), ainsi qu'une peinture en rotation (par rapport à un point), et une peinture en tuiles (par translations multiples).
Quelles sont les autres personnes derrière GIMP ?
GIMP est un des fanions du Libre, à n'en pas douter. Néanmoins contrairement (quoique…) à d'autres gros projets Libres, le projet GIMP a un problème de sous-effectif et une organisation bien plus informelle. Ainsi, là où beaucoup de projets se regroupent sous une fondation, une association, voire une société, GIMP n'a aucune entité officielle. Il n'y a pas non plus de marque GIMP. C'est un projet à la structure totalement informelle, comme le sont en général les projets libres de petite taille.
Pour tout ce qui nécessite un nom plus officiel, par exemple afin de recevoir des dons aisément, le projet GIMP est sous le parapluie de la fondation GNOME. Ainsi GNOME gère les finances de GIMP et héberge plusieurs de ses serveurs, ainsi que ses sources et son suivi de bugs. Néanmoins, le projet GIMP ne peut pas vraiment être considéré comme un projet GNOME. Il s'agit davantage d'une relation symbiotique où GNOME fait une faveur à un plus petit projet frère qui partage de nombreuses briques de base. Notamment, il est à rappeler que GTK+, le toolkit graphique à la base de GNOME, vient originellement du projet GIMP (GTK+ signifie « GIMP ToolKit »). Bien sûr, avec tant en commun, le projet GIMP suit de près les recommandations et évolutions GNOME, si possible, et les standards des bureaux Libres, tout en restant séparé. Ainsi GIMP n'a aucune dépendance à l'infrastructure GNOME (installer GIMP ne requiert pas l'environnement et le bureau GNOME) et est considéré comme indépendant.
GIMP a extrêmement peu de contributeurs actifs, en particulier pour un projet de cette taille. Ainsi, si on regarde les statistiques de contributions, on se rend compte qu'un unique contributeur, Michael Natterer (Mitch), a fait plus de 60 % des commits sur la dernière année, suivi de quelques contributeurs actifs mais bien moins productifs (comme moi, avec pourtant seulement 4% des commits, je suis le second développeur C si on regarde sur un an!) et enfin énormément de contributeurs avec des patchs uniques. Mitch est bien entendu le mainteneur du projet GIMP.
Néanmoins quand on considère GIMP, il faut dorénavant aussi prendre en compte GEGL et babl, briques désormais essentielles, dont Øyvind Kolås (Pippin) et Daniel Sabo sont les mainteneurs. Les trois projets ont bien entendu beaucoup de développeurs en commun, bien que certains se concentrent clairement plus d'un côté ou l'autre.
Beaucoup de contributeurs beaucoup moins actifs dorénavant au niveau du code restent impliqués pour les décisions ou communautairement. Michael Schumacher par exemple est clairement l'administrateur de GIMP, s'occupant de toute tâche administrative (comme la gestion financière, les relations publiques ou notre relation avec GNOME).
Il est aussi à noter qu'à l'heure actuelle, aucun développeur n'est payé pour améliorer GIMP, à notre connaissance, pas même indirectement (je ne parle pas de mini-financements ponctuels, mais de développeurs à temps plein ou partiel sur du long terme).
Les développeurs GIMP ont très peu de rencontres physiques (le principal point de rencontre est le canal irc #gimp sur irc.gimp.org). Néanmoins, l'un des évènements désormais phare du projet est le Libre Graphics Meeting, chaque année, pour lequel GIMP est un sponsor majeur (sponsoriser l'évènement et défrayer les contributeurs est quasiment la seule grande dépense annuelle du projet). C'est l'occasion pour les contributeurs principaux de GIMP de pouvoir se rencontrer chaque année, et discuter du projet de vive voix. GIMP fait venir des contributeurs du monde entier, pour certains depuis des zones aussi lointaines que le Brésil, Israël et la Nouvelle-Zélande.
Ci-dessous un aperçu d'une réunion de développeurs à l'université de Leipzig, en Allemagne, en mars 2014, lors de LGM 2014.
Puis à Montréal à l'université de Toronto, au Canada, pour LGM 2015:
Comment GIMP tire-t-il parti du Google Summer of Code ?
GIMP a été régulièrement un projet mentor du Google Summer of Code, mais l'an dernier, le projet n'a pas été accepté et cette année, je crois qu'on n'a même pas essayé (sauf erreur, puisque je n'ai pas suivi).
Je pense que GSoC est une contribution intéressante et, en même temps, il faut relativiser l'apport. En général les résultats ne sont pas de qualité adéquate pour finir immédiatement dans l'arbre de développement de GIMP et ce même si le projet étudiant est qualifié de « succès » (l'étudiant a bien travaillé et il serait injuste de le faire échouer, mais le résultat final n'est pas pour autant d'une qualité suffisante pour intégration immédiate). Dans tous les cas, il reste beaucoup de travail d'intégration, de revue et d'assurance qualité une fois les projets achevés, ce qui est surtout un problème quand les étudiants disparaissent une fois la récompense empochée, ce qui n'est pas si rare (ce n'est pas non plus un reproche. Les étudiants ne promettent pas de rester, même si c'est bien sûr le secret espoir d'un projet Libre).
Ainsi même les projets GSoC les plus éblouissants en démo vont prendre des mois, voire des années à être intégrés, pour atteindre le seuil de qualité adéquate.
Ensuite cela serait moins un problème s'il y avait beaucoup de développeurs permanents, ce qui permettrait de faire beaucoup plus de revues de code, mais comme je le disais, on est au final très peu sur GIMP.
Néanmoins, le Google Summer of Code reste un apport intéressant pour les projets. Cela apporte du sang frais et des fonctionnalités inédites. J'espère personnellement que nous serons de nouveau dans la liste des organisations mentor un jour.
GIMP n’a pas été retenu parmi les projets participants au GSoC cette année : sait-on comment s’opère la sélection ?
J'ai demandé aux autres développeurs, un jour, et ils savaient pas non plus a priori. Les critères de sélection sont non divulgués par Google, il me semble. Donc non, je sais pas. Si je devais m'aventurer à deviner, je dirais que GIMP perd un peu de son aura ces dernières années car on n'a pas assez de sorties (trop espacées). Donc de l'extérieur, le projet peut avoir l'air mort, ce qui n'est pas du tout le cas. Une autre raison possible serait que notre propre intérêt pour le GSoC s'est affaibli. Comme je disais plus haut, plusieurs développeurs ont vu les limites du programme Google, et aussi ont peut-être estimé que leur temps pouvait être mieux utilisé plutôt qu'encadrer des étudiants pour du code qu'on n'est pas sûr d'utiliser. En tous les cas, au final, on n'avait que deux mentors intéressés l'an dernier (moi notamment car je n'y avais jamais participé et que ça m'intéressait de voir l'envers du décor) et — sauf erreur — seulement un cette année (pas moi cette fois, je n'avais pas le temps).
Peut-être que Google a vu cela (nos listes de diffusion et discussions étant publiques), et a préféré donner du financement pour des projets plus à fond sur le programme ?
Depuis des années, GIMP possède un système de greffons (plug-ins) ayant permis de nombreuses contributions extérieures au projet. Avec l’arrivée de GEGL, comment vois-tu ce système de greffon évoluer ? Risque-t-on de perdre l’immense base de greffons existants ?
Dans GIMP 2.10, tout greffon qui marche en 2.8 est censé continuer à marcher. On reste dans la lignée de GIMP 2, donc la compatibilité est assurée. Si ce n'est pas le cas, alors il y a un bug, et dans ce cas faites-vous plaisir : remplissez des rapports de bug !
GIMP 3 par contre (future version majeure de GIMP qui suivra 2.10) pourra entraîner des changements d'API. Je ne suis pas certain lesquels, mais globalement je pense que les fonctions “dépréciées” à l'heure actuelle pourraient alors être retirées.
GEGL deviendra alors le moteur de GIMP pour tout ce qui touche aux données bitmap. Il est donc possible que certaines fonctions qui donnaient accès aux données bitmap à un autre niveau disparaissent dans GIMP 3.0. Mais ça ne voudra absolument pas dire que le développeur de greffons devra absolument passer par des nœuds GEGL pour modifier les images. Développer une opération GEGL est la voie préférée et conseillée dans lequel le projet GIMP se dirige à la place de greffons de type "filtres", mais les buffers GEGL ne sont pas des structures opaques, et sont accessibles aux greffons. Un développeur de greffons pourra tout à fait récupérer les données bitmap bruts, les modifier comme il faisait avant, puis les remettre dans le buffer. Il pourrait donc y avoir un peu de réécriture de code, mais rien d'insurmontable, et rien d'anormal pour un passage de version 2 à 3 ! Simplement ils ne pourront alors pas profiter de toutes les supers fonctionnalités permises par GEGL (visualisation directe sur le canvas, même partielle, édition non destructrice, création de graphes d'effets qui pourraient être réutilisés sur de multiples d'images sources, etc.).
Ensuite je ne suis pas le plus grand expert de GEGL chez GIMP (donc je peux dire des erreurs aussi), mais c'est ce qui ressort de ma petite expérience à manipuler l'API GEGL et parce que ce sont des choses que j'ai aussi demandées au mainteneur.
Par contre les thèmes qui utilisent des icônes fait-maison directement risquent d'être cassés car on utilise maintenant le standard des thèmes d’icônes. Mais bon ce n'est pas le pire des cassages.
Personnellement ce qui m'intéresse bien plus serait d'avoir une vraie plateforme de diffusion et de gestion des greffons. À l'heure actuelle, installer un greffon est manuel : on trouve un bout de code ou une archive sur le net, on l'installe dans le bon répertoire, éventuellement on se heurte à des problèmes de droit, etc. Sans compter que l'on ne sait en général pas quelle version on a installée, donc les mises à jour sont inexistantes. Au final, comme tu dis, on a une immense base de greffons, mais les gens en utilisent très peu. Il y en a quelques uns qui sont très connus comme G'MIC, grâce à une équipe de développement active, aussi bien pour le développement que la communication du projet.
Mais tous ces petits greffons de quelques lignes, adaptés à certains cas d'usage très particuliers et qui pourraient vraiment sauver la vie (du moins la simplifier grandement) à certaines catégories d'utilisateurs ? Ceux-là sont perdus dans le grand internet, quelque part sur un serveur qui peut disparaître demain sans que personne s'en rende compte.
Le projet GIMP a un dépôt où les gens peuvent déposer des plugins, mais totalement envahi par le spam et le flood, donc l'enregistrement de nouveaux comptes est fermé depuis plus d'un an, sans compter que l'UI générale laisse clairement à désirer. J'aimerais qu'on ait une vraie plateforme de greffons, avec laquelle les utilisateurs pourraient installer, retirer et mettre à jour un greffon depuis GIMP même, avec de la sécurité (vérifications de code automatique et par des humains si nécessaire), un système de versionnement et de mise à jour des greffons, une spécification, etc.
De mon expérience en tant qu'utilisateur, Firefox et WordPress sont de très bons exemples avec une vraie plateforme de gestion et téléchargement des greffons, et j'aimerais qu'on y pioche des idées.
J'ai en fait le projet de travailler sur une telle plateforme (et ai même déjà des bouts de code "stashed" quelque part sur mon ordi) et ça pourrait être mon prochain gros projet. Mais j'attends déjà de voir comment mon projet actuel (film d'animation 2D libre "ZeMarmot") se passe. Si ça ne marche pas bien, je ne sais pas si je continuerai longtemps. Si ZeMarmot marche par contre, on pourrait voir une nouvelle proposition de financement pour cette plateforme dans quelques mois.
Comment vois-tu les interactions entre GIMP et les autres projets libres ?
Je pense personnellement que GIMP est un projet moteur du mouvement Libre, dont le but n'est pas uniquement de créer un logiciel, mais a suscité de nombreux autres projets. Il est ainsi à l'origine de briques essentielles comme GTK+ (qui est la base de nombreux programmes, que l'on aime ou non ce toolkit et son état actuel), et maintenant babl et GEGL, qui eux-mêmes seront à l'avenir — je pense — des briques majeures de nombreux autres projets. GIMP aussi participe activement aux discussions avec d'autres projets, et tente de suivre les standards pour un bureau de travail sain. Plutôt que de bosser dans son coin, la collaboration est clairement un créneau majeur, comme le montre l'intégration des brosses MyPaint, qui inaugure une ère nouvelle où les divers projets majeurs de l'image raster souhaitent collaborer et créer ensemble un format de partage des brosses entre applications.
Ceci sans parler du format OpenRaster, encore balbutiant et dont le développement est peu actif, mais qui pourrait être très important s'il va au bout des espérances, et dont GIMP est aussi un contributeur majeur pour la spécification.
C'est pourquoi, si vous avez le moindre problème avec GIMP, je conseillerai de faire un pas en avant et d'aider le projet, avec du code, du design ou de l'aide communautaire. Nous manquons de mains !
À ce propos, quel est ton avis sur GTK+ comme boite à outils pour interface graphique et ses évolutions ?
Personnellement je suis très peu intéressé par les guerres et trolls, etc. En fait je suis anti-spécialisé. Je m'intéresse à un peu tout, et le fait que je fais plus souvent du GTK+ dernièrement est essentiellement dû au fait que le hasard a voulu que les logiciels auxquels je me suis intéressé étaient en GTK+.
Hors cela, je n'aurais aucun problème à développer en Qt demain si le prochain programme qui me faisait de l'œil devait être en Qt, ou en quoi que ce soit d'autre.
Au final je fais avec ce que j'ai. Ce qui m'intéresse, c'est de faire quelque chose de bien. Le reste, c'est de la perte de temps.
Ensuite oui c'est pas parfait, et je m'y connais pas assez pour savoir comment c'est à côté, mais je doute qu'on change le toolkit de GIMP (surtout qu'il vient de GIMP !), donc bon. Plutôt que brasser du vent à rouspéter contre quelque chose qui ne changera pas, je fais avec; et franchement ce toolkit n'est pas si mal. :-)
Tout ça pour dire : GTK+, je m'en balance. C'est ce que je fais avec qui m'intéresse.
Qu'est-ce que tu aimerais (voir) changer/améliorer dans GIMP ou son développement, quels sont les prochains sujets et même les futurs enjeux pour GIMP ?
Au niveau fonctionnalité, mon gros chantier à l'heure actuelle, c'est l'animation, la peinture numérique et la consolidation de GIMP.
Mon prochain gros projet, c'est les plugins. Je l'ai déjà dit plus haut. Je pense que c'est vraiment important qu'on ait une plateforme saine et cela devrait vraiment apporter un renouveau.
Ensuite il y a toute la partie "édition non destructrice" qui sera un bond majeur dans la manière dont les gens travaillent l'image avec les logiciels Libres.
Un autre point majeur est le design et l'interface utilisateur de GIMP qui souffre de sa vieillesse. GIMP se traîne des casseroles dues essentiellement à son âge (20 ans cette année !) et ce serait vraiment un projet très important, non seulement pour l'image du logiciel, mais surtout pour améliorer la simplicité d'utilisation. À vrai dire on a un tel projet avec Aryeom, et elle pense démarrer un groupe de design et UI pour GIMP dans l'année à venir.
Enfin un dernier gros point qui me chagrine est le cycle de sortie du projet : il est trop long. Ceci est aussi dû à l'âge du projet, d'une époque où on laissait les choses mûrir des années et où les utilisateurs compilaient eux-mêmes quand ils souhaitaient le logiciel plus vite. Mais de nos jours, il faut sortir plus vite, et passer à un cycle de sortie rapide. On devrait être capable de faire une sortie rapidement pour juste quelques corrections de bug, mais aussi pour des fonctionnalités. C'est quand même triste qu'on doive attendre des années pour utiliser des fonctionnalités qui sont déjà implémentées dans l'arbre de développement.
Comment s'établit la feuille de route ?
La feuille de route s'établit essentiellement par discussion. Les divers développeurs discutent, que ce soit sur IRC ou physiquement (sans sortir les poings !) lors de rencontres telles que Libre Graphics Meeting, et choisissent de ce qui est prioritaire ou non.
Ensuite le reste, c'est aussi l'intérêt personnel. Si quelque chose est prioritaire pour moi, je le développe, le soumet à revue et c'est intégré même si c'était une basse priorité dans notre feuille de route.
Contribues-tu également à d'autres logiciels ? As-tu des projets en rapport avec le logiciel libre dans un futur proche ?
Oui, comme j'expliquais, quand je rencontre un problème ou un manque, mon premier réflexe est de chercher s'il n'existe déjà pas une solution, puis d'ouvrir un rapport de bug (ou demande de fonctionnalité) et enfin de corriger/implémenter moi-même s'il le faut (en estimant bien entendu le temps que j'y passerai comparativement avec mon désir d'avoir le bug corrigé ou la fonctionnalité disponible).
Donc j'ai déjà des patchs dans une trentaine de projets d'après OpenHub, et encore ce site ne compte pas tous les projets auxquels j'ai contribué sans le nom en auteur, notamment parce qu'ils utilisaient un dépôt de source qui n'a pas de concept d'auteur vs. committer, comme le vieillissant SVN. Ainsi j'ai par exemple deux patchs dans Blender (qui utilise git maintenant mais utilisait svn à l'époque où j'ai fourni ces patchs) et dans de nombreux autres logiciels dont je ne me souviens probablement même plus avoir fourni un patch.
Sinon j'ai créé l'outil crossroad, initialement justement pour cross-compiler GIMP pour Windows depuis GNU/Linux (c'est tellement horrible d'essayer de compiler des logiciels sous environnement Windows alors que c'est si simple sous GNU/Linux !).
Enfin, je pense que vous avez tous entendu parler ici de ZeMarmot, un film d'animation Libre (Creative Commons BY-SA) en 2D, dessiné avec GIMP, édité avec Blender et Ardour. Dans ce contexte, je vais continuer à développer pour GIMP, mais aussi je vais travailler sur un nouveau logiciel pour la gestion d'un projet de film d'animation. Et ce sera cool. :-)
D'ailleurs notre financement n'est pas terminé puisqu'on a eu droit à une prolongation de la plateforme. Donc si quelqu'un lit cet entretien, et souhaiterait contribuer, ce qui aidera à améliorer GIMP et d'autres logiciels Libres, vous êtes les bienvenus!.
Pour ZeMarmot justement, tu utiliseras certainement beaucoup GIMP. GIMP est souvent vu comme un logiciel de retouche alors que Krita est présenté comme adapté à la peinture numérique… Quelle est ton opinion au sujet de ces deux logiciels et des outils de travail proposés ?
Oui c'est une image de GIMP qui est selon moi totalement erronée. GIMP est très générique (le 'G' signifiait d'ailleurs "General" avant d'être renommé pour signifier "GNU" à la place) et est fait notamment pour de la retouche photographique en effet, aussi bien que pour de la composition d'image, et de la création d'image, c'est-à-dire dessin, peinture… Cf. la description officielle:
GIMP is the GNU Image Manipulation Program. It is a freely distributed piece of software for such tasks as photo retouching, image composition and image authoring.
Bien sûr, d'autres logiciels ont décidé de se spécialiser dans le dessin numérique, comme Krita ou MyPaint, tous deux de très bons logiciels d'ailleurs. C'est un choix totalement valide, mais au final on voit que ces derniers se mettent à recouper des utilisations de retouche photo et autre, avec des filtres, etc. Comme quoi tout est lié dans l'image et vouloir être mono-utilisation seulement a peut-être ses limites ?
Pour moi, aussi bien MyPaint, que Krita ou GIMP sont valables pour la peinture numérique. D'ailleurs je pense que les dessins d'Aryeom en sont la preuve, non ? Et elle n'est pas seule. Sur le web, on trouve de nombreuses perles, des dessins sous GIMP vraiment superbes techniquement. Maintenant c'est sûr que GIMP est 1000 fois moins fort en marketing que Krita, surtout ces dernières années où son mainteneur a décidé d'en vivre et fait donc très fort pour promouvoir ce dernier (ce qui lui a valu une bonne accélération, et c'est vraiment cool). Clairement GIMP a des progrès à faire du côté "marketing".
Au final il est juste dommage que certaines personnes veuillent absolument reléguer GIMP à une partie seulement de ces capacités, et certains exprès, j'ai l'impression malheureusement. Des fois j'ai l'impression de voir les fans de Krita cracher sur GIMP et je ne comprends vraiment pas le but. Deux logiciels Libres ne peuvent-ils pas vivre en paix côte à côte?
En conclusion: GIMP est un très bon logiciel de dessin/peinture numérique, qu'on se le dise!
Je conclus donc avec l'affiche de notre film ci-dessous (que vous connaissez déjà ici) comme exemple, dessinée entièrement avec GIMP; désolé si vous vous dites que j'en fais trop! :p
Quels distribution et environnement graphique utilises‐tu ?
J'ai été longtemps utilisateur Mandrake, puis Mandriva, puis Mageia. J'ai abandonné Mageia car j'avais trop de petits problèmes (petits, mais à force, ça devient majeur) qui rendaient mon utilisation quotidienne de plus en plus désagréable et malheureusement mes rapports de bug n'étaient quasiment jamais traités et simplement fermés lors d'une montée de version (j'aurais pu chercher pour corriger moi-même mais comme je disais plus haut, il faut quand même estimer le temps qu'on y passera et la priorité. Or là, c'était beaucoup plus simple de passer sur une autre distribution, donc priorité basse. Désolé aux contributeurs de Mageia du coin !). Dernièrement j'ai surtout utilisé Linux Mint (depuis plus d'un an), et globalement cela se passe bien. C'est tout de même une distribution bien maintenue et ficelée. Je n'ai plus aucun des problèmes que j'avais sous Mageia notamment. Ensuite elle manque de trucs excitants à mon goût. Je voudrais au moins tester GNOME 3 (et sous Mint, installer GNOME 3 tient du parcours du combattant à priori), donc je suis en train de considérer le passage à Fedora pour la première fois. Aucune idée si j'y resterai.
Sinon j'ai testé un peu Ubuntu à une époque, pas accroché du tout. Mon grand amour au niveau stabilité et fonctionnalité fut Gentoo. La seule raison pour laquelle je n'y reviens pas est le temps que cela prend à mettre en place, à compiler chaque paquet, à peaufiner les détails, etc. En même temps, c'est peut-être grâce à cela que c'est une si bonne distribution. Mais je n'ai plus le courage de passer des heures juste pour avoir mon environnement (même s'il est super). Maintenant je préfère que tout marche direct, même si c'est moins marrant et avec moins de fonctionnalités dernier cri.
Environnement graphique : j'ai pas mal testé, du KDE, du GNOME (2), WindowMaker, ion3 pendant un bon moment aussi. Mon environnement graphique préféré fut Openbox, puis Openbox+Cairo-dock. Malheureusement là aussi je n'y suis pas resté à cause de détails ici ou là. C'est vraiment dommage, je pense que ce sont vraiment les détails qui changent tout dans l'utilisabilité d'une solution informatique.
À l'heure actuelle, je suis sur le Cinnammon par défaut de ma Linux Mint. Je n'y ai pas grand chose à redire, mais je n'en suis pas non plus fou et n'aurai pas de regret à le quitter.
Merci pour l’entretien et pour ta contribution à GIMP !
Et merci à vous pour les questions ! :-)
Aller plus loin
- Studio Girin (843 clics)
- GIMP (592 clics)
- Contributions (non-exhaustif) de Jehan à des projets Libres (611 clics)
# Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Thrillseeker . Évalué à -10.
…
…
Quand on lit cela, on peut se dire que le logiciel est dans un état très avancé. Sauf que la base n'est pas du tout au rendez-vous.
Ce mois-ci (donc dernière version, 2.8.14), je voulais écrire du texte sur une image… par défaut, j'ai la police "Sans", juste "Sans"… super nom de police par défaut, limite cela fait bug. Je souhaite donc en changer. Je clique sur l'icone correspondante et une liste déroulante s'affiche contenant la liste des polices. Sauf que la liste est petite, peu importe la dimension de la barre d'outils, la liste reste toujours petite (même largeur et hauteur), et donc la majorité des noms de police est tronquée. Du coup il y a la magnifique barre de scroll horizontale, mais c'est moche et débile. Réaction immédiate, je vais agrandir la liste moi-même, comme dans tout logiciel. ET NON, ce n'est pas possible.
Pour la petite histoire, j'ai voulu faire une capture d'écran montrant cette belle liste bien pourrie. ET NON, ce n'est pas possible, la touche Impr écran ne marche pas quand la liste est visible. Les joies de X ? surement un hack ? GTK sucks ? oh yeah.
Autre problème que j'ai eu, c'était pour la taille de la police. Je tape du texte et je me dis que je veux agrandir tout ça. Je monte la taille de la police… rien ne se passe. Contrairement à d'autres logiciels (KolourPaint), dans GIMP, un même texte peut contenir différentes tailles. Du coup, en modifiant la dimension, rien ne se passait car rien n'était sélectionné. On va dire que c'est à cause de l'habitude des autres logiciels. Rien de grave.
Par contre, en augmentant la dimension de la police à l'aide la souris, le focus du clavier se déplace dans la zone de saisie (de la dimension de la police). On ne peut donc pas augmenter vite-fait le texte et continuer à taper son texte, car cela oblige de cliquer à nouveau sur l'image pour mettre le focus au bon endroit. Je sais que PhotoShop 7, il y a bien des années en arrière, n'avait pas ce problème.
GIMP, c'est le logiciel que j'ai toujours fui, la moindre chose que je dois faire avec me rappelle pourquoi.
Rien de dramatique, mais comme c'est si bien dit: "c'est tout con, mais c'est horripilant."
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Pascal Obry (site web personnel) . Évalué à 10.
Si tu avais lu complètement l'article tu aurais fait comme Jehan… c'est à dire remonter et corriger les problèmes plutôt que de venir ici faire un commentaire horripilant.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Thrillseeker . Évalué à 3.
Oui, tout le monde devrait être comme Jehan, quand on utilise un logiciel il faut toujours remonter tous les problèmes et même en corriger soi-même. Après, je donnerai des interviews et je serai une star du libre.
Je sais que mon commentaire précédent est "horripilant" (et que celui-ci aussi). Mais quand les développeurs de GIMP s'attardent sur des problèmes avancés en mettant de coté les problèmes d'interface utilisateur qui doivent exister surement depuis le début, ça "m'horripile". Surement car aucun n'est bloquant.
J'ai lu en entier l'article et je trouve que ce que fait Jehan est très bien, c'est une belle contribution. Mais je trouve également dommage que certains points d'interface utilisateur qui sont souvent utilisés (comme écrire du texte) et qui m'ont personnellement agacé (ou horripiler en fait), soient délaissés. Après, c'est peut-être lié à GTK ?
Ceci dit, c'est peut-être seulement moi, dans mon coin isolé, dans ma configuration particulière, qui rencontre ces problèmes. Et peut-être que ça agace que moi ? Surement.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par eingousef . Évalué à 10.
Ben en tout cas t'as plus de chances de devenir une star du libre comme ça qu'en venant poster tes rapports de bugs sur Linuxfr.
*splash!*
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Maderios . Évalué à 10. Dernière modification le 27 juin 2015 à 20:19.
L'histoire désolante du fil "save" et "save as" (bin oui, bizarrement, Gimp ne veut pas enregistrer directement que le .xcf) sur la liste gimp-user montre que l'équipe des dev de Gimp est hermétique aux suggestions des utilisateurs. Pour contourner le problème, un plugin a été créé par Akkana Peck (merci à elle) mais c'est quand même moins pratique que la fonction save as conventionnelle que l'on trouve dans tous les logiciels d'édition.
http://shallowsky.com/software/gimp-save/
http://www.gimpusers.com/forums/gimp-user/14746-a-plug-in-for-those-who-still-don-t-like-the-new-save-export
https://github.com/akkana/gimp-plugins/
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Julien.D . Évalué à 5.
Les utilisateurs n'ont pas à imposer leurs idées aux développeurs. On peut trouver que certains choix sont mauvais, on peut essayer d'argumenter et d'échanger avec les développeurs, mais ils restent ceux qui prennent les décisions au final.
Je ne dis pas que le fonctionnement actuel soit idéal, j'aimerais plutôt une boite de dialogue de ce genre.
et avec une configuration globale dans le logiciel.
Les développeurs voient les choses autrement ? C'est dommage, mais ils restent les développeurs.
Je réagis surtout sur le fait que non, les utilisateurs ne peuvent pas forcer les développeurs à faire les choses comme eux l'entendent.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Maderios . Évalué à 3.
On pourrait ajouter, chacun son métier, on ne peut être en même temps au four et au moulin. Dans la majorité des logiciels destinés à la production, les développeurs s'appuient sur l'expérience des utilisateurs pour concevoir les interfaces et les fonctionnalités. Dans le monde du libre, on peut citer Digikam et Enlightenment dont les dev sont à l'écoute des besoins des utilisateurs (cf les user-list). C'est une bonne démarche puisqu'elle permet aux projets de s'enrichir et d'avancer plus vite.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par GuieA_7 (site web personnel) . Évalué à 10.
Va vraiment falloir retrouver et tabasser les utilisateurs qui ont demandé à ce que E17 sorte avec 10 ans de retard et sans appli :)
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Muchacho . Évalué à -2.
C'est quand même vachement dommage.
Le truc désolant, c'est que certaines décisions sont parfois "arbitraires" ou non justifier quand bien même les utilisateurs font des remarques légitimes.
Ce qui me désole vraiment c'est que l'écosystème des logiciels libres communautaires devraient ressembler plus ou moins à quelque chose de démocratique, dans le sens où c'est le public - l'utilisateur final - qui peut dire comment son expérience peut être améliorer.
La finalité c'est qu'on se croirait en politique, où ce sont les gens d'en haut qui n'écoutes pas assez souvent les gens qu'ils sont censés écouter.
Après j'entends bien que le développeur n'est pas l'esclave des utilisateurs. Mais ça serait sympa de voir naître des système démocratique, où les utilisateurs ont le même poids qu'un utilisateur. Tu fais un vote/sondage et tu suis le résultat…
Du haut de ma naïveté, j'ose croire qu'on aurait déjà eu des environnements de bureau et des distributions "Mme Michou-friendly" si on écoutait plus les utilisateurs.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par GuieA_7 (site web personnel) . Évalué à 10. Dernière modification le 29 juin 2015 à 21:37.
J'imagine que si 10 personnes venaient te demander de venir balayer la rue un dimanche (alors que toi tu voulais mater des Game of Thrones tranquille), gratuitement et pendant qu'ils regardent, tu t'exécuterai. Ben oui ça serait très démocratique (ils sont 10 et toi 1), et en plus ça serait utile à la communauté (alors que bon glander pendant ton temps libre, quelle idée). Et puis bon ils pourraient tout à fait apprendre à balayer, mais sincèrement ça a l'air difficile et assez chiant, alors que toi tu feras ça sûrement très bien. Ne t'inquiète pas, dans un grand élan démocratique ils seront toujours prêts à te dire si ton travail ne leur convient pas et qu'ils faut recommencer. Enfin sauf qu'en fait M. Machin il voulait que tu balayes devant chez lui avant devant chez Mme Truc, du coup il ne trouve pas ça super démocratique quand même, tu ne l'écoutes pas du tout, il a même l'impression que tu lui pisses à la raie, c'est pas très sympa.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Muchacho . Évalué à 3.
En me mettant à ton niveau ça donnerait quelque chose du genre :
Les 5 personnes balaient (des devs), 5 personnes sortent les poubelles (des utilisateurs qui donnent des feedbacks, rapports de bugs), 9 personnes disent à celle qui est à la tête du projet Balayement qu'il vaudrait mieux balayer tel endroit qui est très fréquenté et non un endroit où strictement personne passe, ou bien changer le type de balaie parce qu'un balaie à frange pour les feuilles c'est pas top.
Et cette personne refuse, parce qu'elle n'a pas envie de changer son habitude.
Au passage ce n'est pas très honnête d'avoir ignoré ma phrase :
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par GuieA_7 (site web personnel) . Évalué à 7.
Pas du tout; en fait c'est très exactement le contraire : je souligne l'incohérence de tes propos, et en particulier cette phrase.
En effet, il n'est pas du tout question d'esclavage dans mon post ; tu es tout à fait en droit de refuser. En fait n'importe qui refuserait, c'est bien normal. Pourtant les 10 personnes n'ont aucune gène à venir demander ("on n'est pas du tout pour l'esclavage hein, mais si tu le ne fais pas t'es qu'un sale égoïste"). Pourtant tu le vois comme de l'esclavage, et c'était le but.
En revanche, désolé, mais c'est toi qui es malhonnête :
Allez comme j'adore les analogies je vais affiner un peu :)
Il se trouve qu'en effet un week-end sur 2 tu nettoies le littoral (à la base tu adores le littoral, le centre ville tu t'en tapes). 10 personnes (parmi lesquelles un t'a prêté un balai et une autre donné un sac poubelle) viennent te voir pour que tu nettoies d'autres quartiers. 3 veulent que tu nettoies le quartier A, 2 le quartier B, le reste 5 quartiers différents ; celui qui t'a prêté un balai continuera à le faire, et peut être même qu'une 2ème personne te donnera un sac poubelle. Et donner des retours ne leur fait pas peur non plus : si ce n'est pas assez propre ils te le diront. Parce que tu es gentil, tu acceptes de nettoyer le quartier A (c'était les plus nombreux). Bilan: tu fais 7 déçus qui penses que tu es un égoïste et que tu ne les écoutes pas du tout :)
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Muchacho . Évalué à 3.
J'ai répondu avec une analogie bancale parce que tu as initiés le débat comme ça. Tous nos exemples sont foireux (affinés ou non).
Du coup je ne vais pas essayer de m'expliquer d'avantage (d'autant plus que tu sembles interpréter les phrases à ta convenance, je ne vois pas où tu as vu une forme d'égoïsme ou de personnes qui travaille plus dur que d'autre dans ce que j'ai dit, il n'y avait pas assez de données pour affirmer ça :p).
Pour résumer : il existe dans certains cas des gens qui ont une place "forte" et qui bloquent/nuisent à au bon déroulement de certaines choses. ça existe dans les entreprises, dans notre système politique et beaucoup d'autres systèmes plus ou moins hiérarchiques en fait. Je pointais du doigt le fait qu'il existe aussi très fortement dans un système aussi vertueux que les logiciels libres (ça amène à des forks etc.).
Bref ne me fait pas dire que les développeurs sont égoïstes par essence, c'est totalement absurde.
J'arrête le débat ici pour ma part.
Btw, ta réaction est/était intéressante. o/
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Évidemment qu'il y a des chefaillons un peu partout, y compris dans le libre. Mais tu présentes ça dans un thread qui parle d'une fonctionnalité bancale de Gimp. Alors c'est peut-être juste maladroit de ta part, mais du coup tu présentes le problème des chefaillons comme majeur dans le libre, et qui expliquerai peut-être la frustration de cet utilisateurs : peut-être que si les fonctionnalités étaient choisies par les utilisateurs finaux il y aurait moins de frustration.
Je pense que, dans le cas général, et dans notre cas particulier de Gimp, c'est un faux problème (ou tout du moins très mineur). Non le problème c'est qu'il y a très peu de développeurs par rapport à l'importance du logiciel (on a vu la même chose avec OpenSSL par exemple). Les fonctionnalités peuvent être choisies au mieux, il faudrait 10 fois plus de codeurs (et/ou que les dév actuels puissent travailler à plein temps dessus) pour que le développement se fasse à une vitesse satisfaisante.
Mais le problème est complexe, ce n'est pas la faute des utilisateurs qui seraient juste des feignasses hein. Du coup l'initiative de Jehan qui permet aux utilisateurs de financer le développement du logiciel est très bonne à mon avis. Parce que contrairement aux simples dons que tous les projets acceptent, là on a une vrai dynamique de 'vous donnez et moi derrière je peux bosser à plein temps'.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Thomas Douillard . Évalué à 5.
La démocratie c'est surtout des tonnes d'opinions, des tonnes de discussions, et à la fin on est jamais content des décisions prises.
Sérieusement c'est une analogie complètement foireuse dans le monde du logiciel.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Zenitram (site web personnel) . Évalué à -4. Dernière modification le 01 juillet 2015 à 14:13.
Comme dans la vraie vie, on peut planter un logiciel avec une démocratie ayant des électeurs refusant de voir les contraintes techniques.
Donc l'analogie va bien plutôt, la différence est juste qu'on peut se barrer plus facilement (mais toujours avec les avantages de se barrer… Et les inconvénients, cette facilité empêche quand même de mutualiser plein d'efforts dans certains cas) dans certaines structures où "tout le monde décide" (on a une meilleure UI globale chez Apple que chez Gnome/KDE/Linux en général car la démocratie Apple, car c'est bien une démocratie vu que n'importe qui peut acheter une action Apple et qu'il y a plein d'études faites sur les utilisateurs, est de nommer un chef qui gère la cohérence plutôt que de faire des dictatures de la majorité complètement incohérentes entre elles).
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Thomas Douillard . Évalué à 6.
Le problème c'est que la relation développeur/utilisateur a peu de choses à voir avec une relation électeur/élu par exemple.
Oui il y a des décisions à prendre sur la gestion du projet, c'est de la politique donc en un sens, mais c'est pas la politique sur une manière de partager les lieux et tout, c'est une politique sur comment les développeurs utilisent leur temps, c'est tout, globalement, et éventuellement ce qu'ils font des retours utilisateurs.
Globalement, les utilisateurs n'élisent pas les développeurs, ne peuvent pas vraiment les virer, ne les payent pas souvent, donc ce n'est ni une démocratie, ni une entreprise …
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Zenitram (site web personnel) . Évalué à -3.
En libre? euh… Ils peuvent, ça s'appelle un fork.
choisir d'utiliser un logiciel (ou matériel) est une forme d'élection.
Ils peuvent, donc ils ont le choix, c'est ce qui importe.
Une démocratie n'est pas juste une truc précis d'élection, c'est le peuple pour le peuple.
Une entreprise est un outil d'un plus grand ensemble.
Bref, ça dépend complètement de comment tu veux voir la chose, mais globalement on retrouve tous les principes démocratiques.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Thomas Douillard . Évalué à 6.
Parler fork quand on parle d'utilisateurs qui ne font que gueuler, c'est paradoxal :)
Ouais enfin quand un développeur développe pour son plaisir, il n'a pas vraiment de raison de le faire pour le peuple.
Pas vraiment. Le projet global n'est pas les institutions reliant un peuple ou des gens, c'est … un bête logiciel.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par FantastIX . Évalué à -2. Dernière modification le 07 juillet 2015 à 09:59.
Bien sûr, ce n'est pas à une majorité (qui sait sans doute ce qu'elle veut) d'imposer ses vues à la minorité (qui sait peut-être ce qu'elle fait et) qui a décidé de bosser pour elle, il vaut mieux l'inverse, n'est-ce pas? Ou bien est-ce que ce n'est pas plutôt l'idée d'imposer tout court qui est mal?
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Le Gab . Évalué à 10.
Y en a un peu marre qu'on critique les choix UI de GIMP, le multi-fenêtrage parce que Windows® gère les fenêtres comme un branque, les gens sont allés attaquer le concept.
Ici, je trouve que l'idée est pertinente, GIMP est une application pour gérer des projets d'illustrations ou de photo-montages entre autres choses, il me semble normal que ça se ressent dans le mode de gestion des fichiers.
Et ça sera d'autant plus vrai lorsque GIMP sera vraiment non-destructeur.
Les blogueurs qui n'ont que ça à faire de tirer sur l'ambulance ou de se servir de ce faux problème pour se ramener de l'audience, ou les gens prêts à perdre leur temps à pondre un greffon alors qu'il suffirait juste d'apprendre ce nouveau réflexe - grand max 2 secondes - sont quand même pitoyables.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par DerekSagan . Évalué à 1.
Bah le concept est minoritaire et pourri également sous Linux avec un window manager digne de ce nom.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Antoine . Évalué à -2.
Bienvenue dans le logiciel libre, où une description de problèmes a une chance non négligeable (et, sur Linuxfr, assez élevée) de se voir rétorquer une réponse de boy-scout.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par xcomcmdr . Évalué à 1.
Le "boy-scout" disait juste de mettre ça de manière plus informative (donc le problème aura plus de chance d'être réglé), et plus pérenne/centralisée sur un bugtracker upstream (comme cela ce sera plus pratique d'en discuter avec les développeurs, et davantage visible).
T'as un problème avec ça ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Antoine . Évalué à 6.
Il y a l'art et la manière de faire une suggestion… Vu le ton que tu adoptes ci-dessus, oui, il y a certainement un problème. Personnellement, je m'en fous, je contribue assez au libre, et depuis assez longtemps, pour ne plus m'arrêter à ce genre de détails : je suis de l'autre côté de la barrière et, si je trouve qu'un zozo devient insupportable pour les utilisateurs, je lui fais la remarque… comme ici. Mais la plupart des gens seront facilement intimidés et découragés par une attitude de défiance ombrageuse qui est ici la tienne ou celle du posteur précédent.
Et il faudrait que les "libristes" comprennent que rapporter un bug sur un bug tracker n'a rien de naturel pour les utilisateurs, cela demande en fait du courage, du temps, des compétences. Ce n'est pas "yakafokon". Surtout, d'ailleurs, si on a eu des expériences négatives dans le passé, ce qui peut arriver sur certains projets (exemple caricatural : rapport un problème d'utilisabilité à propos de GNOME :-)).
Mais bon, se serrer les coudes entre soi dans son petit pré carré, ça a son charme aussi.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par xcomcmdr . Évalué à 4.
Idem pour le commentaire d'origine si tu le lis bien. Franchement, la réponse de boy scout n'avait rien d'aussi agressive que le commentaire auquel il répondait.
Mon ton était tout à fait courtois, ne t'en déplaise.
On a pas dit le contraire.
Mais tu admettras qu'en revanche, venir se défouler sur un logiciel sur linuxfr ne demande que de la bile, un peu de temps, et ne résout jamais rien.
À bon entendeur, salut !
Pour info je préfère moi aussi utiliser autre chose que GIMP pour mettre du texte sur une image (par exemple : Pinta), mais ce n'est pas une raison pour se comporter comme un gamin qui évacue sa colère et s'en va.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Ms-Mac . Évalué à 2.
Mais oui!!!
no comment
Tout le monde a un cerveau. Mais peu de gens le savent.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par xcomcmdr . Évalué à 8.
ça tombe bien, toi non plus.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Pascal Obry (site web personnel) . Évalué à 8. Dernière modification le 28 juin 2015 à 12:10.
Non c'est juste que chacun ne voit que son petit monde. Dans pas mal de cas tu as 50% des utilisateurs qui sont pour et les autres contre. Tu fais quoi? Et ceux contre viennent râler au complot sans souvent avoir lu le rapport des développeurs pour étayer le choix. Il est impossible de plaire a tout le monde. Pour ma part le choix du "save as" soulevé plus haut de GIMP me va très bien, ce qui ne veut pas dire que j'ai raison, c'est juste bien tombé… Et pour les autres cas et bien je m'adapte, c'est jamais très compliqué et ça permet de rester avec un esprit jeune :)
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Thomas Douillard . Évalué à 2.
Faudrait que les deux menus mènent à une boîte de dialogue unique avec un onglet "sauvegarde du travail" et un onglet "utiliser le résultat". Comme ça si on s'est gouré, ya ka cliquer.
Bon par contre c'est juste un bikeshed, j'ai aucune envie ni de coder ni de discuter vu mon utilisation sporadique.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Graveen . Évalué à 10.
C'est pas faux. La gestion du texte est clairement compliquée sous GIMP.
Ce n'est pas une critique stérile comme le save / save as qui m'est apparu comme un point tout à fait discutable, avec des arguments pro/con donc la décision de l'équipe de dev est tout à fait compréhensible.
Maintenant, GIMP possède aussi beaucoup de fonctions qui sont trés bien fichues, et réduire le logiciel à un problème de boite de textes OU d'interface est clairement dommage dans une utilisation équilibrée.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Tout à fait. La gestion du texte est un très gros chantier sur lequel on aimerait tous venir un jour. C'est clairement un outil assez frustrant à de nombreux égards. Je suis le premier à être d'accord, et Aryeom ne dira pas le contraire non plus! Tous les autres dévs en sont conscients aussi car on en parle régulièrement (on en a encore parlé avec le mainteneur y a 2 mois lors de LGM 2015).
De manière général, le commentaire initial du fil liste plusieurs problèmes réels, connus et qu'on veut améliorer.
Par contre j'ai voulu répondre, mais j'ai abandonné. Le commentaire n'a clairement pas été fait pour initier un échange constructif, et je sens que toute réponse (celle-ci comprise probablement) ne m'apportera que des attaques ad-hominem. C'est donc mon premier et dernier message sur ce fil de discussion.
Par contre si y a d'autres questions ou commentaires intéressants, et même des critiques constructives, n'hésitez pas à créer un autre fil.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Bon j'ai dit que je répondrai pas, mais je marche dedans! J'arrive pas à retenir mes doigts.
Qu'est-ce qui ne marche pas? Qu'un outil n'est pas parfait n'est pas la même chose qu'un outil cassé. L'outil de texte marche très bien. Quand on trouve un bug, je peux t'assurer qu'on n'attend pas longtemps avant de le corriger.
En outre, c'est justement ce petit plus de l'UI parfaite qui prend du temps. Parler c'est beau, mais si tu as la science de l'UI idéale infuse, on les veut bien tes dessins et tes spécs détaillés (c'est à dire qui prend en compte tous les cas, pas juste un yakafokon en 1 ligne) pour rendre l'outil de texte bien meilleur.
Merci de venir nous donner des leçons de vie. Heureusement que les trolls sont là pour nous apprendre comment gérer notre temps (avec ce magnifique exemple justement pour nous le faire perdre! En fait c'est peut-être cela la "gestion" du temps que tu veux nous enseigner?); sans eux, que ferait-on?
Je concluerai par un lien vers notre bugtracker, de la liste des rapports qui sont passés en statut "FIXED" (= corrigé) depuis janvier 2015: 75 bugs à ce jour
Et encore, c'est sans compter les bugs découverts en interne et corrigés sans qu'il y ait eu un rapport de bug. Je compte donc, dans la seule année 2015, 459 commits dans GIMP master, 26 dans babl master, et 218 dans GEGL master. C'est sûr, les développeurs de GIMP n'en font vraiment pas une et "se fout[tent] de l'utilisateur".
D'ailleurs saviez-vous que lorsqu'un utilisateur rapporte un bug, en fait on va se moquer de lui derrière son dos et on rigole bien car on fait exprès de ne jamais corriger les bugs.
Non mais qu'est-ce qu'il faut pas lire!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 28 juin 2015 à 21:44.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Graveen . Évalué à 10.
Dis donc, tu n'écrirais pas un peu beaucoup de merde toi ? :p
Ou alors tu n'as aucune notion de la gestion d'un projet de 15 ans.
Sans doute les 2 :)
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par GuieA_7 (site web personnel) . Évalué à 10.
Je ne sais pas si c'est de la bêtise ou de la méchanceté (les 2 n'étant pas mutuellement exclusifs), mais tes commentaires sont vraiment toxiques.
J'imagine que cracher sur le travail des autres ça t'aide à te sentir malin. C'est sûr que c'est plus facile que de venir nous présenter ton propre travail ; toi qui fait sûrement passer l’intérêt des utilisateurs avant le tien (et ce même lorsque c'est sur ton temps libre évidemment), ça doit être bien pourtant. Mais je suis à peu près sûr que ça n'arrivera pas…
(et oui désolé linuxfr je ne t'ai pas écouté et j'ai nourri le troll)
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Zenitram (site web personnel) . Évalué à 10.
Non, ça veut juste dire avoir se priorités.
Quand l’utilisateur paye, à la limite on peut l'écouter, mais celui qui consomme gratos doit regarder la licence (hint: "AS IS").
Ne pas être l'esclave de l'utilisateur != se foutre de lui.
Aucun programmeur ne se fout de l'utilisateur. Par contre pas mal d'utilisateurs se foutent des programmeurs…
PS : et toi, tu fais quoi pour l'utilisateur? tu ne te fouterais pas de lui à ne pas patcher? tu es une personne horrible car tu te fous de l'utilisateur à ne rien patcher!
Comme quoi, c'est facile de critiquer… Tu peux te critiquer uassi car tu es pire que ceux que tu critiques (eux patchent, toi tu ne fais rien)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Zenitram (site web personnel) . Évalué à 9.
Ne pas faire exactement ce qu'un utilisateur veut != ne pas écouter la communauté des utilisateurs.
Ta vision du développement fait qu'on perd toujours.
Une personne 1 veut A, une personne 2 veut l'opposé de A, si tu fais A la personne 2 dit qu'on n'écoute pas les utilisateurs, tu fais l'opposé de A la personne 1 dit qu'on n'écoute pas les utilisateurs.
Désolé, écouter les utilisateurs n'a absolument rien à voir avec faire ce que veut une personne particulière. Ca ça s'appelle une dictature.
bref, tu ne connais rien à ce qui est du développement avec des utilisateurs mais tu penses savoir mieux que ceux qui ont à gérer des utilisateurs comment il faut gérer.
Yaqua, un grand classique de ceux qui ne font rien.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 29 juin 2015 à 16:24.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Zenitram (site web personnel) . Évalué à 10.
Autant je peux comprendre qu'on n'aime pas la GPL (par exemple moi), autant haïr me dépasse.
Ca me dépasse encore plus qu'on arrive à tranquillement balancer ça comme excuse pour ne pas contribuer (mais alors, utiliser et critiquer, ça ne dérange pas? bravo).
Je crois que je n'arriverai jamais à comprendre comment on peut haïr, déjà de manière générale, mais ensuite haïr une licence, libre en plus…
Bon j'imagine que comme tu ais, tu n'utilises pas de Linux, de GCC, de GIMP etc… Sinon ça serait quand même bizarre comme logique (utiliser sans problème, mais bosser problème, hum hum. Ho, mais comment connais-tu les bugs de GIMP si tu haïs la GPL? Qui haïs ne touche pas généralement, de près ou de loin)
Peut-être. Mais alors, pourquoi ne le fais-tu pas?
(non, la licence n'est pas une explication, ça ne te coûte pas grand chose donc tu peux passer au dessus de la licence. enfin, si critiquer sans rien faire d'autre n'est pas ton but).
Faut croire que "pas grand chose" est déjà trop pour toi, c'est bien ce que je disais dans mon commentaire précédent, merci de me le confirmer.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 30 juin 2015 à 00:09.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Zenitram (site web personnel) . Évalué à 9.
tiens, ça change, avant c'était parce que c'était GPL.
tiens, ça change, quand c'est les autres ce n'est pas grand chose, quand c'est toi tu n'as pas le temps, comme c'est bizarre…
Et les développeurs GIMP ne sont pas payés pour te faire plaisir. 1 point partout.
Euh… Très discutable??? c'est ta vision. Tu montres que tu n'a aucun respect pour le choix des autres.
aucun espoir de l'être? A cause de tes choix très discutables peut-être… N'inverse pas les causes. Et ce n'est pas le sujet, si tu as un problème tu peux patcher et tu n'auras plus le problème, aucune notion de fric ici.
"prétendait", ça devient intéressant, si c'est de la pub mensongère alors la je te suis, je réagis assez souvent même ici contre les gens qui prétendent que tel logiciel répond à tel besoin.
Mais regardons :
- quel problème? On t'a promis que "Sans" n'est pas un nom de police? la liste est inutilisable car il n'y a que 25 caractères, vraiment? Ca rend le logiciel "un gros caca"? Qui t'a promis l'agrandissement de police?
- qui t'a promis que ce serait parfait pour ? Les développeurs? OK, je te suis, c'est faire perdre son temps. Quelqu'un d'autre? c'est sur ce quelqu'un d'autre qu'il faut taper.
Mais en fait, ça me fait bien rire, le plus gros reproche que tu lui fais est de ne pas savoir que "Sans" veut dire quelque chose en français et que ça te perturbe, qu'une fonctionnalité non promise n'est pas la, qu'une largeur est insuffisante pour toi même si elle est suffisante pour tous les autres, et c'est tellement horrible tout ça que ça en fait un "gros caca".
Donne moi un nom de logiciel que tu développes, tu vas voir que c'est rapide, je vais prendre un mot du site de présentation, le comprendre comme un truc précis, voir qu'il n'y est pas "comme il faut" (c'est moi qui décide), et l'appeler un gros caca.
GIMP fonctionne, que ça te plaise ou pas.
Ce n'est pas un argument.
Un autre outil te plait, tant mieux! Pas la peine de mentir sur GIMP pour autant.
Je reprend ton texte :
TA base n'est pas au rendez-vous. Complètement différent.
Vraiment, tu es très fort, me voilà un défendre un logiciel que je n'aime pas (je le critique aussi, mais voila je ne vais pas l'appeler "un gros caca" juste parce qu'il a quelques bugs, tous les logiciels ont des bugs même les tiens… Enfin, si tu fais des logiciels), à répondre à une critique alors que d'habitude c'est moi qui critique, à la vue du n'importe quoi que tu racontes ("un gros caca", rien que ça… C'est d'un pertinent), très fort…
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Pascal Obry (site web personnel) . Évalué à 7.
Bien voilà, fallait commercer par là!! Un troll de chez Adobe, maintenant je comprends ton message. Tu as vraiment du temps à perdre ou tu as déjà piraté toutes les clés des logiciels Adobe? Je dis ça sans te connaître, c'est pas bien… mais la vérité est que toutes les personnes que je connais utilisant les logiciels propriétaires du vendeur sus-cité les ont piratés! Ça aussi c'est horripilant!
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Thomas Douillard . Évalué à 3.
Dis donc, t'essayerai pas de relancer un troll licences ?
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Thrillseeker . Évalué à 6.
J'ai repris ton expression "c'est tout con, mais c'est horripilant", mais il n'y a rien de personnel envers toi. Au contraire, comme je l'ai déjà dis dans un autre commentaire, tu réalises une belle contribution et je te dis même merci.
@Graveen, je ne réduit pas le logiciel à un problème d'interface, j'ai moi-même cité des exemples de fonctionnalités avancés en prélude et j'ai conclu qu'il n'y avait rien de dramatique. GIMP est un logiciel très évolué :-)
Sauf qu'en tant qu'utilisateur occasionnel, j'ai rencontré ces problèmes. Mon commentaire initial, c'est la réaction que j'ai sur le moment en me disant "merde, GIMP possède plein de fonctionnalités mais juste le truc dont j'ai besoin, un outil basique, est mal fichu et surement depuis le début".
J'ai partagé mon retour d'expérience dans une communauté sur ton provocateur car j'étais "énervé" (très déçu plus exactement) en lisant l'interview car des choses très évoluées sont intégrées à GIMP (ce qui est une bonne chose) mais qu'à côté des détails peuvent "ruiner" (c'est exagéré) l'expérience utilisateur.
Je suis donc ravis d'entendre que ces problèmes soient connus et discutés en interne, et du coup il n'y a pas lieu de débattre sur ces points :-)
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Ok. Pas de problème. Je vais donc répondre ce que je voulais dire l'autre jour.
Pour "Sans", il s'agit d'un alias qui était un alias par défaut de fontconfig. Cela permet de choisir la police Sans-serif par défaut de ton installation. Autrement on ne peut pas vraiment savoir quelles polices sont installées sur ton ordi, chaque OS/distribution ayant des différences (mais on sait que chaque OS aura au moins une Sans-serif par défaut et qu'il comprendra l'alias.
De nos jours ceci dit, c'est renommé "Sans-Serif" et "Sans" existe toujours mais est déprécié (j'ai regardé un peu le code de fontconfig et c'est ce que j'ai constaté). Je proposerai donc le changement chez nous aussi.
Le second truc auquel je ne m'étais jamais vraiment penché jusque là, c'est effectivement que ce serait mieux si on pouvait agrandir la liste déroulante. Par contre je regarderai d'abord si c'est déjà faisable sous GTK+3, et si c'est le cas, c'est possible que nous ne passerons pas trop de temps dessus (car on sait que ça marchera pour GIMP 3, ce qui n'est pas pour tout de suite, malheureusement).
En tous cas, j'ai bien pris en compte les remarques. Ensuite c'est toujours mieux et constructif dans une relation aimable entre les êtres humains que nous sommes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
Juste pour info, on a fait le changement dans notre code master: https://bugzilla.gnome.org/show_bug.cgi?id=751836
Et en fait, je réfléchis même si on ne veut pas virer les Sans-serif/Serif/Monospace de la liste tout court car un designer ne veut pas un alias. Il choisit directement une fonte. Les alias, c'est plutôt pour les GUIs (où on ne sait pas qui a quelle fonte sur quel système). Ce serait bien tout de même que les alias marchent pour rechercher les fontes par défaut, mais ne soient pas visibles pour autant dans la liste. C'est pourquoi je ne vais pas proposer de suite de les retirer de la liste tant que je n'ai pas le code pour permettre la "redirection" d'alias automatique.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Question de n00b
Posté par Ginko . Évalué à 3.
C'est quoi l'édition non-destructrice ?
Une recherche rapide conduit là. C'est bien mais c'est quoi l'intérêt en fait d'avoir ça dans le cœur de GIMP ? Parce que je vois pas bien la différence avec le fait d'enregistrer avec un nom différent de l'image de base ou encore de faire une copie du calque de base au début ou encore d'utiliser l'historique.
J'imagine que l'utilité du machin doit résider dans l'ergonomie et le fait qu'il n'y a plus besoin de prendre de précautions : quoiqu'il arrive l'image de base sera toujours dispo.
J'ai bon ? Il y a d'autres raisons ? Quelqu'un pour les expliciter ?
Less is more
[^] # Re: Question de n00b
Posté par matteli . Évalué à 5.
Si, à partir d'une image de base, tu appliques 5 filtres successivement. Dans le cas de l'édition non-destructive, j'imagine que tu pourras modifier les paramètres du 2ème filtre par exemple sans avoir besoin d'annuler les 3 derniers.
[^] # Re: Question de n00b
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
[^] # Re: Question de n00b
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
Benoît Sibaud a bien répondu avec des détails. Mais globalement ce que tu dis est juste aussi.
En gros, l'idée est de ne plus travailler avec des filtres temporellement mais avec un graphe (ou au moins une pile) de filtres. Tu ne modifies donc plus l'image avec ça, puis ça, puis ça. Puis tu dois tout annuler pour retirer juste le premier filtre. Tu as juste une image (qui reste toujours clean) et une pile de filtres au dessus. Et tu peux éditer tes filtres, les réordonner, en ajouter un, avant, après ou au milieu des filtres existants, etc.
L'historique n'a plus tellement de sens et n'est plus utile. Cette méthode de travailler est bien plus flexible.
Par contre, il y a certaines choses pour lesquelles l'historique a toujours du sens: tout ce qui est peinture ou assimilé.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question de n00b
Posté par David Tschumperlé (site web personnel) . Évalué à 8.
Petite question à ce sujet… L'édition non destructrice est intéressante, mais il me semble qu'elle se limite quand même à des filtres de traitement d'images "basiques", rapides à calculer. De même pour la fonctionnalité "preview on canvas" qui est poussée en avant pour les prochaines releases avec GEGL.
On imagine mal en effet devoir attendre 15 minutes (au hasard) le recalcul d'un rendu après avoir changé un paramètre d'un des filtres (parce que le graphe comprend un filtre très long à calculer, qui a été appliqué à la fin). Avez vous prévu quelque chose de spécial dans ce cas ?
Si non, cela veut-il dire que les opérateurs GEGL seront de toute façon limités à des traitements basiques, si on veut les rendre utilisables en pratique ?
Merci.
[^] # Re: Question de n00b
Posté par VictorAche . Évalué à 5.
Bah a priori, tu ne perds jamais de temps parce que tu fais les choses bien. Si tu modifies le deuxième filtre de ta pile de 8 filtres de 20 minutes chacun, t'iras quand même plus vite que si tu n'avais pas gardé le calcul du rendu après le premier.
"The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln
[^] # Re: Question de n00b
Posté par David Tschumperlé (site web personnel) . Évalué à 5.
C'est juste, mais ma question portait plus sur l'expérience utilisateur.
Avec ton exemple, il va certes attendre 140 minutes au lieu de 160, mais ça reste quand même 140 minutes :)
Un utilisateur non expérimenté risque de faire une drôle de tête si sa machine mets trop de temps à recalculer un rendu alors qu'il a juste changé le paramètre de variance de son flou gaussien, appliqué en tout début de pipeline (qui est un opérateur en soi immédiat à recalculer quand c'est appliqué "à part").
D'où ma question. Ca me parait pas si trivial de rendre fluide le tout.
Dans le futur, est-ce que chaque opérateur de traitement de GIMP sera un noeud GEGL ?
C'est ce qui a l'air d'être préconisé si on écoute les développeurs de GIMP actuellement.
Si c'est le cas, ce genre de problème pourrait rapidement se poser pour les noeuds un peu "lourds" à calculer, et également pour le "preview on canvas".
Est-ce qu'il y aura possibilité pour un noeud de se signaler comme étant gros consommateur de ressources ? Avez vous prévu des méchanismes spéciaux pour gérer ce genre de noeuds ?
[^] # Re: Question de n00b
Posté par Jehan (site web personnel, Mastodon) . Évalué à 8.
Oui et non. Oui, ça limite l'intérêt, et notamment clairement la prévisualisation en directe pourrait devenir une véritable plaie (bloquant l'UI et empêchant de configurer correctement son filtre si à chaque fois qu'on affleure même un slider, on doit se taper une prévis).
Ensuite non, la non-destructivité est quand même utile (selon moi) pour les filtres longs. Du moment qu'on gère bien toute la partie ennuyante (comme la prévisualisation, en ne l'autorisant pas sur certains filtres), il reste tout de même d'autres avantages bien réels. Par exemple, tu parles de changer le paramètre d'un filtre. Ben dans ce cas là, même avec la méthode destructive (annuler, refaire le filtre), on doit se retaper les 15 minutes de traitement du filtre. Ben au moins avec la méthode non-destructive, on peut le faire n'importe quand, même après plusieurs heures de travail et des centaines d'autres actions faites entretemps; donc revenir sur l'historique — si possible, des fois ça ne l'est même pas — en revient à perdre des heures de travail.
Je ne suis pas certain, mais il est clair que nous ne laisserons pas ce genre de problèmes arriver (ou par erreur, et dans ce cas là, ce sera à considérer un bug à corriger). Il faudra les traiter. Je peux imaginer plusieurs choses.
Déjà la détection: on peut ajouter une notion de coût (théorique, comme un paramètre disponible en introspection) à une opération (il me semble me rappeler que cela a d'ailleurs déjà été discuté sur IRC). Ainsi avant même de commencer une opération, on peut avertir l'utilisateur que la prévisualisation risque d'être longue pour certaines opérations (voire même l'interdire pour des opérations qu'on sait vraiment vraiment trop longue), ou bien même pour toute opération si on l'exécute sur une image de vraiment trop grande taille. Ensuite on peut aussi avoir, en plus, un timer qui prend la main quand une prév dure trop longtemps, et donne la possibilité à l'utilisateur de l'interrompre.
Ensuite comment gérer ces ops trop longues?
1/ On peut donc simplement interdire la prév automatique comme je disais.
2/ Mais on peut aussi permettre une prév explicite avec un bouton dans ce cas. C'est à dire que ça ne va pas re-rendre le résultat juste en bougeant un slider d'un micromètre (bon moyen de rendre une UI inutilisable). Par contre, l'utilisateur peut bouger ses boutons et sliders tranquillement, puis cliquer sur un bouton, aller prendre un café et revenir voir le résultat après 15 minutes. Éventuellement refaire des changements, etc. Ou sinon appliquer (ce qui sera instantané puisque tout est déjà calculé).
Cela reste toujours légèrement plus pratique et rapide que d'appliquer, annuler, rouvrir l'UI de plugin, réappliquer, réannuler… Pas énormément différent, hein. Mais un peu, selon moi.
3/ L'utilisateur peut supprimer la visualisation d'un filtre (avec l'icône "œil"). Ça permet de l'appliquer au début, mais ensuite de l'empêcher d'actualiser sans cesse la vue (surtout si on prévoit de peindre sur le calque de base, etc.).
4/ On peut aussi permettre d'appliquer un filtre (ou une liste de filtres) directement sur l'image (c'est à dire en destructif comme maintenant). En fait j'en ai jamais discuté avec les autres, mais personnellement cela me paraît une fonctionnalité évidente.
Il y a toujours des cas où appliquer un filtre est mieux, voire nécessaire. Par exemple si on souhaite peindre directement sur le rendu (et non sur le calque de base, ni sur un autre calque au dessus), il n'y a pas d'autres choix que d'appliquer le filtre pour qu'il ne fasse qu'un avec son calque. Blender par exemple permet de faire cela (on peut mettre des filtres genre miroir sur des objets 3D. Puis ensuite on l'applique, ce qui permet de travailler sur un côté de l'image différemment par exemple).
En tous cas, cela signifie qu'une architecture non-destructive n'oblige absolument pas à travailler non-destructif tout du long. L'utilisateur peut toujours revenir à une méthode de travail destructive.
5/ Enfin, en revenant sur la problématique des prévisualisations, il y a des moyens de les accélérer (en dehors de la solution d'optimiser les opérations elle-même bien sûr), notamment lorsque le viewport ne montre qu'une partie de l'image. Ou à l'inverse quand la vue de l'image est plus petite que la taille réelle du fichier à cause d'un zoom-out. Bon c'est pas moi l'expert, mais voici un email du mainteneur GEGL sur le sujet de l'accélération de la prévisualisation.
Ce sont des choses auxquels les divers développeurs réfléchissent beaucoup.
Non puisque comme je disais, on devrait toujours pouvoir les utiliser en destructifs à l'ancienne. C'est juste une question d'UI.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question de n00b
Posté par David Tschumperlé (site web personnel) . Évalué à 3.
Ok merci pour ta réponse, du coup ma deuxième question du dessus est inutile :)
[^] # Re: Question de n00b
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
Tu peux jouer un peu avec darktable qui fait uniquement de l'édition non-destructrice, y compris avec des opérations non-triviales sur les images. C'est un plaisir à utiliser. Côté performance, on ne perd pas vraiment :
Si on continue à travailler comme avant, on ne modifie que le dernier filtre de la pile, et si le logiciel est un peu intelligent il a en cache la sortie de l'avant-dernier filtre => chaque opération n'applique qu'un filtre, comme avant côté temps de calcul (mais plus gourmand en RAM).
Si on utilise vraiment le non-destructif, cf. la réponse de VictorAche : on utilise plus le CPU/GPU, mais ça reste beaucoup plus rapide que de tout ré-appliquer à la main.
Sauf erreur de ma part, Photoshop sait faire du non-destructif depuis des lustres et personne ne s'en plaint.
Je ne sais pas ce qui est prévu pour Gimp, mais par exemple avec darktable, par défaut, il n'applique le pipeline que sur la portion d'image visible ou bien il travaille sur une image avec résolution réduite si le facteur de zoom est petit (donc ça va toujours vite), mais le non-destructif fait qu'il peut ré-appliquer le pipeline sur l'image complète au moment de l'export (donc pas de compromis sur la qualité au final).
# Vagabondage
Posté par jon . Évalué à 2.
Rapidement, tu peux expliquer tes aventures de vagabondage ? (j'ai vagabondé un peu aussi il y a pas si longtemps que ça, et la photo rappelle des souvenirs… :)
Et j'imagine que coder ou quoi avec ce que tu as l'air d'avoir sur cette première photo, c'est difficile, voir pas vraiment d'actualité pendant ce genre de voyage/vagabondage. Comment ça se passe/s'est passé avec tes différents projets/contributions ?
[^] # Re: Vagabondage
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Salut,
Cette photo, c'était en Mongolie. J'ai vagabondé entre la France et le Japon pendant 6 mois, puis j'ai vécu au Japon, en Corée, en Nouvelle Zélande, où j'ai aussi pas mal bougé.
En effet je code pas, ou presque, quand je suis sur la route.
Ben tu mets en pause quand tu sais que de toutes façons, tu n'auras pas vraiment l'opportunité de contribuer. Par exemple à l'époque je contribuais beaucoup dans le monde XMPP. Ben avant de partir, j'ai quitté la XSF (ils ont assez de membres fantômes, pas la peine d'en rajouter un), de la même façon que j'ai démissionné de mon job ou que j'ai donné un préavis pour l'appart que je louais à l'époque. Y a pas vraiment de différence. :-)
Par contre une fois un peu plus posé, même si tu peux rester mobile et déménager tous les mois, rien n'empêche de contribuer avec même un petit portable léger et peu puissant. J'ai codé pendant plusieurs années sur un petit eeepc acheté au Japon. J'ai même codé dans une startup au Japon avec cet eeepc pendant plus d'1 an (avant qu'ils m'achètent un ordi puissant) où j'étais senior developer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vagabondage
Posté par Goffi (site web personnel, Mastodon) . Évalué à 8.
Salut,
il m'est aussi arrivé de coder en voyageant (principalement en australie), bon j'avais un van c'était un peu plus simple, mais sinon c'est dans les bibliothèque avec un pc portable léger le meilleur endroit: t'as du courant, des fois internet, une table et parfois du silence (y'en a qui aiment avoir de la musique pour bosser, moi il me faut du silence)…
[^] # Re: Vagabondage
Posté par tao popus . Évalué à 1.
Je me doutais en regardant la photo que c'était la steppe de Mongolie. Ça a du influencer le projet marmotte non ? :).
Je suis passé pour la deuxième fois en Mongolie-Intérieure il y a quelques mois, mais n'ai pas encore eu l'occasion de goûter à la marmotte. Est-ce qu'elle est très salée comme le mouton ? Je ne sais pas si c'est uniquement une habitude mongole ou l'influence des gens de la province voisine du Shanxi qui y sont nombreux et mangent aussi très salés et très gras (ils se sont en tout cas beaucoup influencés mutuellement). J'ai bien aimé l'alcool de lait (jument ou brebis) distillé et les bonbons de yaourt-fromage séché avec le thé au lait et millet frit.
Les Mongols disent que leur écriture (pas le cyrillique, l'écriture traditionnelle d'origine ouïghoure) est verticale parce que c'est plus facile pour écrire sur le cou d'un cheval. Ça marche peut-être aussi avec le code et la moto ? Un demi-clavier sur chaque poignée du guidon pour les longs trajets dans la steppe toute plate et ne pas s'endormir au volant comme le chauffeur du film Urga :).
[^] # Re: Vagabondage
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
Dans le sens où y a des Marmottes en Mongolie? Dans ce cas, non, car j'avais déjà ma Marmotte avec moi. Si tu regardes bien sur la photo, tu peux voir une petite peluche sur le guidon: mon copilote la Marmotte! Mais sinon oui, on voit régulièrement des marmottes dans ces coins de l'Asie centrale (pas les mêmes que les européennes).
Dans le sens où le film parle de vagabondage? Dans ce cas, oui forcément, c'est lié. J'aime me balader, donc j'en parle. J'aime les histoires d'aventure, donc c'est ce que j'écris.
Franchement je ne pense pas avoir jamais mangé de la marmotte (enfin j'espère!). Ensuite j'ai mangé des trucs non identifiés en Mongolie, notamment un jour où j'ai été hébergé dans une yourte après avoir fait chuté la moto en traversant une rivière (donc le moteur était inondé, me forçant à des réparations de fortune).
De manière générale, il me semble que les gens mangent surtout ce qu'ils élèvent. Certaines familles ont des moutons, donc ils mangent surtout du mouton et boivent du lait de brebis. Ceux qui ont des chèvres, pareil. Et ceux qui ont un troupeau de yak pareil. Les chevaux, pareil. Etc.
En tous cas, c'est quasi essentiellement une nourriture à base de viande rouge (pas beaucoup de verdure; jamais non plus de poisson a priori, même s'ils ont des lacs et des rivières; et du lait en boisson, fermenté ou non, plutôt que de l'eau…).
Alors j'ai pas vu ce film, mais en vrai c'est loin d'être de tout repos. Il n'y a pas de route, c'est que du sable à perte de vue. Et dans ce contexte, le sol est loin d'être "plat". Il en a l'air, et il l'est "globalement", mais dans le détail, c'est juste une succession de bosses et de trous, parfois très dangereux. Je devais m'arrêter environ toutes les heures et faire le tour de la moto avec un tournevis pour repérer et revisser les diverses vis qui se dévissait par les vibrations seulement. J'y allais avec toutes mes forces possibles, mais même là, ça se dévissait encore. Et j'en ai perdu quand même pas mal dans le process.
Pour la petite histoire, j'ai dû perdre une bonne vingtaine de vis sur la moto, et le garage où j'ai fait révisé/réparé la moto au Japon a trouvé même quelques vis internes tombées au fond du moteur (j'ai eu de la chance donc que ça me pête pas à la figure; et évidemment ces vis là, je pouvais pas les revisser moi-même).
Quand tu conduis en Mongolie, au Kazakhstan, ou même en Russie, tu as 2 choix: rouler très lentement (40/50 km/h), et dans ce cas, c'est extrêmement inconfortable (tout tremble constamment), mais c'est plus sûr; ou tu vas vite, et à ce moment, il y a un palier (vers les 90 km/h) où tu te mets à "voler" au dessus des trous. Il n'y a plus de tremblement, ni de vibration excessive (enfin si, mais bien plus confortable), tu n'as plus mal. Par contre c'est très effrayant et tu dois garder une concentration très appuyée pendant toute la conduite (tu te prends un trou un peu trop grand que tu n'as pas vu venir dans ces steppes, à l'allure lisse de loin sous le soleil, et c'est fini pour toi. Y aura probablement personne pour te venir en aide).
Très vite, on se met à prendre ce second choix, car conduire des jours en vibrant et en ayant mal partout, c'est peu tenable. Mais alors on fatigue aussi très vite (conduire bien, c'est à dire concentré et avec sérieux, c'est pas reposant!).
Enfin voilà, tout ça pour dire: non tu t'endors pas au volant. Et quand ça arrive, c'est qu'il est l'heure de s'arrêter, faire une pause, voire de sortir le sac de couchage si c'est le soir.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vagabondage
Posté par tao popus . Évalué à 2.
Tout d'abord, grand merci pour la réponse, c'est vrai que la route que j'ai faite en mongolie-Intérieure était majoritairement bitumée (avec lampadaires éolien + panneau solaire) et en minibus et c'est vrai aussi que ça vibrait bien dès qu'on prenait les vrais chemins de steppe. Sans doute que le gros camion dans Urga (1991, 25 ans) réparti mieux sur les roues les nombreux trous et bosses des chemins de steppe. Dans le film Urga, le Russe qui conduit le camion s'endort et se plante dans un lac, il a vraiment de la chance de tomber sur une famille qui vit pas loin. C'est sans doute avant tout une façon pour le réalisateur de montrer la vie des nomades des steppes et les échanges avec les voisins russes et chinois han. Le soleil dans les yeux => problème quand on voyage vers l'Est le matin ça doit être plus sympa entre Cap-town et Tromsø sur ce point. Un type à fait Mont-St Michel Fuji San en vélo couché à voile dans le genre. Je suis très admiratif de vous deux.
Effectivement, sauf depuis peu avec le passage au capitalisme sauvage après des dizaines d'années de communisme, et donc, appauvrissement subite pour les moins aisés, on ne mange traditionnellement/culturellement que de la viande qui broute de l'herbe en Mongolie (façon locale d'être végétarien puisqu'il n'y a pas de fruits/légumes). Une partie du Kazakhstan et Kirghizistan est culturellement quasi-mongole (les restes turco-mongols). Comme le poisson peut potentiellement manger des insectes, il est banni de la nourriture. Le lait de chamelle semble bien répandu dans le Sud-Ouest aussi. On voit que les gamins de 3 ans maîtrisent le chameau comme ici le vélo dans ces régions (voir « l'histoire du chameau qui pleure ») :) et du rennes d'ans d'autres (notamment chez les evenk(i)s. La marmotte doit être un des rares produits de la chasse. Il y a eu un carnage cette année, suite à une épidémie (de peste je crois).
À cheval dans la steppe on a la même sensation qu'à moto visiblement, le trot c'est essoufflant, le galop ça plane. Le Chameau je n'ai fait que rapidement (dans le temps) et lentement (dans la vitesse) dans un petit désert de sable entre Ordos et Baotou, ça secoue plus, mais on est en sécurité entre les deux bosses contrairement au dromadaire où l'on se retrouve au dessus de la bosse. Pas de problèmes de visses sur ces bêtes, mais ça serait probablement moins facile pour le passage à la frontière (quarantaine) sur un si long trajet et probablement moins rapide et d'autres ennuis en perspective.
[^] # Re: Vagabondage
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Bon ça c'est une spécificité générique de l'équitation, dans la steppe ou ailleurs, aucune différence. Le trot, c'est toujours inconfortable. Pour être confortable, il faut soit aller au pas, soit au galop (mais là aussi il y a une forme de frayeur). Par contre un cheval ne peut pas non plus galoper trop longtemps (c'est comme si on nous demandait de courir à fond tout le temps, j'imagine). C'est pourquoi en général, voyager à cheval, ça signifie surtout voyager au pas. C'est pas énormément plus rapide qu'à pied (mais moins fatigant).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Merci.
Posté par Tanouky . Évalué à 10.
Ce n'est pas la première fois que je te lis et je trouve toujours ton avis très intéressant. Gimp, malgré quelques défauts très rarement handicapants, est un logiciel que j'affectionne particulièrement. J'en apprécie l'interface, les outils, la stabilité (bah oui, je le trouve très stable, personnellement !), l'efficacité. Ça m'a ouvert un monde graphique que je ne soupçonnais pas et dans lequel je me trouve plutôt bon (je suis une merde, mais ce niveau me suffit pour mon usage).
Je vagabonde beaucoup, depuis une douzaine d'années maintenant. Je te félicite d'être parvenu à trouver le temps de profiter du monde et en même temps, de lui être utile !
Merci à toi, j'espère pouvoir te rendre la pareille, un jour.
[^] # Re: Merci.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
De rien. Si vraiment tu veux absolument m'aider et que tu as un peu de sous, contribuer au projet ZeMarmot est le moyen idéal de le faire! :-)
Non seulement il permettra de faire un film d'animation vraiment cool — et en plus Libre! — mais en plus ça me fera utiliser plus de temps pour améliorer GIMP. :-)
Enfin je dis ça… j'dis rien hein! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci.
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Résultats de la campagne de financement ZeMarmot: 154%, 330 contributeurs, 13875€.
[^] # Re: Merci.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
Et on remarque que 13875 / 330 ~= 42 € par personne!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci.
Posté par Tanouky . Évalué à 1.
Je dois t'avouer que le projet ne m'intéresse pas grandement (mais c'est très personnel). Je vais y réfléchir.
# Merci
Posté par grissouris . Évalué à 10.
ça m'a changé la vie de ne plus être obligée de fermer Gimp à chaque fois que je voulais brancher la tablette graphique. je suis très contente de pouvoir te remercier.
[^] # Re: Merci
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 30 juin 2015 à 19:37.
De rien! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# contenu inutile.
Posté par kowalsky . Évalué à 10.
Apparemment les Devs GIMP manquent de remerciement, donc je fais ce message un peu inutile.
Merci les gars !
J'utilise GIMP depuis presque 10 ans, j'ai réalisé un grand d'image avec, de la retouche de dessins ou photos, réalisation d’icônes, réalisation de site web et je ne sais quoi d'autre encore avec GIMP. Donc merci.
GIMP, ça fait partit des murs, Linux¹ ne serait pas Linux sans lui. Je sais que le passage de Windows à Linux n'est pas une fin en soi, mais la migration deviendrait impossible pour certain utilisateur.
Les critiques de GIMP, c'est normal, il n'est pas parfait, mais franchement, il fait parfaitement le boulot. Mais il faut savoir rester constructif.
L'interface graphique ?
Il faut s'y faire, mais comme tous les logiciels un peu complexe.
Au début, des fois la barre d'outils disparaît sous une autre fenêtre, mais bon :
Clique droit pour la garder au dessus ou redimensionnement des fenêtres. Pas de quoi rendre GIMP inutilisable comme certain le disent.
La boite enregistrement ?
Franchement, le logiciel fait un milliard de choses, il est scriptable, multi-platforme (réellement, pas juste Windows/Linux), toussa toussa et les gens butent la dessus pour dire GIMP çaÿdeulamaÿrde? C'est juste des trolls baveux.
En fait je ne me souviens même pas de la première fois ou j'ai été confronté au "problème", mais ça a du être du genre :
Le menu a changé, je re-regarde, ah y a export.
Bim, ça marche. Au pire une recherche sur le net et c'est plié.
L'utilisateur qui n'arrive pas à se débrouiller avec ça ne peut pas utiliser GIMP de toute façon.
Je le redis au cas ce n'était pas clair : Merci !
¹L'ecosysteme, pas le noyau, je vois les trolls venir.
[^] # Re: contenu inutile.
Posté par Tanouky . Évalué à 10.
Tu es au courant que depuis la 2.8, tu as un mode Fenêtre Unique ? :) (Je dis ça par rapport à ta boîte d'outils qui se glisse sous une autre fenêtre)
Perso, le Enregistrer/Exporter, j'ai rarement vu un débat plus stérile et inutile. Du commérage de capricieux.
[^] # Re: contenu inutile.
Posté par whity . Évalué à 3.
En fait, pas tant que ça…
Le problème est que gimp est un « alien » quelque soit l’environnement de bureau utilisé (y compris mac / windows). Que ses menus et son ergonomie générale ne sont pas en cohérence avec le reste du bureau.
Inkscape fait la même différence enregistrer / exporter, mais d’une manière différente. Est-ce qu’elle est meilleure ou moins bonne, j’ai envie de dire que ça ne m’intéresse effectivement pas trop. Ce qui me gêne, en revanche, c’est d’avoir deux manières différentes, d’avoir des applis qui ne se comportent pas de la même manière.
Sous debian wheezy, faire alt-F4 alors qu’une image était ouverte fermait l’image, pas gimp. Je remercie le gars qui a corrigé ça pour que sous jessie le comportement soit celui attendu (gimp se ferme, éventuellement avec une boîte de confirmation s’il y a des modifs en cours), parce que le plus gênant, ce n’est finalement pas tel ou tel comportement, mais bien les différences de comportement entre les applications.
À terme, j’espère que gimp arrivera à un niveau de séparation outils/interface tels que qui que ce soit pourra pondre et maintenir une interface réellement adaptée à chaque environnement majeur. C’est un sacré chantier par contre et une charge supplémentaire par la suite, je comprends donc que ça ne soit pas dans les priorités.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: contenu inutile.
Posté par Tanouky . Évalué à 2.
Cela pointe un peu du doigt le manque d'homogénéité de tous les bureaux Linux, finalement ! J'ai pris l'habitude d'avoir des applis pour lesquelles il fallait réapprendre telle chose ou telle chose, pour cela que je considère le débat comme…vraiment non-prioritaire.
Néanmoins, je comprends ce besoin, mais en utilisant des logiciels comme Blender, qui demande de connaître plusieurs centaines de raccourcis claviers pour être efficace, sans faire attention à l'environnement de bureau, aux autres types de logiciels, etc, hé bien, j'ai été un peu rôdé.
Perso, la séparation me convient très bien, et si Gimp poursuit son évolution (images sans pertes, etc.), je comprendrai encore davantage la logique d'avoir deux options, l'une destinée à l'enregistrement et au travail, l'autre à l'utilisation finie d'une image. En attendant, les deux options fonctionnent, j'estime que c'est le plus important.^
(Je ne suis pas encore passé à Jessie ! Merci de prévenir, j'aurai pu être surpris.^ )
[^] # Re: contenu inutile.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
Tout à fait!
C'est exactement cela. Les "images" GIMP (XCF) sont à considérer comme des projets en cours. Un format de travail. Ce n'est pas à considérer comme un standard (ce n'en est pas un), cela suit les évolutions logicielles de GIMP même, et ne peut être comparé à un format d'image (PNG, JPG, whatever…).
C'est comme Blender. Enregistrer, c'est du .blend (le format de travail qui suit les logiques logicielles de Blender). Ça n'empêche pas d'exporter en Collada (le standard pour la 3D) ou d'autres formats (souvent proprios).
En effet comme tu le notes, l'édition sans perte est une des énièmes très bonnes raisons: les formats d'image n'ont de concept de calque d'effet. Il faudra donc du XCF (enregistrer en PNG, jpg ou autre impliquera d'appliquer les effets et donc perdront de l'info). De même que la haute précision de couleur (PNG par exemple prend en charge jusqu'à 16 bits. GIMP ira bien plus haut).
Enfin il y a l'UI elle-même. À l'heure actuelle, on s'est contenté d'utiliser la même UI (puisque historiquement c'était la même chose), et donc ça perturbe les utilisateurs qui se disent "ben c'est la même chose". C'est compréhensible. Mais l'idée c'est qu'à l'avenir on aura 2 UIs différentes et adaptées. En fait j'ai même déjà du code
stash-équi commence le travail, mais faut que je trouve le temps de finir.Par exemple beaucoup de gens demandent une gestion de "l'export pour le web", c'est à dire notamment changer la résolution d'une image très haute rés, appliquer éventuellement quelques filtres, etc. À l'heure actuelle, on doit faire ce genre de choses dans l'image même, puis surtout ne pas oublier de les annuler après export de l'image (pour ne pas engendrer de perte de qualité, surtout quand l'image est aussi destinée pour de la haute résolution). Ben je pense que ce genre de choses devraient être faisable aisément dans une UI séparée qui gère ce genre de choses (comme un graphe d'effet à appliquer seulement dans un mode d'export particulier qu'on peut sauver).
Ce sont des exemples mais on peut en trouver beaucoup d'autres. Sauver et exporter sont vraiment des processus très différents. Simplement nous n'avons pas encore l'UI. C'est la base de cette évolution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: contenu inutile.
Posté par antistress (site web personnel) . Évalué à 7. Dernière modification le 30 juin 2015 à 19:50.
Ha oui, il est bien ton exemple (blender toussa)
je commence à comprendre pourquoi ça ne me choque pas : j'ai l'habitude des UI des logiciels de montage vidéo, où "enregistrer le projet" n'est pas "exporter".
En fait c'est peut être ça le malentendu entre ceux qui comprennent le système et ceux qui ne le comprennent pas : ça dépend si tu as connu des logiciels qui demandent un travail important avant export, où il serait suicidaire de ne pas sauvegarder le projet à chaque fois qu'on ferme l'appli si on veut pouvoir revenir dessus sans tout reprendre…
[^] # Re: contenu inutile.
Posté par Watchwolf . Évalué à 1.
c'est en effet compréhensible vu comme ça.
Il aurait être jsute fallu attendre d'avoir la nouvelle UI pour éviter les remarques négatives ;)
[^] # Re: contenu inutile.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
En même temps, l'UI est la partie visible de l'iceberg. Il reste que le format XCF suit parfaitement les fonctionnalités de GIMP et donc est le seul format de projet valable pour du travail en cours. La haute précision ou le non-destructif ne sont pas encore là, mais il y a déjà foultitude d'autres fonctionnalités qui nécessite XCF.
Par exemple quel format garde la sélection en cours? (permettant de commencer à travailler sur une sélection complète, la laisser en suspens, sauver le fichier, et y revenir plus tard là où on en était)
Quel format bitmap a aussi des notions (basiques certes, mais existantes) de vectoriel?
Quel format garde aussi des masques de calques?
Quel format garde des calques de texte?
Très peu de format ont même la notion de calque tout court.
Peu de format ont la prise en charge de la transparence (et quand ils l'ont, pas forcément avec la précision de GIMP).
Etc. etc. etc.
Je ne prétends pas connaître tous les formats et certains ont peut-être certaines de ces notions, mais aucun format n'a tout ce que fait GIMP (seul XCF puisqu'il est calqué sur les fonctionnalités).
En fait, je n'étais pas présent dans la période d'avant la séparation sauver/exporter, mais je sais qu'il y avait énormément de personnes qui venaient se plaindre car ils avaient perdus une partie de leur travail en "sauvant" dans un format d'image classique (que ce soit PNG ou jpg).
Par exemple, le classique, ils rajoutent du texte au dessus d'une image, exportent en PNG (car on leur dit "PNG est non destructif"), et — paf! — le texte devient une image non éditable! Après ils viennent se plaindre que le texte ne peut plus être corrigé, qu'ils doivent tout refaire de zéro et ont perdu des heures de travail.
Il faut donc bien comprendre: on sauve son travail en cours, et on exporte un "cliché" à un instant T. Comme on exporterait une vidéo en mpg/avi/whatever, ou encore on compilerait un binaire exécutable à partir d'une source texte. L'export c'est pour l'instantané prêt à la diffusion/utilisation. La sauvegarde, c'est le projet, le travail.
Le changement d'UI sera la cerise sur le gâteau, absolument pas le cœur de la fonctionnalité. Et il faut changer le cœur avant de rajouter la cerise (un peu comme GEGL, la prochaine version aura un nouveau cœur mais l'UI ne le réflètera pas encore, c'est à dire pas d'édition non destructrice visible. Ça arrive forcément après).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: contenu inutile.
Posté par whity . Évalué à 1.
Certes, mais…
Libreoffice a exactement les mêmes contraintes (j’ouvre un csv sous libreoffice calc, je rajoute une colonne avec des formules dedans, je choisis enregistrer), mais un comportement différent (ie il affiche une boîte de dialogue « êtes-vous sûr de vouloir faire ça, vous risquez de perdre des données » avec un bouton « Enregistrer en ods ».
Je ne prétends pas que cette solution est meilleure que celle de gimp. Je me désole juste que les deux logiciels ne se comportent pas de la même manière, et que je ne vois pas poindre d’issue à cette situation qui est pourtant « hostile » vis à vis de l’utilisateur final.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: contenu inutile.
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Comme souvent, une question de choix de mots peut avoir des conséquences importantes.
Tu viens d'écrire sauver/exporter alors que je vois enregistrer/exporter dans les menus. Historiquement c'était enregistrer qui conduisait à toutes les options, ce qui est une cause d'incompréhension.
Le fait d'utiliser le mot sauver comme tu viens de le faire est très important. Pour ma part j'ai eu dans mon travail un souci analogue avec le mot refusé. Les textes officiels en aéronautique et spatial disent qu'un contrôleur peut refuser un produit. Ce produit va alors à la destruction. J'avais fait un logiciel qui vérifiait toutes les caractéristiques des produits et si c'était bon, proposait au contrôleur de l'accepter. Si tout n'était pas parfait, le logiciel listait les problèmes puis proposait de refuser le produit (ou le laisser en l'état). Comme les contrôleurs utilisaient souvent cet outil pour faire le point sur les produits, le logiciel leur posait chaque fois la question sur le refus. Certains confirmaient le refus car ils refusaient d'accepter le produit pour le moment. Le logiciel verrouillait les données et considérait le matériel comme mort.
J'ai changé plusieurs fois l'ordre et le texte des questions puis demandé d'écrire "REFUSE" puis de confirmer… Rien ne fonctionnait bien. Pendant trois ans, j'ai eu besoin de ressusciter des morts par erreur jusqu'au jour où j'ai demandé d'écrire "REBUT". Avec une bonne compréhension il n'y a plus eu d'erreur.
Voila donc pourquoi, je préfère sauver à enregistrer !
Pour les 4 sens des mots : http://pjarillon.free.fr/redac/4-sens
C'est aussi pour cela que je me suis intéressé à la définition de l'interopérabilité.
[^] # Re: contenu inutile.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
J'utilise la version anglaise, et j'ai juste fait une traduction perso (et mauvaise) de save/export. En VF, enregistrer/exporter ne me choque pas comme étant la bonne trad.
Ensuite de manière générale, ce que tu dis sur les mots est juste. Comme on le dit en général dans le développement d'application (à moitié blague, à moitié sérieux), le plus dur en informatique, c'est de nommer les choses (le code lui-même comme le texte visible d'ailleurs).
Par contre cela ne s'applique qu'à moitié au problème ici, puisqu'il n'est pas spécifique à la VF. Et je doute sincèrement que si on utilisait sauver/exporter, soudainement tous les francophones contre la fonctionnalité disent soudainement "ah ok je comprend mieux, c'est bon alors" (mais je veux bien me tromper). Par contre on aurait soudainement beaucoup de nouveaux en colère parce que "sauver" est un faux-ami et pas la bonne traduction pour "save". On sauve quelqu'un qui est en danger, on ne "sauve" pas du travail.
Tout ça pour dire que j'ai simplement fait une erreur de traduction dans mon commentaire, et je ne pense pas vraiment que rendre mon erreur de trad officielle soit la vraie solution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: contenu inutile.
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Effectivement save c'est le premier mot de SOS !
Pourquoi pas sauvegarde ? Il me semble que toutes ses homonymies vont dans le bon sens.
[^] # Re: contenu inutile.
Posté par whity . Évalué à 3.
Encore une fois, parce que le terme usuel qu’on trouve partout, dans tous les logiciels, est « Enregistrer ». Que « Sauvegarde » évoque plutôt une copie de sauvegarde, quelque chose qu’on fait à côté de son document de travail, pour en conserver une copie en cas de pépin.
Donc non, changer pour « sauver » ou « sauvegarder », ce serait pire :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
# Quelques fiches techniques libres
Posté par Space_e_man (site web personnel) . Évalué à 10.
Ma petite pierre à l'édifice … qui ne devrait n'être qu'un début…
→ http://www.spaceeman.be/ftl/#GIMP
# Contribution
Posté par Axone . Évalué à 4.
Cet interview m'a décidé à contribuer à ZeMarmotte. J'ai donné !
# Merci !
Posté par Noobinux . Évalué à 1.
Merci Jehan pour tout ton travail !
Je suis un des contributeurs de ZeMarmot, et j'espère sincèrement que Gimp sera amélioré par la même occasion ! :)
# GIMP 2.10
Posté par Pascal Obry (site web personnel) . Évalué à 2.
J'ai une question qui me brûle les lèvres Jehan… La sortie de la 2.10 est à compter en jours, semaines, mois ou années? Je suis un dev, je sais que ce n'est pas facile de répondre, mais généralement on a une petite idée de l'ordre de grandeur et c'est vraiment la seule chose que je cherche a savoir. En cherchant les forums sur le net c'est pas clair… Alors une idée? Ou c'est la réponse habituelle… Lorsque ce sera prêt!
Merci d'avance!
[^] # Re: GIMP 2.10
Posté par Jehan (site web personnel, Mastodon) . Évalué à 8.
Oui bien sûr, je peux répondre. La prochaine sortie est à compter en [bzzz bzzz interférences bzzz bzzz]. ;-)
Plus sérieusement, je n'en ai aucune idée. On peut essayer de pousser mais au final le mainteneur choisit. Aussi GIMP 2.10 est dans une situation très particulière avec le passage à GEGL. Nous avons quelques fonctionnalités "cassées" par ce port, et s'il y a bien une chose que les utilisateurs ont du mal à encaisser, ce sont les régressions.
En tous cas, je suis moi-même complètement "pour" qu'on arrive à accélérer les sorties, comme je le dis dans l'interview. Et j'ai fait rajouter l'item "proposition de passer en mode sortie rapide" pour notre réunion à LGM 2014. Ce qui en est ressorti, c'est que les autres dévs ne sont pas contre, mais cela devra commencer à partir de GIMP 3.0, à cause du passage à GEGL, puis du passage à GTK 3.0. Après ces 2 ports, je pousserai vraiment pour passer à des sorties rapides, et qu'on adapte notre infrastructure de tests et de sortie s'il le faut.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP 2.10
Posté par Pascal Obry (site web personnel) . Évalué à 3.
Merci pour ta réponse… mais évite de donner les informations importante en passant dans un tunnel car là on a perdu l'essentiel :)
# Michael Schumacher, ce farceur !
Posté par akh2020 . Évalué à 1.
«Michael Schumacher par exemple est clairement l'administrateur de GIMP, s'occupant de toute tâche administrative (comme la gestion financière, les relations publiques ou notre relation avec GNOME).» => «Michael Natterer par exemple […]» ?
À part ça, c'est édifiant de constater que finalement, pour un logiciel aussi connu dans le milieu, il y ait finalement si peu de développeurs. Surtout quand on met ça en regard de le nombre de détracteurs dont l'unique argument est que «GIMP est sans doute bien, mais l'interface est pas nulle comparée à photoshop lol»…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.