C'est possible, je ne saurais dire.
J'imagine que je le recroiserai sûrement un jour. Il me semble l'avoir aperçu aussi aux RMLLs. J'imagine donc qu'il fait divers évènements et que je le reverrai un jour.
Pour tout dire, j'avais pris des infos sur lui et sur son activité pour voir ce qu'il faisait un peu plus en détail (par intérêt de manière général sur ce qui se fait en Libre sur le sujet), mais je n'ai pas pris la peine de vérifier immédiatement après et ne sais plus où j'ai bien pu noter cela. :-/
Enfin bon, si je le recroise, j'essaierai de retrouver cette news et mettrai une réponse. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Il reste encore les aveugles qui paye très cher leurs matérielles uniquement compatibles Crosoft.
À un apéro Parinux, j'ai croisé un aveugle qui avait monté une boîte pour répandre et développer les solutions pour aveugles sous Linux. Je ne sais plus son nom ni celui de sa boîte. Mais en tous cas, cela existe et semble suffisamment fonctionnel pour en faire un business sans passer par les logiciels Microsoft.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je vais aller voir ce que Richard Hughes a prévu pour la v2
Il est en train de faire un batch en ce moment (il attend le retour d'usine). Je vais probablement en acheter un à ce moment là. Il me dit qu'il utilise le ColorHug 2 pour calibrer son écran Dreamcolor et qu'il a de très bons résultats avec.
sRGB c'est quand même pas très pro.
Pour être tout à fait réaliste, aller loin au dessus de AdobeRGB, il y a aussi beaucoup de masturbation intellectuelle ou de "victime de la mode" (d'ailleurs on y a succombé aussi, mais je me suis posé longtemps la question et je me la pose encore).
Je ne dis pas que dans certains cas, c'est pas utile. Typiquement un photographe qui va travailler avec des couleurs très saturées, très souvent, oui. Mais même en étant dans le métier de l'impression (photographe, designer, etc.), pour beaucoup de pros, c'est inutile. En effet, pas tout le monde n'aime les couleurs pêtantes, et beaucoup de pros de l'image vont même plutôt se faire une spécialité de travailler dans des couleurs plus subtiles, pastelles même, etc. Et dans ce cas là, que ton écran soit sRGB ou Adobe RGB ne changera rien (car tes couleurs ne sortiront jamais du gamut sRGB de toutes façons). Dans un tel cas, il vaut probablement même mieux un écran sRGB très précis qu'un Adobe RGB moins précis, par exemple.
En plus travailler en Adobe RGB ajoute tout de suite un peu plus de stress dans son workflow de peur de faire des erreurs, et il faut toujours tout re-vérifier. En sRGB, au moins, y a pas trop à se poser de questions car c'est du défaut partout.
Mais oui, c'est sûr que c'est mieux si le colorimètre est capable de tout bien calibrer. :-)
En fait, Richard travaille même sur un spectromètre OpenHardware (le ColorHug+) qui sera dans les 400 EUR probablement (en retard sur le planning, il a qu'un prototype et en a vendu aucun à ce jour). Cela permettra d'avoir des calibrations encore plus précises, et même de calibrer une imprimante.
Je trouve perso son activité vraiment intéressante! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je trouve cela super que ça existe, mais j'ai une expérience perso mitigée. J'ai souvent eu des résultats un peu trop vers le rouge.
Déjà dans l'idéal, il faut avoir une matrice de correction spécifique pour ton écran (ce qui est créé avec un spectromètre). Or le colorhug en a une liste (que tu peux voir là) générée par la communauté, mais elle est petite, car la communauté est elle-même encore petite, et surtout peu ont un spectromètre, ce qui est du matos cher. Il n'y a pas de CCMX pour mon écran malheureusement. Je dois toujours approximer avec un autre CCMX. :-/ D'ailleurs c'est aussi pour cela que je demande si quelqu'un a un spectromètre. Si je pouvais générer moi-même le fichier CCMX pour notre Dell U2413, je serai heureux de le fournir upstream pour la liste communautaire.
En outre, le colorhug marche mieux pour les écrans sRGB et a du mal avec le wide gamut (Adobe RGB…), ce qui est le cas de notre écran. Richard Hughes est en train de créer le colorhug2 qui marchera bien mieux avec les écrans Wide Gamut, mais bon… je l'ai pas.
Au final, j'ai envie de supporter le projet, et je ne regrette pas d'avoir donné des sous si ceux-ci permettent de faire avancer la colorimétrie OpenHardware. Par contre je dois bien avouer que mon expérience reste un peu faible.
Est-ce que ça vaut le coup pour un ordi portable ?
En fait on peut se poser la question si ça a vraiment le moindre intérêt pour un portable. Déjà parce que les écrans de portables sont en général pourris (un point très important par exemple est de voir les mêmes couleurs sous tous les angles, sinon ça n'a aucun sens de calibrer les couleurs: à peine tu tournes la tête de quelques cms et tu vois déjà d'autres couleurs! C'est pourquoi on va en général privilégier les écrans IPS ou PVA. Peu de portable ont ces dalles). Ensuite parce que c'est dur de changer la luminosité sur un écran de portable en hardware. Enfin parce que par définition, tu changes l'angle et la position de ton écran sans arrêt. On va plutôt calibrer de bons écrans, qui ont un angle de vision large et qui restent toujours au même endroit.
Dernière question, tu parles de X-rite dans ton post, mais c'est des profils proprio ça non ? Du coup on fait comment sous Linux ?
Comme beaucoup de matos proprios, il y a des drivers Linux. En tous cas, dispcalgui affirme le prendre en charge, donc je suppose que c'est utilisable sous Linux.
En outre l'écran que je souhaite calibrer a des fonctionnalités de calibrage matériel, mais qui ne marche qu'avec un logiciel sous Windows. J'ai un Windows en VM que je souhaite donc utiliser pour le calibrage matériel (en espérant que c'est possible à travers une VM) pour pouvoir ensuite en profiter dans mon usage quotidien sous Linux.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ah c'est quand même beaucoup mieux. L'URL en particulier est la partie dangereuse car elle peut donner des informations. Typiquement le premier exemple qui me vient à l'esprit sont les adresses dans les spams (en considérant que beaucoup de gens regardent leurs emails par webmail donc dans le navigateur) qui contiennent souvent un identifiant quelconque (soit votre adresse email en clair, soit un hash abscons qui vous identifie dans la base du spammeur et leur permet de savoir qui a encore une adresse active par exemple, et sûrement bien plus!). Si le simple fait de survoler un lien (quelque chose que je fais typiquement régulièrement, justement pour voir où ça mènera et si ça a l'air d'un lien clairement frauduleux ou relativement sûr…) envoyait des données (HEADER, URLs…), alors ce serait une terrible faille de sécurité.
Il faut donc espérer que cette partie reste toujours ainsi.
La première partie (limiter l'ouverture spéculative à certaines ressources) est bien aussi, ceci dit. Même seulement une connexion TCP sur n'importe quel serveur, on sait jamais. Autant que le navigateur ne s'amuse pas à ouvrir des connexions avec n'importe quel lien qui traîne…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui. Sauf que je ne trouve pas de "répertoire" qui soit vraiment au dessus de la moyenne. Cette appli web fait plus que juste garder des infos sur tes contacts. Il gère les rencontres avec les dits-contacts, ajoute une sorte de suivi pour avoir des "évènements". Bien sûr, tu peux reproduire plus ou moins les infos avancées et les rencontres avec un champs "Notes", mais c'est quand même bien moins parlant.
Tu peux aussi coupler avec ton calendrier pour créer des évènements, mais franchement j'ai pas envie d'encombrer mon calendrier de ce type d'items. C'est quand même pas la même catégorie d'évènements que noter un RDV avec qqun, etc.
Ou alors tu t'installes un annuaire (directory script), ou tu ajoutes un plugin à un cms que tu as déjà quelque part : il y a des extensions d'annuaires pour tous les cms ou presque.
Le cahier des charges, c'était "pas web". Sinon je peux aussi bien prendre Saru qui m'a l'air sympa et je n'aurais pas eu besoin de faire ce post de forum.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je confirme.
À l'heure actuelle, on peut se dire que github ne peut pas mourir. Regardez comme c'est populaire! Ben revenez quelques années en arrière, et on aurait dit la même chose de Sourceforge. À une époque, c'était la référence évidente et être "pragmatique" signifiait d'y héberger son projet. Tout ça pour dire qu'en regardant un tel service en surface, on ne peut juste rien en dire. Donc être pragmatique, ce serait justement d'éviter au cas où ça se passe mal (changer d'hébergeur a un coût, pas forcément financier pour les projets communautaires, mais au moins en temps, en travail, en problèmes…). On a eu le même problème avec Google Code d'ailleurs. C'est Google et par conséquent, il y a quelques mois encore, quelqu'un aurait dit que ça allait fermer se serait fait rire au nez. Et pourtant…
De 2 choses l'une: soit la mode passe, un autre service "référence" arrive et prend la tête, et github disparaît (ou devient un fantôme à la Sourceforge) dans quelques années; soit effectivement il continue sur sa lancée et la boîte devient énorme et incontournable pendant des années et des années, à la Microsoft ou Google, collectant des masses considérables d'information, trouvant de nouveaux business modèles pour les rentabiliser et faire toujours plus d'argent, etc.
Dans un cas comme dans l'autre, ce n'est pas souhaitable.
Je pense que pour héberger des projets Libres, typiquement il faut des projets communautaires. Ils ne sont pas faits pour devenir n°1 et prendre la place d'autrui, certes. Donc on perd l'effet "monopole" qui apporte une puissance de réseau (qu'on qualifierait de "réseau social"). Par contre la pérennité est accrue. Alors je dis pas, une assoce/fondation peut aussi mal tourner, elle peut aussi fermer, etc. Mais les chances sont moindres car c'est normalement fait de telle sorte que les raisons que cela se produisent sont plus faibles. Justement parce que le but n'est pas de faire de l'argent ou de "passer n°1". Ce n'est pas grave si on a peu d'utilisateurs, et on a juste besoin de suffisamment d'argent pour payer les serveurs (pas de besoin de "rentabilité").
Ensuite devoir ouvrir des comptes partout. Oui, c'est un des problèmes du net d'aujourd'hui. On s'ouvre des comptes sur tous les services web ou autres. Des solutions standardisées ont été tentées, comme OpenId. Malheureusement les solutions qui se mettent à marcher sont tout sauf standard (Facebook et co.). Mais si cela doit devenir l'excuse pour ne se mettre qu'à utiliser les services que de quelques entreprises proprios, alors c'est triste. Si tout le reste, le côté communautaire, Libre et ouvert, devait s'effacer devant le confort d'une identification unique, ben… c'est vraiment pas le net que je veux voir venir.
Oui, j'aimerais bien qu'on trouve un système standard pour s'identifier une seule fois.
Non, je veux pas que cela se passe par un monopole qui crée un standard de fait, non standardisé, et qu'il est le seul à contrôler.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pour "Sans", il s'agit d'un alias qui était un alias par défaut de fontconfig. Cela permet de choisir la police Sans-serif par défaut de ton installation. Autrement on ne peut pas vraiment savoir quelles polices sont installées sur ton ordi, chaque OS/distribution ayant des différences (mais on sait que chaque OS aura au moins une Sans-serif par défaut et qu'il comprendra l'alias.
De nos jours ceci dit, c'est renommé "Sans-Serif" et "Sans" existe toujours mais est déprécié (j'ai regardé un peu le code de fontconfig et c'est ce que j'ai constaté). Je proposerai donc le changement chez nous aussi.
Juste pour info, on a fait le changement dans notre code master: https://bugzilla.gnome.org/show_bug.cgi?id=751836
Et en fait, je réfléchis même si on ne veut pas virer les Sans-serif/Serif/Monospace de la liste tout court car un designer ne veut pas un alias. Il choisit directement une fonte. Les alias, c'est plutôt pour les GUIs (où on ne sait pas qui a quelle fonte sur quel système). Ce serait bien tout de même que les alias marchent pour rechercher les fontes par défaut, mais ne soient pas visibles pour autant dans la liste. C'est pourquoi je ne vais pas proposer de suite de les retirer de la liste tant que je n'ai pas le code pour permettre la "redirection" d'alias automatique.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On était le stand juste à côté de linuxfr au village du Libre, et ça… c'est cool! :-)
Merci à Linuxfr pour cette photo (postée sur leur compte Twitter) car on n'est vraiment pas doué et on n'a quasiment pas fait de photo (ou alors de très mauvaise qualité sur vieux téléphone).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui bien sûr, je peux répondre. La prochaine sortie est à compter en [bzzz bzzz interférences bzzz bzzz]. ;-)
Plus sérieusement, je n'en ai aucune idée. On peut essayer de pousser mais au final le mainteneur choisit. Aussi GIMP 2.10 est dans une situation très particulière avec le passage à GEGL. Nous avons quelques fonctionnalités "cassées" par ce port, et s'il y a bien une chose que les utilisateurs ont du mal à encaisser, ce sont les régressions.
En tous cas, je suis moi-même complètement "pour" qu'on arrive à accélérer les sorties, comme je le dis dans l'interview. Et j'ai fait rajouter l'item "proposition de passer en mode sortie rapide" pour notre réunion à LGM 2014. Ce qui en est ressorti, c'est que les autres dévs ne sont pas contre, mais cela devra commencer à partir de GIMP 3.0, à cause du passage à GEGL, puis du passage à GTK 3.0. Après ces 2 ports, je pousserai vraiment pour passer à des sorties rapides, et qu'on adapte notre infrastructure de tests et de sortie s'il le faut.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Comme souvent, une question de choix de mots peut avoir des conséquences importantes.
Tu viens d'écrire sauver/exporter alors que je vois enregistrer/exporter dans les menus.
J'utilise la version anglaise, et j'ai juste fait une traduction perso (et mauvaise) de save/export. En VF, enregistrer/exporter ne me choque pas comme étant la bonne trad.
Ensuite de manière générale, ce que tu dis sur les mots est juste. Comme on le dit en général dans le développement d'application (à moitié blague, à moitié sérieux), le plus dur en informatique, c'est de nommer les choses (le code lui-même comme le texte visible d'ailleurs).
Par contre cela ne s'applique qu'à moitié au problème ici, puisqu'il n'est pas spécifique à la VF. Et je doute sincèrement que si on utilisait sauver/exporter, soudainement tous les francophones contre la fonctionnalité disent soudainement "ah ok je comprend mieux, c'est bon alors" (mais je veux bien me tromper). Par contre on aurait soudainement beaucoup de nouveaux en colère parce que "sauver" est un faux-ami et pas la bonne traduction pour "save". On sauve quelqu'un qui est en danger, on ne "sauve" pas du travail.
Tout ça pour dire que j'ai simplement fait une erreur de traduction dans mon commentaire, et je ne pense pas vraiment que rendre mon erreur de trad officielle soit la vraie solution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
À cheval dans la steppe on a la même sensation qu'à moto visiblement, le trot c'est essoufflant, le galop ça plane.
Bon ça c'est une spécificité générique de l'équitation, dans la steppe ou ailleurs, aucune différence. Le trot, c'est toujours inconfortable. Pour être confortable, il faut soit aller au pas, soit au galop (mais là aussi il y a une forme de frayeur). Par contre un cheval ne peut pas non plus galoper trop longtemps (c'est comme si on nous demandait de courir à fond tout le temps, j'imagine). C'est pourquoi en général, voyager à cheval, ça signifie surtout voyager au pas. C'est pas énormément plus rapide qu'à pied (mais moins fatigant).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je me doutais en regardant la photo que c'était la steppe de Mongolie. Ça a du influencer le projet marmotte non ? :).
Dans le sens où y a des Marmottes en Mongolie? Dans ce cas, non, car j'avais déjà ma Marmotte avec moi. Si tu regardes bien sur la photo, tu peux voir une petite peluche sur le guidon: mon copilote la Marmotte! Mais sinon oui, on voit régulièrement des marmottes dans ces coins de l'Asie centrale (pas les mêmes que les européennes).
Dans le sens où le film parle de vagabondage? Dans ce cas, oui forcément, c'est lié. J'aime me balader, donc j'en parle. J'aime les histoires d'aventure, donc c'est ce que j'écris.
n'ai pas encore eu l'occasion de goûter à la marmotte. Est-ce qu'elle est très salée comme le mouton ?
Franchement je ne pense pas avoir jamais mangé de la marmotte (enfin j'espère!). Ensuite j'ai mangé des trucs non identifiés en Mongolie, notamment un jour où j'ai été hébergé dans une yourte après avoir fait chuté la moto en traversant une rivière (donc le moteur était inondé, me forçant à des réparations de fortune).
De manière générale, il me semble que les gens mangent surtout ce qu'ils élèvent. Certaines familles ont des moutons, donc ils mangent surtout du mouton et boivent du lait de brebis. Ceux qui ont des chèvres, pareil. Et ceux qui ont un troupeau de yak pareil. Les chevaux, pareil. Etc.
En tous cas, c'est quasi essentiellement une nourriture à base de viande rouge (pas beaucoup de verdure; jamais non plus de poisson a priori, même s'ils ont des lacs et des rivières; et du lait en boisson, fermenté ou non, plutôt que de l'eau…).
les longs trajets dans la steppe toute plate et ne pas s'endormir au volant comme le chauffeur du film Urga :).
Alors j'ai pas vu ce film, mais en vrai c'est loin d'être de tout repos. Il n'y a pas de route, c'est que du sable à perte de vue. Et dans ce contexte, le sol est loin d'être "plat". Il en a l'air, et il l'est "globalement", mais dans le détail, c'est juste une succession de bosses et de trous, parfois très dangereux. Je devais m'arrêter environ toutes les heures et faire le tour de la moto avec un tournevis pour repérer et revisser les diverses vis qui se dévissait par les vibrations seulement. J'y allais avec toutes mes forces possibles, mais même là, ça se dévissait encore. Et j'en ai perdu quand même pas mal dans le process.
Pour la petite histoire, j'ai dû perdre une bonne vingtaine de vis sur la moto, et le garage où j'ai fait révisé/réparé la moto au Japon a trouvé même quelques vis internes tombées au fond du moteur (j'ai eu de la chance donc que ça me pête pas à la figure; et évidemment ces vis là, je pouvais pas les revisser moi-même).
Quand tu conduis en Mongolie, au Kazakhstan, ou même en Russie, tu as 2 choix: rouler très lentement (40/50 km/h), et dans ce cas, c'est extrêmement inconfortable (tout tremble constamment), mais c'est plus sûr; ou tu vas vite, et à ce moment, il y a un palier (vers les 90 km/h) où tu te mets à "voler" au dessus des trous. Il n'y a plus de tremblement, ni de vibration excessive (enfin si, mais bien plus confortable), tu n'as plus mal. Par contre c'est très effrayant et tu dois garder une concentration très appuyée pendant toute la conduite (tu te prends un trou un peu trop grand que tu n'as pas vu venir dans ces steppes, à l'allure lisse de loin sous le soleil, et c'est fini pour toi. Y aura probablement personne pour te venir en aide).
Très vite, on se met à prendre ce second choix, car conduire des jours en vibrant et en ayant mal partout, c'est peu tenable. Mais alors on fatigue aussi très vite (conduire bien, c'est à dire concentré et avec sérieux, c'est pas reposant!).
Enfin voilà, tout ça pour dire: non tu t'endors pas au volant. Et quand ça arrive, c'est qu'il est l'heure de s'arrêter, faire une pause, voire de sortir le sac de couchage si c'est le soir.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Il aurait être jsute fallu attendre d'avoir la nouvelle UI pour éviter les remarques négatives ;)
En même temps, l'UI est la partie visible de l'iceberg. Il reste que le format XCF suit parfaitement les fonctionnalités de GIMP et donc est le seul format de projet valable pour du travail en cours. La haute précision ou le non-destructif ne sont pas encore là, mais il y a déjà foultitude d'autres fonctionnalités qui nécessite XCF.
Par exemple quel format garde la sélection en cours? (permettant de commencer à travailler sur une sélection complète, la laisser en suspens, sauver le fichier, et y revenir plus tard là où on en était)
Quel format bitmap a aussi des notions (basiques certes, mais existantes) de vectoriel?
Quel format garde aussi des masques de calques?
Quel format garde des calques de texte?
Très peu de format ont même la notion de calque tout court.
Peu de format ont la prise en charge de la transparence (et quand ils l'ont, pas forcément avec la précision de GIMP).
Etc. etc. etc.
Je ne prétends pas connaître tous les formats et certains ont peut-être certaines de ces notions, mais aucun format n'a tout ce que fait GIMP (seul XCF puisqu'il est calqué sur les fonctionnalités).
En fait, je n'étais pas présent dans la période d'avant la séparation sauver/exporter, mais je sais qu'il y avait énormément de personnes qui venaient se plaindre car ils avaient perdus une partie de leur travail en "sauvant" dans un format d'image classique (que ce soit PNG ou jpg).
Par exemple, le classique, ils rajoutent du texte au dessus d'une image, exportent en PNG (car on leur dit "PNG est non destructif"), et — paf! — le texte devient une image non éditable! Après ils viennent se plaindre que le texte ne peut plus être corrigé, qu'ils doivent tout refaire de zéro et ont perdu des heures de travail.
Il faut donc bien comprendre: on sauve son travail en cours, et on exporte un "cliché" à un instant T. Comme on exporterait une vidéo en mpg/avi/whatever, ou encore on compilerait un binaire exécutable à partir d'une source texte. L'export c'est pour l'instantané prêt à la diffusion/utilisation. La sauvegarde, c'est le projet, le travail.
Le changement d'UI sera la cerise sur le gâteau, absolument pas le cœur de la fonctionnalité. Et il faut changer le cœur avant de rajouter la cerise (un peu comme GEGL, la prochaine version aura un nouveau cœur mais l'UI ne le réflètera pas encore, c'est à dire pas d'édition non destructrice visible. Ça arrive forcément après).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Merci à toi, j'espère pouvoir te rendre la pareille, un jour.
De rien. Si vraiment tu veux absolument m'aider et que tu as un peu de sous, contribuer au projet ZeMarmot est le moyen idéal de le faire! :-)
Non seulement il permettra de faire un film d'animation vraiment cool — et en plus Libre! — mais en plus ça me fera utiliser plus de temps pour améliorer GIMP. :-)
Enfin je dis ça… j'dis rien hein! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai partagé mon retour d'expérience dans une communauté sur ton provocateur car j'étais "énervé" (très déçu plus exactement) en lisant l'interview car des choses très évoluées sont intégrées à GIMP (ce qui est une bonne chose) mais qu'à côté des détails peuvent "ruiner" (c'est exagéré) l'expérience utilisateur.
Ok. Pas de problème. Je vais donc répondre ce que je voulais dire l'autre jour.
Pour "Sans", il s'agit d'un alias qui était un alias par défaut de fontconfig. Cela permet de choisir la police Sans-serif par défaut de ton installation. Autrement on ne peut pas vraiment savoir quelles polices sont installées sur ton ordi, chaque OS/distribution ayant des différences (mais on sait que chaque OS aura au moins une Sans-serif par défaut et qu'il comprendra l'alias.
De nos jours ceci dit, c'est renommé "Sans-Serif" et "Sans" existe toujours mais est déprécié (j'ai regardé un peu le code de fontconfig et c'est ce que j'ai constaté). Je proposerai donc le changement chez nous aussi.
Le second truc auquel je ne m'étais jamais vraiment penché jusque là, c'est effectivement que ce serait mieux si on pouvait agrandir la liste déroulante. Par contre je regarderai d'abord si c'est déjà faisable sous GTK+3, et si c'est le cas, c'est possible que nous ne passerons pas trop de temps dessus (car on sait que ça marchera pour GIMP 3, ce qui n'est pas pour tout de suite, malheureusement).
En tous cas, j'ai bien pris en compte les remarques. Ensuite c'est toujours mieux et constructif dans une relation aimable entre les êtres humains que nous sommes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Perso, la séparation me convient très bien, et si Gimp poursuit son évolution (images sans pertes, etc.), je comprendrai encore davantage la logique d'avoir deux options, l'une destinée à l'enregistrement et au travail, l'autre à l'utilisation finie d'une image.
Tout à fait!
C'est exactement cela. Les "images" GIMP (XCF) sont à considérer comme des projets en cours. Un format de travail. Ce n'est pas à considérer comme un standard (ce n'en est pas un), cela suit les évolutions logicielles de GIMP même, et ne peut être comparé à un format d'image (PNG, JPG, whatever…).
C'est comme Blender. Enregistrer, c'est du .blend (le format de travail qui suit les logiques logicielles de Blender). Ça n'empêche pas d'exporter en Collada (le standard pour la 3D) ou d'autres formats (souvent proprios).
En effet comme tu le notes, l'édition sans perte est une des énièmes très bonnes raisons: les formats d'image n'ont de concept de calque d'effet. Il faudra donc du XCF (enregistrer en PNG, jpg ou autre impliquera d'appliquer les effets et donc perdront de l'info). De même que la haute précision de couleur (PNG par exemple prend en charge jusqu'à 16 bits. GIMP ira bien plus haut).
Enfin il y a l'UI elle-même. À l'heure actuelle, on s'est contenté d'utiliser la même UI (puisque historiquement c'était la même chose), et donc ça perturbe les utilisateurs qui se disent "ben c'est la même chose". C'est compréhensible. Mais l'idée c'est qu'à l'avenir on aura 2 UIs différentes et adaptées. En fait j'ai même déjà du code stash-é qui commence le travail, mais faut que je trouve le temps de finir.
Par exemple beaucoup de gens demandent une gestion de "l'export pour le web", c'est à dire notamment changer la résolution d'une image très haute rés, appliquer éventuellement quelques filtres, etc. À l'heure actuelle, on doit faire ce genre de choses dans l'image même, puis surtout ne pas oublier de les annuler après export de l'image (pour ne pas engendrer de perte de qualité, surtout quand l'image est aussi destinée pour de la haute résolution). Ben je pense que ce genre de choses devraient être faisable aisément dans une UI séparée qui gère ce genre de choses (comme un graphe d'effet à appliquer seulement dans un mode d'export particulier qu'on peut sauver).
Ce sont des exemples mais on peut en trouver beaucoup d'autres. Sauver et exporter sont vraiment des processus très différents. Simplement nous n'avons pas encore l'UI. C'est la base de cette évolution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Petite question à ce sujet… L'édition non destructrice est intéressante, mais il me semble qu'elle se limite quand même à des filtres de traitement d'images "basiques", rapides à calculer. De même pour la fonctionnalité "preview on canvas" qui est poussée en avant pour les prochaines releases avec GEGL.
On imagine mal en effet devoir attendre 15 minutes (au hasard) le recalcul d'un rendu après avoir changé un paramètre d'un des filtres (parce que le graphe comprend un filtre très long à calculer, qui a été appliqué à la fin).
Oui et non. Oui, ça limite l'intérêt, et notamment clairement la prévisualisation en directe pourrait devenir une véritable plaie (bloquant l'UI et empêchant de configurer correctement son filtre si à chaque fois qu'on affleure même un slider, on doit se taper une prévis).
Ensuite non, la non-destructivité est quand même utile (selon moi) pour les filtres longs. Du moment qu'on gère bien toute la partie ennuyante (comme la prévisualisation, en ne l'autorisant pas sur certains filtres), il reste tout de même d'autres avantages bien réels. Par exemple, tu parles de changer le paramètre d'un filtre. Ben dans ce cas là, même avec la méthode destructive (annuler, refaire le filtre), on doit se retaper les 15 minutes de traitement du filtre. Ben au moins avec la méthode non-destructive, on peut le faire n'importe quand, même après plusieurs heures de travail et des centaines d'autres actions faites entretemps; donc revenir sur l'historique — si possible, des fois ça ne l'est même pas — en revient à perdre des heures de travail.
Avez vous prévu quelque chose de spécial dans ce cas ?
Je ne suis pas certain, mais il est clair que nous ne laisserons pas ce genre de problèmes arriver (ou par erreur, et dans ce cas là, ce sera à considérer un bug à corriger). Il faudra les traiter. Je peux imaginer plusieurs choses.
Déjà la détection: on peut ajouter une notion de coût (théorique, comme un paramètre disponible en introspection) à une opération (il me semble me rappeler que cela a d'ailleurs déjà été discuté sur IRC). Ainsi avant même de commencer une opération, on peut avertir l'utilisateur que la prévisualisation risque d'être longue pour certaines opérations (voire même l'interdire pour des opérations qu'on sait vraiment vraiment trop longue), ou bien même pour toute opération si on l'exécute sur une image de vraiment trop grande taille. Ensuite on peut aussi avoir, en plus, un timer qui prend la main quand une prév dure trop longtemps, et donne la possibilité à l'utilisateur de l'interrompre.
Ensuite comment gérer ces ops trop longues?
1/ On peut donc simplement interdire la prév automatique comme je disais.
2/ Mais on peut aussi permettre une prév explicite avec un bouton dans ce cas. C'est à dire que ça ne va pas re-rendre le résultat juste en bougeant un slider d'un micromètre (bon moyen de rendre une UI inutilisable). Par contre, l'utilisateur peut bouger ses boutons et sliders tranquillement, puis cliquer sur un bouton, aller prendre un café et revenir voir le résultat après 15 minutes. Éventuellement refaire des changements, etc. Ou sinon appliquer (ce qui sera instantané puisque tout est déjà calculé).
Cela reste toujours légèrement plus pratique et rapide que d'appliquer, annuler, rouvrir l'UI de plugin, réappliquer, réannuler… Pas énormément différent, hein. Mais un peu, selon moi.
3/ L'utilisateur peut supprimer la visualisation d'un filtre (avec l'icône "œil"). Ça permet de l'appliquer au début, mais ensuite de l'empêcher d'actualiser sans cesse la vue (surtout si on prévoit de peindre sur le calque de base, etc.).
4/ On peut aussi permettre d'appliquer un filtre (ou une liste de filtres) directement sur l'image (c'est à dire en destructif comme maintenant). En fait j'en ai jamais discuté avec les autres, mais personnellement cela me paraît une fonctionnalité évidente.
Il y a toujours des cas où appliquer un filtre est mieux, voire nécessaire. Par exemple si on souhaite peindre directement sur le rendu (et non sur le calque de base, ni sur un autre calque au dessus), il n'y a pas d'autres choix que d'appliquer le filtre pour qu'il ne fasse qu'un avec son calque. Blender par exemple permet de faire cela (on peut mettre des filtres genre miroir sur des objets 3D. Puis ensuite on l'applique, ce qui permet de travailler sur un côté de l'image différemment par exemple).
En tous cas, cela signifie qu'une architecture non-destructive n'oblige absolument pas à travailler non-destructif tout du long. L'utilisateur peut toujours revenir à une méthode de travail destructive.
5/ Enfin, en revenant sur la problématique des prévisualisations, il y a des moyens de les accélérer (en dehors de la solution d'optimiser les opérations elle-même bien sûr), notamment lorsque le viewport ne montre qu'une partie de l'image. Ou à l'inverse quand la vue de l'image est plus petite que la taille réelle du fichier à cause d'un zoom-out. Bon c'est pas moi l'expert, mais voici un email du mainteneur GEGL sur le sujet de l'accélération de la prévisualisation.
Ce sont des choses auxquels les divers développeurs réfléchissent beaucoup.
Si non, cela veut-il dire que les opérateurs GEGL seront de toute façon limités à des traitements basiques, si on veut les rendre utilisables en pratique ?
Non puisque comme je disais, on devrait toujours pouvoir les utiliser en destructifs à l'ancienne. C'est juste une question d'UI.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Rapidement, tu peux expliquer tes aventures de vagabondage ? (j'ai vagabondé un peu aussi il y a pas si longtemps que ça, et la photo rappelle des souvenirs… :)
Cette photo, c'était en Mongolie. J'ai vagabondé entre la France et le Japon pendant 6 mois, puis j'ai vécu au Japon, en Corée, en Nouvelle Zélande, où j'ai aussi pas mal bougé.
Et j'imagine que coder ou quoi avec ce que tu as l'air d'avoir sur cette première photo, c'est difficile, voir pas vraiment d'actualité pendant ce genre de voyage/vagabondage.
En effet je code pas, ou presque, quand je suis sur la route.
Comment ça se passe/s'est passé avec tes différents projets/contributions ?
Ben tu mets en pause quand tu sais que de toutes façons, tu n'auras pas vraiment l'opportunité de contribuer. Par exemple à l'époque je contribuais beaucoup dans le monde XMPP. Ben avant de partir, j'ai quitté la XSF (ils ont assez de membres fantômes, pas la peine d'en rajouter un), de la même façon que j'ai démissionné de mon job ou que j'ai donné un préavis pour l'appart que je louais à l'époque. Y a pas vraiment de différence. :-)
Par contre une fois un peu plus posé, même si tu peux rester mobile et déménager tous les mois, rien n'empêche de contribuer avec même un petit portable léger et peu puissant. J'ai codé pendant plusieurs années sur un petit eeepc acheté au Japon. J'ai même codé dans une startup au Japon avec cet eeepc pendant plus d'1 an (avant qu'ils m'achètent un ordi puissant) où j'étais senior developer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Bon j'ai dit que je répondrai pas, mais je marche dedans! J'arrive pas à retenir mes doigts.
sur ce qui ne marche manifestement pas.
Qu'est-ce qui ne marche pas? Qu'un outil n'est pas parfait n'est pas la même chose qu'un outil cassé. L'outil de texte marche très bien. Quand on trouve un bug, je peux t'assurer qu'on n'attend pas longtemps avant de le corriger.
En outre, c'est justement ce petit plus de l'UI parfaite qui prend du temps. Parler c'est beau, mais si tu as la science de l'UI idéale infuse, on les veut bien tes dessins et tes spécs détaillés (c'est à dire qui prend en compte tous les cas, pas juste un yakafokon en 1 ligne) pour rendre l'outil de texte bien meilleur.
Il faut aussi savoir gerer son temps.
Merci de venir nous donner des leçons de vie. Heureusement que les trolls sont là pour nous apprendre comment gérer notre temps (avec ce magnifique exemple justement pour nous le faire perdre! En fait c'est peut-être cela la "gestion" du temps que tu veux nous enseigner?); sans eux, que ferait-on?
Je concluerai par un lien vers notre bugtracker, de la liste des rapports qui sont passés en statut "FIXED" (= corrigé) depuis janvier 2015: 75 bugs à ce jour
Et encore, c'est sans compter les bugs découverts en interne et corrigés sans qu'il y ait eu un rapport de bug. Je compte donc, dans la seule année 2015, 459 commits dans GIMP master, 26 dans babl master, et 218 dans GEGL master. C'est sûr, les développeurs de GIMP n'en font vraiment pas une et "se fout[tent] de l'utilisateur".
D'ailleurs saviez-vous que lorsqu'un utilisateur rapporte un bug, en fait on va se moquer de lui derrière son dos et on rigole bien car on fait exprès de ne jamais corriger les bugs.
Non mais qu'est-ce qu'il faut pas lire!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est pas faux. La gestion du texte est clairement compliquée sous GIMP.
Tout à fait. La gestion du texte est un très gros chantier sur lequel on aimerait tous venir un jour. C'est clairement un outil assez frustrant à de nombreux égards. Je suis le premier à être d'accord, et Aryeom ne dira pas le contraire non plus! Tous les autres dévs en sont conscients aussi car on en parle régulièrement (on en a encore parlé avec le mainteneur y a 2 mois lors de LGM 2015).
De manière général, le commentaire initial du fil liste plusieurs problèmes réels, connus et qu'on veut améliorer.
Par contre j'ai voulu répondre, mais j'ai abandonné. Le commentaire n'a clairement pas été fait pour initier un échange constructif, et je sens que toute réponse (celle-ci comprise probablement) ne m'apportera que des attaques ad-hominem. C'est donc mon premier et dernier message sur ce fil de discussion.
Par contre si y a d'autres questions ou commentaires intéressants, et même des critiques constructives, n'hésitez pas à créer un autre fil.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Très bonne nouvelle.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Accessibilité: ACAT, Intel libère le logiciel d'assistance du professeur Hawking. Évalué à 2.
C'est possible, je ne saurais dire.
J'imagine que je le recroiserai sûrement un jour. Il me semble l'avoir aperçu aussi aux RMLLs. J'imagine donc qu'il fait divers évènements et que je le reverrai un jour.
Pour tout dire, j'avais pris des infos sur lui et sur son activité pour voir ce qu'il faisait un peu plus en détail (par intérêt de manière général sur ce qui se fait en Libre sur le sujet), mais je n'ai pas pris la peine de vérifier immédiatement après et ne sais plus où j'ai bien pu noter cela. :-/
Enfin bon, si je le recroise, j'essaierai de retrouver cette news et mettrai une réponse. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Très bonne nouvelle.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Accessibilité: ACAT, Intel libère le logiciel d'assistance du professeur Hawking. Évalué à 5.
À un apéro Parinux, j'ai croisé un aveugle qui avait monté une boîte pour répandre et développer les solutions pour aveugles sous Linux. Je ne sais plus son nom ni celui de sa boîte. Mais en tous cas, cela existe et semble suffisamment fonctionnel pour en faire un business sans passer par les logiciels Microsoft.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: ColorHug
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Quelqu'un sur Paris ou région parisienne pour me prêter une sonde colorimétrique?. Évalué à 3.
Il est en train de faire un batch en ce moment (il attend le retour d'usine). Je vais probablement en acheter un à ce moment là. Il me dit qu'il utilise le ColorHug 2 pour calibrer son écran Dreamcolor et qu'il a de très bons résultats avec.
Pour être tout à fait réaliste, aller loin au dessus de AdobeRGB, il y a aussi beaucoup de masturbation intellectuelle ou de "victime de la mode" (d'ailleurs on y a succombé aussi, mais je me suis posé longtemps la question et je me la pose encore).
Je ne dis pas que dans certains cas, c'est pas utile. Typiquement un photographe qui va travailler avec des couleurs très saturées, très souvent, oui. Mais même en étant dans le métier de l'impression (photographe, designer, etc.), pour beaucoup de pros, c'est inutile. En effet, pas tout le monde n'aime les couleurs pêtantes, et beaucoup de pros de l'image vont même plutôt se faire une spécialité de travailler dans des couleurs plus subtiles, pastelles même, etc. Et dans ce cas là, que ton écran soit sRGB ou Adobe RGB ne changera rien (car tes couleurs ne sortiront jamais du gamut sRGB de toutes façons). Dans un tel cas, il vaut probablement même mieux un écran sRGB très précis qu'un Adobe RGB moins précis, par exemple.
En plus travailler en Adobe RGB ajoute tout de suite un peu plus de stress dans son workflow de peur de faire des erreurs, et il faut toujours tout re-vérifier. En sRGB, au moins, y a pas trop à se poser de questions car c'est du défaut partout.
Mais oui, c'est sûr que c'est mieux si le colorimètre est capable de tout bien calibrer. :-)
En fait, Richard travaille même sur un spectromètre OpenHardware (le ColorHug+) qui sera dans les 400 EUR probablement (en retard sur le planning, il a qu'un prototype et en a vendu aucun à ce jour). Cela permettra d'avoir des calibrations encore plus précises, et même de calibrer une imprimante.
Je trouve perso son activité vraiment intéressante! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: stage
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Quelqu'un sur Paris ou région parisienne pour me prêter une sonde colorimétrique?. Évalué à 2.
Dommage. Ça veut dire qu'il avait accès à des colorimètres/spectromètres, mais plus maintenant?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: ColorHug
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Quelqu'un sur Paris ou région parisienne pour me prêter une sonde colorimétrique?. Évalué à 4.
Je trouve cela super que ça existe, mais j'ai une expérience perso mitigée. J'ai souvent eu des résultats un peu trop vers le rouge.
Déjà dans l'idéal, il faut avoir une matrice de correction spécifique pour ton écran (ce qui est créé avec un spectromètre). Or le colorhug en a une liste (que tu peux voir là) générée par la communauté, mais elle est petite, car la communauté est elle-même encore petite, et surtout peu ont un spectromètre, ce qui est du matos cher. Il n'y a pas de CCMX pour mon écran malheureusement. Je dois toujours approximer avec un autre CCMX. :-/ D'ailleurs c'est aussi pour cela que je demande si quelqu'un a un spectromètre. Si je pouvais générer moi-même le fichier CCMX pour notre Dell U2413, je serai heureux de le fournir upstream pour la liste communautaire.
En outre, le colorhug marche mieux pour les écrans sRGB et a du mal avec le wide gamut (Adobe RGB…), ce qui est le cas de notre écran. Richard Hughes est en train de créer le colorhug2 qui marchera bien mieux avec les écrans Wide Gamut, mais bon… je l'ai pas.
Au final, j'ai envie de supporter le projet, et je ne regrette pas d'avoir donné des sous si ceux-ci permettent de faire avancer la colorimétrie OpenHardware. Par contre je dois bien avouer que mon expérience reste un peu faible.
En fait on peut se poser la question si ça a vraiment le moindre intérêt pour un portable. Déjà parce que les écrans de portables sont en général pourris (un point très important par exemple est de voir les mêmes couleurs sous tous les angles, sinon ça n'a aucun sens de calibrer les couleurs: à peine tu tournes la tête de quelques cms et tu vois déjà d'autres couleurs! C'est pourquoi on va en général privilégier les écrans IPS ou PVA. Peu de portable ont ces dalles). Ensuite parce que c'est dur de changer la luminosité sur un écran de portable en hardware. Enfin parce que par définition, tu changes l'angle et la position de ton écran sans arrêt. On va plutôt calibrer de bons écrans, qui ont un angle de vision large et qui restent toujours au même endroit.
Comme beaucoup de matos proprios, il y a des drivers Linux. En tous cas, dispcalgui affirme le prendre en charge, donc je suppose que c'est utilisable sous Linux.
En outre l'écran que je souhaite calibrer a des fonctionnalités de calibrage matériel, mais qui ne marche qu'avec un logiciel sous Windows. J'ai un Windows en VM que je souhaite donc utiliser pour le calibrage matériel (en espérant que c'est possible à travers une VM) pour pouvoir ensuite en profiter dans mon usage quotidien sous Linux.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: lire la doc
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Firefox/Iceweasel se connecte silencieusement lors du survol d'un lien. Évalué à 6.
Ah c'est quand même beaucoup mieux. L'URL en particulier est la partie dangereuse car elle peut donner des informations. Typiquement le premier exemple qui me vient à l'esprit sont les adresses dans les spams (en considérant que beaucoup de gens regardent leurs emails par webmail donc dans le navigateur) qui contiennent souvent un identifiant quelconque (soit votre adresse email en clair, soit un hash abscons qui vous identifie dans la base du spammeur et leur permet de savoir qui a encore une adresse active par exemple, et sûrement bien plus!). Si le simple fait de survoler un lien (quelque chose que je fais typiquement régulièrement, justement pour voir où ça mènera et si ça a l'air d'un lien clairement frauduleux ou relativement sûr…) envoyait des données (HEADER, URLs…), alors ce serait une terrible faille de sécurité.
Il faut donc espérer que cette partie reste toujours ainsi.
La première partie (limiter l'ouverture spéculative à certaines ressources) est bien aussi, ceci dit. Même seulement une connexion TCP sur n'importe quel serveur, on sait jamais. Autant que le navigateur ne s'amuse pas à ouvrir des connexions avec n'importe quel lien qui traîne…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Un répertoire, quoi.
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Logiciel desktop de suivi des contacts?. Évalué à 2.
Oui. Sauf que je ne trouve pas de "répertoire" qui soit vraiment au dessus de la moyenne. Cette appli web fait plus que juste garder des infos sur tes contacts. Il gère les rencontres avec les dits-contacts, ajoute une sorte de suivi pour avoir des "évènements". Bien sûr, tu peux reproduire plus ou moins les infos avancées et les rencontres avec un champs "Notes", mais c'est quand même bien moins parlant.
Tu peux aussi coupler avec ton calendrier pour créer des évènements, mais franchement j'ai pas envie d'encombrer mon calendrier de ce type d'items. C'est quand même pas la même catégorie d'évènements que noter un RDV avec qqun, etc.
Le cahier des charges, c'était "pas web". Sinon je peux aussi bien prendre Saru qui m'a l'air sympa et je n'aurais pas eu besoin de faire ce post de forum.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: forges
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal SourceForge dans les choux. Évalué à 10.
Je confirme.
À l'heure actuelle, on peut se dire que github ne peut pas mourir. Regardez comme c'est populaire! Ben revenez quelques années en arrière, et on aurait dit la même chose de Sourceforge. À une époque, c'était la référence évidente et être "pragmatique" signifiait d'y héberger son projet. Tout ça pour dire qu'en regardant un tel service en surface, on ne peut juste rien en dire. Donc être pragmatique, ce serait justement d'éviter au cas où ça se passe mal (changer d'hébergeur a un coût, pas forcément financier pour les projets communautaires, mais au moins en temps, en travail, en problèmes…). On a eu le même problème avec Google Code d'ailleurs. C'est Google et par conséquent, il y a quelques mois encore, quelqu'un aurait dit que ça allait fermer se serait fait rire au nez. Et pourtant…
De 2 choses l'une: soit la mode passe, un autre service "référence" arrive et prend la tête, et github disparaît (ou devient un fantôme à la Sourceforge) dans quelques années; soit effectivement il continue sur sa lancée et la boîte devient énorme et incontournable pendant des années et des années, à la Microsoft ou Google, collectant des masses considérables d'information, trouvant de nouveaux business modèles pour les rentabiliser et faire toujours plus d'argent, etc.
Dans un cas comme dans l'autre, ce n'est pas souhaitable.
Je pense que pour héberger des projets Libres, typiquement il faut des projets communautaires. Ils ne sont pas faits pour devenir n°1 et prendre la place d'autrui, certes. Donc on perd l'effet "monopole" qui apporte une puissance de réseau (qu'on qualifierait de "réseau social"). Par contre la pérennité est accrue. Alors je dis pas, une assoce/fondation peut aussi mal tourner, elle peut aussi fermer, etc. Mais les chances sont moindres car c'est normalement fait de telle sorte que les raisons que cela se produisent sont plus faibles. Justement parce que le but n'est pas de faire de l'argent ou de "passer n°1". Ce n'est pas grave si on a peu d'utilisateurs, et on a juste besoin de suffisamment d'argent pour payer les serveurs (pas de besoin de "rentabilité").
Ensuite devoir ouvrir des comptes partout. Oui, c'est un des problèmes du net d'aujourd'hui. On s'ouvre des comptes sur tous les services web ou autres. Des solutions standardisées ont été tentées, comme OpenId. Malheureusement les solutions qui se mettent à marcher sont tout sauf standard (Facebook et co.). Mais si cela doit devenir l'excuse pour ne se mettre qu'à utiliser les services que de quelques entreprises proprios, alors c'est triste. Si tout le reste, le côté communautaire, Libre et ouvert, devait s'effacer devant le confort d'une identification unique, ben… c'est vraiment pas le net que je veux voir venir.
Oui, j'aimerais bien qu'on trouve un système standard pour s'identifier une seule fois.
Non, je veux pas que cela se passe par un monopole qui crée un standard de fait, non standardisé, et qu'il est le seul à contrôler.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 7.
Juste pour info, on a fait le changement dans notre code master: https://bugzilla.gnome.org/show_bug.cgi?id=751836
Et en fait, je réfléchis même si on ne veut pas virer les Sans-serif/Serif/Monospace de la liste tout court car un designer ne veut pas un alias. Il choisit directement une fonte. Les alias, c'est plutôt pour les GUIs (où on ne sait pas qui a quelle fonte sur quel système). Ce serait bien tout de même que les alias marchent pour rechercher les fontes par défaut, mais ne soient pas visibles pour autant dans la liste. C'est pourquoi je ne vais pas proposer de suite de les retirer de la liste tant que je n'ai pas le code pour permettre la "redirection" d'alias automatique.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: baladodiffusion
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Émissions "Symbiose" de l'APRIL sur "Ici et Maintenant". Évalué à 2.
Un podcast est maintenant en ligne: http://iluk.fr/150627-Gimp-Marmot.ogg
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: plop du jour
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Rencontres Mondiales du Logiciel Libre, du 04 au 10 juillet 2015, à Beauvais. Évalué à 4.
On était le stand juste à côté de linuxfr au village du Libre, et ça… c'est cool! :-)
Merci à Linuxfr pour cette photo (postée sur leur compte Twitter) car on n'est vraiment pas doué et on n'a quasiment pas fait de photo (ou alors de très mauvaise qualité sur vieux téléphone).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP 2.10
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 8.
Oui bien sûr, je peux répondre. La prochaine sortie est à compter en [bzzz bzzz interférences bzzz bzzz]. ;-)
Plus sérieusement, je n'en ai aucune idée. On peut essayer de pousser mais au final le mainteneur choisit. Aussi GIMP 2.10 est dans une situation très particulière avec le passage à GEGL. Nous avons quelques fonctionnalités "cassées" par ce port, et s'il y a bien une chose que les utilisateurs ont du mal à encaisser, ce sont les régressions.
En tous cas, je suis moi-même complètement "pour" qu'on arrive à accélérer les sorties, comme je le dis dans l'interview. Et j'ai fait rajouter l'item "proposition de passer en mode sortie rapide" pour notre réunion à LGM 2014. Ce qui en est ressorti, c'est que les autres dévs ne sont pas contre, mais cela devra commencer à partir de GIMP 3.0, à cause du passage à GEGL, puis du passage à GTK 3.0. Après ces 2 ports, je pousserai vraiment pour passer à des sorties rapides, et qu'on adapte notre infrastructure de tests et de sortie s'il le faut.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: contenu inutile.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 4.
J'utilise la version anglaise, et j'ai juste fait une traduction perso (et mauvaise) de save/export. En VF, enregistrer/exporter ne me choque pas comme étant la bonne trad.
Ensuite de manière générale, ce que tu dis sur les mots est juste. Comme on le dit en général dans le développement d'application (à moitié blague, à moitié sérieux), le plus dur en informatique, c'est de nommer les choses (le code lui-même comme le texte visible d'ailleurs).
Par contre cela ne s'applique qu'à moitié au problème ici, puisqu'il n'est pas spécifique à la VF. Et je doute sincèrement que si on utilisait sauver/exporter, soudainement tous les francophones contre la fonctionnalité disent soudainement "ah ok je comprend mieux, c'est bon alors" (mais je veux bien me tromper). Par contre on aurait soudainement beaucoup de nouveaux en colère parce que "sauver" est un faux-ami et pas la bonne traduction pour "save". On sauve quelqu'un qui est en danger, on ne "sauve" pas du travail.
Tout ça pour dire que j'ai simplement fait une erreur de traduction dans mon commentaire, et je ne pense pas vraiment que rendre mon erreur de trad officielle soit la vraie solution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vagabondage
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 2.
Bon ça c'est une spécificité générique de l'équitation, dans la steppe ou ailleurs, aucune différence. Le trot, c'est toujours inconfortable. Pour être confortable, il faut soit aller au pas, soit au galop (mais là aussi il y a une forme de frayeur). Par contre un cheval ne peut pas non plus galoper trop longtemps (c'est comme si on nous demandait de courir à fond tout le temps, j'imagine). C'est pourquoi en général, voyager à cheval, ça signifie surtout voyager au pas. C'est pas énormément plus rapide qu'à pied (mais moins fatigant).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vagabondage
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 7.
Dans le sens où y a des Marmottes en Mongolie? Dans ce cas, non, car j'avais déjà ma Marmotte avec moi. Si tu regardes bien sur la photo, tu peux voir une petite peluche sur le guidon: mon copilote la Marmotte! Mais sinon oui, on voit régulièrement des marmottes dans ces coins de l'Asie centrale (pas les mêmes que les européennes).
Dans le sens où le film parle de vagabondage? Dans ce cas, oui forcément, c'est lié. J'aime me balader, donc j'en parle. J'aime les histoires d'aventure, donc c'est ce que j'écris.
Franchement je ne pense pas avoir jamais mangé de la marmotte (enfin j'espère!). Ensuite j'ai mangé des trucs non identifiés en Mongolie, notamment un jour où j'ai été hébergé dans une yourte après avoir fait chuté la moto en traversant une rivière (donc le moteur était inondé, me forçant à des réparations de fortune).
De manière générale, il me semble que les gens mangent surtout ce qu'ils élèvent. Certaines familles ont des moutons, donc ils mangent surtout du mouton et boivent du lait de brebis. Ceux qui ont des chèvres, pareil. Et ceux qui ont un troupeau de yak pareil. Les chevaux, pareil. Etc.
En tous cas, c'est quasi essentiellement une nourriture à base de viande rouge (pas beaucoup de verdure; jamais non plus de poisson a priori, même s'ils ont des lacs et des rivières; et du lait en boisson, fermenté ou non, plutôt que de l'eau…).
Alors j'ai pas vu ce film, mais en vrai c'est loin d'être de tout repos. Il n'y a pas de route, c'est que du sable à perte de vue. Et dans ce contexte, le sol est loin d'être "plat". Il en a l'air, et il l'est "globalement", mais dans le détail, c'est juste une succession de bosses et de trous, parfois très dangereux. Je devais m'arrêter environ toutes les heures et faire le tour de la moto avec un tournevis pour repérer et revisser les diverses vis qui se dévissait par les vibrations seulement. J'y allais avec toutes mes forces possibles, mais même là, ça se dévissait encore. Et j'en ai perdu quand même pas mal dans le process.
Pour la petite histoire, j'ai dû perdre une bonne vingtaine de vis sur la moto, et le garage où j'ai fait révisé/réparé la moto au Japon a trouvé même quelques vis internes tombées au fond du moteur (j'ai eu de la chance donc que ça me pête pas à la figure; et évidemment ces vis là, je pouvais pas les revisser moi-même).
Quand tu conduis en Mongolie, au Kazakhstan, ou même en Russie, tu as 2 choix: rouler très lentement (40/50 km/h), et dans ce cas, c'est extrêmement inconfortable (tout tremble constamment), mais c'est plus sûr; ou tu vas vite, et à ce moment, il y a un palier (vers les 90 km/h) où tu te mets à "voler" au dessus des trous. Il n'y a plus de tremblement, ni de vibration excessive (enfin si, mais bien plus confortable), tu n'as plus mal. Par contre c'est très effrayant et tu dois garder une concentration très appuyée pendant toute la conduite (tu te prends un trou un peu trop grand que tu n'as pas vu venir dans ces steppes, à l'allure lisse de loin sous le soleil, et c'est fini pour toi. Y aura probablement personne pour te venir en aide).
Très vite, on se met à prendre ce second choix, car conduire des jours en vibrant et en ayant mal partout, c'est peu tenable. Mais alors on fatigue aussi très vite (conduire bien, c'est à dire concentré et avec sérieux, c'est pas reposant!).
Enfin voilà, tout ça pour dire: non tu t'endors pas au volant. Et quand ça arrive, c'est qu'il est l'heure de s'arrêter, faire une pause, voire de sortir le sac de couchage si c'est le soir.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: contenu inutile.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 7.
En même temps, l'UI est la partie visible de l'iceberg. Il reste que le format XCF suit parfaitement les fonctionnalités de GIMP et donc est le seul format de projet valable pour du travail en cours. La haute précision ou le non-destructif ne sont pas encore là, mais il y a déjà foultitude d'autres fonctionnalités qui nécessite XCF.
Par exemple quel format garde la sélection en cours? (permettant de commencer à travailler sur une sélection complète, la laisser en suspens, sauver le fichier, et y revenir plus tard là où on en était)
Quel format bitmap a aussi des notions (basiques certes, mais existantes) de vectoriel?
Quel format garde aussi des masques de calques?
Quel format garde des calques de texte?
Très peu de format ont même la notion de calque tout court.
Peu de format ont la prise en charge de la transparence (et quand ils l'ont, pas forcément avec la précision de GIMP).
Etc. etc. etc.
Je ne prétends pas connaître tous les formats et certains ont peut-être certaines de ces notions, mais aucun format n'a tout ce que fait GIMP (seul XCF puisqu'il est calqué sur les fonctionnalités).
En fait, je n'étais pas présent dans la période d'avant la séparation sauver/exporter, mais je sais qu'il y avait énormément de personnes qui venaient se plaindre car ils avaient perdus une partie de leur travail en "sauvant" dans un format d'image classique (que ce soit PNG ou jpg).
Par exemple, le classique, ils rajoutent du texte au dessus d'une image, exportent en PNG (car on leur dit "PNG est non destructif"), et — paf! — le texte devient une image non éditable! Après ils viennent se plaindre que le texte ne peut plus être corrigé, qu'ils doivent tout refaire de zéro et ont perdu des heures de travail.
Il faut donc bien comprendre: on sauve son travail en cours, et on exporte un "cliché" à un instant T. Comme on exporterait une vidéo en mpg/avi/whatever, ou encore on compilerait un binaire exécutable à partir d'une source texte. L'export c'est pour l'instantané prêt à la diffusion/utilisation. La sauvegarde, c'est le projet, le travail.
Le changement d'UI sera la cerise sur le gâteau, absolument pas le cœur de la fonctionnalité. Et il faut changer le cœur avant de rajouter la cerise (un peu comme GEGL, la prochaine version aura un nouveau cœur mais l'UI ne le réflètera pas encore, c'est à dire pas d'édition non destructrice visible. Ça arrive forcément après).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 7.
Et on remarque que 13875 / 330 ~= 42 € par personne!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 6.
De rien. Si vraiment tu veux absolument m'aider et que tu as un peu de sous, contribuer au projet ZeMarmot est le moyen idéal de le faire! :-)
Non seulement il permettra de faire un film d'animation vraiment cool — et en plus Libre! — mais en plus ça me fera utiliser plus de temps pour améliorer GIMP. :-)
Enfin je dis ça… j'dis rien hein! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 10.
Ok. Pas de problème. Je vais donc répondre ce que je voulais dire l'autre jour.
Pour "Sans", il s'agit d'un alias qui était un alias par défaut de fontconfig. Cela permet de choisir la police Sans-serif par défaut de ton installation. Autrement on ne peut pas vraiment savoir quelles polices sont installées sur ton ordi, chaque OS/distribution ayant des différences (mais on sait que chaque OS aura au moins une Sans-serif par défaut et qu'il comprendra l'alias.
De nos jours ceci dit, c'est renommé "Sans-Serif" et "Sans" existe toujours mais est déprécié (j'ai regardé un peu le code de fontconfig et c'est ce que j'ai constaté). Je proposerai donc le changement chez nous aussi.
Le second truc auquel je ne m'étais jamais vraiment penché jusque là, c'est effectivement que ce serait mieux si on pouvait agrandir la liste déroulante. Par contre je regarderai d'abord si c'est déjà faisable sous GTK+3, et si c'est le cas, c'est possible que nous ne passerons pas trop de temps dessus (car on sait que ça marchera pour GIMP 3, ce qui n'est pas pour tout de suite, malheureusement).
En tous cas, j'ai bien pris en compte les remarques. Ensuite c'est toujours mieux et constructif dans une relation aimable entre les êtres humains que nous sommes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 2. Dernière modification le 30 juin 2015 à 19:37.
De rien! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: contenu inutile.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 9.
Tout à fait!
C'est exactement cela. Les "images" GIMP (XCF) sont à considérer comme des projets en cours. Un format de travail. Ce n'est pas à considérer comme un standard (ce n'en est pas un), cela suit les évolutions logicielles de GIMP même, et ne peut être comparé à un format d'image (PNG, JPG, whatever…).
C'est comme Blender. Enregistrer, c'est du .blend (le format de travail qui suit les logiques logicielles de Blender). Ça n'empêche pas d'exporter en Collada (le standard pour la 3D) ou d'autres formats (souvent proprios).
En effet comme tu le notes, l'édition sans perte est une des énièmes très bonnes raisons: les formats d'image n'ont de concept de calque d'effet. Il faudra donc du XCF (enregistrer en PNG, jpg ou autre impliquera d'appliquer les effets et donc perdront de l'info). De même que la haute précision de couleur (PNG par exemple prend en charge jusqu'à 16 bits. GIMP ira bien plus haut).
Enfin il y a l'UI elle-même. À l'heure actuelle, on s'est contenté d'utiliser la même UI (puisque historiquement c'était la même chose), et donc ça perturbe les utilisateurs qui se disent "ben c'est la même chose". C'est compréhensible. Mais l'idée c'est qu'à l'avenir on aura 2 UIs différentes et adaptées. En fait j'ai même déjà du code
stash-équi commence le travail, mais faut que je trouve le temps de finir.Par exemple beaucoup de gens demandent une gestion de "l'export pour le web", c'est à dire notamment changer la résolution d'une image très haute rés, appliquer éventuellement quelques filtres, etc. À l'heure actuelle, on doit faire ce genre de choses dans l'image même, puis surtout ne pas oublier de les annuler après export de l'image (pour ne pas engendrer de perte de qualité, surtout quand l'image est aussi destinée pour de la haute résolution). Ben je pense que ce genre de choses devraient être faisable aisément dans une UI séparée qui gère ce genre de choses (comme un graphe d'effet à appliquer seulement dans un mode d'export particulier qu'on peut sauver).
Ce sont des exemples mais on peut en trouver beaucoup d'autres. Sauver et exporter sont vraiment des processus très différents. Simplement nous n'avons pas encore l'UI. C'est la base de cette évolution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question de n00b
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 8.
Oui et non. Oui, ça limite l'intérêt, et notamment clairement la prévisualisation en directe pourrait devenir une véritable plaie (bloquant l'UI et empêchant de configurer correctement son filtre si à chaque fois qu'on affleure même un slider, on doit se taper une prévis).
Ensuite non, la non-destructivité est quand même utile (selon moi) pour les filtres longs. Du moment qu'on gère bien toute la partie ennuyante (comme la prévisualisation, en ne l'autorisant pas sur certains filtres), il reste tout de même d'autres avantages bien réels. Par exemple, tu parles de changer le paramètre d'un filtre. Ben dans ce cas là, même avec la méthode destructive (annuler, refaire le filtre), on doit se retaper les 15 minutes de traitement du filtre. Ben au moins avec la méthode non-destructive, on peut le faire n'importe quand, même après plusieurs heures de travail et des centaines d'autres actions faites entretemps; donc revenir sur l'historique — si possible, des fois ça ne l'est même pas — en revient à perdre des heures de travail.
Je ne suis pas certain, mais il est clair que nous ne laisserons pas ce genre de problèmes arriver (ou par erreur, et dans ce cas là, ce sera à considérer un bug à corriger). Il faudra les traiter. Je peux imaginer plusieurs choses.
Déjà la détection: on peut ajouter une notion de coût (théorique, comme un paramètre disponible en introspection) à une opération (il me semble me rappeler que cela a d'ailleurs déjà été discuté sur IRC). Ainsi avant même de commencer une opération, on peut avertir l'utilisateur que la prévisualisation risque d'être longue pour certaines opérations (voire même l'interdire pour des opérations qu'on sait vraiment vraiment trop longue), ou bien même pour toute opération si on l'exécute sur une image de vraiment trop grande taille. Ensuite on peut aussi avoir, en plus, un timer qui prend la main quand une prév dure trop longtemps, et donne la possibilité à l'utilisateur de l'interrompre.
Ensuite comment gérer ces ops trop longues?
1/ On peut donc simplement interdire la prév automatique comme je disais.
2/ Mais on peut aussi permettre une prév explicite avec un bouton dans ce cas. C'est à dire que ça ne va pas re-rendre le résultat juste en bougeant un slider d'un micromètre (bon moyen de rendre une UI inutilisable). Par contre, l'utilisateur peut bouger ses boutons et sliders tranquillement, puis cliquer sur un bouton, aller prendre un café et revenir voir le résultat après 15 minutes. Éventuellement refaire des changements, etc. Ou sinon appliquer (ce qui sera instantané puisque tout est déjà calculé).
Cela reste toujours légèrement plus pratique et rapide que d'appliquer, annuler, rouvrir l'UI de plugin, réappliquer, réannuler… Pas énormément différent, hein. Mais un peu, selon moi.
3/ L'utilisateur peut supprimer la visualisation d'un filtre (avec l'icône "œil"). Ça permet de l'appliquer au début, mais ensuite de l'empêcher d'actualiser sans cesse la vue (surtout si on prévoit de peindre sur le calque de base, etc.).
4/ On peut aussi permettre d'appliquer un filtre (ou une liste de filtres) directement sur l'image (c'est à dire en destructif comme maintenant). En fait j'en ai jamais discuté avec les autres, mais personnellement cela me paraît une fonctionnalité évidente.
Il y a toujours des cas où appliquer un filtre est mieux, voire nécessaire. Par exemple si on souhaite peindre directement sur le rendu (et non sur le calque de base, ni sur un autre calque au dessus), il n'y a pas d'autres choix que d'appliquer le filtre pour qu'il ne fasse qu'un avec son calque. Blender par exemple permet de faire cela (on peut mettre des filtres genre miroir sur des objets 3D. Puis ensuite on l'applique, ce qui permet de travailler sur un côté de l'image différemment par exemple).
En tous cas, cela signifie qu'une architecture non-destructive n'oblige absolument pas à travailler non-destructif tout du long. L'utilisateur peut toujours revenir à une méthode de travail destructive.
5/ Enfin, en revenant sur la problématique des prévisualisations, il y a des moyens de les accélérer (en dehors de la solution d'optimiser les opérations elle-même bien sûr), notamment lorsque le viewport ne montre qu'une partie de l'image. Ou à l'inverse quand la vue de l'image est plus petite que la taille réelle du fichier à cause d'un zoom-out. Bon c'est pas moi l'expert, mais voici un email du mainteneur GEGL sur le sujet de l'accélération de la prévisualisation.
Ce sont des choses auxquels les divers développeurs réfléchissent beaucoup.
Non puisque comme je disais, on devrait toujours pouvoir les utiliser en destructifs à l'ancienne. C'est juste une question d'UI.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vagabondage
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 10.
Salut,
Cette photo, c'était en Mongolie. J'ai vagabondé entre la France et le Japon pendant 6 mois, puis j'ai vécu au Japon, en Corée, en Nouvelle Zélande, où j'ai aussi pas mal bougé.
En effet je code pas, ou presque, quand je suis sur la route.
Ben tu mets en pause quand tu sais que de toutes façons, tu n'auras pas vraiment l'opportunité de contribuer. Par exemple à l'époque je contribuais beaucoup dans le monde XMPP. Ben avant de partir, j'ai quitté la XSF (ils ont assez de membres fantômes, pas la peine d'en rajouter un), de la même façon que j'ai démissionné de mon job ou que j'ai donné un préavis pour l'appart que je louais à l'époque. Y a pas vraiment de différence. :-)
Par contre une fois un peu plus posé, même si tu peux rester mobile et déménager tous les mois, rien n'empêche de contribuer avec même un petit portable léger et peu puissant. J'ai codé pendant plusieurs années sur un petit eeepc acheté au Japon. J'ai même codé dans une startup au Japon avec cet eeepc pendant plus d'1 an (avant qu'ils m'achètent un ordi puissant) où j'étais senior developer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 10.
Bon j'ai dit que je répondrai pas, mais je marche dedans! J'arrive pas à retenir mes doigts.
Qu'est-ce qui ne marche pas? Qu'un outil n'est pas parfait n'est pas la même chose qu'un outil cassé. L'outil de texte marche très bien. Quand on trouve un bug, je peux t'assurer qu'on n'attend pas longtemps avant de le corriger.
En outre, c'est justement ce petit plus de l'UI parfaite qui prend du temps. Parler c'est beau, mais si tu as la science de l'UI idéale infuse, on les veut bien tes dessins et tes spécs détaillés (c'est à dire qui prend en compte tous les cas, pas juste un yakafokon en 1 ligne) pour rendre l'outil de texte bien meilleur.
Merci de venir nous donner des leçons de vie. Heureusement que les trolls sont là pour nous apprendre comment gérer notre temps (avec ce magnifique exemple justement pour nous le faire perdre! En fait c'est peut-être cela la "gestion" du temps que tu veux nous enseigner?); sans eux, que ferait-on?
Je concluerai par un lien vers notre bugtracker, de la liste des rapports qui sont passés en statut "FIXED" (= corrigé) depuis janvier 2015: 75 bugs à ce jour
Et encore, c'est sans compter les bugs découverts en interne et corrigés sans qu'il y ait eu un rapport de bug. Je compte donc, dans la seule année 2015, 459 commits dans GIMP master, 26 dans babl master, et 218 dans GEGL master. C'est sûr, les développeurs de GIMP n'en font vraiment pas une et "se fout[tent] de l'utilisateur".
D'ailleurs saviez-vous que lorsqu'un utilisateur rapporte un bug, en fait on va se moquer de lui derrière son dos et on rigole bien car on fait exprès de ne jamais corriger les bugs.
Non mais qu'est-ce qu'il faut pas lire!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 10.
Tout à fait. La gestion du texte est un très gros chantier sur lequel on aimerait tous venir un jour. C'est clairement un outil assez frustrant à de nombreux égards. Je suis le premier à être d'accord, et Aryeom ne dira pas le contraire non plus! Tous les autres dévs en sont conscients aussi car on en parle régulièrement (on en a encore parlé avec le mainteneur y a 2 mois lors de LGM 2015).
De manière général, le commentaire initial du fil liste plusieurs problèmes réels, connus et qu'on veut améliorer.
Par contre j'ai voulu répondre, mais j'ai abandonné. Le commentaire n'a clairement pas été fait pour initier un échange constructif, et je sens que toute réponse (celle-ci comprise probablement) ne m'apportera que des attaques ad-hominem. C'est donc mon premier et dernier message sur ce fil de discussion.
Par contre si y a d'autres questions ou commentaires intéressants, et même des critiques constructives, n'hésitez pas à créer un autre fil.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]