GIMP 2.10.14 et 2.10.18 : sans limites

• # The GIMP Foundation ?

  Posté par Nico7as le 21 mai 2020 à 11:54. Évalué à 5.

  

  Attention, question N00b!

  Blender et LibreOffice sont respectivement protés par The Blender Foundation et The Document Foundation, et me semblent être des projets références dans le libre.

  Que pourrait apporter la création d'une "The GIMP Foundation" ou "The Image Manipulation Foundation" pour porter le développement de GIMP, et des projets connexes (G'MIC, GEGL, etc…)

  cela a déjà été envisagé?

  • [^] # Re: The GIMP Foundation ?

    Posté par claudex le 21 mai 2020 à 12:52. Évalué à 7.

    

    Blender, je connais moins. Mais The Document Foundation, elle a été mise en place pour gérer les différents contributeurs et les entreprises participantes. Ici, ils sont 3, donc ils doivent arriver à s'organiser. Ils ont aussi une structure pour recevoir de l'argent. Qu'est-ce que tu attends donc d'une fondation GIMP ? Je ne vois pas bien ce que ça apporterait à part beaucoup de perte de temps administrative.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: The GIMP Foundation ?

      Posté par Nico7as le 21 mai 2020 à 14:34. Évalué à 3.

      

      Je me dis qu'une fondation peut être perçue différemment d'un groupe de dev soutenus deci delà par des entitées plus ou moins confidentielles, comme LILA.
      Une fondation renverrait une certaine image ambitieuse, rassurante pour de nouveaux contributeurs, financiers ou développeurs.
      Dans un premier temps, ce serait surtout ça, une sorte de stratégie marketing, mais qui pourrait préparer à un grossissement réel, avec une organisation déjà anticipée dans l'organisation de la fondation.

    • [^] # Re: The GIMP Foundation ?

      Posté par marty314 le 21 mai 2020 à 21:07. Évalué à 1.

      

      Je pense que le côté fiscal d'une fondation d'entreprise peut être très intéressant pour le financement d'une oeuvre commune et je pense que c'est son essence même…

• # Bravo

  Posté par jpaul le 21 mai 2020 à 12:36. Évalué à 10.

  

  Franchement je suis admiratif de projets comme Blender, Gimp, Wikipedia ou Wine (entre autres bien sûr, la liste est longue) qui traversent les décennies en continuant sans arrêt à s’améliorer. Vous avez littéralement créé des dizaines de milliers de vocations, probablement sorti des gens de la misère, « juste » en leur rendant accessible un logiciel dont les concurrents ne sont accessibles qu’aux gros portefeuilles.

  Bravo aux contributeurs, vous faites partie de ces gens qui redonnent foi en l’humanité.

  • [^] # Re: Bravo

    Posté par mothsART le 21 mai 2020 à 19:53. Évalué à 4.

    

    Admiratif également et utilisateur régulier de Gimp : je ne pourrais plus m'en passer.

    Je fais principalement du pixel art avec ces derniers temps.
    Quand j'ai débuté, on m'avait conseillé Aseprite mais finalement, je n'y ai jamais trouvé mon compte : je suis plus productif (par habitude ou pour d'autres raisons, difficile de trancher) sur Gimp.

    Peux-être le seul bémol serait d'avoir une config de Gimp uniquement pour ce type d'usage : y'a plein d'outils qui ne servent pas ou peu dans ce cadre.

