Vous le savez, on travaille dur sur GIMP. Le mois dernier, les contributeurs principaux se sont retrouvés en Espagne pour une semaine de hacking intense : la Wilber Week [du nom de la mascotte de GIMP, Wilber]. Très sympathique semaine, dans une vieille maison, une résidence d’artistes au milieu de la nature et chauffée au feu de bois.
J’ai déjà écrit un compte‐rendu sur l’événement, mais je vous fais un résumé des points importants personnels (en seconde partie). Et il y a un appel à voter aussi…
Flatpak
GIMP distribuera un Flatpak dès la version 2.10, j’en reparlerai plus tard.
Règles de sortie
Pour accélérer la sortie, on a décidé d’alléger nos règles de sortie. En particulier, on autorisera désormais les sorties de versions mineures avec de nouvelles fonctionnalités. À terme, je souhaiterais un cycle de sortie continue, comme d’autres programmes (j’en parlais déjà en 2014) le font déjà.
Pour comprendre un peu le fond du problème, nous avons des fonctionnalités vraiment cool en réserve, codées, incluses, mais non totalement finies (il arrive que des contributeurs nous balancent des correctifs, puis disparaissent dans la nature ; que dis‐je, « il arrive », c’est le plus courant !). Dans certains cas, elles sont juste trop lentes pour être utilisables, parfois il y a des bogues d’interface utilisateur, parfois elles vont carrément faire planter le programme. Ce sont des bloqueurs de sortie. Bien sûr, on peut simplement les désactiver, mais cela signifie alors attendre une prochaine sortie de majeure. Or, à notre rythme de sortie, ça signifie repousser de plusieurs années ! C’était assez décourageant et on avait alors tendance à repousser la majeure, en espérant que quelqu’un corrige les fonctionnalités problématiques.
Autoriser de nouvelles fonctionnalités en version mineure va donc complètement nous débloquer, car on aura alors beaucoup moins de remords à désactiver les fonctionnalités dont nous ne sommes pas contents. Celles‐ci pourront revenir plus tard, même dans une mineure (si quelqu’un les finit).
GIMP 2.10
Une autre bonne nouvelle (conséquence de la précédente) est que nous souhaitons donc sortir GIMP 2.10 cette année ! Youhou ! On ne l‘avait pas annoncé officiellement, mais aujourd'hui, nous venons de publier une interview du mainteneur, que j’avais faite lors de la Wilber Week et qui est le premier document officiel donnant l’information d'une sortie prévue en 2017.
Pour info, cette interview est un de mes projets pour redonner une vie communautaire autour de GIMP. J’ai déjà réalisé quatre interviews (c’est la première en ligne) et prévois d’étendre et d’en faire beaucoup plus. Des interviews de développeurs (GIMP ou des projets en lien, comme GEGL…), mais aussi de contributeurs non‐développeurs, d’artistes qui se servent de GIMP, etc.
Interviews
D’ailleurs, si jamais vous souhaitez traduire l’interview sur LinuxFr.org, n’hésitez pas à y participer dans l’espace de rédaction. Elle est en CC‐BY-SA, comme tout ce que je fais (et c’est aussi la politique de licence du site gimp.org, même si je crois qu’on n’a pas encore ajouté l’info en pied de page. Mais en l’occurrence, l’auteur, là, c’est moi et je vous le dis en direct par écrit ;p).
Financement
Je conclurai ces bonnes nouvelles en rappelant que vous pouvez financer le projet ZeMarmot, soit par Tipeee (en euros), soit par Patreon (en dollars des États‐Unis). Cela nous permettrait à terme de financer notre développement de GIMP, donc de vivre du logiciel libre, tout en accélérant les sorties et la stabilité de GIMP, de sortir des films d’animation sympas, de faire vivre la communauté avec des interviews, des ateliers, etc. :-)
Votez GIMP, sur le Prix de l’Initiative Audiens
À plus petite échelle, je rappelle que vous pouvez toujours voter pour nous (pendant encore deux semaines) au Prix de l’Initiative Audiens. C’est un financement moins pérenne que le financement mensuel, mais ça aide quand même si l’on gagne et ça se fait en un clic. ;-)
Aller plus loin
- Journal à l’origine de la dépêche (167 clics)
- Prix de l’Initiative Audiens (107 clics)
- Compte‐rendu sur la Wilber Week (146 clics)
- Prix de l’Initiative Audiens, votez GIMP ! (167 clics)
# Détails !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 03 mars 2017 à 01:55.
Salut !
Je ne m’attendais pas à ce que ça passe en première page. Sinon, j’aurais mieux écrit mon journal…
Dans ce cas, je tiens à préciser que lorsque je parle de « résumé des points importants », ce sont des points importants « personnels ". D’autres contributeurs ont aussi bossé sur des choses très importantes. Notamment, il y a eu un travail (qui est toujours en cours) très important sur la base de Linear is the new black par Pippin, Mitch et les contributeurs GEGL. Ce travail se base sur le principe que les images en 32 bits flottants en lumière linéaire sont le format de travail idéal.
Aussi, les modes de calques (et plein d’autres fonctionnalités) ont été revus et l’interface utilisateur mise à jour par Mitch, en se basant sur le travail précédent. Bien sûr, comme la compatibilité descendante est un besoin majeur pour nous, les anciennes implémentations de modes sont toutes présentes à vie et utilisées en chargeant de vieux documents (de sorte qu’un ancien XCF aura toujours le même rendu, même dans 10 ans)¹ mais l’interface utilisateur est faite de telle sorte que les nouveaux documents utiliseront les nouvelles implémentations (bien qu’il restera possible de trifouiller pour retrouver les anciennes). Je ne veux pas trop parler de cela en détail, car j’ai peur de dire des bêtises.
Un peintre et contributeur (de rapports de bogues, d’idées, de propositions d’amélioration…), Americo Gobbo, fait d’ailleurs pas mal de recherche sur les nouvelles possibilités de GIMP en la matière, surtout les applications directes à la peinture numérique grâce aux nouveaux modes de calques. Notamment, il peint en texturant ses brosses. Voir ses expérimentations, par exemple ça ou encore ceci ou cela… Il fait aussi quelques vidéos intéressantes sur le sujet.
Il n’était pas présent à Wilber Week (il sera à LGM, je l’ai invité au nom de GIMP car son travail est intéressant et important pour améliorer GIMP et son interface graphique), mais ses expérimentations de brosses et textures se basent directement sur des changements de code de janvier.
Et c’est sans parler du travail de Elle Stone (qui n’était pas présente non plus mais est souvent sur IRC), une experte des couleurs et algorithmes, l’une des plus grosses critiques de GIMP, mais en même temps une contributrice majeure en revue de code et d’algorithme ultra‐poussé (elle n’est pas développeuse, mais elle lit le code à l’occasion et fait des correctifs algorithmiques), tests de versions de développement au pixel près, pointage de problème (on ne peut rien cacher sous le tapis avec elle !) avec force insistance, etc. Je ne comprends pas tout ce qu’elle dit car elle est très calée, mais ses revues sont de grande valeur.
On a aussi eu un contributeur (qui ne veut pas voir son nom cité) dont le trip est d’implémenter des algorithmes de recherche, et il a fait pas mal de contributions sur GEGL et aussi sur GIMP lors du Wilber Week. Il fait d’ailleurs du code de très bonne qualité. On espère qu’il restera avec nous. :-)
Il s’est donc passé pas mal de choses pendant et autour de cette Wilber Week. On était plusieurs développeurs et contributeurs sur place (et d’autres qui ne pouvaient venir, genre Ell, un contributeur majeur de ces derniers mois). Voilà, je voulais donc revenir un peu sur mon impression de compte‐rendu, qui a l’air bien terne si jamais on croit que c’est le compte‐rendu complet de Wilber Week : ça ne l’est pas ! C’était un compte‐rendu tout à fait personnel. D’ailleurs, on prévoit aussi un compte‐rendu plus global de l’évènement sur gimp.org.
C’est personnel dans le sens : je m’y suis impliqué. Pas dans le sens « le reste m’intéresse pas », bien entendu. :P
C’est super excitant ce que d’autres font en parallèle. C’est ça aussi qui est cool : travailler dans une équipe hétéroclite qui bosse sur plein de trucs différents tous très intéressants ! Franchement, je n’aimerais pas donner l’impression que Wilber Week, c’était juste pour faire un paquet Flatpak et discuter du changement de logique de version à dix personnes pendant une semaine (aussi intéressants que soient ces deux items !). Cette dépêche a peut‐être été promue un peu vite. Si j’avais su… Il aurait fallu la compléter un peu avant. :-)
Mais merci quand même ! ;-)
[1] Pour la petite histoire, sous Photoshop, pa exemple, certains fichiers identiques peuvent apparaître différemment selon qu’ils sont ouverts avec CS5 ou CS6. C’est un problème assez sérieux pour des gens qui travailleraient en équipe avec versions disparates (problème classique dans le logiciel propriétaire, car mettre à jour signifie payer une mise à jour de licence) ou simplement pour réutiliser ses vieux documents.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Détails !
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
J'ai modifié la dépêche pour préciser « personnels » et mettre un lien vers ton commentaire.
[^] # Re: Détails !
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
Les rencontres entre développeurs sont très importantes. J'en suis tellement convaincu que j'ai conçu les RMLL ne novembre et décembre 1999. Le but que je poursuivais était de créer un lieu d'échange et de travail entre des développeurs d'origines différentes. Ainsi, la réunion Gimp pourrait se tenir aux RMLL et s'enrichir de discussions avec les développeurs d'autres applications graphiques.
À titre d'exemple, en 2000, David Axmark (MySQL) et Hans Reiser (Reiserfs) ont passé des journées à comparer une transaction de base de données et la journalisation d'un système de fichier. À Amiens, le développeur de Audacity a rencontré celui de Ardour ; ils étaient en admiration mutuelle et ont longuement échangé.
Aux RMLL, il se passe ainsi beaucoup de très bonnes choses dont on apprend l'existence longtemps après.
# Mineures, majeures
Posté par rpnpif . Évalué à 1.
Bravo.
Quelle serait la différence entre version mineure et majeure dans ce cas si les mineures ont de nouvelles fonctionnalités ? Ce serait un système à la Firefox ou à la Libreoffice ?
Par ailleurs, une petite coquille dans le texte, je pense, car je ne comprends pas ici :
[^] # Re: Mineures, majeures
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Mineures, majeures
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
Pour l'instant il y a quand même de grandes différences. En tous cas 2.10 avec un changement profond du moteur graphique (certes déjà en cours, mais jusqu'alors GEGL n'était utilisé que pour des trucs superficiels, maintenant c'est vraiment partout); puis 3.0 avec le passage à GTK+3, ce qui va débloquer aussi beaucoup de choses normalement, avec prise en charge améliorée des tablettes, amélioration des thèmes, route vers HiDPI, etc. Plein de choses merveilleuses et féériques qui nous sont promises. Ensuite je suis persuadé que tout ne sera pas magique et qu'il faudra travailler un peu pour y arriver, mais au moins on sera sur le chemin. Pour l'instant avec GTK+2, on est un peu contre un mur.
Mais oui peut-être qu'à terme, la différence entre une mineure et une majeure pourra s'amenuiser. Est-ce un mal? Je ne pense pas. Même le noyau Linux n'a pas vraiment de différence entre ses majeures et ses mineures. On le voit bien dans les emails de Linus pour décider les passages de majeures, en général il l'accompagne d'une blague, genre "j'ai plus assez de doigts pour compter". Et voilà on est passé sur une majeure version 4.x du noyau sur un coup de tête et un sondage sans aucune autre logique que "est-ce que vous avez envie ou pas qu'on passe à v4?"
Est-ce un problème? Je ne pense pas vraiment, surtout si ça permet de rendre le développement plus énergique (on peut sans cesse créer des nouvelles fonctionnalités attrayantes!).
Firefox, oui. Je ne sais pas quel système utilise LO, mais si c'est comme Firefox, alors oui aussi.
La seule chose que je voudrais faire différemment que Firefox, c'est de garder une promesse de stabilité de l'API un certain temps. Et pour ça, les versions à point restent un bon moyen simple pour reconnaître la stabilité, contrairement à un simple entier. Firefox, de ce que je comprends, c'est qu'ils cassent l'API sur un coup de tête un peu n'importe quand, et que pour un dév de plugin, il faut vraiment se tenir à jour à chaque version et lire le changelog en détail. Avec une promesse de stabilité basé sur un numéro de version, c'est facile: le premier chiffre est le même, donc mon plugin continuera à fonctionner.
Je pense que cela reste un très bon intérêt aux numéros à point.
Ensuite, je me réserve le droit de changer d'avis dans un sens ou l'autre. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mineures, majeures
Posté par ff9097 . Évalué à 0.
Je pense que vous pouvez passez directement à GTK+4
[^] # Re: Mineures, majeures
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Cf. l'interview. ;-)
Plus sérieusement ceci dit, c'est justement le moment de bosser sur GTK+3 puisqu'il est maintenant stable. Je pense que GTK+4 ne sera pas considérée comme stable avant 2 ans (si je me souviens bien de la news sur le changement de version. À moins que ce fut 3 ans?). Tu vas me dire, le temps de sortir GIMP 3, les 2 ou 3 ans seront passés. Mais en fait, j'aimerais pouvoir accélérer les rythmes de sortie drastiquement (en tous cas, si je parviens à en vivre, c'est l'un de mes buts).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# le floue
Posté par ppb31 . Évalué à 8.
Bonjour à tous et à toutes,
D'abord et comme c'est la premier fois que j'interviens sur ce forum, je voudrai remercier toutes les équipes qui en sont responsables car le travail effectué de publication et de maintiens est formidable. Je pense que je le suis depuis ses début, car je travail sur Linux des 1998.
Le problème de GIMP: Les deux logiciels qui sont à l’origine de mon transféré de Windows à Linux sont Blender 3d et Gimp, à l'époque j'avais une boite qui réalisée des mise en 3d pour les architectes on utiliser Lightwave et pour faire des calculs distribués il fallait passer par des serveur DEC ALPHA avec beaucoup de bricolage.
Spécialiste des serveurs SUN j'ai basculé sur Linux naturellement avec une Redhat 5.2
Donc GIMP depuis 98, avec pas mal d'espoir de rattraper l’éternel Photoshop. Les soucis ne sont pas les fonctionnalités mais le flous éternel autour 12 et 16 bits natif.
Entre temps pour des raison professionnel je me suis mis à utiliser pas mal de photos dans mon travail et donc j'utilise exclusivement Darkatble, GIMP et Affinity Designer sur linux c'est possible.
Comme toutes les professions le monde du graphisme est relativement conservateur et malgré d'indéniable qualités les publication qui entour les nouvelles fonctionnalités de chaque version restent flous sur le sujet pourtant crucial de la prise en charge en natif du 16 bits et +, vue de l’extérieur la seul grosse amélioration après la gestion des calques en avance sur Photoshop à l'époque fut en 2012 avec la possibilité du mode fenêtre unique sur la version 2.8 j'insiste car 2.8 est toujours la version courante en 2017, 5 plus tard; Vue de l’extérieur "mais que foute les développeurs" Dractable, Krita, Blender ex.. avancent à pas de géants avec des moyens pas forcement plus important.
Donc oui les numéros de version compte ça fait plus de 5 ans que le 3 est attendu la 2.10 va encor donner l'impression que l'on avance à tous petit pas alors que si GEGL est le moteur complet par défaut avec effectivement une prise en charge natif du 16 b et + politiquement ça ferrait dans les chaumières OUF !!! enfin car franchement je connais les qualités de GIMP et notamment ça réactivité, mais si les version avancent à tous petit pas ce la parais suspect à plus d'un.
Donc je souhaite bon courage à toutes les équipes de développent, je continuerai à promouvoir se formidable logiciel.
Bonne et belle journée à tous le monde
[^] # Re: le flou
Posté par alex666 . Évalué à -2. Dernière modification le 03 mars 2017 à 11:35.
prise en charge 16 bits et +?
Fait depuis longtemps avec Gimp 2.9, par ailleurs parfaitement utilisable dans la vraie vie!
Avec et surtout sans cette horreur "fenêtre unique" (afficher des tas de trucs moches, mais bariolés, et accessoirement s'il reste de la place l'image à traiter)
Alors, les numéros de version…
[^] # Re: le flou
Posté par lolop (site web personnel) . Évalué à 3.
C'est un aspect psychologique important pour certains…
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: le flou
Posté par xcomcmdr . Évalué à 4.
J'adore le mode fenêtre unique, c'est le seule mode que j'arrive à utiliser…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: le floue
Posté par Le Pnume . Évalué à 5. Dernière modification le 03 mars 2017 à 14:35.
Je ne suis pas et de loin en champion de l’orthographe mais ça :
ça pique vraiment les yeux et les oreilles
[^] # Re: le floue
Posté par ppb31 . Évalué à 7.
Je répond oui ça pique et c'est pour cela que j'interviens très peux sur les forum car je suis dyslexie donc avant de critiquer la forme critique le fond et le points de vue le reste me parais dérisoire.
[^] # Re: le floue
Posté par Shunesburg69 . Évalué à 3. Dernière modification le 04 mars 2017 à 00:03.
Pas de soucis, on comprend l'essentiel, c'est l'essentiel.
Je ne pense pas qu'il te critiquait mais plutôt qu'il t'avertissait pour que tu reformules ta phrase.
Continue d'intervenir malgré ton souci, si tu te trompes c'est pas grave, tu peux toujours modifier ou préciser après coup.
[^] # Re: le floue
Posté par Le Pnume . Évalué à 5. Dernière modification le 04 mars 2017 à 12:20.
Une me*de sans faute reste une me*de et un bon texte avec des fautes reste un bon texte. L'absence de faute sur un bon texte est juste une couche de vernis en plus.
Je passe allégrement sur les "s" manquant, sur les ses-ces… en gros dès que la phonétique est respectée.
Pourquoi je me suis arrêté sur cette phrase, c’est parce qu’elle m’a obligé à interrompre la lecture continue d'un texte que je trouvais intéressant, j'ai dû la relire pour la comprendre. Quand je lis "qui réalisée" ou "on utiliser", j'"entend" des "é" pas des "ait" et mon cerveau me dit qu'il y a un souci dans la phrase alors je dois relire pour comprendre. Si j'avais dû faire ça 3 ou 4 fois, je ne serais jamais allé jusqu'au bout du texte.
Fond et forme ne peuvent pas être complétement détachés, je suis incapable de compter le nombre de livre que je n'ai pas lu parce qu'après quelques paragraphes le style (donc la forme) ne me plaisait pas.
Vous pouvez vous déchainer sur les fautes dans ce message.
[^] # Re: le floue
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Juste pour être sûr qu'on se comprend, notre objectif n'est pas de "rattraper" Photoshop, ni de le copier. On fait notre propre logiciel de création graphique, aussi bien qu'on puisse et en Libre. Le but de GIMP n'a jamais été d'être un clone. Je ne dis pas que c'est ce que tu voulais dire. C'est pas très clair. Mais au cas où, je le précise car c'est un commentaire qu'on a régulièrement. :-)
Il n'y a pas vraiment de flou, c'est très simple: en 2.8, y a prise en charge de 8 bits seulement, et en 2.10 y aura prise en charge 16 et 32 bits pour l'image de travail. :-)
Pour du 12 bits, je sais pas si y a des formats d'image qui ont cette profondeur, mais si oui, on devrait alors pouvoir exporter en 12 bits sans problème à partir d'une image de travail 16 ou 32.
Ensuite comme quelqu'un le note, la version de développement (estampillée 2.9) est déjà très fonctionnelle et stable au quotidien et te permettrait déjà de travailler des images en 16/32 bits. On utilise essentiellement la version 2.9 depuis plus d'un an pour le projet ZeMarmot. Maintenant soyons clair que c'est une version de développement et il peut y avoir de la casse. Pour une utilisation pro de la version de développement, il convient d'être tout de même un utilisateur éclairé au cas où les choses se passent mal. On fait gaffe, mais on ne peut absolument pas assurer une stabilité parfaite entre 2 versions de développement. Mais ça reste faisable. On le fait bien (mais évidemment en tant que développeur de GIMP, je suis un utilisateur assez éclairé aussi!).
Vu de notre côté, on avance aussi bien, mais c'est moins visible car on ne sort pas de version avec nos avancées. Et donc oui, vu de l'extérieur, ça n'a pas l'air d'avancer et c'est frustrant, je le comprends tout à fait. D'où le problème de versionnement qu'on essaie de résoudre et dont je parle dans cette news.
Ensuite "des moyens pas forcément plus importants"… alors Darktable oui, c'est le seul de la liste où c'est vrai. Mais Blender ont leur fondation derrière qui a maintenant des moyens de plus en plus conséquents (pas encore gigantesque, mais ils font quand même des crowdfunding à plusieurs centaines de milliers d'euros, et touchent du financement européen du même ordre de grandeur, ils ont leur cloud avec abonnement, etc.), et Krita ont créé leur propre fondation et font du marketing à fond, des crowdfundings, etc.
GIMP reste essentiellement communautaire. Néanmoins il y a quelques développeurs, notamment moi, qui essayons justement de nous donner des moyens financiers. Le jour où notre financement Tipeee ou Patreon sera de quelques milliers par mois, alors oui on pourra commencer à dire qu'on commence à avoir des moyens pour développer GIMP professionnellement. À ce jour, le développement de GIMP est financé avec des cacahuètes.
Qui attend le 3? On n'a même pas vraiment commencé à travailler dessus. Bien sûr, on a quelques commits de temps en temps, mais c'est minime. On maintient la branche juste assez pour qu'elle compile avec GTK+3. Et de temps en temps, on fait quelques trucs, mais c'est pas assez pour dire qu'y a du dév actif.
Le développement actif est quasi essentiellement sur la version 2.10. C'est là où les choses se passent et la seule version à attendre pour l'instant.
Je ne comprends pas, le problème est juste une histoire de numéro? Chez GIMP, le second nombre indique une sortie majeure. 2.10 sera autant une majeure que 3.0. De même que 2.8 était une sortie majeure.
Bonne chose, mauvaise chose, je ne sais pas. Peut-être que cela changera un jour. J'ai l'impression qu'historiquement, cela suit simplement les versions de GTK+. Avec l'accélération du versionnement de GTK+, ça voudrait d'ailleurs dire que les versions de GIMP risquent d'accélérer aussi beaucoup après GIMP 3. On verra.
Ben oui, GEGL a la prise en charge du 16 bit (même 32 bit, qui est maintenant le format natif de GIMP). C'est ce qu'on dit. Je pense que tu n'as simplement pas suivi les nouvelles de GIMP depuis… 4 ou 5 ans? ;-)
Bon bien sûr, ça implique de suivre les news de dév, puisqu'il n'y a effectivement pas de sortie de version stable. Donc je comprends l'incompréhension, pas de problème.
Qu'est-ce qui paraît suspect? Que GIMP est un logiciel libre développé à 99.999% par du bénévolat dans le temps libre, que personne ne bosse à temps plein, payé, et qu'on est pas un business? J'ai du mal à comprendre où tu veux en venir.
Personnellement j'aimerais bien en vivre et pouvoir faire cela (développer GIMP) à temps plein. Mais pour cela, il faut nous soutenir financièrement sur les liens du projet ZeMarmot donnés juste au dessus. Parce qu'autrement, nous dire que ça paraît "suspect" que ça avance pas plus vite, ben ça me fait juste mal au cœur. ;-(
À l'heure actuelle mon état d'esprit est le suivant: on finit notre épisode cette année et si on a pas atteint un financement acceptable pour vivre décemment (à l'heure actuelle, le financement ne paye même pas un loyer, surtout qu'on fait tout dans les règles et qu'y a des charges sociales en salaire, etc. C'est pour te dire que si y a une définition de la précarité, je rentre dedans), ben on commencera à chercher des alternatives et mon implication à GIMP en souffrira probablement drastiquement malheureusement. Et il n'y aura rien de "suspect" au fait que la rapidité de développement de GIMP diminuera beaucoup plus puisque je suis le second plus gros contributeur depuis plusieurs années. Ensuite il reste Mitch, qui fait 2 fois plus de commits que moi en ayant son propre business. Je sais pas vraiment comment il fait (enfin si, je sais; il contribue à GIMP depuis 20 ans et connaît son code bien mieux que moi, et aussi il a beaucoup plus d'expérience de développement en général que moi). Mais il est entièrement bénévole alors lui reprocher aussi de pas aller assez vite serait tout aussi aberrant.
Voilà j'espère que ça te donne une autre perspective sur le développement de GIMP et les "moyens" (assez imaginaires) que tu sembles imaginer derrière son développement.
Merci. En tous cas, tu as l'air de bonne foi et amical (contrairement à d'autres cas; malheureusement contribuer à GIMP, c'est s'exposer à pas mal d'insultes et de haine et je suis pas toujours bien taillé pour cela; mais je travaille pour me durcir le caractère et être moins sensible à la méchanceté, car des fois ça a été dur). Mais je te conseillerais de faire attention dans ton choix de mots car ils peuvent être assez mal pris. Surtout quand justement je cherche à en vivre mais n'y arrive pas (j'ai parfois l'impression de faire des appels au crowdfunding dans le vide).
J'espère que mon explication t'aura un peu éclairé sur GIMP et son développement. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: le floue
Posté par ppb31 . Évalué à 3.
De la haine pour travailler sur GIMP ? qu'elle drôle de monde ! d'abord merci d'avoir pris le temps de répondre avec autant de détails.
Je reprend ce que je disais sur le souci des versions et il faut le regarder avec un point de vue extérieur (utilisateur lambda non développeur) donc, la version officiel est la 2.8.20 pas les 2.9 qui est la version test je suppose car mois qui suis aussi développeur ( master 2 en SI) le principe des versions est mon cœur de métier notamment avec la mise en place de version documentaires pour les entreprises.
le fait que la 2.9 et full 16 bits importe peux car sur la page https://www.gimp.org/ la version par défaut proposer est la 2.8.20 et la série de 2.8 est en place depuis plus de 5 ans ce qui à pour effet ce que j'explique précédemment quoi que l'on en dise.
Utiliser la 2.9 est plus compliqué car elle n'existe pas dans les PKGs par défaut des principales distributions
en plus vue que la le 16 bits est pleinement opérationnelle pourquoi ne pas l’intégrer et le bon vers une version 3.x.x serai justifier. Juste pour rappel quand on veut ouvrir une image Tiff 16 bits par défaut la phrase est : "Attention l'image que vous chargez possède 16 bits par canal. GIMP ne peut manipuler que 8 bits, donc elle sera convertie pour vous. Des informations seront perdues à cause de cette conversion." et c'est ce qui hérisse les potentiels nouveaux utilisateurs, pour eux le jeux de la version 2.8.x ou 2.9 n'est pas compréhensible
l'utilisation de GIMP est très agréable, mai quand j’essaie de convaincre du monde on me reproche toujours ce soucis.
GIMP représente depuis très longtemps l'alternative à Photoshope et en tous cas toujours présenter comme ce la par plus ou moins tous le monde dans la presse spécialisée ou pas, sur internet ou pas et ce la on ne peux pas le nier depuis aix mons 20 ans .
Ce n'est pas une question de bonne foi ce la reste objectif, je me suis pas arrêté il y a 5 ans mais sur la dernier Ubuntu qui propose par défaut le 2.8.18, la comparaison avec les autre programmes phares du graphisme sur Linux est justifier puisque ils sont disponibles et que l'utilisateur ne va pas rentrer dans les détails du développement mais qui se posent des questions tous simplement. Il existe aussi un autre d'on les versions 0.92 pour Inkscape interroge mais comme le vectoriel ne pose pas de soucis d'importation d'image 16 bits par nature la comparaison avec des solutions propriétaire est moins facile.
Je pense effectivement que la communication est essentielle et qu'elle passe aussi dans le référencement des versions en tous cas c'est mon point de vue.
[^] # Re: le floue
Posté par Space_e_man (site web personnel) . Évalué à 2.
Je suis entièrement d'accord avec ppb31 ! :/
Cela ne m’empêche pas de n'utiliser que GIMP, même en 2.8 / 8 bits, de manière très poussée et parfois professionnelle avec au final Scribus qui s'occupe de la quadri' pour l'imprimeur par exemple… (oui, car il y a également la question du RGB vs CMJK)
Cela ne m'empêche pas non plus d'inviter mes clients, mes collègues ou mes élèves à utiliser GIMP, en 2.8/8b, avec le système GNU que je leur ai installé.
Cela fait maintenant plus de 12 ans que je n'ai pas touché un Photoshop d'Adobe. Et donc je sais pas s'ils ont fait des progrès et c'est pas très important car à ma connaissance, côté liberté et de l'éthique, ils sont toujours nul part. Mais donc, à l'époque, GIMP avait également ses propres avantages "techniques" :
Attention, attention !
Je ne cherche pas ici à comparer les deux logiciels ! D'un point de vue technique, je suis presque sûr que la dernière version de Photoshop est "supérieur" à GIMP 2.8. Alors que d'un point de vue des libertés et de l'éthique, GIMP à toujours maintenu une énorme supériorité (presque infinie) sur Photoshop.
Comme je l'ai signalé dès le départ, j'attends moi aussi une version stable, « grand public » de GIMP 2.10 et ensuite 3.x avec de grosses nouveautés comme le 16 bits (et plus) ! mais pas que…
Comme le dis ppb31, GIMP a déjà su se faire une belle réputation. Mais dans le milieu, tous le monde sait que GIMP* n'est « que en 8 bits » (*: version stable, facile d'accès, livres, etc.).
Alors imaginons un peu, le bruit que pourrait faire une sortie officielle d'une version stable, facile à installer pour toutes les plateformes, avec enfin le 16 bits ! (et la quadri)
Personnellement, j'attends ça depuis plus de 3 ans maintenant !
On se demanderait presque s'il n'y a pas du sabotage au sein de l'équipe GIMP pour ralentir et retarder un tel événement :)
On nous fait languir et presque baisser « le soutient » (à l'instar de la garde) avec cette histoire d'un 2.9 avec du 16 bits pour les initiés… Donc à la fois oui, et non… :/
Mais j'ai cru comprendre également, que l'intégration de GEGL à énormément ralenti la sortie du « 16 bits » et de nouvelle versions majeurs. Et en même tant, GEGL permettrait tellement plus encore, que nous aurions tout à y gagner à patienter encore, et encore…
Et finalement, si tout cela ne tenait également qu'au financement ?
C'est donc pour cela que, dès lors que j'en avais la possibilité, j'ai effectué un don. Et j'aimerais vous encourager tous, dans la mesure du possible à faire pareil. Car l'argent est parfois le nerf du progrès, y compris pour les libertés et l'éthique.
GIMP est pour moi une pièce maîtresse de nos systèmes GNU. GIMP en 16 bits, il est plus que temps ! Alors, pour ceux d'entre-nous qui souhaitons vivre le projet GNU, investir dans GIMP 1 €, c'est un peut comme pour un « capitaliste » d'investir 100 € ou 1000 € en actions Adobe.
Investir dans « le commun » n'est-il pas beaucoup moins coûteux que d'investir dans « la domination » ?
[^] # Re: le floue
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
Alors soyons clair: je vous comprends tous les deux tout à fait. Si ça ne tenait qu'à moi, on aurait sorti une 2.10 en cachant toutes les fonctionnalités non finies y a plus d'un an. Mais voilà d'une, ça ne tient pas qu'à moi; de deux ça aurait été probablement une erreur quand je vois les changements de fond qui sont faits en ce moment par Mitch. On aurait sorti GIMP sans ces changements, cela aurait probablement été un très gros problème et même un boulet sur le long terme pour GIMP (car on fait attention à la compatibilité descendante, donc on doit être aussi sûr que possible de ne pas sortir avec des choses qui seront ensuite un poids à vie dans GIMP). Et c'est aussi dans ces moments-là où je suis content de pas être seul sur GIMP, du fait que ça ne tient pas qu'à moi, car je fais équipe avec plein d'autres gens compétents. :-)
C'est notre synergie qui fait de GIMP un logiciel final plutôt pas trop mal. ;-)
Et puis c'est exactement pour corriger ce problème de sortie qui prennent trop de temps qu'on allège nos règles de sorties en espérant ainsi pouvoir accélérer la sortie des majeures.
Quand je parlais que l'utilisation de la 2.9 était possible, ce n'était nullement pour dire que ça existe et que c'est sorti, donc qu'il faut simplement l'utiliser. J'ai d'ailleurs bien mis en garde sur les problèmes possibles. J'ai juste donné une alternative potentielle pour des utilisateurs avancés (car y en a pas mal sur linuxfr), au cas où ça intéresse de savoir. On est nombreux à utiliser la 2.9 en "production".
Mais oui je me rends bien compte que ce n'est pas la même chose qu'une stable et je suis bien conscient du problème de sortie. :-/
Tout à fait, c'est vraisemblablement le fond du problème. D'ailleurs merci encore pour y participer. ;-)
GIMP n'est pas une entreprise avec des délais à tenir, etc. C'est un projet communautaire essentiellement et on ne peut par forcer un bénévole à se dépêcher pour sortir une version dans les temps. Parallèlement nous ne sommes que 2 développeurs à vouloir essayer de vivre du logiciel libre et donc du développement de GEGL ou GIMP et le succès est mitigé pour le moment.
Donc je dirais que le fond du problème, c'est que d'un côté, y a l'image que les gens ont de GIMP (ils imaginent un gros projet avec des centaines de gars dont pas mal bossent dessus à temps plein, mais certains "saboteraient" le projet de l'intérieur) et la réalité, les faits (quelques péquins qui font ce qu'ils peuvent, la plupart en bénévoles sur leur temps libres; certains essaient de se financer, mais on n'y est pas encore).
Idéalement on arriverait à aligner la réalité à l'image (sans les parties "sabotage").
Parce que même si je comprends tout à fait ce que vous dites, ppb31 et toi, et je vois complètement votre "point de vue extérieur (utilisateur lambda non développeur)" (en reprenant les mots de ppb31), ben y a la réalité qui intervient: y a des limites à ce que quelques personnes seules dans leur coin peuvent faire. Et même si on aimerait en faire plus en se faisant payer (dans mon cas), en attendant on n'en a pas les moyens.
Enfin voilà, on fait ce qu'on peut. On espère que ça suffira et que vous apprécierez quand même!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: le floue
Posté par remico . Évalué à 2.
Le reproche qui est fait au 8bit (256 valeurs) pour la photographie ce n'est pas d'être insuffisant pour le stockage ou la visualisation en jpg, c'est de générer des "crans" dans une suite de traitement et d'obtenir un histogramme en peigne. Ce phénomène s’atténuerait à chaque augmentation de la précision, il serait moins sensible en 11bits (2048 valeurs par canal) par exemple pour le traitement, même si l'exportation finale se ferait en 8 bits.
A titre indicatif beaucoup d'appareils sont en 14bits ou en 12bits pour le stockage des données brutes raw voire même moins 11bits +7 pour certains raw Sony. Ces 11bits +7 ne sont pas 18bits mais par portion de 16 pixels deux sont codés en 11bits et le reste en 7bits.
J'insiste sur ces valeurs intermédiaires car j'ai constaté avec la version de développement qu'en 16bits pour un fichier issu d'un 10Mpix certains traitements prennent du temps, ce n'est plus l'utilisation fluide de la 2.8, c'est vrai aussi que je n'ai pas une machine ni très récente ni haut de gamme, c'est probablement le cas aussi d'une majorité d'utilisateurs de Gimp. Avec des valeurs intermédiaires les inconvénients du 8bits seraient bien atténués tout en gardant une fluidité d'utilisation, et comme le 16bits ne semble pas indispensable y compris par les fabricants d'appareils photo ..
[^] # Re: le floue
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
Je sais pas trop où tu veux en venir en disant cela. Tu t'imagines bien que je sais à quoi sert de travailler en 16 ou 32 bits. D'ailleurs c'est bien pour cela que je fais la différence entre le format de travail et le format d'export dans le bout de texte que tu cites toi-même.
Essaie en 32 bits, ce sera peut-être plus rapide. La seule raison de travailler en 16 bits seraient éventuellement pour des problèmes d'espace disque. Sinon autant travailler dans le format interne qui est en 32 bit.
Ça dépend vraiment pour quoi. Beaucoup de choses sont bien plus rapides en 2.9/2.10 qu'en 2.8 (notamment dans les effets, maintenant des opérations GEGL); mais y a aussi des choses plus lentes en effet.
Je veux aussi noter que GIMP reste un logiciel de traitement d'image pour utilisateur avancé (c'est la première cible), qui auront normalement du meilleur matériel, adapté au traitement graphique (un procédé lent par définition car ça se repose sur beaucoup de calculs). Ensuite ce n'est pas une excuse et y a évidemment des choses qu'il serait vraiment bien d'optimiser. L'amélioration ne s'arrête jamais! ;-)
Néanmoins il est bon de rappeler ce que GIMP est: un logiciel qui fait du traitement lourd et complexe. Avoir une meilleure machine si c'est une utilisation habituelle ne serait pas une mauvaise idée.
Tu veux dire proposer du 12, 14 bits, etc.? Ça ne changerait rien. Le nombre de bit ne changera pas la vitesse de calcul. Au contraire, si tu veux éviter un max les conversions, travaille en 32 bits.
Pour info, certains développeurs parmi nous veulent même se débarrasser du menu de choix des précisions pour que GIMP reste constamment dans son format optimal (32 bit float linear). La logique est que ce choix ne fait que perturber les gens qui ne comprennent pas bien comment tout cela marche, même si parfois ils croient avoir compris et vont alors faire des choix qui les desservent (et je m'inclus volontiers dans cette liste de gens, attention! Ce sont des sujets super compliqués et je veux pas te donner l'impression de te prendre ou qui que ce soit de haut. J'ai d'ailleurs récemment acquis un livre sur les couleurs pour essayer d'approfondir mes connaissances sur ce sujet). Il me semble que cette argumentation a du sens même si ce genre de choses sont encore en discussion. Personnellement je préfère que GIMP prenne ce genre de choix pour moi.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: le floue
Posté par remico . Évalué à 1.
Merci pour les précisions, effectivement, je viens d'essayer le réglage virgule flottante en 32 bits sans impact sur la rapidité alors que j'aurai pensé que le pc ne l'encaisserait pas et je ne m'y serais pas risqué.
Ce qui est long comme opération mais qui n'est pas non plus d'un usage courant c'est les opérations de tone mapping. Par exemple avec l'algorithme Fattal et une image 3896x2616 sur ma machine Gimp calcule 1 minute pour générer l’aperçu, qu'il faut recalculer à chaque action sur les curseurs, pendant ce temps il ne veut pas quitter ni annuler l'opération, faut attendre la fin. Pour trouver le bon réglage il vaut mieux passer par une image réduite en 800x600 où la génération de l'aperçu est affaire de secondes.
# Soutenir l'œuf et la poule !
Posté par Space_e_man (site web personnel) . Évalué à 1.
Entre mes revenus et ce que me coûte la vie (flux d’entrés/sorties), j’avais un petit surplus. Étant donné que je ne suis pas capitaliste pour un sou (“buffer overflow”), j’ai simplement pu réaliser un rêve, mais pas que… → « Soutenir l'œuf et la poule »
Un tout Grand Merci à vous !
# Dons, mais où?
Posté par alex666 . Évalué à 2.
Je veux bien donner une partie de ce que me coûterait un photosh…
Mais où et comment? Ni Gnome, interface imbuvable pour moi, ni les films d'animation ne sont ma tasse de thé. Et si en plus c'était reconnu par le fisc (les formations photosh… sont bien largement subventionnées, fiscalement et par d'autres moyens) ce serait mieux.
[^] # Re: Dons, mais où?
Posté par Space_e_man (site web personnel) . Évalué à 3.
L'animation n'est peut-être pas ta tasse de thé mais c'est actuellement la principale motivation de l'un des deux principaux développeurs de GIMP, en tant qu'utilisateur. En même tant, le projet et ses fruits seront libres également ! Cela signifie que des écoles d'infographie et d'animation auront le nec plus ultra en terme de matériel pédagogique en lien avec GIMP et la démonstration faite que GIMP peut être utilisé pour de tels réalisations professionnelles (libres ou pas libres). Voila pourquoi, j'ai personnellement trouvé un sens multiple au fait de faire un don pour le projet ZeMarmot tout en soutenant le travail de Jehan, qui dans le cadre de ce projet va être pour une bonne partie des avancées dans GIMP et l’imminente sortie d'une version 2.10, etc. → « Soutenir l'œuf et la poule ! »
C'est par ailleurs dans l'un des commentaires que tu trouveras la réponse de Jehan à propos de comment faire un dons et à qui…
Merci d'avance _^
[^] # Re: Dons, mais où?
Posté par Okki (site web personnel, Mastodon) . Évalué à 3.
GNOME se contente de gérer les dons, l'ensemble de la somme (hormis les quelques frais engendrés par leur gestion) allant bien au projet GIMP.
Sinon, j'en profite pour rebondir sur cette histoire d'interface pour rappeler qu'il suffit de deux ou trois extensions (Dash to Panel, TopIcons Plus, Applications menu…) pour obtenir une interface similaire à Windows.
Même chose si tu souhaites récupérer les boutons minimiser / maximiser les fenêtres ou faire en sorte que de cliquer quinze fois sur une icône te lance bien quinze fenêtres de la même application. Tout se règle en deux cliques de souris, et il ne faut guère plus de cinq minutes de configuration pour obtenir un environnement plus traditionnel.
[^] # Re: Dons, mais où?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
Financer GIMP ne finance pas GNOME! J'explique cela dans le premier paragraphe ici.
Tu n'es pas obligé de vouloir faire ou voir du film d'animation pour apprécier notre travail sur GIMP.
De mémoire, j'ai implémenté des corrections de bugs et de plantages par dizaines, notamment ai corrigé des plantages massifs sur l'utilisation de tablette graphique (avant nous, une micro-coupure de la connexion de la tablette faisait planter GIMP et MyPaint! Autant dire que ces 2 logiciels n'était pas utilisable au quotidien par des illustrateurs non masochistes…), prise en charge du standard XDG pour les fichiers de configuration, ai participé à l'intégration des brosses MyPaint, ai implémenté la peinture en symétrie, ai intégré la recherche d'action, ai lancé le travail sur les nouvelles icônes et nouveaux thèmes, ai créé le Flatpak de GIMP, fait beaucoup de correctifs et changements en rapport avec l'internationalisation (j'aime beaucoup les langues donc l'internationalisation d'application est un sujet qui me passionne) comme par exemple une vraie prise en charge des méthodes d'entrée dans l'outil texte, ai poussé à de meilleurs valeurs par défaut, ai fait des dizaines de revues de code, ai aidé à la prise en charge de webp, ai ajouté la prise en charge de la modification des options dans le système de migration des fichiers de configuration, etc.
On en fait des choses en plus de 500 commits.
Tu n'es donc pas obligé d'apprécier les films d'animation (ni voir ni faire) pour apprécier mon travail et sa portée bien au delà du sujet "animation" pure. ;-)
Désolé. L'association LILA n'est pas une association reconnue d'intérêt général ou d'utilité publique.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Dons, mais où?
Posté par Dareg . Évalué à 1.
Mais ne pourrait-elle pas l'être ?
Apporter de nombreuses contributions a un logiciel libre et produire un film lui aussi libre me semble aller dans l'intérêt général.
Mais je suppose que ce n'est pas aussi simple.
# Boîtes à outils masquables ?
Posté par AlexTérieur . Évalué à 0. Dernière modification le 06 mars 2017 à 22:48.
Bravo et félicitation à toute l'équipe. Gimp est pour moi depuis des années devenu un incontournable.
Seule question : je ne sais pas si c'est déjà possible mais je voulais savoir s'il est prévu de faire des boîtes à outils masquables (qui se transforment en "onglet" sur les côtés lorsque non utilisés et apparaissent lorsque la souris passe dessus), je pense que c'est le meilleur compromis entre le fenêtrage unique "à la Photoshop" et le "multi-fenêtre habituel de Gimp que certains critiquent (un peu trop).
[^] # Re: Boîtes à outils masquables ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
Perso, j'ai toujours détesté les trucs qui "bougent tout seul", se cache ou apparaissent, etc. juste au passage de la souris. Parce que ça apparaît tout le temps quand je ne le veux pas, et c'est le meilleur moyen de cliquer là où on ne le veut pas. Par exemple, j'ai désactivé l'apparition de l'overview dans GNOME en mettant la souris en haut à gauche, car je trouve cela énervant au plus haut point.
Ensuite c'est personnel, car de toutes évidences, ce type de GUI auto-apparente est utilisé dans plein de logiciels.
Par contre, oui l'idée est intéressante, mais je choisirais donc un clic de souris sur l'onglet plutôt qu'un simple survol, personnellement.
Aussi connais-tu le raccourci Tab (équivalent du menu "Windows" > "Hide Docks") qui permet justement de cacher et afficher l'ensemble des docks au simple clic d'un bouton?
En fait le multi-fenêtrage a son fan-club aussi. En général, ceux qui aime le multi-fenêtre ne supportent pas le simple fenêtrage. Personnellement mon but est d'arrêter la différenciation entre multi et simple fenêtrage. Il ne faut qu'un seul mode de fenêtrage qui permette de mélanger les deux logiques: rassembler les fenêtres en une, mais en séparer seulement certaines, etc.
En fait on a ça partiellement pour les docks qui peuvent déjà être séparés dans une fenêtre différente même en mode simple fenêtrage. Mais la boîte à outil ne le peut pas. Ni les images qui sont forcément en onglet.
Pour moi, cela n'a aucun sens de maintenir une différenciation totalement artificielle entre ces 2 modes.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Boîtes à outils masquables ?
Posté par alex666 . Évalué à 1.
"Il ne faut qu'un seul mode de fenêtrage…"
Mais qui donc est ce "il"?
Comme tout le monde, j'ai ma solution qu'elle est la meilleure: un écran réservé à mon image, l'autre aux fenêtres utilitaires que j'utilise.
Il faut laisser le maximum de choix à l'utilisateur plutôt que de décider ce qui est bien pour
luisoi, non?[^] # Re: Boîtes à outils masquables ?
Posté par B r u n o (site web personnel) . Évalué à 1.
Tu n'as pas lu la fin de la phrase que tu cites, Jehan a dit :
Le but me semble donc justement de laisser l'utilisateur décider ce qui est bien pour lui, totalement.
[^] # Re: Boîtes à outils masquables ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Tout à fait. Avec un mode de fenêtrage unique, on pourra faire tout ce qu'on peut déjà faire avec les 2 modes, et plus.
Exemple typique de problème: quelqu'un aime le simple fenêtrage, mais les images ne peuvent pas être détachées. On ne peut donc avoir deux images côte-à-côte. Seul le multi-fenêtrage le permet.
En fait, en y repensant, les différences entre le simple et multi fenêtrage ne sont pas si grandes et sont très artificielles. Il n'y a aucune raison d'avoir 2 modes. Il faut juste une flexibilité du fenêtrage de manière générale.
Le simple et multi-fenêtrage sont justement des choix qui ont été faits pour les gens. Si on veut laisser un vrai choix, il ne faut plus de modes de fenêtrage.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Boîtes à outils masquables ?
Posté par AlexTérieur . Évalué à 0. Dernière modification le 07 mars 2017 à 23:10.
Je ne pense pas que dans le cas des boites à outils cela apparaisse inopinément. L'image serait centrée sur l'écran, et la tendance naturelle veut qu'on se concentre sur le centre de l'écran et pas autour…
Justement, ce que je dis est (à mon humble avis) un compromis idéal. Mais si tu veux mon avis personnel, la fenêtre à la Photoshop m'agace au plus profond, car l'objet même du travail, à savoir l'image à éditer, se voit amputer d'une partie de l'affichage. Mais comme tu le dis, ce n'est que mon avis.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.