Jehan a écrit 1633 commentaires

  • # Vive le télétravail

    Posté par  (site web personnel, Mastodon) . En réponse au journal Télétravail, premier pas vers une délocalisation générale ?. Évalué à 10.

    Salut,

    Ça fait 10 ans que je télétravaille (plus ou moins, ça dépend des périodes, de certains projets, etc. Les conditions sont aussi différentes, etc.). Pour moi personnellement, c'est la seule bonne manière de travailler. Les avantages sont multiples, et plein de personnes (dans les commentaires ici ou ailleurs) les ont déjà cités. Donc je vais pas répéter, mais en conclusion: ça revient à un meilleur cadre de travail et de vie.

    C'est marrant car d'ailleurs en effet depuis des années, quand je parlais de télétravail en France, beaucoup de gens faisaient immanquablement des barrières mentales (sans jamais avoir vraiment essayé eux-même) et disaient que c'était en gros impossible (même si moi, tout comme des personnes innombrables dans le monde en sont la preuve contraire). Mais soudainement, depuis qu'une majorité de gens ont été forcé de télétravailler 3 mois, rendre cela permanent est devenu la grosse discussion. Y a des articles qui sort, des discussions un peu partout. J'en parlais même au téléphone l'autre jour avec un ami qui me disait avant qu'il ne pourrait pas se passer des bureaux et maintenant il me dit qu'il regrette que ça s'arrête, qu'il vit mieux son travail de chez lui et est même plus efficace. Il travaille dans une grosse multinationale et maintenant les employés commencent à s'activer pour changer les règles d'entreprise et avoir plusieurs jours de télétravail permis par semaine.

    Maintenant au sujet des peurs:

    Il voit que le télétravail diminue les arrêts de travail (moins d'accident de la route) et augmente la productivité. Mieux, les bureaux sont ils encore nécessaire au prix de l'immobilier ?
    C'est le premier stade, où certaines entreprises se trouvent déjà .

    Je suis pas sûr de comprendre, mais considères-tu cela comme un problème car l'entreprise y voit un gain? Au contraire c'est gagnant-gagnant. Oui il y a un gain pour les employés (qualité de conditions de travail, temps gagné, coût de la vie) et pour l'entreprise (productivité, loyer…). En effet, clairement l'aspect loyer est loin d'être négligeable et si les entreprises peuvent lâcher un peu de leurs locaux, c'est tout bénéf. Pourquoi une entreprise devrait-elle absolument avoir des espaces énormes? Idéalement on garde juste des espaces pour des réunions d'équipe, des rendez-vous avec des clients, quelques bureaux pour des cas particuliers, mais si les gens peuvent bosser chez eux, de partout même (pas juste à quelques kms, mais même au frais, dans la campagne, sans pollution, etc. Ou bien même à l'étranger au besoin) la majeure partie du temps, pourquoi s'en priver? Pourquoi serait-ce mal? Pourquoi faut-il absolument bloquer de l'espace pour un lieu finalement redondant. D'ailleurs quand on voit l'encombrement de l'immobilier, notamment dans les grandes villes (où les gens peinent à trouver un logement décent à prix raisonnable; Paris, on pense à toi!), je pense que c'est même un changement social et écologique nécessaire.

    Quant à la diminution des arrêts de travail, c'est pour moi bénéficiaire autant aux employés (qui aime être malade/blessé?) qu'aux entreprises (coût).

    Le second stade, on peux imaginer que la productivité du Français de chez lui n'a pas diminué, et donc on peux penser que la productivité d'un citoyen d'un pys à délocalisation ne diminuerait pas. Donc, pourquoi ne pas proposé l'emploi en télétravail de quelqu'un qui a sa maison dans un tel pays ? Tout en faisant passer la crise sanitaire comme responsable de tous les maux de l'entreprise ?

    Je pense que si les entreprises le voulaient, elles le pouvaient déjà (et s'en privaient d'ailleurs pas vraiment en fait; ça fait de nombreuses années qu'on voit beaucoup d'entreprises avec une partie de salariés dans des pays moins chers). En fait je me dis que ta dernière question est peut-être inversée. Si une entreprise se mettait à faire de la délocalisation à outrance (uniquement pour des raisons de coûts sans se préoccuper de la qualité du travail, du confort de travail, ou d'autres questions sociales), mettre cela sur le dos du télétravail, n'est-ce pas faire passer le télétravail comme responsable de tous les maux des salariés? :-)

    La seule vraie critique qui est clairement réelle et qu'on voit beaucoup depuis quelques mois (notamment dans les commentaires de ce journal), c'est le travail avec les enfants à côté. Néanmoins c'est lié aux conditions particulière du confinement où les enfants aussi étaient confinés. Mais en reprenant la vie courante, les enfants seront aussi censé reprendre école et compagnie.

    En conclusion, je dirais que le télétravail, c'est génial. Je le vis déjà depuis 10 ans, l'ai toujours dit et en suis profondément persuadé. Pour moi, refuser cela est principalement donner corps à des peurs souvent infondés, majoritairement basée sur une part d'inconnue. Et le fait que les entreprises y trouvent aussi leur compte est un avantage, pas un inconvénient (perso quand c'est pas un projet perso, je travaille que sur des projets qui me bottent et si j'arrive à faire réussir le projet ou à faire faire des économies à l'employeur, je suis heureux; je suis pas là pour les faire raquer).
    Si une entreprise devait vraiment faire des saletés à ses salariés, ce serait juste une mauvaise entreprise, et à la base je voudrais juste pas travailler pour eux (télétravail ou non). D'ailleurs la raison du mauvais coup (genre virer pour employer dans un pays pas cher à la place, ce qui semble être la peur que tu as) importe peu (ce serait principalement une excuse en fait). Je pense que le travail est principalement une expérience sociale (même en télétravail; les gens qui croient qu'on a plus de relation sociale juste parce qu'on travaille de chez nous comprennent juste pas grand chose d'après moi 😛) et il faut juste choisir des gens avec qui on veut travailler avant tout. C'est vrai, télétravail ou non.

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

  • [^] # Re: Contenu du CD d'installation

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 7.

    Un peu plus sérieusement, ce qui m'embête dans la GPL c'est surtout que la license est longue

    J'écris plus en code (et en commentaires sur Linuxfr!) tous les 2/3 jours! Franchement c'est pas long, faut arrêter avec la légende (le texte de la GPLv3: https://www.gnu.org/licenses/gpl-3.0.en.html). N'importe quel contrat pour n'importe quelle connerie qu'on signe de nos jours est plus long que ça (et je les lis aussi, ces contrats, avant de les signer; par contre les trucs internet sont souvent aberrants, genre la taille d'un roman!).

    et que finalement peu de gens (même ici!) prennent le temps de la lire. La preuve, chaque fois que je parle de ce genre de détails, on me dit "mais t'es sûr de ça?".

    C'est pas une preuve. Des gens disent la même chose quand on parle des licences BSD. Ils les lisent pas plus et pourtant c'est quelques lignes.
    En fait c'est juste que plein de gens vont simplement jamais lire ces textes de licences parce qu'ils trouvent ça rébarbatifs par principe (de même que beaucoup de gens ne lisent jamais les contrats qu'ils signent).

    Pour aller plus loin, les forums sont pleins de gens qui comprennent pas comment marche le droit d'auteur de manière générale (en fait très peu de personne semble même comprendre la base de la logique de ce droit), et qui posent des questions sur même les licences très courtes genre les variantes BSD, voire même MIT.

    Je trouve ça dommage parce que du coup c'est facile de louper un truc dans cette license assez longue et riche en subtilités. Il me semble d'ailleurs que l'une des personnes qui a beaucoup travaillé sur la rédaction de la GPL 3 n'est pas d'accord avec la FSF sur l'interprétation de certaines parties du texte…

    C'est le propre des contrats. C'est justement pour cela que les gens essaient de les rendre plus longs et détaillés, pour essayer de retirer les différences d'interprétation en retirant les incertitudes. Mais quoiqu'on rajoute, il reste toujours des incertitudes (car y a une infinité de trucs possibles dans le monde).

    Tu crois qu'y a aucun désaccord d'interprétation sur les licences BSD ou MIT? Franchement quand je lis leur texte, y a plusieurs trucs qui sont vraiment sujets à interprétation. Par exemple dans la BSD 4-clauses, quand on demande l'ajout d'une phrase "This product includes software developed by the <organization>" sur les divers documents mentionnant des fonctionnalités ou le logiciel, jusqu'où va-t-on pour caractériser l'usage du logiciel donné dans un système plus large? C'est super vague. Que rentre-t-on dans les "advertising materials"? Ça peut aussi être potentiellement super large. Et puis faut-il que ce soit vraiment écrit dessus de manière proéminente, ou cela peut-il être mentionné en minuscule, limite illisible?

    Quant à la 4ème clause (ou 3ème clause sur la version 3 clause), jusqu'où va-t-on considérer que la mention du nom d'un développeur peut impliquer le soutien de ce dernier? D'ailleurs même la 3ème et 4ème clause ensemble peuvent potentiellement être très antithétique. On est obligé de nommer les auteurs, d'une façon donnée, quand on mentionne le logiciel sur du matériel promotionnel mais tout en faisant gaffe que ça ne donne pas l'impression que ces derniers soutiennent. Ex: X fait un logiciel générique, qui est utilisé dans un système logiciel plus large et une affiche promotionnel parle de ce système et décide de faire les choses bien en ajoutant "This product includes software developed by X". Sincèrement malgré la phrase assez neutre, c'est assez dur de pas donner l'impression que X soutient ce projet.

    Et puis le texte principal des diverses BSD (qui dit en gros "quoiqu'il arrive, c'est pas ma faute"), ben ça pose en fait plein de question sur la réalité dans les diverses circonscriptions légales. En gros, c'est pas parce qu'on l'écrit que c'est vrai en fonction de la loi du territoire. Et puis en plus si jamais c'est un logiciel écrit sous contrat, c'est pas parce qu'on a écrit "c'est pas ma faute" dans son code que ça ne le sera vraiment pas le jour où y a un problème.

    Même la licence MIT, super courte, pose des questions sur le peu écrit. Une question assez courante que j'ai lu sur divers forums est au sujet de cette phrase:

    The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

    Mais qu'est-ce qui est considéré une portion "substantielle"? Est-ce déjà substantiel dès quelques lignes? Un demi fichier? Si c'est une reprise d'une logique importante du code (vs. du code important en taille mais finalement plutôt basique en logique)?

    La raison pour laquelle je me pose moins de questions (comme pour beaucoup de gens), c'est l'expérience. À force des années (et des cas en justice dont j'ai eu vent, etc.), on comprends un peu ce que veulent dire les diverses parties d'une licence, on voit comment les autres utilisent ces licences, ce qu'on peut ou doit faire ou non, etc.
    Aussi clairement pour ceux qui ont choisi les licences permissives, il y a clairement tout un aspect "finalement j'abandonne, je vais rien faire même s'il y a violation de licence". Donc c'est pas que les gens comprennent mieux ces licences, c'est qu'on sait que ceux qui ont choisi ces licences vont rarement essayer de faire respecter leur droit.

    Mon approche est plutôt d'utiliser une license permissive et de convaincre les gens de l'intérêt de publier les sources […]

    En fait tout le reste de ton commentaire se résume à cette phrase de toi. Y a d'un côté ceux qui pensent qu'il faut protéger la liberté du code avec des règles claires, et ceux qui (comme toi, semblerait-il) sont plutôt fatalistes et décident qu'on y peut rien, c'est trop compliqué, donc laissent tomber le côté légal et essaient à la place de convaincre.

    Il n'y a pas vraiment de bon ou mauvais choix. Ce sont deux approches différentes. Perso je suis plus copyleft car je trouve que les gens s'en foutent du libre et si je régule pas mes règles par la licence, alors rien va se passer. J'ai arrêté d'essayer de "convaincre" les gens du libre. Je fais du libre de mon côté car je considère que c'est la chose à faire et que le code se doit d'être libre, mais si les gens veulent faire du propriétaire, grand bien leur fasse. Ils le feront pas avec mon code, c'est tout. Au moins avec la GPL, j'ai pas à les convaincre de faire du libre ou de ne pas faire du propriétaire avec mon code. J'ai clairement édicté les règles en en-tête de chacun de mes bouts de code donc tout est clair et net dès le début.

    Néanmoins je considère les licences permissives meilleures à terme, ou pour être plus clair, je pense que dans le futur idéal, on aurait plus à se faire chier avec des licences tout court. Tout serait libre par défaut, et chacun peut utiliser le code de tous sans suer. Faut arrêter avec tout cet égo comme si notre code à chacun était si fabuleux. Mais bon en attendant d'arriver à ce futur idyllique où les gens remettent enfin les pieds sur terre (ahahah on peut rêver! 🤣), ben je mets le code sous GPLv3 (ou mieux AGPL). Comme ça justement pas besoin de "convaincre".

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

  • [^] # Re: Contenu du CD d'installation

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 6.

    Il faut quand même faire une offre écrite à ce sujet et y'a pas la place pour ça sur la pochette du DVD.

    Quand je lis "written offer" (offre écrite), je comprends que faire cette offre dans un fichier à l'intérieur du DVD (typiquement un fichier README/LISEZMOI, voire carrêment un nom bien explicite genre LINKS_TO_SOURCES, à la racine du DVD avec toutes les infos) serait aussi acceptable. "Offre écrite", pour moi, ne signifie pas "sur papier obligatoirement".

    Ensuite même si c'était vraiment là l'esprit de la licence (genre si le support est physique, alors l'offre écrite doit l'être aussi), une ligne ("Les sources de tous les logiciels sont disponibles sur ce lien:") avec une URL me paraît quand même pas insurmontable même pour une petite pochette CD.

    on a envie d'être un peu procédurier et de dire que c'est leur faute, tout ça.

    Pour être tout à fait juste, la GPL2, c'est une époque (1991) où internet est réservé soit au milieu académique, soit aux gens très riche. Moi je sais qu'à l'époque, j'étais loin de l'un comme de l'autre (et ma famille n'était pas du milieu informatique du tout non plus) et donc si j'obtenais un logiciel (sur disque à l'époque, et si j'avais un ordi, ce qui n'était même pas le cas) et qu'on me donnait un lien internet pour récupérer les sources, c'était comme si on m'avait rien donné.

    Mes premiers contacts avec internet, c'était vers le dernier tiers des années 90 quand un pote m'introduit au club info au lycée. Ce même pote avait déjà internet chez lui, mais justement il était d'une famille très aisée d'ingénieurs et chefs de grosses entreprises. Comme ma famille était quand même relativement dans une bonne moyenne financière, on a nous même eu internet un peu plus tard, je pense vers la toute fin des années 90, un peu avant 2000 (et à l'époque, on installait des logiciels pour compter les MiB téléchargés car on avait des abonnements avec quota super restreints; j'aurais pas téléchargé des centaines de MiB de code source même si j'avais un lien, même à cette époque). Les familles de mes potes moins à l'aise ont eu internet des années après.

    Clairement cette restriction (qui peut paraître absurde de nos jours) a vraiment un sens dans le contexte de l'époque et dans l'esprit de la GPL (qui est vraiment pas juste "on peut dans la théorie avoir accès aux sources, mais ahah c'est juste un leurre"). L'idée est que quand on dit qu'on a accès aux sources, il faut que ce soit vrai dans une mesure raisonnable (c'est à dire, on vous fait payer l'envoi en plus, mais rien d'insurmontable).

    Ensuite ils ont bien vu que cette restriction est devenue déraisonnable dans un monde où il est de plus en plus courant d'avoir accès à internet en haute vitesse (et même si vous faites partie des gens pour qui ce n'est pas le cas, il est simple de nos jours de payer un peu, genre cyber-café, pour avoir cet accès temporairement, ce qui équivaut à payer des frais pour un envoi physique). Donc ils ont juste mis à jour pour GPLv3 en rendant la restriction plus souple (plus d'obligation d'envoi sur support physique).

    Tout ça pour dire que dire que "c'est leur faute" me paraît un peu injuste. Ils sont juste très attachés à faire respecter l'esprit de la licence. Il est vrai que d'autres licences ne précisent rien de tout ça, voire ne demandent même pas forcément la livraison du source (il est possible de ne livrer que des binaires). Bon ben toujours la même histoire, c'est la différence entre les licences permissives et copyleft. Ces derniers sont en général plus attaché à la signification derrière la diffusion en logiciel libre. Pour aller au delà du théorique "vous avez le droit (mais on va tout faire pour que ça soit un parcours du combattant si vous essayez d'utiliser votre droit)", ben ils ont ajouté des restrictions à ce que veut dire de donner ce droit aux gens. Pas juste des mots jetés en l'air histoire de dire qu'on fait du logiciel libre. Perso j'aime bien. 🙂

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

  • [^] # Re: Contenu du CD d'installation

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 10.

    La GPL impose quand on distribue un logiciel d'offrir la distribution des sources correspondantes par le même moyen pendant 5 ans.

    C'est pas 5 ans, mais 3 ans. Ce n'est pas "par le même moyen" mais "par un moyen habituel d'échange de données logicielle" (cela pourrait être une clé USB de nos jours):

    on a medium customarily used for software interchange

    Personnellement je pourrais même lire qu'un lien sur internet est aussi un medium habituel pour l'échange de données logicielle de nos jours mais la FAQ gnu.org a un item spécifiquement sur le sujet qui dit en effet qu'on doit envoyer un média physique (notez bien que là non plus, ils disent pas que ça doit absolument être le même) si c'est explicitement demandé.

    Notez que cette histoire de 3 ans est seulement dans le cas d'une distribution du binaire sans les sources côte à côte. Donc pour une distribution physique sans les sources, c'est vrai. Mais si tu diffuses par un site web, et que sur le même serveur, le fichier à côté de l'exécutable est celui des sources, tu peux arrêter du jour au lendemain de distribuer les 2 ensemble.

    Enfin tout cela est vrai seulement pour la GPL2. Pour la GPL3, le cas spécifique d'une distribution physique est listé et indique que tu peux accompagner le média d'une note écrite qui donne accès à une copie des sources en ligne, du moment qu'il n'y a pas de frais additionnel pour le demandeur. Tu n'es plus obligé d'envoyer un autre média physique. Par contre l'histoire des 3 ans reste pour ce cas spécifique (ça me paraît logique, ça évite la vente abusive de logiciels libres avec une personne qui disparaît une semaine après et dit "ah bah la distribution est fini, trop tard pour demander les sources).

    Clairement cela s'adapte à l'ère du temps. Au temps de la GPL2 (écrite en 1991!), Internet était beaucoup moins commun (et plus cher) et imposer d'avoir internet pour récupérer des sources, c'était un bon moyen pour ne pas avoir à les donner à la majorité des gens. Donc je pense que c'est pour cela que cette ancienne version imposait de pouvoir les envoyer physiquement aussi (j'étais très loin de ce milieu à l'époque, mais de ce que je connais, s'échanger des programmes par média physique était chose courante). Avec la GPL3 (2007), ils se sont mis au goût du jour, car donner un moyen dématérialisé de transfert est devenu parfaitement acceptable, même pour le grand public.

    Vous pouvez les mettres à disposition, mais pas à votre dépend tout de même.

    Si tu diffuses par média physique, tu dois en effet aussi pouvoir fournir le code par média physique avec la GPL2. Mais comme le dit Zurvan, ce n'est en effet pas à ses dépends pour autant. Tu as le droit de demander de payer des frais pour l'envoi. Ensuite ces frais doivent être considéré "raisonnables pour le fait d'envoyer physiquement les sources". Plus précisément en anglais:

    Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code

    Donc de nos jours, ça voudrait dire re-facturer la clé USB (j'ai pas de graveur CD/DVD et je pense pas que beaucoup en ont encore de nos jours) et les frais de poste, au minimum. Ensuite si ça me prend un peu de mon temps (faire la copie: 15 min, aller à la poste: 30 min, aller dans une boutique acheter une clé: 30 min), je pense qu'il est raisonnable de facturer le temps perdu (pas de manière exubérante, genre rajoutez pas 500€ de travail humain, même si c'est peut-être vraiment votre valeur sur le marché du travail; mais mettre +25€ ne me paraît pas aberrant).

    Bon c'est mon interprétation. Faudrait demander à la FSF si ça rentre bien dans ce qu'ils appellent "your cost of physically performing source distribution"; moi ça me paraît raisonnable. Et devant un juge, je pense que l'intention rentre en compte. C'est à dire que si vous offrez aussi un lien dématérialisé facilement accessible, mais qu'une personne insiste absolument pour avoir une version physique, bon vous vous pliez à la demande, car c'est dans la licence choisie. Mais dans ce cas où vous perdez une heure de votre vie, rajouter quelques sous (pas grand chose, juste de quoi faire un bon repas; surtout peut-être comparé à votre salaire, ça dépend des cas) en plus du prix du support physique et de l'envoi, faudrait vraiment tomber sur un mauvais juge pour ne pas considérer que ça rentre dans "le coût pour un envoi physique".

    Ensuite, je rappelle, c'est GPLv2 seulement. La GPLv3 n'a pas cette restriction et le lien internet marche parfaitement même si vous distribuez en média physique.

    Enfin je pense qu'intégrer les sources dans le CD/DVD (si on veut absolument envoyer un logiciel par ce moyen dépassé!) reste de toute façon la vraie bonne chose à faire dans l'esprit de cette licence. Envoyer un logiciel libre en binaire seulement me paraît à l'antithèse de ce qu'est le logiciel libre et sa compréhension.
    Enfin sans moyen simple d'accéder aux sources, j'entends; insérer juste une note avec un lien qui va vraiment rester pour télécharger les sources me paraît tout à fait raisonnable (en fait même mieux, si en plus d'avoir accès à la version figée des sources, ça m'indique aussi où trouver la version en développement pour récupérer les sources les plus récentes). En gros, l'idée est qu'on ne doit pas entraver l'accès aux sources en rendant cela plus difficile que cela ne pourrait l'être. Si on fait cela, ça veut en général dire que c'est pas vraiment du logiciel libre qu'on veut faire.

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

  • [^] # Re: By ?

    Posté par  (site web personnel, Mastodon) . En réponse au message La licence que je cherche pour ouvrir mon code existe-t-elle?. Évalué à 10.

    Oui enfin surtout, que ce soit un CC by, une BSD, ou tout autre licence qui demande de garder la paternité d'un code, cette restriction s'applique à du code dérivé, pas à une œuvre produite avec le dit logiciel.

    Autrement une image produite avec GIMP devrait être sous GPL (ce n'est pas le cas!), de même qu'une vidéo produite avec Blender (toujours pas le cas). Ou encore plus simple: tout exécutable produit par GCC serait aussi en GPL (évidemment pas le cas non plus).

    Enfin bon, tout ça pour dire, aucune des licences libres, ou même autour du libre, que je connais ne correspond à ce que tu cherches (appliquer des restrictions sur le résultat produit par le logiciel). Si c'est vraiment ce que tu veux, alors faut une licence faite maison. Ensuite faut pas se leurrer, pour moi, c'est pas du "mieux que rien". C'est 100% la logique qui alimente le logiciel propriétaire. Beaucoup disent exactement ça: "nous, on est vraiment pour le partage, et on veut vraiment aider les autres, mais vous comprenez, hein, faut bien vivre, on va pas non plus juste donner notre dur labeur aux autres comme ça sans rien faire!"
    C'est juste une position qui ne tient pas. Soit on veut vraiment travailler et partager avec le monde, soit on veut garder son code dans son coin.

    D'ailleurs le coup de la vidéo produite avec des logos, si je ne m'abuse, c'est (c'était?) classique de certains freeware qui proposaient de produire des vidéos mais avec un logo (ou avec des fonctionnalités très limitées) et fallait payer pour débloquer la version complète ou sans logo.

    Ensuite personnellement je comprends pas trop. Soit le pote t'as bien payé pour ce logiciel et là tu te mets d'accord pour faire la licence qu'il veut (voire lui promettre que ce logiciel est que pour lui), soit t'as juste fait ça pour l'aider sans contrepartie, et dans ce cas, c'est pas très cool d'en plus t'imposer des trucs sur ce que t'as le droit de faire ou non avec ton propre code. Il a déjà un avantage à la base du simple fait que le logiciel a été originellement calibré pour ses besoins propres. Rien que ça, c'est déjà un avantage énorme sur ses "concurrents".

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

  • [^] # Re: Version HTML5

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche « Shpactris » sort en v1 et apporte la coopération en ligne. Évalué à 6.

    rahan fait vraisemblablement référence au petit speech sur le danger de télécharger n'importe quoi trouvé sur le web qui est sur la page de Shooting Pactris. Et ça fait d'ailleurs du bien de voir ce type de remise en question car je me pose toujours des questions quand je vois les gens télécharger/exécuter tout et n'importe quoi sans même une seconde d'hésitation.

    De manière générale, tout exécutable binaire est une boîte noire plus ou moins opaque, et l'exécuter sur notre machine (hors sandbox ou équivalent, avec même là cependant des limites) est potentiellement dangereux. Ensuite vient le point de confiance. Par exemple si un binaire vient directement d'une équipe qui fait un logiciel bien connu depuis des années, on peut raisonnablement accorder plus de confiance; éventuellement si le binaire vient d'une personne seule mais qui a aussi une réputation certaine depuis quelques années. Mais surtout le mieux est quand la production du binaire est faite de manière transparente, avec des scripts publics, sur des serveurs qui produisent des logs elles-même publiques, etc. C'est comme ça que sont faits de nos jours les paquets des distributions majeures ou de certains dépôts tiers génériques (par exemple Flathub). Bien sûr, même dans ces cas, on n'est jamais sûr à 100% et le point de la confiance rentre encore en jeu (mais dans le cas d'une équipe voire d'une distribution ou d'un dépôt communautaire, il faudrait que beaucoup plus de monde soient dans le coup pour la production de de binaires malveillants — on approche de la théorie du complot — ou bien que quelqu'un, ou un sous-groupe, arrive à berner toutes les autres personnes).

    En tous les cas, en effet, il faut toujours réfléchir un peu avant de lancer un binaire et le faire en connaissance de cause. 🙂

    Disons qu'il faut pas tomber dans la paranoïa 😱 et à un moment donné, il faut aussi savoir se lancer et donner sa confiance (sinon on vit plus), mais ce n'est sain que si on en est au moins conscient.

    Typiquement là je n'ai pas lancé le binaire sur ce site (soyons clair, même sans le petit discours, je n'aurais jamais fait une telle chose; je ne lance jamais un binaire trouvé sur un site inconnu au bataillon). Mais le petit discours et l'explication sur comment lancer le jeu (comme un barbare, en utilisant un logiciel de développeur!) m'a poussé à contacter le développeur et contribuer au final un paquet Flathub (qui devrait être disponible d'ici quelques jours, on espère!), pour justement bénéficier de binaires dont la production (de source à exécutable) est publique, parfaitement suivable et inspectable.

    En tous cas, le jeu est très marrant. On adore surtout le côté coopération. On se parle beaucoup en jouant: "cette pièce, on la met à gauche?"… "non, tourne la!"… "attention au fantôme!"…
    Notre record familial est le niveau 7! 😃

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

  • [^] # Re: J'adore peertube

    Posté par  (site web personnel, Mastodon) . En réponse au lien Nos plans pour PeerTube v3 : collecte perlée, du live pour cet automne - framablog. Évalué à 4. Dernière modification le 28 mai 2020 à 14:22.

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

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

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

    👍

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

  • [^] # Re: Traduction approximative

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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: J'adore peertube

    Posté par  (site web personnel, Mastodon) . En réponse au lien Nos plans pour PeerTube v3 : collecte perlée, du live pour cet automne - framablog. Évalué à 3. Dernière modification le 28 mai 2020 à 11:19.

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

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

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

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

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

  • [^] # Re: Traduction approximative

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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: Plus d'infos

    Posté par  (site web personnel, Mastodon) . En réponse au lien Libre Graphics Meeting en live (là maintenant) et atelier GIMP à 17h. Évalué à 6.

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

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

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

  • # Code?

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche « Shpactris » sort en v1 et apporte la coopération en ligne. Évalué à 6.

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

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

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

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

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

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

  • # Plus d'infos

    Posté par  (site web personnel, Mastodon) . En réponse au lien Libre Graphics Meeting en live (là maintenant) et atelier GIMP à 17h. Évalué à 6.

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

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

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

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

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

  • [^] # Re: J'adore peertube

    Posté par  (site web personnel, Mastodon) . En réponse au lien Nos plans pour PeerTube v3 : collecte perlée, du live pour cet automne - framablog. Évalué à 6.

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

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

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

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

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

  • [^] # Re: Traduction approximative

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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.

    Illusion de couleur

    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.
    Salle de Color Grading

    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:

    Winamp et ses skins

    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  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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 ]

  • [^] # Re: Traduction approximative

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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 ]

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

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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: Traduction approximative

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. É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: Perte d'infos ?

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Utiliser une des LED d’un Raspberry Pi comme témoin d’enregistrement TV. Évalué à 10.

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

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

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

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

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

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

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