• # Traduction approximative

  Posté par rmfx le 21 mai 2020 à 20:19. Évalué à -10.

  

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

  "Un nouveau filtre de Carte normale (Normal map) fait son apparition."

  Vous avez vraiment traduis normal map par carte normale dans GIMP aussi?
  Parce que dans ce contexte, map en français signifie texture.

  • [^] # Re: Traduction approximative

    Posté par WrathOfThePixel le 21 mai 2020 à 22:53. Évalué à 5.

    

    Non, en anglais, texture se dit… texture.
    Le "mapping" tel qu'utilisé en 3D se rapporte aux coordonnées de la texture. Une "normal map" désigne les coordonnées des normales (qui sont donc des vecteurs) à un point donné de la texture. Parler de carte est pas si déconnant, même si c'est la première fois que je vois ça aussi (je travail peu voire pas avec des logiciels en français cependant, je connais mal l'usage).

    • [^] # Re: Traduction approximative

      Posté par rmfx le 21 mai 2020 à 22:59. Évalué à -5.

      

      texture (au sens image avec des donnes) est "texture map" en anglais.

      Donc map est une contraction qui veux aussi dire texture dans le jargon. Je suis infographiste professionnel, donc plutôt bien place pour connaitre les termes, et on dit souvent on a "update the maps" pour dire on a update les textures.

      Carte de normales est just totalement ridicule comme traduction en tous les cas.

      • [^] # Re: Traduction approximative

        Posté par WrathOfThePixel le 22 mai 2020 à 12:54. Évalué à 10. Dernière modification le 22 mai 2020 à 12:58.

        

        Il n'y a pas vraiment concensus sur la question. Le terme texture lui même tombe de toutes façons en désuétude au profit de material, plus précis. Un matériau est composé de différentes maps, nommées différement suivant les softs utilisés. Certains appelent (de moins en moins) "texture map" ce que d'autres vont appeller albedo, ou diffuse, ou simplement color, on trouve aussi la normal ou bump map, la roughness map, displacement map, et d'autres encore. J'ai en effet trouvé un exemple où le terme map etait interchangé avec texture, mais c'est à mon sens un abus de langage, qui survit de l'époque ou on se contentait de caler un bitmap sur les polygones, et job done. Ce temps est révolu et le terme est amené à disparaître à plus ou moins longue échéance, à mon avis.

        Ah, et je ne suis pas moi même boulanger depuis plus de 20 ans, je sais aussi de quoi je parle, s'il faut vraiment faire péter l'argument d'autorité.

        T'as un avis sur la question de la traduction, c'est très bien, mais comme le disais soit Voltaire soit Franklin, je sais plus : Les avis sur internet, c'est comme les anus, tout le monde en a un (et personne ne veut l'entendre).

        J'arrête de feeder maintenant.

  • [^] # Re: Traduction approximative

    Posté par Jehan (site web personnel, Mastodon) le 21 mai 2020 à 23:15. Évalué à 10. Dernière modification le 21 mai 2020 à 23:18.

    

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

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

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

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

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

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

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

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

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

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

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

    • [^] # Re: Traduction approximative

      Posté par barmic 🦦 le 22 mai 2020 à 07:55. Évalué à 6.

      

      En plus de ce genre de communication (qui n'existe pas que pour krita), il y a aussi je pense un coté grégaire : si tu n'utilise pas le même outil que moi il faut que je t'explique pourquoi le miens est meilleur. C'est très dommage, ça crée des clivages artificiels. Je comprends qu'on veuille valider et faire valider nos choix et aussi qu'on crée un affect avec les logiciels que l'on utilise, mais c'est dommage d'aller jusqu'à faire de l'entrisme ou au dénigrement.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Traduction approximative

        Posté par Anonyme le 22 mai 2020 à 09:03. Évalué à 10.

        

        Bah c'est surtout que comme l'a dit Jehan, les deux softs ne font pas exactement la même chose. Krita est plus axé peinture numérique/illustration, Gimp est plus axé infographie. Perso j'utilise les deux à différentes étapes et pour différents travaux,selon les forces de chacun. Pas besoin d'être un « infographiste professionnel » pour constater qu'il n'y a pas de "concurrence", pas plus qu'il y en a entre les différents outils de Corel ou entre ceux de Adobe.

        • [^] # Re: Traduction approximative

          Posté par alex666 le 23 mai 2020 à 15:02. Évalué à 5.

          

          En tout cas, pour mon usage (photographie), il n'y a pas photo: sans Gimp, je ne saurais vraiment pas comment faire, sauf à nous adapter, mon portefeuille (je donne qq sous à Gimp de temps en temps) et moi-même, à certains logiciels privateurs trop bien connus.

    • [^] # Commentaire supprimé

      Posté par Anonyme le 22 mai 2020 à 11:16. Évalué à 4.

      

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Traduction approximative

        Posté par Jehan (site web personnel, Mastodon) le 22 mai 2020 à 12:50. Évalué à 10. Dernière modification le 22 mai 2020 à 12:55.

        

        Salut,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        On y lit, entre autres:

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

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

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

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

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

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

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

        • [^] # Commentaire supprimé

          Posté par Anonyme le 22 mai 2020 à 14:22. Évalué à 7.

          

          Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Traduction approximative

        Posté par Noyal le 22 mai 2020 à 21:39. Évalué à 10.

        

        Et quand je lis la réponse que tu as faite quant à l'existence de Glimpse sur LinuxFR, je te prie de me pardonner, mais j'ai l'impression que c'est un peu l'hôpital qui se fout de la charité, à attaquer sur ci, sur ça, sur le choix de faire leur GUI, etc…
        Même si le fork ne s'est pas fait dans les conditions les plus idéales, il faut respecter leur travail.

        Tu te fiches de qui? Ça a été dés le départ une campagne de dénigrement de GIMP. Ces personnes n'ont jamais contribué et sont d'ailleurs à peine identifiées.

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

        Va faire un petit tour sur le repo de Glimpse. Tu n'y trouveras aucuns nouveau code, les commits se limitent à des substitutions du mot Gimp et du packaging et ce, depuis 1 an.

        @Jehan ne te justifie pas, stp.

        • [^] # Commentaire supprimé

          Posté par Anonyme le 23 mai 2020 à 22:51. Évalué à -10.

          

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Traduction approximative

            Posté par Jehan (site web personnel, Mastodon) le 24 mai 2020 à 01:08. Évalué à 10.

            

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

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

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

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

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

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

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

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

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

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

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

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

            • [^] # Commentaire supprimé

              Posté par Anonyme le 24 mai 2020 à 11:42. Évalué à -2.

              

              Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Traduction approximative

        Posté par Thomas Debesse (site web personnel) le 26 mai 2020 à 22:58. Évalué à 10. Dernière modification le 26 mai 2020 à 23:00.

        

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

        Là faut arrêter, j’ai pris la peine de consulter les commits de Glimpse et d’analyser leur activité. En gros le premier commit avant de faire quoi que ce soit ça a été pour demander des sous, et depuis c’est une cacophonie de commits qui ne font rien fonctionnellement. Imagine tu recrutes un développeur et pendant des mois tout ce qu’il fait c’est installer des IDE, tester des plugins, configurer son thème de coloration syntaxique et les couleurs du terminal, renommer ses dossiers, réorganiser les icônes de son bureau… Le comportement de l’équipe de Glimpse c’est ça.

        Et au delà de la diffamation faite par les gens derrière le projet Glimpse, le fait que la licence libre permette de forker GIMP ne signifie pas que le comportement de l’équipe de Glimpse ne relève pas du parasitisme. Si la GPL ne parle pas d’autre chose que la modification, distribution etc. du programme c’est parce que le reste ne relève pas de sa juridiction.

        Perso quand j’ai vu la réponse de Jehan je me suis dit qu’il aurait pu économiser son temps, pas en dire autant. Mais il a raison de réagir. Il répondait à :

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

        OK, à première vue certains pourront tenter de justifier ces propos en disant que ça signifie « Il a dit que Krita se révélait plus attractif pour beaucoup de gens ». Je ne vais pas me voiler la face et je vais analyser cette affirmation plus en profondeur.

        Cette personne affirme deux choses négatives concernant GIMP : « GIMP n’est pas une référence », « GIMP a perdu en référence ». Ces affirmations sont fortes, qu’elles soient vraies ou non, on ne peut pas affirmer comme ça de telles affirmations sans les défendre sérieusement. Observons maintenant l’argument proposé pour soutenir ces affirmations : « Krita se révèle plus attractif ». Puisqu’il s’agit d’une comparaison, cela signifie aussi cela : « Krita se révèle plus attractif que GIMP ».

        Et je ne me soucie pas de savoir si c’est vrai, je constate que c’est une affirmation auto-justifiante et irréfutable et c’est un procédé malhonnête. Ce qui est affirmé sans preuve peut être nié sans preuve, qu’elle dise des choses vraies ou fausses, cette contribution est invérifiable et inutile. Je précise que je ne traite pas du tout de la popularité des logiciels, je ne répond pas à cela.

        L’affirmation exprime : « Gimp est moins attractif depuis qu’il est moins attractif ». Comme ça, magiquement, la personne dénigre GIMP et soutient son dénigrement avec… l’argument d’un autre dénigrement.

        L’autre argument est un appel à la popularité imaginaire (je ne parle pas de l’éventuelle popularité de Krita mais de la forme de l’argument employé) : « beaucoup de gens ». Déjà que l’argument d’autorité c’est minable, mais là en plus c’est une autorité en carton. C’est de la pure malhonnêteté intellectuelle sur toute la ligne. Que l’affirmation soit vraie ou fausse ne m’importe pas du tout là. La contribution est malhonnête dans sa forme de quatre ou cinq manière différentes.

        Aussi il faut arrêter de se voiler la face en se cachant derrière le fait que le dénigrement n’est pas explicite. Tu sais ce que c’est le passif-agressif ?

        C’est parce que je ne me cache pas derrière les fausses impressions qui me satisfont que je n’ai pas peur de dire que les gens autour de Glimpse font de la diffamation. Ça suffit les faux-semblants. Si je disais par exemple, dans un contexte de concurrence, « moi je ne suis pas sexiste, au moins », il serait malhonnête de me défendre en disant « je n’ai pas dit que les autres sont sexistes ». La communication de Glimpse use des mêmes procédés malhonnêtes.

        Bref, pour moi le défaut de la réponse Jehan est d’avoir répondu sur le fond alors que l’intervention devait se faire démonter sur la forme. Et d’avoir dépensé beaucoup d’énergie pour quelque chose qui n’en valait pas la peine.

        Mais je ne regrette pas d’en avoir appris un peu plus, et je n’ai aucun de mal à le croire parce que ça correspond à ce que j’ai pu observer par moi-même. Par exemple quand GIMP a fait évoluer le format XCF pour prendre en charge de nouvelles fonctionnalité, il y a eu des gens du côté de Krita pour dire que GIMP cassait la compatibilité exprès pour garder le contrôle de son format et empêcher les autres logiciels de lire ces fichiers. En plus d’être cousu de paranoïa, ce sont de fausses accusations et du dénigrement, là encore, gratuit.

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Commentaire supprimé

          Posté par Anonyme le 27 mai 2020 à 14:02. Évalué à -10.

          

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Traduction approximative

            Posté par Thomas Debesse (site web personnel) le 28 mai 2020 à 22:21. Évalué à 10.

            

            Je critiquais le fait que d'un côté, Jehan appelle à un respect du travail accompli, et de l'autre, critique le travail d'un autre.

            S’il te plais arrête de jouer avec le sens des mots. Je ne sais pas si c’est intentionnel ou par maladresse, mais ça n’est pas juste.

            Le verbe critiquer a plusieurs sens et tu l’utilises-là avec plusieurs sens ce qui donne l’impression d’une équivalence, je vais citer le wiktionnaire:

            critiquer transitif 1er groupe

            1. (Péjoratif) Faire des reproches, faire ressortir uniquement les défauts.  

               Il est doué pour critiquer les autres ; mais il est plutôt mal placé car lui-même n’a aucun talent.

            2. Faire ressortir, par le discours ou par l’écrit, les défauts ou les qualités des choses ou des personnes.  

               Critiquer un ouvrage, un écrivain. - Il critique les actions, la conduite de tout le monde.
               Critiquer un tableau, un édifice. - Critiquer les actes d’un ministre.

            3. Exercer son intelligence à démêler le vrai du faux, le bon du mauvais, le juste de l’injuste, en vue d’estimer la valeur de l’être ou de la chose qui est soumise à cet examen.

            Quand Jehan fait une critique, il le fait dans le troisième sens : il recherche (il a pris la peine de discuter avec les gens de Glimpse par exemple), soumes à examen, et fait ressortir les défauts ou les qualités de ce qu’il observe. Cet exercice de critique est parfois faite à la demande d’autres personnes.

            Quand tu critiques, tu fais des reproches, et c’est tout. Et tu oses comparer ces deux choses comme si elles étaient comparables…

            Je ne veux pas vivre dans un monde où la peur de froisser les susceptibilités passe avant la compréhension des choses et l’exercice constructif de l’intelligence. Faire une critique des choses est sain, même quand ça pointe des problèmes.

            Je ne veux pas vivre dans un monde où les adultes pleurniches comme des gamins de cours de récré avec des expressions à la « il m’a critiqué », alors que le monde ne peut pas tourner sans faire la critique des œuvres, des moyens, des manières et des intentions.

            Tout le monde dit ce que Jehan devrait faire

            À aucun moment je ne dirige Jehan. Je donne mon avis sur ce que j’observe, je fais la critique des actions, des manière etc. Jehan ne lirait pas mon commentaire que je l’aurai écrit de la même manière, mon commentaire ne lui est pas adressé, je parle de lui c’est différent.

            Pour le reste, paille / poutre, tu connais ? Tu emploies exactement les mêmes méthodes que celles que tu critiques !

            Non, justement, relis encore ce que je viens d’écrire sur la critique. Il y a plein de nuances de ce type sur lesquelles tu joues dans ton commentaire, peut-être totalement inconsciemment et en toute bonne foi c’est tout à fait possible. Je ne vais donc pas m’étendre plus sur tous ces biais.

            Ensuite, puisque tu parles de paille et de poutre et que je connais l’image, tu sembles me mettre dans un camp, comme si je pouvais avoir la charge de porter la poutre d’un de ces camps. Ceci est confirmé juste après avec ton épouvantail :

            Ce que je vois surtout, ce sont des ardents supporters qui ne supportent pas que leur logiciel préféré […]

            Je ne suis pas supporter de quoi que ce soit. J’utilise beaucoup GIMP parce que historiquement je l’ai utilisé à une époque où il n’y avait pas d’alternative viable, c’était à l’époque de GTK1 je crois. Si je l’utilise encore aujourd’hui ce n’est pas parce que je suis convaincu qu’il serait meilleur qu’un autre dans l’absolu (j’en sais fichtrement rien), mais à cause de mon investissement préalable. Je n’ai aucun difficulté à dénigrer quelque chose que j’utilise à la place de quelque chose que je considère comme meilleur. Par exemple je n’ai aucun difficulté à dénigrer la disposition de clavier Azerty et je suis convaincu que la disposition Bépo est meilleure, mais à cause de mon investissement sur Azerty bah je l’utilise encore, et c’est pas comme si je ne m’étais pas acheté un clavier bépo et des trucs comme ça pour m’encourager à changer. Je préférerai autre-chose, je suis convaincu qu’il y a mieux mais je l’utilise quand même à cause de mon investissement. Ma relation avec GIMP pourrait être tout à fait la même s’il y avait un logiciel dont je serai convaincu qu’il serait incroyablement meilleur pour moi, peut-être que j’utiliserai GIMP quand même, en pestant contre lui peut-être même !

            Personnellement je n’ai pas de problème pour pointer ce qui ne va pas même quand je voudrai que ce ne soit pas vrai. Je vais donner un exemple : j’ai constaté un problème de qualité avec beaucoup d’applications KDE, j’ai quelques idées sur les causes, en particulier le fait que l’usage de certains outils et méthodes de travail on un effet négatif sur la qualité. Et bien tu sais quoi ? Ça me désole parce que j’aimerai utiliser et conseiller ces outils ! J’aimerai pouvoir conseiller Kdenlive à mon entourage, mais ce n’est pas possible. J’utilise Kdenlive, par exemple je sais ce que c’est de produire avec une série de 50 épisodes avec diffusion quotidienne. Je peux dire : j’utilise Kdenlive avec beaucoup de souffrance. Mais je sais aussi que Kdenlive ne peut être utilisé que si l’utilisateur apprend à contourner les bugs, et modèle son workflow de manière à passer entre les gouttes. À aucun moment je ne peux conseiller à quelqu’un Kdenlive : il faut des années d’apprentissage de contournement pour s’en servir de manière productive. Tu vois, je fais la critique de ce logiciel, et pourtant je voudrai l’aimer, je voudrais en être fier, je voudrai le conseiller… J’ai des tas de problèmes avec DigiKam par exemple, mais je peux difficilement le conseiller dans un cadre professionnel sans avertir de certains comportement bizarres (l’un d’eux est d’ailleurs un problème dans Qt lui-même, une fonction standard de Qt sur Windows stockent les données utilisateur dans un dossier fait pour ne pas être sauvegardé). J’aimerai que Kdenlive et DigiKam soient des étendards du libre comme le sont GIMP, VLC, LibreOffice ou Blender… Mais je suis lucide, à mon grand regret ils ne le sont pas. Et malheureusement le problème se retrouve profondément dans la méthode de travail, par exemple un jour j’ai rapporté un bug de manière très détaillée, le genre de bug qui ne peut pas se corriger sans que quelqu’un ne l’adresse explicitement, et bien il a été fermé avec le statut “Ça marche pour moi” au motif magique que “du temps est passé maintenant”. Je crois qu’il a été réouvert discrètement depuis mais bon… pas de nouvelles.

            Je n’ai rien contre Krita, mon a priori c’est que c’est un bon logiciel. Je ne l’utilise pas personnellement à cause de mon investissement sur GIMP. Pas de fanboyisme, je n’ai pas de mal à dire de lui, je n’ai pas de mauvaise expérience avec lui (je n’ai quasiment pas d’expérience en fait), je me dis que si des gens comme David Revoy en disent du bien, c’est qu’il doit être moins buggé que Kdenlive par exemple.

            Cette discussion est vraiment le royaume des arguments en carton et des procédés rhétoriques douteux.

            En fait, tout ça me donne l’impression d’une forme de lâcheté où certaines personnes ne se sentent pas à l’aise avec le fait de vouloir aimer autre chose que ceci ou cela et recherchent chez les autres la validation sociale de leur préférence, et sinon, les prétextes de leur préférences.

            Le pire dans tout ça, c'est que personnellement, j'avais plutôt tendance à pencher en faveur de Gimp dans cette histoire de fork. Mais là, le seul dénigrement constant que je vois, c'est de personnes supportant Gimp, et pas que vis-à-vis de Glimpse.

            Ah bah tiens que dis-je… Tu as besoin que ce soit de la faute des autres si tu as un avis ? Et tu veux faire du chantage affectif aussi ?

            --
            Thomas DEBESSE

            ce commentaire est sous licence cc by 4 et précédentes

            • [^] # Commentaire supprimé

              Posté par Anonyme le 29 mai 2020 à 08:30. Évalué à -1.

              

              Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Traduction approximative

      Posté par Guillaume Maillard (site web personnel) le 23 mai 2020 à 11:49. Évalué à 10.

      

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

      Il me semble que les devs de GIMP ont aussi une lourde responsabilité.
      Voila plus de 20 ans que je vois GIMP s'améliorer sans cesse, techniquement un sacré travail et surtout une grande détermination à ajouter sans cesse de nouvelles fonctionnalités qui ont de quoi balayer Photoshop. Et je vous adore pour ça.
      Par contre, les lourdes critiques sont liées au revers de cette médaille : massacre en règle de l'ergonomie, peu d'écoute des retours constructifs, UI mal pensée et encore moins bien réalisée.
      N’empêche que j'aime bien bien ce projet et un supporter du projet.
      A chaque téléchargement de GIMP, je me dis "allez c'est bon, ils ont du faire le tour des fonctionnalités, ils ont bien du prendre un peu de temps pour repenser l'interface du logiciel", mais non, alors je patiente sans trop râler :)

      Retour d'un graphiste qui juge GIMP sur un simple screenhot de son UI :

      
      (pour quand vous aurez le temps ou l'envie de régler le problème n°1 de GIMP : l'UI )
      De haut en bas:
      Drop Shadow (en titre), Drop Shadow en sous titre, un machin tronqué sans raison "Drop… 27 (Untitled) : on peut pas faire mieux ? A quoi il sert ce logo à gauche? et la preview de 4mm x 3mm, elle sert à quelque chose en l'état?
      Presets : pourquoi un ":" ? Icônes minuscule pas vraiment parlantes.
      X : "X" collé à gauche, marge à revoir, de plus le "slider" est plus au que les autres widget. Le fait de mettre le label (X) dans le widget casse la logique de l'interface.
      Clipping : un combo avec un look encore différent
      Preview / Split : bizarre ce Split qui part à droite
      Help & reset: des icônes discrètes seraient suffisantes

      Polices : choix : bof, rendu de police: beurk

      A comparer par exemple à :

      

      

      Bref, si un jour vous avez le temps!

      • [^] # Re: Traduction approximative

        Posté par Stinouff le 23 mai 2020 à 13:17. Évalué à 10. Dernière modification le 23 mai 2020 à 13:18.

        

        Si on en arrive à ce genre de pinaillages, c'est que le logiciel est vraiment bon ! :p

        Mais je suis d'accord avec toi sur les interfaces. Je galère toujours à placer des guides (un tableau paramétrique serait parfait), à effectuer une rotation précise (par rapport à un guide), à reconnaître des éléments, à trouver une bonne taille de canevas (pour des imports multiples).

        Le côté peu paramétrique du logiciel me pose souvent problème puisqu'il fourmille d'éléments partout…

        Mais dans l'absolu, je le trouve beau quand même, stable (presque parfait), fiable (presque parfait aussi) et très fonctionnel. Je suis toujours admiratif du travail accompli et du soin apporté à des tas de détails. L'intelligence des contributeurs n'est plus à prouver, d'ailleurs. Jehan le démontre régulièrement.
        Si je le pouvais vraiment, d'ailleurs, j'aiderais autrement que financièrement. Ça m'embête d'être si impersonnel, mais bon, au moins, c'est un petit soutien parce qu'ils vont vraiment dans la bonne voie et je suis toujours ravi d'y travailler.

        • [^] # Re: Traduction approximative

          Posté par alex666 le 23 mai 2020 à 15:15. Évalué à 2. Dernière modification le 23 mai 2020 à 15:15.

          

          L'intelligence des contributeurs n'est plus à prouver

          Je crois que c'est justement ça qui pose problème à certains !!
          Ben oui, faut de temps en temps réfléchir un peu, et se demander à quoi correspond ce qu'on va faire, au lieu de chercher le bouton "optimisation automatique" et cliquer.

      • [^] # Re: Traduction approximative

        Posté par ted (site web personnel) le 23 mai 2020 à 13:39. Évalué à 5.

        

        Ce qui est un peu déroutant, c'est aussi ce genre de popup qui apparaît quand on utilise certains outils ou filtres. Quand j'ai ça je suis obligé de le mettre de côté, je ne sais pas trop où, ça me cache à moitié la vue, et je dois souvent les re-re-déplacer…

        Quand on utilise ce genre d'outil normalement on n'a pas besoin en même temps d'accéder à la boite à outils et aux options des outils. Il ne serait pas possible d'ancrer ces popup à cet endroit le temps de valider ou d'annuler leur utilisation?

        Un LUG en Lorraine : https://enunclic-cappel.fr

      • [^] # Re: Traduction approximative

        Posté par ZeroHeure le 23 mai 2020 à 15:11. Évalué à 10.

        

        Tout ça c'est bien beau, mais c'est pas dans un forum qu'on aide les développeurs : fais un rapport de bug, ou encore mieux va sur la liste et présente un guide pour l'interface graphique. Tes remarques sont pertinentes, il faut les formaliser.

        Pour info l'icône de G correspond à GEGL, ça indique la gestion de l'outil par GEGL.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Traduction approximative

          Posté par Guillaume Maillard (site web personnel) le 23 mai 2020 à 17:19. Évalué à 6.

          

          Quand j’étais étudiant, il y 20 ans, j'ai déjà tenter avec des camarades de promo… l’accueil de patchs et d'améliorations concrètes fut assez "sulfureux", mais on est pas sortis rancuniers pour autant.

          Pour le guide des interface graphique, Apple a fait le job il y a bien longtemps : http://www.multimedialab.be/doc/tech/doc_osx_hi_guidelines.pdf (cf alignements pages 282)
          Le guide est assez général pour s'appliquer à toutes les plateformes, et contrairement aux autres productions Apple, c'est encore d'actualité.

          Merci pour l'info sur le G pour GEGL, pas sûr que ça valait le coût de polluer l’interface avec (par contre l'auteur d'un bugreport pour le retirer va se prendre une balle en pleine tête).

      • [^] # Re: Traduction approximative

        Posté par alex666 le 23 mai 2020 à 15:23. Évalué à 5.

        

        UI mal pensée

        Perso, je n'utilise QUE l'UI multifenêtres depuis au moins 10 ans.
        Je ne me sers de Darktable que pour dérawtiser mes photos, notamment à cause de son interface que je trouve imbuvable.

        Comme quoi tous les loups ne hurlent pas à l'unisson…

        • [^] # Re: Traduction approximative

          Posté par Guillaume Maillard (site web personnel) le 23 mai 2020 à 16:33. Évalué à 3.

          

          Le multi-fenêtrage n'est pas un problème, c'est même très pratique.

          Il faut plutôt chercher tout ce qui énerve, n'est pas pratique, pas facilement compréhensible, mal présenté… Souvent les problèmes arrivent avec le temps, on ajoute ci ou ça, on ne sait pas trop ou le mettre sans tout réorganiser. Avec le recul de 20 ans sur GIMP, j'aurai plutôt du écrire "en manque d'amour" que "mal pensée".
          Réorganiser, simplifier, aligner, polisher seraient à mon avis plus bénéfique à court terme au projet que : optimiser, claquer "de la fonctionnalité de la mort", ajouter des réglages.

      • [^] # Re: Traduction approximative

        Posté par EmmanuelP le 23 mai 2020 à 17:44. Évalué à 10.

        

        Tu dis que GIMP massacre l'ergonomie, et les exemples que tu donnes ne sont que du pinaillage esthétique.

        Si on compare les interfaces de GIMP et de DaVinci, les développeurs de DaVinci ont eux sacrifié l'ergonomie pour l'esthétique pour les sliders horizontaux: ils n'occupent pas toute la largeur disponible, l'étiquette et l'affichage de la valeur rognent sur la place qu'ils pourraient prendre, il n'y a pas les deux flèches d'ajustement. Et il est probable que la hauteur de la zone cliquable pour déplacer le slider soit plus petite en proportion que celle de GIMP.

        • [^] # Re: Traduction approximative

          Posté par bubar🦥 (Mastodon) le 23 mai 2020 à 18:25. Évalué à 9. Dernière modification le 23 mai 2020 à 18:45.

          

          Je rebondis sur ton commentaire pour un autre éclairage sur l'UI. bémol : je ne suis qu'un utilisateur de base qui se servait très peu de gimp : en fait uniquement de ses greffons Je n'ai jamais utilisé Gimp pour autre chose car la multi-sélection de masque me manquait trop, ne sachant comment faire sans, ben je n'ai pas utilisé Gimp pour ça (ça c'est un défaut d'usage probablement, en tout cas c'est une opposition tout à fait recevable, mais quelle bonne surprise d'apprendre que c'est maintenant dans les cartons)
          Puis j'ai arrêté d'utiliser Gimp, il y 5 ans environ, pour une autre raison : lorsqu'on lance le logiciel à priori rien n'a changé, on trouve toujours les mêmes icônes aux mêmes endroit, cependant impossible de refaire facilement les opérations courantes que je faisais : en fait de nombreuses choses dans l'UI avaient changées, dans les sous menus ou les manière de faire. Et ça c'est complètement déroutant : soit on est conservateur avec les mêmes outils et mêmes fonctions aux mêmes endroits et on a plaisir à voir leurs améliorations, soit on s'attend à ce que la nouveauté "saute aux yeux", qu'immédiatement on trouve la nouvelle information (et ensuite apprendre à faire). Là ce n'est ni l'un ni l'autre : on a l'impression que l'UI n'a que très peu changé alors qu'en fait beaucoup de choses "moyennement avancées" ne se font plus du tout comme avant.

          Il me semble, bien humblement, que c'est l'UI qui permettra à Gimp de dépasser son stade actuel, car dessous tout est là (semble t il) et les apports récents sont absolument fantastiques (à lire les dépêches de Jehan, pas besoin d'utiliser au quotidien pour suivre, en plus d'être un dev majeur il assure les infos !)

          Alors c'est une critique, seule et sans propositions de patchs, certes et j'en suis bien désolé. Mais ça saute tellement aux yeux aujourd'hui, en 2020, que tout ce qu'il manque à Gimp c'est une évolution de sa GUI ou un dev spécialisé sur le sujet et qui aime ce projet, qu'il me semble que, parfois, une petite critique ne fait pas de mal (et ce n'est certainement pas son but) tant qu'elle n'est pas criée sur les toits.

        • [^] # Re: Traduction approximative

          Posté par Guillaume Maillard (site web personnel) le 23 mai 2020 à 20:38. Évalué à 3.

          

          A l'occasion, essayes DaVinci.
          C'est un bijou d'ergonomie.

          Étrangement, je n'ai pas vu passer d'article élogieux sur l'ergonomie de GIMP, pas contre les critiques pleuvent. Il me semble que GIMP est un bon logiciel dans un emballage pas encore à la hauteur de ses capacités.

          Utiliser toute la largeur pour un slider, c'est une bonne intention, mais en pratique, est-ce utile?
          Si l'on souhaite permettre de fixer une valeur particulière, on fournit généralement un "textfield".
          Les programmeurs de DaVinci ont eu une bonne idée, le "textfield" permet de faire "slider" aussi pour remplacer les "flèches d'ajustements" pour gagner un peu de place et ne pas surcharger l'interface. De plus, rien n’empêche d'avoir un petit bouton sur le slider et de permettre de l'attraper sur une zone bien plus haute (et large).

          Faire simple c'est un long travail de réflexion et de tests.
          J'en profite pour conseiller un livre, qui pour moi, est LA référence à ce sujet : https://designopendata.files.wordpress.com/2014/05/lawsofsimplicity_johnmaeda.pdf

      • [^] # Re: Traduction approximative

        Posté par rmfx le 23 mai 2020 à 18:59. Évalué à -6.

        

        Très bon retours sur les aberrations de l'UI,
        en plus plus quand on est graphiste, on a l'oeil pour voir les incohérences visuelles, alors quand les outils qui servent au graphisme sont eux même pas super graphiquement, ca rend fou.

      • [^] # Re: Traduction approximative

        Posté par Jehan (site web personnel, Mastodon) le 24 mai 2020 à 00:09. Évalué à 10.

        

        Merci pour les retours!
        Voici quelques commentaires:

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

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

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

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

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

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

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

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

        A quoi il sert ce logo à gauche?

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

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

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

        Presets : pourquoi un ":" ?

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

        Icônes minuscule pas vraiment parlantes.

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

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

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

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

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

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

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

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

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

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

        Clipping : un combo avec un look encore différent

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

        Preview / Split : bizarre ce Split qui part à droite

        Pourquoi cela? Je trouve pas cela bizarre du tout.

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

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

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

        Polices : choix : bof, rendu de police: beurk

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

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

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

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

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

        • [^] # Re: Traduction approximative

          Posté par barmic 🦦 le 24 mai 2020 à 01:00. Évalué à 4.

          

          J'y jetterai sûrement un œil plus tard.

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

          Personnellement je trouve cela tellement mineur que j'ai pas envie de perdre du temps dessus. Et j'ai pas trop d'opinion sur le sujet. Mais si quelqu'un trouve cela absolument primordial et que personne dans l'équipe n'est contre, j'accepterais un patch faisant le changement sans problème.

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

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Traduction approximative

            Posté par Jehan (site web personnel, Mastodon) le 24 mai 2020 à 01:34. Évalué à 10.

            

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

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

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

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

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

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

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

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

            • [^] # Re: Traduction approximative

              Posté par barmic 🦦 le 24 mai 2020 à 09:16. Évalué à 3.

              

              Par contre clairement au final, pinailler sur ce point va faire perdre beaucoup de temps à beaucoup de gens si on fait un rapport de bug et qu'on se met à discuter dessus. Donc si je devais lever les yeux au ciel, ce serait plutôt pour cette raison.

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

              Le changement paraît anodin, l'établir comme règle permet de mettre en évidence que c'est un choix qui a un impact.

              Je ne dis pas de le faire pour le cas présent, vous gérez le projet comme vous me voulais et vous faites ça très bien. C'est plutôt pour éventuellement donner des idées.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Traduction approximative

                Posté par Jehan (site web personnel, Mastodon) le 24 mai 2020 à 11:43. Évalué à 10.

                

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

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

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

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

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

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

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

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

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

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

                Enfin dernière remarque sur:

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

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

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

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

            • [^] # Re: Traduction approximative

              Posté par Guillaume Maillard (site web personnel) le 24 mai 2020 à 15:01. Évalué à -3.

              

              Je ne vois pas de vérité absolue là-dedans et absolument rien d'évident.

              Exact, mais si retirer quelque chose n'affecte en rien le résultat -> on vire
              -> https://designopendata.files.wordpress.com/2014/05/lawsofsimplicity_johnmaeda.pdf

              Donc pour les ":", on peut l'appliquer, et les traductions existantes un replaceAll(":",""); ne devraient rien casser.

              • [^] # Re: Traduction approximative

                Posté par seveso le 24 mai 2020 à 19:20. Évalué à 9.

                

                Donc pour les ":", on peut l'appliquer, et les traductions existantes un replaceAll(":",""); ne devraient rien casser.

                J'ai très peu d'expérience en i18n/l10n mais j'en ai suffisamment pour savoir que les solutions à base de "replaceAll()" c'est désastreux, quand bien même le changement parait ridicule comme ici. Les effets de bord ne se voient que très tard après la manip. Trop tard même, quand on ne peut plus faire machine arrière et qu'il faut alors régler un par un les libellés cassés alors qu'on ne parle pas Ouzbek…

        • [^] # Re: Traduction approximative

          Posté par Guillaume Maillard (site web personnel) le 24 mai 2020 à 14:49. Évalué à 10. Dernière modification le 24 mai 2020 à 14:50.

          

          Merci pour ton retour, voici un petit mockup en prenant en compte tes explications:

          

          Le rendu proposé des polices n'est pas terrible, je n'ai pas de moyen simple de faire un rendu 'subpixel'.

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

          Tout est aligné au pixel près (marges : 6px x 4px).
          Les fonctions du preset sont dans le "…", car (à priori) pas des fonctions principales.

          En testant la dernière mouture de GIMP je me suis rendu compte que le slider est encore moins pratique que je pensais, pour remplacer la valeur 10 par 15, il ne suffit pas de cliquer en taper 15, si on fait ca on se retrouve avec un comportement peu intuitif, il faut alors double cliquer sur le texte, et hop, fausse manip, on a vite fait d'interagir avec le slider superposé… Bref, j'ai repris du "classic".
          Pour ce qui est de la largeur du slider, il est bien assez large pour avoir les valeurs qui ont du sens, on peut aussi imaginer d’adopter la stratégie d'autre logiciel en faisant un slider non linéaire quand dépasse les 75%.
          Il n'y a pas de "petites flèches" dans les textfields, le support de la roulette de la souris s'y substitue bien mieux.

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

          Note pour ceux qui pensent que c'est du pinaillage, les alignements verticaux permettent une lecture plus rapide, l'homogénéisation des marges et hauteurs aident aussi car le cerveau à tendance à donner se focaliser sur les différences.

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

          Si l'UI devient une priorité de GIMP, je peux aider à raison d'une analyse/redesign de fenêtre par semaine, et aussi à poser les questions qui fâchent (genre "on s'en fout pas un peu du G"). Je n'ai pas de problème non plus à compiler les sources depuis le master et à causer Franglish.

          • [^] # Re: Traduction approximative

            Posté par jyes le 25 mai 2020 à 09:17. Évalué à 3. Dernière modification le 25 mai 2020 à 09:22.

            

            Clairement tu n’utilises pas Gimp. Les sliders de ton mockup ne remplacent pas fonctionnellement ceux de Gimp, qui sont larges et ont en fait deux sliders selon que l’on glisse la partie haute ou basse. Si tu devais mettre deux sliders à chaque fois, ton UI serait déjà beaucoup moins légère. Et cette fonctionnalité de Gimp, déroutante à la première utilisation, est extrêmement pratique à l’usage ! En plus, les tiens sont plus courts, c’est dommage, c’est autant de précision en moins en un mouvement simple.

            Les + et [<] ont disparus sur ton mockup. C’est dommage, d’autant plus que le [<] est une fonctionnalité très utile qui permet de personnaliser très fortement l’UI de Gimp et de modifier certains points que tu critiques par ailleurs. Encore une fois, je pense que tu ne l’utilises pas. Du coup, c’est chouette que tu fasses un joli mockup avec moins de fonctions, mais Gimp s’adresse aussi à des gens qui s’en servent pour de vrai et qui ne tiennent pas à perdre ces fonctionnalités juste pour avoir une police plus grosse et plus de vide autour.

            Je trouve ça sympa que tu veuilles absolument corriger l’UI de Gimp et vienne plein de bons conseils, mais ces conseils donnent vraiment l’impression que tu n’utilises pas le logiciel du tout et que tu passes complètement à côté de son UX, avec une UI riche en fonctionnalités qui permet d’être efficace quand on apprend à la connaître un peu. Donc j’espère vraiment que les devs Gimp qui te lisent ne t’écouteront pas trop. Les retours de non-utilisateurs ne sont pas si utiles au logiciel.

            • [^] # Re: Traduction approximative

              Posté par Guillaume Maillard (site web personnel) le 25 mai 2020 à 11:52. Évalué à 5. Dernière modification le 25 mai 2020 à 11:52.

              

              C'est toujours sympa cette tendance à commencer par un préjugé.

              Pour + et [<], respectivement "ajouter un preset" et l’accès au menu import/export/gestion des presets. Je ne vois pas ce que tu perds à tout ranger dans un seul menu accessible avec une icône "…" plutôt qu'un minuscule [<] . L'ajout de preset n'étant pas la fonctionnalité majeure de cette UI.

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

              Tu trouves ça pratique de "shooter" la valeur quand il faut double cliquer pour taper une valeur précise?

              Pour ce qui est du "haut"/"bas" des sliders, j'expliquai plus haut que la fonctionnalité peut être gardée sans les fleches avec l'utilisation de la roulette. Rien n’empêche de les garder non plus sur le "textfield". Proposer n'est pas imposer. Merci.

              • [^] # Re: Traduction approximative

                Posté par jyes le 25 mai 2020 à 14:40. Évalué à 9. Dernière modification le 25 mai 2020 à 14:41.

                

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

                Ok, pour le filtre exact que tu prends en exemple, mais je trouve ça pas plus mal que les sliders soient les mêmes partout. Quant au « "haut"/"bas" », je ne suis pas sûr qu’on se soit compris, je ne parle pas de flèches haut/bas à droite du sliders, mais de la région haute et basse du sliders, qui permet par exemple de faire défiler sans molette (en bas), à la tablette graphique par exemple, et de choisir une valeur absolue (en haut) dans le même widget.

                à tout ranger dans un seul menu accessible avec une icône "…" plutôt qu'un minuscule [<] .

                Et là je reconnais mon erreur, dans cette fenêtre de filtre, le [<] et le + n’ont effectivement pas besoin d’être séparés (le [<] ne permet pas d’ancrer la fenêtre de réglages comme avec les outils).

                En fait, je suis sûr que tes propositions peuvent servir mais quand tu te défends en disant que

                Proposer n'est pas imposer.

                dans un fil dans lequel tu dis que l’UI de Gimp est toute pourrie, et que tu fais les louanges d’un logiciel (proprio) qui n’a pas grand chose à voir en comparant des fenêtres qui n’ont que 3 réglages, ta « proposition » est lourde de jugement, et ta comparaison montre bien mal la différence de qualité qui te saute aux yeux.

                • [^] # Re: Traduction approximative

                  Posté par Guillaume Maillard (site web personnel) le 25 mai 2020 à 19:30. Évalué à 0.

                  

                  Bon, j'ai fini par sortir la tablette graphique, ai essayé de cliquer/glisser au stylet les parties hautes et basses des sliders X,Y,Opacité… il n'y a pas de comportement particulier. Seul bouger gauche/droite change la valeur du slider, comme pour… un slider standard…
                  Donc soit c'est bien planqué, soit je suis débile, soit tu parles de quelque chose qui n'a rien à voir avec ce filtre.

                  Un grand merci aussi pour le fait de caricaturer ce que j'ai pu écrire, ça fait toujours plaisir.

                  Je me rend compte que ce que j'ai proposé n'est pas encore assez abouti, il manque les unités sur X/Y/rayons. De plus, la "combobox" pour les 2 choix de "rognages" pourrait être remplacée par un "radiobutton" afin d'éviter un clic.

                  Ce qui me rassure c'est que Jehan a trouvé pertinent mes quelques remarques.
                  Je vais donc lui emboiter le pas, et ne plus perdre de temps sur le sujet.

              • [^] # Re: Traduction approximative

                Posté par Adrien Dorsaz (site web personnel, Mastodon) le 25 mai 2020 à 14:40. Évalué à 10.

                

                Hello,

                Il ne faut pas oublier que les scroll bar actuelles sont très pratique avec l'utilisation d'une tablette graphique.

                Avec ce système, le pointeur du stylet est capable de changer de 2 manières différentes les valeurs sans avoir besoin de déplacer ses mains sur un clavier ou une souris.

                Je trouvais aussi pertinent de ne pas oublier qu'il ne faut juste faire une "belle" UI, mais que ça reste aussi utilisable pour les utilisateurs. Dans ce cas, je trouve que proposer une solution inadaptée aux tablettes graphiques est une réelle régression.

                Le mieux, pour avoir les avis des développeurs est de ne pas continuer la conversation dans Linuxfr, mais sur leur système de suivis.

          • [^] # Re: Traduction approximative

            Posté par Tonton Th (Mastodon) le 25 mai 2020 à 16:41. Évalué à 7.

            

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

            Parlante pour toi, peut-être. Mais moi, j'y vois plutôt un Undo :)

          • [^] # Re: Traduction approximative

            Posté par Jehan (site web personnel, Mastodon) le 25 mai 2020 à 22:57. Évalué à 10. Dernière modification le 25 mai 2020 à 23:00.

            

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

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

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

            

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

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

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

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

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

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

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

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

            Ok. Pourquoi pas.

            Maintenant pour le curseur, gros sujet!

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

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

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

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

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

            il faut alors double cliquer sur le texte

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

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

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

            Tu dis dans un autre commentaire:

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

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

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

            Tu dis aussi ailleurs:

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

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

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

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

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

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

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

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

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

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

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

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

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

            

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

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

            Si l'UI devient une priorité de GIMP

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

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

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

            • [^] # Re: Traduction approximative

              Posté par Guillaume Maillard (site web personnel) le 27 mai 2020 à 22:39. Évalué à 4. Dernière modification le 27 mai 2020 à 22:42.

              

              le fond de GIMP est dans un gris neutre.
              avec teinte bleutée, et forcément, ça pête tout de suite

              Oui, le mockup est basé sur ce que propose DaVinci, ni plus ni moins.
              C'est pas non plus du rose pétant, pour être exact #2f3036 soit 18.4% de rouge, 18.8% de vert, 21.2% de bleu, soit un écart max de 1.7% par rapport à la valeur moyenne (19.5%).
              Je ne conteste pas, j'ai rectifié.

              Pour la petite histoire, DaVinci c'est l'outil des pros qui bossent dans des studios neutre, avec éclairage neutre, sur des écrans qui coute le prix d'une belle voiture, histoire d'avoir un environnement constant pour le "color grading" de nos films préférés.
              Je présume, qu'ils savent ce qu'ils font en "bleutant" par défaut et en proposant une option pour "neutraliser" le tout.
              Voici d'ailleurs ce qu'en dit la documentation :
              Use gray background interface: By default, DaVinci Resolve uses a blue-gray UI background, intended to provide a more attractive experience for users focused on the less color-critical aspects of DaVinci Resolve, namely editing. Turning this checkbox on switches DaVinci Resolve to a totally neutral, desaturated gray UI, which can be valuable as a point of reference for colorists concerned about the blue-gray UI’s potential to bias the eye in the dark environment of the grading suite.

              C'est sûr que si j'écris tout en plus gros, on lit mieux. Tu peux te permettre de faire cela, car encore une fois, tu as travaillé sur une capture d'écran de qualité médiocre, pas sur un vrai logiciel.
              Sauf que… c'est du PNG… donc sans pertes, et issu de ma capture sur ma machine sur le vrai GIMP fraichement mise à jour.

              La taille de la police, je l'avais précisé : ne pouvant simplement faire un rendu subpixel, elle est un peu plus grande.
              J'ai rectifié.
              (N’empêche que si c'est plus lisible, je ne vois pas pourquoi s'en passer).

              Mais le faire au niveau de 2 captures comme comparaison de mockups, c'est un peu de la "triche", si je puis dire. Cette différence n'existe que dans ta comparaison en image.
              Non, elle provienne de la même machine, même écran, même jour.
              Et tu les visionnes (en toute logique) sur le même écran, tu peux donc les comparer sans "biais".

              Comme j'ai dit dans mon précédent commentaire, les noms de calque/image sont certes des infos redondantes mais utiles. La redondance est en effet parfois très utile si elle te permet de sauver de précieuses secondes, puis minutes, puis heures en cumulé.

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

              Note à "je ne sais plus qui" : ouvrir un 2eme filtre ferme le premier, on est donc pas près de se perdre…

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

              Ok. Pourquoi pas.

              Super, on peut aller même un peu plus loin, cf plus bas.

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

              Pas tous les pointeurs n'ont de roulette, notamment pas les tablettes graphiques

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

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

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

              Je comprends pas ce que tu dis. Je viens de tester, ça marche exactement comme ça. Double cliquer permet de tout sélectionner, un comportement assez classique pour un widget de texte.

              Ok, j'ai fini par comprendre… ma (la) tendance naturelle est de (double) cliquer sur le texte, ce qui met le slider à l'endroit du clic, et donc change la valeur…
              Pour un widget de texte dans une interface de saisie, j'aurai tendance à suivre le comportement usuel de sélectionner le texte lors du focus afin de pouvoir taper directement sans avoir à effacer (ou double cliquer).

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

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

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

              400 pas pour l'opacité, me semble overkill, je n'ai pas demandé non plus à fixer la largeur max du slider, on a le droit de redimensionner aussi la fenêtre.
              Utiliser le slider comme outil de précision, me semble peu adapté. Cf plus haut.
              Pour résumé : valeur précise : textfield, incrément précis : jog/shuttle wheel.

              Je crains qu'il y a beaucoup de perte de précision dans ta proposition.

              Si la fenêtre est un peu plus large, non.

              [J'anticipe le "oui, mais si la fenetre est plus large, on va mordre encore plus sur l'affichage de l'image." en rétorquant que l'interface ne fait rien pour maximiser l'affichage en plaçant 2 larges colonnes,respectivement à droite et à gauche.]

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

              J'ai fini par comprendre.

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

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

              Comme quelqu'un le note, ta proposition d'icône fait aussi penser à "Undo" même si ce type d'icône est aussi utilisé dans des cas de "Reset".

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

              C'est typiquement ce que je disais au sujet de la tendance (depuis pas mal d'années déjà) de remplacer le plus possible les icônes par du texte.
              Oui, quand c'est pertinent.

              Si tu t'intéresses vraiment au design d'application, je te conseillerais de rechercher un peu sur ce sujet.

              Comment dire…

              Tiens regarde les captures du logiciel que tu nous as montré: du texte partout.
              Il a pourtant une foule d’icône… dont l’icône "undo" et à côté de chaque widget.

              Attention, on ne dit pas de ne jamais utiliser d'icônes. Personne ne dit ça. Mais vraiment quand on a le choix, du texte est toujours mieux. Pourquoi? C'est clair, beaucoup moins sujet à controverse ou à mésinterprétation.
              Je suis d'accord avec toi. Mais tu ne peux pas mettre Aide, Réinitialiser, Valider et Annuler à la même sauce.

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

              Pour l'icône d'aide, bien moins usitée, éventuellement ok.

              OK.

              Un alignement du texte à droite (cf. ta proposition) permet-il vraiment une lecture plus rapide que l'alignement à gauche actuel? Honnêtement je sais pas, j'ai jamais rien lu qui dit ça.

              Pour l'occasion j'ai ressorti un de mes bouquins sur le sujet : "Designing Interfaces", 3rd EDITION, Patterns for Effective Interaction Design, aux éditions O'Reilly.
              15 ans pour 3 éditions, un nombre important d'exemples réels et d'explications claires et sourcées.

              Extraits :

              _Chapitre 10 : Getting Input from Users: Forms and Controls
              Use alignment for clear vertical flow
              Use layout and alignment so there is a strong vertical flow to the form whether in one column or more. Align the left edges of the inputs, and use the same vertical separation as much as possible. The eye should be able to move from label to input with minimum travel.

              Chapitre 5 : Visual Style and Aesthetics
              Right Aligned Text : Only use right aligned text in special cases like form labels_

              je dirais qu'il faudrait des études sur le sujet pour me convaincre.

              J'éplucherais bien encore quelques uns de mes bouquins mais je manque de temps.

              En design d'application, on en est vraiment revenu des interfaces où tout est customisé, même si c'était très fun et avec quelques projets vraiment fous (pensez Winamp et ses skins de fous). Juste pour le fun, remémorons nous l'époque fun de Winamp, ahahah:

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

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

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

              L'UI a toujours été une priorité de GIMP, au moins depuis que j'y contribue pour sûr (8 ans), comme tu peux le voir avec mes réponses.

              Important, je veux bien, sinon tu n'auras pas pris le temps de réfléchir aux divers points ci-dessus.
              Cependant, si on "fait parler" le bugtracker de GIMP, on a pour le tag "User Interface" : 640 ouverts, 309 fermés.
              Alors que si on regarde l'ensemble : 2197 ouverts, 2861 fermés.
              Les ratios ne reflètent pas une priorité.

              (Je ne nies pas qu'un gros travail a été fait, globalement dans le bon sens, il n'y a qu'a regarder l'historique des releases notes.)

              On peut toujours faire mieux, bien sûr, mais l'interface n'est absolument pas laissée au hasard, comme tu sembles le croire.

              Non, je ne le crois pas. Je ne connais pas de code qui soit écrit "au hasard".
              L'adjectif "atypique" est peut être plus adapté pour l'UI de GIMP.

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

              Ayant pris en compte les différentes remarques, voici une dernière version. Dé-saturée, avec le nom du calque et le fruit de quelques nouvelles réflexions:

              
              https://ilm-informatique.fr/images/davingimp2.png

              1/ affichage des unités, pour le coup ça manque.
              2/ évolution des réglages : un réglage "Par défaut", sélectionné à l'ouverture de la fenêtre. Dès que l'utilisateur change un paramètre, cela passe en "Personnalisés". Cliquer sur le bouton "Réinitialiser" devient alors choisir dans le sélecteur "Par défaut".
              Ce comportement n'est pas une invention mais décliné dans de multiples logiciels.

              Quitte à me répéter, GIMP je l'utilise (par forcement beaucoup) et je suis d'avis que son UI est largement améliorable.
              J’espère que tu ne prends aucune des remarques sur le logiciel comme un dénigrement du travail accompli (qui est remarquable) ou des personnes qui travaillent dessus.
              Discuter, partager permet d'apprendre, de changer, de progresser (autant pour moi que pour les autres).
              C'est souvent dans ces échanges que découvre des livres, des technologies, des astuces… que j'essaye de partager quand je peux. Merci donc d'avoir pris le temps.

              • [^] # Re: Traduction approximative

                Posté par Guillaume Maillard (site web personnel) le 27 mai 2020 à 22:43. Évalué à 2.

                

                Pour une raison qui m'échappe, impossible d'inclure l'image :
                https://ilm-informatique.fr/images/davingimp2.png

              • [^] # Re: Traduction approximative

                Posté par Jehan (site web personnel, Mastodon) le 28 mai 2020 à 10:44. Évalué à 8.

                

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                J'ai fini par comprendre.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                De même, merci pour les remarques.

                P.S.:

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

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

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

                • [^] # Re: Traduction approximative

                  Posté par Guillaume Maillard (site web personnel) le 28 mai 2020 à 13:09. Évalué à 4.

                  

                  Je pense ne plus avoir grand chose à ajouter, il me semble que l'on s'est a peu près compris sur l'ensemble des points et arguments abordés, et c'est bien l'essentiel.

                  Nom du calque réintégré, "neutralité", diminution des tailles des polices, tu as pu voir le résultat sur la 3eme partie du mockup.

                  Pour le "400", c'est largeur sur la capture du slider de GIMP par défaut (380px pour être exact). Les retrouver par défaut avec ma proposition, ce n'est qu'élargir la fenêtre par défaut. (j'en profite pour signaler un truc très très mineur : lorsque l'on change la taille de la fenêtre, la valeur texte dans le slider, gigote avec un grand temps de retard, ce qui donne un effet un peu étrange)

                  Pour les ratios dans le bugtracker, sur nos projets quand quelque chose est "prioritaire", toute l'équipe ne bosse que sur ça jusqu'à avoir terminé. On s'attendrait donc pour GIMP à avoir un ratio ouvert/fermé sur l'UI extrêmement supérieur à la moyenne. En première lecture, fonctionnalités et bugs semblent les 2 priorités.

                  Pour ce qui est de GIMP et des autres logiciels :
                  Effectivement, je n'ai pas relevé tout ce qui est bien, car ce ne sont pas des points à améliorer (par définition). Ce que je trouve dommage en revanche, c'est l'aspect "layout" vite passé sous le tapis.
                  Proposer une amélioration à quelque chose, ce n'est pas la même chose de dire que c'est extrêmement mauvais de base. (rappel si besoin : si je considérais que "GIMP c'est tout pourri", il n'aurait pas sa place sur mes machines, et je ne passerai pas un peu de mon temps sur le sujet).

                  Plus pragmatiquement, il me parait assez "osé" d'exclure les bonnes pratiques des autres logiciels. Ils sont conçu par de grandes équipes, ont quasi tous des ergonomes, des personnes dédiés à l'UI, bref des moyens que l'on reverrait d'offrir à GIMP. Eux aussi ont itéré, et récupéré ici ou la de bonnes idées.
                  Le but n'est pas de dire "Photoshop c'est mieux", je fais références aux centaines (voir milliers) de logiciels pro, juste en prenant les meilleurs de leurs catégories.

                  Dans tous les cas, je ne peux que recommander à tous la lecture d'ouvrages très complet comme "Designing Interfaces: Patterns for Effective Interaction Design 3rd Ed."

                  [Mes propositions ne sont évidement pas paroles d'évangile, néanmoins du haut de mes 42 ans, un vieux diplôme d'ingénieur (en informatique) en poche, avoir bossé en R&D à Philips, créé divers logiciels (opensource en majorité), une bibliothèque pleine à craquer de bouqins de "référence" informatique, une certaine expérience utilisateur des antiques DeluxePaint & TVPaint, Photoshop, CorelDraw, GIMP, Krita; j'ai peut être la fausse impression d'avoir un minium de recul sur le sujet]

                  • [^] # Re: Traduction approximative

                    Posté par Jehan (site web personnel, Mastodon) le 28 mai 2020 à 13:57. Évalué à 8. Dernière modification le 28 mai 2020 à 13:58.

                    

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

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

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

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

            • [^] # Re: Traduction approximative

              Posté par Maz (site web personnel) le 02 juin 2020 à 12:25. Évalué à 2.

              

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

              C'est une affirmation très péremptoire.

              Des logiciels avec une IU qui ne respecte rien ou presque du SE, il y en a encore beaucoup. C'est peut-être moins le cas sous Linux, mais sous Windows, c'est monnaie courante.

          • [^] # Re: Traduction approximative

            Posté par benja le 26 mai 2020 à 02:17. Évalué à 4.

            

            En quoi supprimer certaines informations (nom de l'outil, nom du calque et du fichier -> bonjour la prise de tête quand tu travailles sur plusieurs calques en même temps) et réduire l'aire de toutes les surfaces de contrôle améliorent l'ergonomie (au pif, tu l'as divisée par 2, cela demande 2x plus de précision/temps de la part de l'utilisateur) ?

            Quand au slider moins pratique, t'es tu fais ton opinion en ayant lu l'explication (illustrée!) dans cette nouvelle ? Ou simplement suite à de longues années de pratique subitement remisent en cause par la nouvelle version ? :P

      • [^] # Re: Traduction approximative

        Posté par Nicolas Boulay (site web personnel) le 25 mai 2020 à 09:28. Évalué à 6.

        

        La critique de l'UI est très régulière. Un logiciel de traitement d'image + de création graphique ne peut pas être simple. Et j'avoue aussi d'avoir du mal à l'avaler.

        Vu que du monde se plaint de l'ergonomie, est-ce qu'il ne serait pas plus "simple" de fournir un moyen que chacun puisse proposer la sienne par plugin ? L'idée serait de faire des "skins" ou des modes qui se concentrent sur une manière de présenter les choses différentes pour une tache ou niveau d'utilisation, mais avec des fonctions sous-jacente identiques. Un genre de CSS pour l'application ?

        J'imagine bien un mode "débutant", un mode "photo", un mode "photo débutant", un mode "création graphique" et pourquoi pas des modes précis genre "colorisation de BD" ou "stop motion", avec un moyen simple de bascule.

        "La première sécurité est la liberté"

        • [^] # Re: Traduction approximative

          Posté par Jehan (site web personnel, Mastodon) le 26 mai 2020 à 10:33. Évalué à 8. Dernière modification le 26 mai 2020 à 10:34.

          

          Tu parles de 2 choses différentes:

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

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

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

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

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

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

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

          • [^] # Re: Traduction approximative

            Posté par Nicolas Boulay (site web personnel) le 26 mai 2020 à 10:36. Évalué à 3. Dernière modification le 26 mai 2020 à 10:36.

            

            Ok, pour moi, c'était un peu la même chose si on voit le thème comme une couche "présentation". L'idée est vraiment de ne pas avoir de fonctions spécifiques pour que chaque mode reste compatible entre eux. Vive les profils :) gtk ne propose pas déjà une solution pour ça ?

            "La première sécurité est la liberté"

            • [^] # Re: Traduction approximative

              Posté par Jehan (site web personnel, Mastodon) le 26 mai 2020 à 10:52. Évalué à 3. Dernière modification le 26 mai 2020 à 10:53.

              

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

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

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

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

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

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

              • [^] # Re: Traduction approximative

                Posté par Nicolas Boulay (site web personnel) le 26 mai 2020 à 13:38. Évalué à 4.

                

                Je dois avoir un peu trop en tête l'organisation d'un serveur d'application web, avec le backend contrôlé par API REST, et un serveur frontend qui sert du HTML plus ou moins statique.

                D'ailleurs, je ne sais pas si il existe des frameworks de dev lourd qui arrive à avoir cette séparation claire entre interface et backend. L’intérêt est aussi d'utiliser des technos différentes. En général, les techno d’affichages vieillissent bien plus vite que les règles métiers.

                "La première sécurité est la liberté"

                • [^] # Re: Traduction approximative

                  Posté par barmic 🦦 le 26 mai 2020 à 14:16. Évalué à 2. Dernière modification le 26 mai 2020 à 14:17.

                  

                  Je dois avoir un peu trop en tête l'organisation d'un serveur d'application web, avec le backend contrôlé par API REST, et un serveur frontend qui sert du HTML plus ou moins statique.

                  Même avec du REST tu as un certain couplage entre la manière dont tu fait ton UI et la manière dont tu fait tes API. Il faut aller voir du coté de GraphQL pour voir des choses ou ça commence à être pas mal découplé.

                  D'ailleurs, je ne sais pas si il existe des frameworks de dev lourd qui arrive à avoir cette séparation claire entre interface et backend.

                  C'est un design d'architecture, tu n'a pas forcément besoin d'un framework pour le faire. C'est le genre de séparation que tu pourra trouver dans le privilege separation chère aux développeurs OpenBSD. Eux implémentent ça sous la forme de 2 processus le parent a des droits en plus et le fils va tourner avec le minimum de privilège.

                  L’intérêt est aussi d'utiliser des technos différentes. En général, les techno d’affichages vieillissent bien plus vite que les règles métiers.

                  Le mieux est sans doute de construire une bibliothèque, non ? C'est ce qu'il y a de plus simple et ce qui entraine le plus faible surcoût.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: Traduction approximative

                    Posté par Nicolas Boulay (site web personnel) le 26 mai 2020 à 14:22. Évalué à 4. Dernière modification le 26 mai 2020 à 14:22.

                    

                    Il faut aller voir du coté de GraphQL pour voir des choses ou ça commence à être pas mal découplé.

                    Pas forcément, non. Certains préfèrent avoir une grosse série de command plutot que de la manipulation création d'objet CRUD. Le CRUD gère très mal les transactions donc c'est difficile d'avoir des données complexes.

                    C'est un design d'architecture, tu n'a pas forcément besoin d'un framework pour le faire.

                    C'est pas faux. Mais dans les faits, quand l'interface n'est pas clairement défini, elle est de plus en plus violé et les interdépendances augmentent.

                    Le mieux est sans doute de construire une bibliothèque, non ? C'est ce qu'il y a de plus simple et ce qui entraine le plus faible surcoût.

                    Une lib C ? C'est assez moche à connecter, et la gestion mémoire peut être hyper complexe. Le projet va sortir un canvas "gimp" et supportera le WASM pour écrire l'interface autour :D

                    "La première sécurité est la liberté"

    • [^] # Re: Traduction approximative

      Posté par rmfx le 23 mai 2020 à 16:41. Évalué à -10.

      

      Quand je disais que GIMP n’est plus la référence, ce n’est pas par méchanceté, c’est pour atténuer l’introduction chauvine qui dit ‘’GIMP, l’outil libre de référence pour l’édition et la retouche d’image’’, ce qui n’est en effet plus chose vrai en effet depuis que Krita a la faveurs de beaucoup d’utilisateurs également. Aujourd’hui GIMP n’est pas LA référence et je le rappelle.

      S’énerver derrière son clavier ne sert à rien, prenez plutôt le temps de comprendre les propos.

      Je maintiens cependant que des traductions comme carte de normal discréditent le logiciel grandement.

      Merci aux devs pour leur travail bien évidemment.

      • [^] # Re: Traduction approximative

        Posté par Anonyme le 23 mai 2020 à 22:24. Évalué à 8. Dernière modification le 23 mai 2020 à 22:24.

        

        Prends le temps de lire les réactions à tes commentaires et de comprendre la phrase que tu cites et sur laquelle tu t'es senti la mission de rétablir la "vérité".

        Je me répète : Krita est un logiciel de peinture numérique avant tout, c'est pour cet usage qu'il a été conçu et il s'est construit autour de cette idée. Comme l'a dit Jehan, il intègre désormais des outils d'édition/retouche mais clairement il n'arrive pas à la cheville de Gimp dans ce domaine, chacun sa spécialité.
        Pour quelqu'un se prétendant infographiste pro, c'est complètement ridicule de manquer ce genre de grosse nuance.

        Pour terminer, "avoir la faveur de beaucoup d'utilisateurs" ne veut pas dire qu'un logiciel est une référence dans son domaine, c'est même souvent le contraire. Sous Windows, Photofiltre ou MSPaint sont toujours populaires parce qu'ils sont gratuits et moins intimidants pour les néophytes que les ténors du marché pro.

      • [^] # Re: Traduction approximative

        Posté par Maderios le 24 mai 2020 à 16:07. Évalué à 9.

        

        Aujourd’hui GIMP n’est pas LA référence

        Dans le monde de la photographie, Gimp est le seul logiciel libre, éditeur d'image, capable de rivaliser avec Photoshop. Gimp est La référence citée par les photographes et les média spécialisés. Ce n'est pas que je n'aime pas Krita, c'est que ce dernier n'est pas fait pour éditer les photos. Pour résumer, dire que x est mieux que z, ou inversement, n'a aucun sens puisqu'ils ne jouent pas sur le même terrain.

      • [^] # Re: Traduction approximative

        Posté par HL le 25 mai 2020 à 18:43. Évalué à 6.

        

        J'utilise l'excellent Krita pour la peinture numérique, mais pour la retouche ou l'édition d'image c'est l'excellent GIMP sans hésiter.

        Et Inkscape pour le dessin vectoriel. :-)

        • [^] # Re: Traduction approximative

          Posté par HL le 25 mai 2020 à 20:55. Évalué à 7.

          

          Je rectifie : l'excellent Inkscape.

• # Calques d'effets ?

  Posté par ricflomag le 21 mai 2020 à 23:08. Évalué à 6.

  

  J'utilisais beaucoup Gimp il y a quelques années pour retoucher mes photos, jusqu'au jour où j'ai découvert un type d'outil différent, plus adapté à cet usage : la "chambre noire numérique", avec Darktable.

  Avant cela, la seule fonction qui me manquait par rapport à Photoshop (je me suis arrêté à la version 7, c'est pas tout récent), c'était les calques d'effets. Une merveille pour faire des retouches en série, tout en ayant la possibilité de revenir sur n'importe laquelle, à n'importe quel moment, sans défaire les autres. Il se trouve que c'est l'un des principes essentiels des chambres noires numériques.

  N'empêche, j'utilise encore régulièrement Gimp pour certaines tâches, et les calques d'effets me manquent parfois. Avec l'arrivée de GEGL, je crois me souvenir qu'ils faisaient partie des "promesses" à venir.

  Vous savez si c'est dans les cartons ?

  • [^] # Re: Calques d'effets ?

    Posté par Jehan (site web personnel, Mastodon) le 21 mai 2020 à 23:35. Évalué à 10.

    

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

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

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

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

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

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

    • [^] # Re: Calques d'effets ?

      Posté par Nicolas Boulay (site web personnel) le 22 mai 2020 à 10:10. Évalué à 5.

      

      Une version simpliste pour 3.0 serait bien, cela permettrait de faire des testes pour les plus courageux, au lieu d'avoir un truc très fini et abouti pour la 3.2.

      J'avoue que je suis souvent perdu entre les "masques", les "calques", les "images" les sélections. J'essayé plusieurs fois de m'y mettre sérieusement, mais à chaque fois, je confond 2 concepts et je n'arrive pas à faire ce que je veux.

      "La première sécurité est la liberté"

    • [^] # Re: Calques d'effets ?

      Posté par Dring le 22 mai 2020 à 10:23. Évalué à 3.

      

      Ca donne l'eau à la bouche ; moi je me suis arrêté à Photoshop 6, et déjà à l'époque quand j'ai basculé sur le monde Linux les effets de filtre sont ce qui m'a le plus coûté.

      Je suis un utilisateur très basique, très irrégulier de Gimp, mais globalement très satisfait car il est toujours possible de faire ce que je veux, que ce soit directement ou via quelques manipulations déjà faites par d'autres. Chaque version améliore la stabilité qui est désormais exemplaire (au contraire des solutions de montage vidéo, mon autre usage basique et irrégulier).

      Concernant Krita, j'ai aussi ce logiciel, mais je m'en sers beaucoup moins ; ça reste mon outil préféré pour travailler avec tablette graphique. Plus adapté au dessin ; et encore, sa stabilité fait que je continue de basculer régulièrement sur Gimp.

• # 2.10.18 dmg pour MacOS

  Posté par Phelibre (site web personnel) le 22 mai 2020 à 09:47. Évalué à 1.

  

  Autour de GIMP
  Version macos améliorée… puis absente…
  Malheureusement notre mainteneur de paquet macOS a disparu pour raison personnelle après la sortie de GIMP 2.10.18. Ainsi à l'heure actuelle, la dernière version officielle pour GIMP sur macOS est la 2.10.14. Aucun des autres contributeurs au long cours n'est vraiment intéressé par macOS.
  Patha Bagchi un canadien francophone nous propose la version 2.10.18 optimisée car utilisant les ressources native de l’OS. Vous trouverez l'archive ici https://www.partha.com

  • [^] # Re: 2.10.18 dmg pour MacOS

    Posté par Nico7as le 22 mai 2020 à 11:40. Évalué à 3.

    

    êtes vous sûr qu'il utilise les ressources de macOS? Il est dit qu'XQuartz (X11) est nécessaire, et franchement, je préfèrerais m'en passer.
    Inkscape 1.0 vient enfin de s'en débarrasser, et c'est le jour et la nuit.

    Il ne me semble pas que GIMP 2.10.14 nécessite X11.

    • [^] # Re: 2.10.18 dmg pour MacOS

      Posté par Phelibre (site web personnel) le 23 mai 2020 à 09:15. Évalué à 2.

      

      Non pas besoin de X11 juste pour le plugins GMIC ….

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.