Assez de débats sur l'interface; des fonctionnalités !!!
Je pense que cette news (et les liens officiels pour compléter) sont suffisants pour te rendre heureux alors, non? ;-)
Je crois pas qu'on ait oublié les nouvelles fonctionnalités. :P
Sinon je voulais noter que la mise-à-jour de GTK+, c'est énormément plus que de l'interface pure. Déjà c'est des fonctionnalités en pagaille. J'ai commencé une meilleure prise en charge de HiDPI dans GIMP 2.10, mais GTK+ >= 3 va énormément simplifier les choses pour une bien meilleure prise en charge des densités d'écran diverses. De même pour une bien meilleure prise en charge des tablettes graphiques qui est vachement problématique dans GIMP 2.x à ce jour. Notamment on aura enfin du hotplug (à l'heure actuelle, la tablette doit être branchée avant de démarrer GIMP pour être détectée/active), de bien meilleures détections de périphériques, et on pourra travailler sur la proposition de meilleurs configurations par défaut, etc. Y a aussi la prise en charge native de Wayland (pour l'instant, ça passe par XWayland). Et bien sûr l'accès à plein de nouveaux widgets (ce qui n'est pas juste esthétique mais utile). Une prise en charge des variantes de thèmes natives (comme les thèmes clairs et sombres) qui ne sont plus des thèmes différents, mais un même thème avec une variante (ce n'est pas juste esthétique; énormément de personnes considèrent les thèmes sombres comme une fonctionnalité essentielle, en particulier pour un logiciel de graphisme). Des thèmes bien plus maintenables en CSS.
Et j'en oublie.
De plus l'interface, c'est aussi la simplicité d'usage ("l'utilisabilité" chère aux designers, "usability" en anglais). Et franchement, c'est pas rien.
Je vais faire un don à Gimp (mais pas à Marmot qui n'est pas dans mon champ d'intérêt, désolé Jehan…)
Très bien. Y a pas de problèmes. Déjà si tu fais un don au projet GIMP, c'est super cool et je t'en remercie.
Je rappelle cependant que les contributions de ZeMarmot, c'est pas juste "faire de l'animation" avec GIMP, ni même "faire du dessin", loin de là. 99% des changements qu'on a apportés sont super utiles à tous. Et je parle même pas du débugging quotidien (donc de la stabilité notamment) et de la revue de code importante qu'on fait. Voir aussi nos comptes-rendus de la 2.9.4 et 2.9.6 notamment (on en avait pas fait pour la 2.9.2 bien qu'on contribuait déjà, et pas encore fait celui de la 2.9.8).
Le logiciel est un tout (y a pas une partie "photo" dissociée d'une partie "dessin"), et pour pouvoir dessiner convenablement, on a besoin d'un logiciel bon globalement et donc nous l'améliorons globalement.
Bon c'était ma minute marketing, parce qu'il faut bien. Mais si tu n'es toujours pas convaincu de notre utilité, je vais pas faire mon lourd. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Peut-on donc conclure de tout cela que le CMJN sera géré, enlevant ainsi un gros reproche fait par beaucoup à The Gimp ?
Y a du soft-proofing qui permet de voir l'image convertie dans un profil colorimétrique de sortie (qui peut typiquement être un profil CMYK d'imprimante). Mais l'image de travail (cad les pixels) reste RGB.
Tu parles de Darktable et d'un autre outil Raw, mais Ufraw est-il toujours connectable ?
Il s'agit d'un plug-in tiers, n'est-ce pas? Dans ce cas, je pense que ça devrait marcher, oui. L'API reste compatible entre 2.8 et 2.10 (ce sera une autre histoire à partir de GIMP 3 où on fera un peu de ménage de vieilles API dépréciées, mais vous avez le temps en années!), donc les plug-ins doivent toujours fonctionner. Quoique, je suis pas sûr ce que GIMP fait si plusieurs plug-ins essaient de s'enregistrer pour le même format avec les APIs standards. Donc à vérifier.
Dans tous les cas, je conseille à ce logiciel de se mettre à jour et donc plutôt passer par la nouvelle API pour se déclarer comme gérant les fichiers de type RAW: gimp_register_file_handler_raw().
Cela permettra d'être traité par GIMP au même titre que les autres, d'être disponible dans les préférences (utile en cas d'installation de plusieurs logiciels de ce type pour sélectionner son préféré), etc.
Ce que nous avons fait avec darktable et RawTherapee n'est absolument pas un "contrat d'exclusivité". Tout logiciel de développement de RAW est invité à se joindre à la fête et à pouvoir communiquer avec GIMP pour le traitement des RAW.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce n'est pas exclus, on en parlait lors de notre réunion Wilber Week (cherche "GTK+4" dans le lien).
À ce jour, GTK+4 n'est pas sorti et il ne faut donc pas mettre la charrue avant les bœufs, surtout que c'est encore vachement instable (par nature de pas être sorti!).
À suivre…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Cela signifie installer plein de dépendances, dans des versions particulières, pour réussir peut être à avoir un GIMP qui marche: on passe plus de temps à faire ça qu'à utiliser le logiciel.
J'avais noté une fois la liste de dépendances (obligatoires et optionnelles) pour quasi l'ensemble des options de GIMP sous Linux (il manque que webkitgtk mais c'est parce que nous nous basons sur une trop vieille version à cause de GTK+2, qui commence à disparaître des distributions depuis cette année), avec une Fedora 27:
À mettre en correspondance aux bons paquets sur une autre distrib.
Puis tu dois compiler toi-même libmypaint, babl, GEGL et enfin GIMP (dans cet ordre, sauf libmypaint qui peut être compilé n'importe quand tant que c'est avant GIMP).
L'ensemble du processus, compilation comprise se fait en moins de 30 minutes sur ma machine de ~5 ans (bonne machine néanmoins: i7, 8GB de RAM et SSD) et j'ai vu des compilations de GIMP vachement plus rapides sur de meilleures machines.
Voilà avec ça, je crois que ça devrait pas prendre trop de temps. :-)
Bien sûr, sur d'autres distributions moins à jour que Fedora, il n'y a pas à douter que tu devras probablement compiler d'autres dépendances (peut-être lcms2 voire libpng; il m'est déjà arrivé d'avoir à compiler Exiv2/GExiv2 mais ça date un peu et j'espère que toutes les distribs se sont mises à jour depuis) mais ça reste rapide (je pense que sur une distrib moderne, tu peux largement compiler GIMP et les dépendances absentes du système de paquet en moins d'une heure).
Je comprend que fournir des builds c'est compliqué pour les dev, mais il suffirait de faire une fois un flatpack pour que tout le monde puisse en bénéficier.
C'est pas compliqué. Je maintiens le flatpak officiel de GIMP sur flathub (mais c'est la version stable, pas de build dév; politique flathub). J'ai déjà les fichiers "manifest" pour un flatpak dev et un nightly et je mets à jour un dépôt privé pour ceux-ci que je fournis pour l'instant juste aux donateurs (et aux gens qui m'en font la demande en privé). La raison est que mon "serveur" est en fait un vieux desktop dans la cave de l'association LILA, qui peine à tourner (le paquet entier compile en 24h dessus, alors qu'il compile en moins de 2h sur flathub — c'est plus que ce que je disais plus haut, mais y a plus de dépendances à compiler dans ce cas là et c'est surtout à cause de webkit qui prend à lui seul 99% du temps de compilation!), tellement vieux qu'il a aidé à trouver et tester un bug de flatpak pour des vieux x86 sans SSE (de mémoire)! Donc je peux pas m'en servir pour soutenir la charge de millions d'utilisateurs de GIMP qui veulent la dernière version.
Je recherche donc une solution. On va peut-être pouvoir fournir ce dépôt sur les serveurs de GIMP mais c'est pas encore clair/sûr (je n'ai pas l'accès perso aux serveurs de download de GIMP; et volontariat, tout ça, j'ai du mal à chopper l'info auprès de ceux qui ont l'accès).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Et d'un autre côté les version devel (pas git mais numérotées) sont suffisamment stable pour être utilisées sur des tâches quotidiennes (peut être pas sur de la grosse production ou en sauvegardant régulièrement ?).
On l'utilise sur de la petite prod (utilisation quotidienne mais par une personne) depuis environ 2 ans.
C'est en effet très stable (mon object n°1).
Ensuite il faut garder en mémoire que ça reste une version de développement quand même et nous on peut se le permettre plus facilement car je suis là. Il m'est arrivé (une unique fois) d'avoir à "sauver" des fichiers XCF corrompus par un bug. Un artiste non-codeur seul n'aurait vraisemblablement pas pu le faire. Mais de manière général, c'est vrai pour toute production de film (récente, donc avec utilisation de technos numériques). Si tu regardes les génériques de tout film, y a toujours des équipes de développeurs (principalement pour développer les logiciels internes, je pense, mais on peut imaginer qu'ils seront aussi présent pour sauver des fichiers en cas de bourdes et qu'ils peuvent aider les artistes ponctuellement au besoin).
Nous on est juste la version réduite avec équipe de 1 artiste + 1 dév. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Effectivement, je n'avais pas vu pour la partie haute/basse des glissoirs, c'est une bonne idée d'illuminer les 2 parties.
Oui, c'est une bonne évolution design cette illumination. Ça a été codé par un nouveau développeur super actif depuis un an (Ell), qui est apparu et soudain s'est mis à contribuer plein de code de super niveau. Ça fait plaisir.
Le lien de notes de version pour gimp-2.8.9 retourne un 404
Eheheh. Oui ça c'est un petit cadeau de ZeMarmot aussi. ;-)
On a contribué cette animation pour la page 404 y a quelques temps en profitant de l'occasion pour découvrir les animations SVG (il me semblait avoir fait un journal à ce sujet, mais je le retrouve pas).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ne pensez-vous pas que la roadmap 2.10 n'est été trop importante étant donné le nombre limités de contributeurs actifs sur le projet ?
Je crois que cette phrase de mon article répond à ta question:
GIMP a été entièrement développé en bénévolat jusqu'à très récemment.
En gros, une entreprise (ou autre entité unique qui gère un logiciel avec des employés) va avoir sa roadmap interne et elle priorise plus facilement certains trucs. Ce n'est pas forcément mieux pour tout. Cela peut d'ailleurs provoquer des conflits avec la communauté quand certains aspects sont trop strictement contrôlés par cette entité, voire quand des refus (ou non-intégration sans refus clair) de fonctionnalités se produisent sans raison claire (par exemple, le rapport de bug de la fonctionnalité WebP dont je donne un lien plus haut vers le bugzilla de Mozilla est à un moment complètement parti en vrille car il y a des patchs depuis plus d'un an et beaucoup de gens attendent que Mozilla finissent la revue et l'intègre; au final le bug est passé lecture seule pour stopper la montée en troll).
Ils ont des employés, ils ont une roadmap probablement assez directive, ils s'y tiennent, et parfois s'ils ont le temps, ils se permettent de regarder un peu ce que fait la communauté.
Dans le cas de GIMP, c'est complètement différent. Pourquoi? Parce qu'y a aucun manager pour dire "c'est la roadmap, c'est comme ça, vous obéissez", et aucun employé pour suivre cette roadmap (qu'il peut discuter, mais au final s'il veut garder son job et que ses arguments sont refusés, il suivra). La "roadmap" de GIMP est donc totalement fluide et cible mouvante. Si tu préfères, on peut presque dire qu'il n'y a pas vraiment de roadmap (dit-il en donnant un lien). Elle est "presque" faite après coup. Ou plutôt puisqu'on se base quasi-essentiellement sur le volontariat, elle dépend des contributeurs du moment. Si y a un contributeur très impliqué qui un jour décide que telle fonctionnalité est sa priorité, alors cela rentre plus ou moins naturellement dans notre roadmap. Bon sauf si la dite-fonctionnalité est totalement tordue et que les autres dévs la refusent… en particulier le mainteneur qui aura le dernier mot (il y a quand même une "vision" du logiciel, disons qu'elle est plus fluide que dans un logiciel commercial).
Pour 2.10, le seul vrai item de la roadmap initiale selon moi, le fil directeur, c'était — je pense — le port de GEGL. Quasiment tout le reste, c'était des choses qui sont simplement arrivées naturellement pendant ce port car des gens (les dévs core ou des contributeurs externes) ont proposés ces améliorations. Quasi rien de ce que vous lisez dans cette news n'était initialement prévu (du moins, pas noir sur blanc comme un plan clair et net).
Le port GEGL en particulier a pris beaucoup de temps car c'est un sujet compliqué, et comme tu le dis, y a peu de développeurs. Lors de mes premiers builds (fin 2012, quand j'ai commencé à contribuer avec quelques patchs mineurs), le gros du port vers GEGL avait déjà été fait, mais GIMP 2.9 était tout simplement inutilisable au quotidien. Les opérations et surtout la peinture sur canevas était incroyablement lentes (tu faisais un trait puis tu allais faire un café le temps que ça apparaisse, ou presque ;p). Les choses se sont progressivement améliorées mais cela a pris du temps. Pendant ce temps là, quand les gens proposaient des patchs pour des nouvelles fonctionnalités super cools, ben le projet allait pas les refuser (sinon les gens proposent plus de patchs et y a pas de nouveaux dévs!).
En gros, tu ne peux pas refuser des fonctionnalités en demandant aux gens de bosser sur autre chose. Si un gars nous propose un patch géniale sur une fonctionnalité révolutionnaire, tu ne vas pas lui dire "ah c'est pas dans notre roadmap, désolé. Par contre, on remarque que tu es un développeur doué. Tu voudrais pas plutôt coder sur GEGL ou le port de GEGL dans GIMP?". Tu fais ça, le gars se barre (en gueulant ou silencieusement suivant les tempéraments), tu entends plus parler de lui et tu viens de tirer un trait sur ta fonctionnalité révolutionnaire.
Par contre, si tu te dis "c'est vraiment trop cool, faut qu'on intègre ça", ben tu te prends un peu de temps pour faire de la revue, commenter le code, demander des corrections, puis l'intégrer, probablement rajouter du code autour pour rendre le truc encore plus génial, etc. Au final, oui tu as utilisé du temps (qui peut-être aurait pu être utilisé pour le port de GEGL… ou pas! On rappelle: volontariat, les gens bossent sur ce qu'ils veulent), ça n'a pas fait avancer GEGL, mais tu as une méga fonctionnalité à la fin. Et le nouveau contributeur, peut-être même qu'il va rester dans le coin et proposer d'autres fonctionnalités géniales. Ou pas. Peut-être qu'il va vouloir aider au port GEGL. Ou pas. Peut-être qu'il va se barrer et on va jamais le revoir. C'est 90% des cas mais ça reste mieux que refuser la fonctionnalité et le gars se barre dans 100% des cas, et en plus on perd une fonctionnalité.
Et surtout, les nouvelles fonctionnalités n'impactent en rien (ou rarement) le port vers GEGL. Donc les refuser sous prétexte que ce n'est pas dans la roadmap n'a aucun intérêt. Refuser une fonctionnalité super cool car GEGL est lent, ou que d'autres parties de GIMP ne sont pas encore portées n'améliore pas ces aspects problématiques (ça n'empire pas non plus. En gros, rien à voir, fils unique, quoi…). Par contre bien sûr, on demande à ce que les nouvelles fonctionnalités soient bien basées sur GEGL (si pertinent). On veut pas intégrer une fonctionnalité basée sur 2.8 et devoir la porter après coup. Là oui, ce serait aller à reculons.
Je ne vais pas expliquer les avantages d'avoir des releases plus fréquentes je pense ne rien vous apprendre mais j'ai du mal à comprendre
Je suppose que tu parles de sorties avec de nouvelles fonctionnalités. Non parce que sinon, GIMP a des sorties tous les 3 à 6 mois (on est à la version 2.8.22, ça fait 12 sorties depuis 2012, c'est plutôt fréquent!). ;-)
Donc oui, je suis d'accord avec toi; notre problème est qu'on fait partie de ces logiciels de la vieille époque qui ont des majeures, mineurs, avec une sémantique des versions, et en particulier: pas de nouvelles fonctionnalités dans une mineure. Depuis les logiques de sortie ont changés dans beaucoup de logiciels jusqu'au point de même faire sauter les logiques de majeures/mineures tout court (beaucoup de logiciels incrémentent simplement à chaque sortie).
On était bloqué par le port de GEGL. Comme je l'ai dit, pendant plusieurs années, c'était trop lent, ou trop imparfait, etc. Mais on est bien conscient du problème et on a décider de faire évoluer notre mode de sortie après la 2.10 car nous entamerons alors un nouveau port qui peut être à nouveau long: le port vers GTK+3.
Nous avons donc décidé et annoncé officiellement en début d'années que nous assouplirons la règle "pas de nouvelle fonctionnalité dans des sorties mineures" après GIMP 2.10.
C'est une évolution que je pousse depuis 2014 (voir par exemple ce compte-rendu de LGM, section "Les réunions GIMP"), et j'ai finalement réussi à faire progresser cela jusqu'à une officialisation.
Donc oui, GIMP aura des sorties de fonctionnalités plus régulières à partir de 2.10. Il y a de fortes chances que nous assouplissons encore plus la logique des versions après GIMP 3. En tous cas, c'est personnellement dans ce sens là que je pousse.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
P.S.: quant à mon explication sur le travail apporté par chaque nouvelle plateforme, mon avis n'a pas changé. C'est toujours embêtant de gérer plusieurs plateformes. Déjà pour les nouvelles à dupliquer (même en copier-coller, faut en général refaire la mise-en-page) mais aussi pour le contenu "statique" qu'il ne faut pas oublier de mettre à jour partout quand quelque chose change, ainsi que la gestion des donateurs, etc.
Mais avec les changements de Patreon, on a perdu 14 patrons pour 71$ de dons en une seule journée (au moment où j'ai regardé, ça a peut-être empiré depuis hier), soit plus de 10% des dons. Et comme c'est pas la première fois qu'on me parle de Liberapay, ben on a décidé de tenter.
En plus, le fait qu'il n'y a pas de nouvelles (sur cette plateforme, il revient aux donateurs de se tenir au courant) ni de gestion des donateurs (car entièrement anonymes) simplifie beaucoup les choses par rapport à mes réticences plus haut.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Il est en fait possible de faire des dons via d'autres moyens que ces plateformes, notamment via paypal (contact chez libreart.info) ou même en virement bancaire ou chèque à l'association LILA dont le projet principal pour l'instant est ZeMarmot. Pour une liste de moyens de donation à LILA: https://libreart.info/fr/donate
Les plateformes sont intéressantes pour la gestion et aussi la visibilité (certaines personnes ont tendance à contribuer principalement parce qu'elle voit que beaucoup d'autres donnent), mais il est clair que les dons directs n'ont pas les frais de ces plateformes, donc c'est intéressant. Nous avons déjà quelques donateurs qui donnent ainsi (en ponctuel et même en récurrent avec virement mensuel).
En tous les cas, merci beaucoup pour ce journal. En effet je n'avais pas relayé l'appel aux dons. Déjà parce que quand je l'ai lancé, j'avais plus accès au compte linuxfr (même si j'ai rapidement retrouvé le mot de passe, genre le lendemain ou surlendemain); et puis j’étais un peu fatigué, faut dire ce qui est. En plus j'ai fait beaucoup de journaux sur linuxfr déjà, alors je me dis qu'à force, ça vous soûlerait! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
La FDL est vraiment un choix. Elle contient un élément très important qui n'est pas réellement couvert par les CC, à savoir la notion de copie transparente
C'est en effet une raison très valide. Il est tout à fait vrai que les Creative Commons n'ont pas cette notion de "source" et c'est souvent ennuyeux. Cela rend beaucoup d'œuvres théoriquement réutilisables pour modification beaucoup moins utiles, voire parfois carrêment inutilisables dans les faits pour modification. Du genre une vidéo sera quasiment toujours dans un format compressé avec perte (à tel point qu'on ne dit même plus "avec perte" pour les codecs vidéos tellement cela paraît évident); enfin je dis "quasiment" pour pas qu'on me ressorte un contre-exemple atypique, mais dans les faits, on exporte toujours des vidéos compressées avec perte pour les cas classiques.
Il existe toutefois des codecs sans perte, comme Huffyuv et beaucoup de codecs avec perte classiques ont une option pour le rendre sans perte (même si c'est quasi-jamais utilisé; la liste est assez longue tout de même d'après Wikipédia). Mais franchement, qui utilise ça? Dans le médical peut-être? (bon je suis sûr qu'y a des cas d'utilisation bien sûr, sinon ça existerait pas!)
Et puis même si les vidéos étaient sans perte, ce n'est pas pareil que d'accéder aux fichiers vraiment source, notamment pour changer les effets, la composition, les transitions, etc. Sans compter que pour charger un fichier vidéo sans perte (qui sera énorme. Des fois, même avec de la perte, selon les options de compression, des vidéos peuvent faire plusieurs GBs pour 30 secondes!), le traiter et extraire des parties sera déjà une gageure. Ce ne sera jamais pareil qu'un film découpé en sources multiples bien plus faciles à traiter.
Tout ça pour dire que oui, je suis d'accord, la notion de "source" comme référence pour les modifications manque cruellement dans les CCs.
ET la licence Art Libre ?
Art Libre a également cette notion de source. Dans leur texte légal, ils appellent cela les "originaux".
Originaux (sources ou ressources de l’œuvre) :
Chaque exemplaire daté de l’œuvre initiale ou conséquente que leurs auteurs présentent comme référence pour toutes actualisations, interprétations, copies ou reproductions ultérieures.
Par contre ils ne définissent pas précisément ce qu'est un "original" (hormis que c'est à utiliser comme référence pour les modifications) et cela reste au choix de l'auteur. En particulier ils ne vont pas limiter les "originaux" à des formats faits pour la modification, donc pas de considération technique. Il reste donc possible pour un artiste de "présenter" un PDF comme étant l'original. Je dirais que c'est matière à controverse, mais dans tous les cas, c'est beaucoup moins précis que la définition FDL.
Pour nuancer mon propos, la FDL donne quelques exemples de "copies transparentes" (les "originaux" d'Art Libre) et je suis pas trop d'accord avec certains:
Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format, SGML
or XML using a publicly available DTD, and standard-conforming simple
HTML, PostScript or PDF designed for human modification. Examples of
transparent image formats include PNG, XCF and JPG.
Le gras est de moi. Autant je suis tout assez d'accord pour la partie texte (on notera toutefois qu'ils incluent le PDF si désigné spécifiquement pour de la modification), autant pour les images, du PNG et du JPG? Je dirais que ça peut être acceptable, mais là aussi avec des cas. Le PNG, oui si l'auteur a travaillé en 16-bit par canal ou moins, sans calque de texte, sans vecteur nécessaire pour modification, etc. Le JPG étant compressé donc destructif par nature par contre ne me semble une source/copie transparente acceptable dans aucun cas (bon à part si on parle d'un JPG sorti directement d'un appareil photo, comme source aussi utilisée par le créateur de l'œuvre sous FDL; mais s'il la modifie, la source de son œuvre finale devrait être un XCF, ORA ou similaire).
Pour moi, la seule source acceptable sans conteste dans les 3 formats proposés est XCF. PNG le sera toutefois dans beaucoup de cas, soyons clair. Mais cela reste à préciser car il y a aussi beaucoup de cas où un PNG est tout sauf une source acceptable.
Donc au final, même la FDL reste assez large sur son acceptation de ce qu'est une source et laisse pas mal à l'interprétation de l'auteur.
La licence Art Libre n'est-elle pas équivalente à la licence CC BY-SA ?
Si depuis quelques années maintenant. Si vous utilisez LAL 1.3 et CC by-sa 4.0, vous pouvez mélanger des œuvres de ces licences. Voir aussi la liste de compatibilité de Creative Commons. De même votre travail dérivé peut lui-même être dans une des licences compatibles de la licence de l'œuvre source.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Dans la pratique, avoir une organisation temporelle simple devant les yeux (classer les données par années et mois, et à l'intérieur par évènements dans mon cas; dans le cas de quelqu'un d'autre ça peut être une autre organisation, du moment que ça a un sens pour la personne, c'est ce qui compte; chacun son truc) me permet de retrouver des données auxquelles je pense plus (mais ça veut pas dire qu'elle ne m'intéressent pas; on oublie, même des choses qu'on aime!). C'est simple, c'est clair et surtout c'est visuel. Des tags, c'est une sorte de trucs un peu brouillard. D'ailleurs c'est marrant car la représentation visuelle la plus classique, c'est… un nuage de tags! Comme quoi… Souvent on va mettre en plus gros les tags les plus utilisés, mais cela n'est pas utile pour chercher. On ne cherche pas forcément ce qu'on fait le plus (cette représentation est plus utile pour les tiers qui veulent savoir les trucs dont tu parles le plus, donc bien dans un blog, mais pas pour soi).
Combien de fois j'ai cherché des trucs et je me dis, c'est quoi comme tag que j'ai mis? J'en essaie 2 ou 3 avant de trouver le bon. Le truc, c'est que dans la vie, on a plus que 3 ou 4 catégories à retenir. On en a des centaines. On se souviendra seulement de comment on taggue les trucs les plus courants qu'on fait quotidiennement. Mais sorti de là, c'est… le brouillard! Quand j'ai des dossiers physiques dans des classeurs, j'ai pas besoin de mémoriser le titre du classeur. Je sais qu'il est placé vers la droite de mon armoire, je lis 2 ou 3 titres, je le trouve, je le sors, et dedans j'ai rangé les choses par date ou alphabétiquement ou autre. C'est facile et je trouve ce que je cherche. Dans des dossiers numériques, c'est pareil. Si tous mes fichiers sont taggués par contre, ça m'obligerait à essayer de me souvenir des tags précis des milliers de trucs que je fais, dont certains une seule fois dans ma vie.
Le truc classique, c'est aussi d'avoir plusieurs tags qui sont en fait les mêmes car on se souvient pas bien de ce qu'on a écrit les fois précédentes (logiciels libres, logiciel libre, free software, FOSS, FLOSS… autant de variantes que je pourrais utiliser!). Franchement les blogs sont toujours plein de duplication de tags légèrement différents. Sans compter les fautes d'orthographe or de typo. Si en tapant vite, j'inverse des lettres, genre "onël", dans mon répertoire 2017/12/, ben quand je chercherai mes photos, je comprendrais tout de suite que c'était une typo, je corrige puis je regarde mes photos (ça ne m'a pris 1 seconde de plus pour corriger). Si les tags sont le seul moyen de retrouver mes photos par contre, je tape "noël 2017" et là… rien! Hop je me dis, ça y est, j'ai perdu les photos. Peut-être que je peux essayer de les retrouver en jouant avec d'autres tags, et avec un peu de chance je les récupère toutes et corrige tous les tags, mais ce sera pas juste quelques secondes que j'aurais perdu. Probablement plus 30 minutes.
En fait, si un jour les assistants personnels sont réellement intelligents, c'est moins grave. On n'a plus besoin de mémoriser le tag précis. On dira "je suis allé voir ce spectacle le mois dernier, tu peux me le retrouver", et il te retourner le truc taggué "danse" car c'était un spectacle de danse. Ou il corrigera tes fautes d'orthographe et de typo. Mais comme je l'ai dit, je ne crois pas que l'IA deviendra réellement intelligente un jour. On peut essayer de faire corriger des mots avec des dictionnaires et en comparant des distances de mot; on peut créer des catégories sémantiques; on peut améliorer de plein de façon après coup en découvrant les limitations au fur et à mesure. Mais ça ne sera jamais parfait. Enfin c'est ce que je pense. On verra dans 10 ans.
Quoiqu'il en soit, ce sont des trucs cools à étudier, à développer et à utiliser. Mais à ce jour, ça ne remplace pas mon organisation personnelle des fichiers. Ça la complète éventuellement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tout ce que vous dites tous est vrai. Mais pour moi, toutes ces choses là viennent en complément d'une organisation classique. Les reconnaissances de visage fonctionnent bien mais ne sont pas parfaites. Les dates sont toujours bonnes sur un portable mais voir une date erronnée sur un appareil photo dont on a enlevé la batterie trop longtemps est encore très courant. Le GPS est dispo sur certains appareils photo haut de gamme (donc cher) mais pas tous, loin de là. La catégorisation automatique (de visage, voyage, sujets, etc.) marche bien mais pas parfaitement. On en sait quelque chose, cela fait des années quand on a tous de la catégorisation dans les emails (antispam) et que les faux-positifs comme les faux-négatifs continuent à apparaître. Et ce, même chez Google (comme chez n'importe quel fournisseur).
Or ces quelques faux-positifs et négatifs même s'il y en a juste quelques uns sont déjà quelques uns de trop. Si tu demandes toutes les photos de noël avec Tati Marie et qu'il en manque quelques unes car la reconnaissance de visage n'a pas marché bien, ou bien parce qu'elles ont été prises avec un appareil qui n'avait pas la bonne date, ben ce sont potentiellement des photos perdues à jamais (mais qui continuent à prendre de la place sur ton disque) et tu n'en sauras jamais rien. Tu ne peux même pas aller les chercher à la main puisque dans ce monde où tout est taggué et reconnu automatiquement, toutes les photos sont en vrac dans un répertoire (ou plusieurs répertoires créés automatiquement) qui contient donc des milliers voire dizaines de milliers de photos au fil des ans.
Si par contre, après Noël, tu as mis toutes tes photos dans un répertoire Pictures/2017/12/soiree-noel/ par exemple, ça ne t'empêche pas d'avoir un assistant pour obtenir en un instant toutes les photos de Noël qui montrent Tati Marie, mais alternativement tu peux aussi jeter un œil toi-même dans ton répertoire qui ne contient que quelques dizaines de photos, et les faire défiler en quelques minutes (voire juste regarder vite fait l'aperçu dans le dossier). Garder un contrôle sur tes fichiers et ton organisation ne t'empêche absolument pas de les tagguer, d'avoir de la reconnaissance dessus, d'utiliser les méta-données quand elles sont présentes (et valides), et d'avoir un assistant électronique pour les retrouver. Mais au moins tu peux toujours revenir aux bases.
Franchement mes emails, heureusement que j'ai des filtres (créés à l'ancienne pour une gestion à l'ancienne par répertoire) et pas juste une organisation automatique (gmail fait ça maintenant l'organisation automatique, ça marche globalement mais y a plein d'erreurs). De même heureusement que je regarde encore de temps en temps la boîte spam car je retrouve régulièrement des emails valides (encore une fois, sur ma boîte principale auto-hébergée comme sur ma boîte gmail que j'utilise pour des contacts par exemple lorsque je veux pas leur donner mon email principal immédiatement; là par exemple je viens de jeter un œil et j'ai découvert une réponse d'un imprimeur à qui j'avais demandé un devis la semaine dernière! Je pensais qu'ils n'avaient pas répondu mais en fait ça a fini en spam… heureusement que j'ai vu. Et on parle de Google).
Donc oui tous ces assistants, ces catégorisations automatiques, etc. c'est vraiment super cool. Ça aide. Mais ça ne remplace pas l'organisation manuelle à ce jour. En fait je vais même oser le dire: je pense que ça ne remplacera jamais totalement une organisation manuelle pour la simple raison que l'intelligence artificielle… n'est pas de l'intelligence! C'était ma spécialité à l'université et en fait c'est juste des stats principalement. La plupart des algorithmes qu'on trouve extraordinaires (réseaux de neurones, filtres bayésien, modèles de markov cachés… un peu tout type d'algo utilisés en reconnaissance de forme ou en décision…) sont dérivées de théories probabilistes et statistiques. Or s'il y a une chose dont on peut être sûr, c'est que des méthodes statistiques ne seront jamais vraies dans 100% des cas; mais dans la plupart, oui. C'est un peu la définition même de ce que sont les statistiques.
Alors certes je n'ai plus vraiment étudié l'IA depuis la fac. Qui sait, peut-être que dans certains labos, ils sont super proches de donner la conscience aux IAs qui penseront vraiment d'elle même et pas avec des stats (mais ce jour là, je suis pas sûr qu'elle seront jouasses d'être nos "assistants personnels", nos esclaves en somme). Si ça arrive, j'aurais eu tort. Car à ce jour, je ne crois pas que ça puisse arriver, justement car j'ai vu, étudié et implémenté ce genre de trucs et que pour moi, c'est tout sauf intelligent (enfin les humains qui ont créé ces systèmes sont intelligents, pas les logiciels). Et je doute vraiment qu'on arrive un jour à créer une vraie conscience (je sais, c'est à la mode de dire l'inverse et d'avoir peur de la révolte des ordis).
Conclusion: oui à tous ces trucs pour nous aider, mais non ça ne remplace pas une organisation humaine en plus en tous cas dès que les données sont considérées un tant soit peu importantes et qu'en perdre un peu régulièrement n'est pas acceptable.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je me rappelle que quand j'avais testé Wayland, des trucs qui n'étaient pas censé marcher marchaient (mais je ne saurais plus dire quoi). Et quand j'en avais parlé avec un dév Wayland, on me disait que c'était sûrement normal pour une application X (GIMP utilise encore GTK+2, donc n'est pas un client Wayland), qui passait donc par XWayland, ce qui contournait des restrictions Wayland.
Peut-être est-ce ce qui t'arrive et peut-être ce contournement des restrictions a-t-il été corrigé depuis dans les versions suivantes (ce qui explique que d'autres n'ont plus ce comportement dans des versions plus récentes).
Petite digression, qu'en est-il d'une API officielle GNOME SHELL pour les extensions?
J'aimerais bien aussi. Cela fait partie de ces choses où j'ai découvert à GUADEC que certains autres développeurs n'avaient pas du tout la même vision que moi. Pour certains, les extensions sont un hack qui ferait mieux de ne pas exister. Pour d'autres (comme toi et moi), c'est super important et il faudrait donc créer une API stable.
Je pense que la seule chose qui manque est une personne qui prenne le sujet en main, crée une API publique et surtout la maintienne dans le temps. Le fait est que si la plupart des core devs ne considère pas l'API comme devant être publique, alors ils n'ont aucune raison à se faire chier à ne pas la changer quand ils ont besoin.
Ce sont les gens qui font le Logiciel Libre. Tout ce qu'il faut, c'est donc des gens qui poussent dans la direction que tu veux (et ça peut être toi-même!). :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne sais pas. Ma connaissance de Wayland est très limitée et s'arrête un peu à ces utilisations de base. Une appli peut/pourra-t-elle demander à ne pas apparaître dans une capture d'écran? Est-ce prévu? Aucune idée. Mais ça pourrait exister, je pense, oui (opinion à prendre avec des pincettes. N'allez pas dire que quelqu'un vous a dit que c'est prévu ou je ne sais quoi! Je ne suis Wayland que de loin).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ta notion du "grand public" me laisse dubitatif. ;)
Quand il parle de "grand public" qui fait des commits/du versionning, ça me fait penser aux gens dans les bureaux (donc pas le grand grand public, mais quand même pas mal de monde) qui nomment leurs fichiers nom-de-fichier-30-01-2017.odt, en gros avec une date. Cela leur permet de revenir en arrière à divers points dans le temps s'ils ont fait une erreur, effacer des trucs sans trop de peur, etc. C'est un peu le commit du pauvre quoi. Ces gens font du versionnement sans s'en rendre compte. C'est d'ailleurs assez marrant car il me semble que la plupart des logiciels de traitement de texte et tableur ont du versionnement intégré de nos jours (on peut faire des snapshots directement dans le même fichier), mais très peu le savent/l'utilisent. Tiens encore y a quelques jours, pour un projet quelqu'un m'a donné un fichier tableur imprimé et le nom du fichier était noté en haut de page. Sans surprise, la date était dans le nom de fichier. Bon ensuite je sais pas si c'est de cela qu'il parle (première fois que j'entends parler de "GED" mais un tour sur Wikipédia me fait dire que c'est autre chose).
On va aussi faire des commits en modifiant des images. Les personnes habituées, voire qui ont déjà perdu des données, vont souvent sauvegarder leur travail à diverses étapes.
Etc.
Donc il n'a pas tout à fait tort, même si je ne dirais pas que c'est tout le monde non plus. Quant à automatiser cela pour les gens, l'exemple du traitement de texte/tableur est assez symptomatique du fait que même lorsque les fonctionnalités existent, les gens ne les utilisent pas forcément. Ils reviennent aux bases qu'ils connaissent: diverses versions du même fichier côte à côte et visible dans un répertoire.
D'ailleurs cette histoire de sauver un fichier c'est aussi un concept complètement périmé.
Au moins un des designers GNOME (Jimmac) pense aussi ainsi, du moins y a un an, la dernière fois qu'on s'est vus. On a eu une discussion à ce sujet et perso je ne suis pas convaincu. Ne pas avoir de concept de "sauver les fichiers", c'est aussi ne pas avoir de concept de répertoire, voire de ranger tout court, ni de nom de fichier. En gros, y a plus vraiment de concept de fichiers. Pour moi, les téléphones sont l'exemple parfait de cela car c'est la première tentative réelle de la disparition du concept de fichier. Au final, les gens font constamment des photos par exemple, et le jour où ils veulent t'en retrouver une, ils se mettent à scroller comme des malades: "attends, c'était y a pas longtemps. Hmmm… je pense que c'est avant d'aller ici… ah attends j'ai dû passer, c'était clairement après ça…" (au bout de 10 minutes, soit ils ont trouvés, soit ils ont abandonnés en te disant que de toutes façons, c'était pas si important). Franchement c'est pas un type d'organisation des données que je veux voir apparaître dans mon ordi principal.
Cela ne peut marcher qu'avec une certaine rigueur, en taggant ses données immédiatement dès qu'on la crée. Mais au final tagger pour recherche ultérieure ou sauver avec un nom de fichier et dans un répertoire donné, quelle différence? Très vraiment. Si on se souvient plus comment on a taggué, on retrouvera pas la donnée, de même que si on se souvient plus on l'a mise. Dans les deux cas, un peu de rigueur est nécessaire.
Alors j'espère qu'on ne verra pas ces disparitions de concept trop rapidement dans GNOME. Ensuite je peux être surpris, qui sait! Peut-être arriveront-ils à le faire avec un design génial.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
GIMP fait toujours des captures d'écran. Simplement il y a eu un intervalle entre les premiers OS sous Wayland et la mise à jour nécessaire de GIMP pour Wayland (pour être plus précis pour GNOME Shell sous Wayland).
Maintenant c'est implémenté mais ce sera disponible dans GIMP 2.10 seulement.
Dans l'optique sécurité de Wayland, je trouve cette protection assez sensé. En gros, toutes les applications auront le droit de faire des captures d'écran (et pas seulement des applications privilégiées), mais elles doivent passer par une API dbus et ce sera le compositeur (ou Window Manager, je sais pas trop qui a la charge de ça) qui se charge de faire la capture pour l'application. Ce que cela signifie est notamment que l'application n'a pas d'accès direct et ne peut pas regarder l'écran en douce. Il doit "demander". Ce que va faire l'OS alors n'est pas d'interdire mais le faire en avertissant l'utilisateur (que ce soit par une popup, un flash de l'écran, un bruit… quelque chose, libre aux designers de décider). En gros, tu peux plus faire un screenlogger qui va faire des captures régulières de l'écran en "loucedé". On pourra toujours faire des captures, mais simplement si le compositeur/window manager est bien designé, il avertira l'utilisateur.
De même, en cas de capture d'une zone de l'écran, ce sera aussi le compositeur/window manager qui gèrera la récupération de coordonnées. Ainsi typiquement dans l'API de GNOME shell, l'application utiliserait la méthode SelectArea, en conséquence de quoi le shell se mettra typiquement dans un mode interactif de récupération d'une zone rectangulaire (classiquement, le curseur change, éventuellement des instructions apparaissent, et l'utilisateur est invité à glisser la souris pour créer une zone rectangulaire). En retour de cette méthode dbus, des coordonnées sont retournées au programme si l'action s'est faite avec succès. Le programme peut alors appeler la méthode dbus ScreenshotArea avec ces paramètres. Il n'y a plus de code dans l'application pour la récupération de coordonnées (puisque l'application n'a plus de visibilité non plus sur sa position dans l'écran et ne peut évaluer cette info) ni pour la prise de capture d'écran ou de zone d'écran elle-même.
Je trouve cela plutôt bien. La logique n'est pas d'interdire mais d'avertir l'utilisateur quand des actions à risque sont entreprises (capture d'écran, keylogging, etc.). Certaines choses sont encore impossibles mais cela ne veut pas dire que c'est fait exprès. Simplement que l'API n'a pas encore été écrite.
Pour moi, le seul problème embêtant est que ces APIs ne soient pas au niveau du protocole mais de chaque implémentation. Ainsi GIMP peut bien maintenant faire des captures d'écran sous GNOME Shell, mais pas forcément sous d'autres implémentations au dessus de Wayland. Cela nous obligera à tester diverses APIs jusqu'à ce qu'une marche. J'aurais préféré une API commune.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Sinon, les réponses des développeurs aux demandes de portage Windows étaient assez revêches… C'est en tout cas la perception que j'en avais.
Il y a effectivement des styles plus abruptes que d'autre. C'est aussi beaucoup car certains en ont assez de se répéter. Ce que je t'ai dit notamment, tu lis en gros la même chose dans les articles officiels (1 et 2) que je trouve posés, détaillés et bien argumentés (et non revêches).
Je fais beaucoup d'efforts pour être didactique et patient car je sais que ça manque parfois. Mais cela a un coût non négligeable, ne serait-ce que par le temps que ça me prend pour faire ce type de réponses, temps que je préférerais passer à coder. D'autres développeurs font le choix inverse, et je le comprends bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Amusant : quand j'ai posté des messages aux développeurs (et aux utilisateurs sur les forums de Darktable) pour expliquer l'utilité d'une version Windows, on s'est (au mieux) moqué de moi…
As-tu un lien? On connaît assez bien les dévs Darktable. On les a rencontré lors de Libre Graphics Meeting et ils traînent sur le canal IRC de GIMP depuis longtemps (au passage GIMP utilise désormais Darktable et Rawtherapee comme greffons pour ouvrir les images RAW) et je peux dire qu'ils n'ont jamais été contre une version Windows. Par contre ils voulaient que ce soit bien fait. Et ça voulait dire avoir au moinsun développeur Windows pour faire le taff. Ils n'avaient pas ça et ne souhaitaient pas le faire eux-même car c'était un boulot conséquent (imaginez bien qu'on parle de support pour un OS majeur!) alors qu'ils n'utilisent même pas le dit OS.
Je vais prendre un exemple que je connais bien mieux: GIMP. Depuis des années, on a quasi aucun développeur Windows, et même les patchs de passage sont rares. À comparer avec Linux, qui est l'OS de tous les développeurs qui restent et contribuent régulièrement et pour laquelle version nous avons aussi des patchs de passage très réguliers. Par contre effectivement je pense que si on faisait des stats, on a bien plus de bugs pour GIMP seulement reproduisibles sous Windows. En gros, GIMP sous Windows est bien moins stable et a beaucoup plus de bugs, mais n'a quasi aucun développeur. Les bugs, quand ils sont corrigés (après être restés des mois sans que personne ne les confirme car souvent tout ce qu'on peut dire, c'est qu'on ne peut reproduire le problème sous Linux), le sont des mois voire années après quand quelqu'un soudainement arrive à comprendre un problème sans le reproduire ou qu'on prenne du temps à installer une VM Windows pour tester/débugguer par exemple. J'en ai corrigé pas mal comme ça, et c'est vraiment contraignant, prend du temps, et est peu satisfaisant.
Depuis quelques mois, on a enfin un dév compétent sous Windows qui a l'air de rester dans le coin et qui nous fait des patchs réguliers. C'est bien mais soyons clair, c'est pas grand chose pour rendre GIMP sous Windows vraiment bon.
Notez que GIMP sous MacOS, c'est à peine mieux. On a un dév qui le maintient dans le peu de temps qu'il a (en plus il vient d'avoir un enfant) et beaucoup de gens qui se plaignent mais quasi personne se prend en main pour patcher (je me souviens même de rapports de bug d'un gars qui nous expliquait qu'il était un utilisateur pro de GIMP et que certains bugs étaient inacceptables car étant aussi développeur, il "savait" que c'était super facile à corriger mais refusait de le faire lui-même car il n'avait pas le temps). Tiens pour l'histoire, j'ai corrigé un bug MacOS y a quelques jours et comme je n'ai pas d'ordi Apple (ni la possibilité de lancer MacOS en VM ni même de cross-compiler, non pas car ces choses ne sont pas possibles techniquement mais parce qu'Apple l'interdit), ben je l'ai fait à l'aveugle en lisant des APIs et exemples sur le web, ai dû pousser un truc totalement à l'aveuglette et ai demandé au rapporteur du bug de tester pour moi. Je peux dire que c'est clairement pas une situation propice au travail de qualité!
Perso si j'étais bien payé, ça me dérangerait pas d'en faire beaucoup plus et d'essayer même de corriger tous les bugs Windows et MacOS. Mais je suis pas payé du tout, alors franchement la plupart du temps j'ai juste envie d'ignorer tout bug que je ne peux reproduire sous Linux car ça me prend 10 fois plus de temps qu'un bug Linux.
Au final sans développeurs suffisamment présents, ces 2 OS sont une plaie pour le développement. C'est facile d'expliquer "l'utilité" d'une nouvelle prise en charge d'un OS à ceux qui donnent vraiment du temps pour développer, mais je t'assure que ce n'est pas très pertinent, à part si c'est aussi accompagné d'une aide réelle au développement: c'est à dire en donnant de son temps aussi. Ça apporte certes plus d'utilisateurs, donc plus de visibilité, mais de mon expérience, proportionnellement très peu enclins à contribuer malheureusement. ;-(
Voilà, j'espère que je suis un peu plus clair sur le "prix" d'un tel développement. Mon but n'est pas d'être abrupte mais d'expliquer leur rejet (totalement compréhensible) depuis des années. Compiler pour Windows n'est pas un problème, mais la prise en charge réelle, c'est autre chose. Si tu as eu l'impression que les développeurs se sont moqués de toi, ma supposition est que tu as mal compris ou que tu l'as mal pris et donc le sens a changé dans ton esprit. Ou alors ils étaient dans un mauvais jour, ça peut arriver à tous. Parce que non, ils n'ont jamais été contre Darktable pour Windows, par contre oui les dévs du moment ne voulaient pas le faire eux-même car ils n'utilisent pas cet OS, tout simplement. Et on peut difficilement leur en vouloir pour ça. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
La seule façon d'éviter cet écueil est d'embaucher quelqu'un qui sort d'une grande école. Ce n'est plus le dirigeant qui choisit, il confère cette fonction à l'école et à ses professeurs.
Alors j'imagine que tu sors d'une grande école, donc je ne veux pas te fâcher… mais je suis pas du tout d'accord avec toi. La compétence n'a rien à voir avec ton école. Être un bon dirigeant n'a non plus rien à voir avec ton école. D'ailleurs ça tombe bien, j'ai un super contre-exemple à ton affirmation! :-) Le vice-amiral Coustillière sort de l'École Navale (promotion 81), une des 4 grandes écoles militaires. Donc si on s'arrête à ton affirmation, alors embaucher Coustillière aurait dû éviter l'écueil de l'avoir embauché. :P
Plus sérieusement, y a cette vision totalement erroné et terrible que les grandes écoles, c'est l'élite de la nation. D'ailleurs dès la prépa, c'est le discours qu'on te sert régulièrement (je trouve cela à vomir avec le recul). C'est terrible et ça forme surtout beaucoup de gens hautains et suffisants (pas tous heureusement, mais beaucoup), bien que sans compétences exceptionnelles. Des gars sortis de grandes écoles qui sont vraiment nuls, j'en ai vu plein. Attention, je dis pas non plus qu'il y a un lien de cause à effet non plus. Simplement des gens qui ne travaillent pas bien, de même que des gens extrêmement compétents, tu en as plein partout, et cela ne dépend juste pas de l'école.
J'ai travaillé avec des développeurs très doués, dont certains qui n'ont même pas fait d'études supérieures du tout! Ils ont simplement commencé à travailler plus tôt, et ça leur confère même une sacré avance (franchement on apprend 10000 fois plus en "faisant" qu'en écoutant des cours ou avec des TPs de 2h qui survolent des concepts).
J'ai aussi connu le coup du petit jeune qui sort à peine de grande école, genre Polytechnique, et qui est direct dans un poste de consultant pour "changer les choses". Comme c'est ce pour quoi il est embauché… ben il essaie de changer les choses, quoi. Il ne connaît rien à comment ça marchait jusque là, ce qui marchait moins bien et plutôt bien, mais il change, c'est tout… Il fait virer des gens, fait des changements de postes, fait des changements d'outils, crée des réunions constamment qui empêche de faire le vrai travail, rend la vie terrible et donne envie aux gens (qui étaient heureux de leur boulot jusque là) de démissionner.
Donc non, franchement non. L'école n'a rien à voir avec la compétence. Et être dirigeant ne doit surtout pas nécessiter de sortir d'une grande école. Il y a des bons en grandes écoles comme des mauvais. De même qu'il y a des bons en université comme des mauvais. De même pour les sans-diplômes! Et non, je ne considère même pas qu'il y a des "tendances". La seule raison pour laquelle on aura plus de gens de grandes écoles en haut poste en France est justement car beaucoup vont penser ainsi et vont donc embaucher avec de tels critères (absurdes, selon moi), ce n'est donc pas une preuve.
Enfin voilà, je veux pas donner l'impression d'être contre le principe des grandes écoles. Mais je pense vraiment qu'on s'en est créée une vision totalement erronée en France.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
par rapport à ce que tu voulais dire, ta phrase est fausse : le code sous licence BSD ne peut pas changer de licence au gré d'une publication, il reste sous BSD même quand inclus dans un programme GPL. la BSD ne te donne pas le droit de changer la licence, juste de packager avec du code GPL (et le binaire devient GPL). Pour avoir le droit de publier sous licence GPL, il faut par exemple du code MIT (qui contrairement à la BSD autorise le changement de licence).
Tout à fait! C'est un point qui étonne toujours quand on explique que le code sous BSD reste sous BSD même s'il est au milieu de code GPL (par exemple). On m'a demandé de donner un cours invité à l'université il y a quelques mois, dont un sur la "gouvernance du Logiciel Libre" où j'ai parlé rapidement de licences… En réponse à une question, j'ai évoqué ce point que les licences d'un code ne changent pas (sauf avec permission explicite bien sûr, comme MIT qui en effet permet le "sublicense") et les professeurs eux-même étaient étonnés et étaient persuadés que j'avais tort car cela va à l'encontre de la simplification des licences que tout le monde entend.
Mais en fait, c'est très simple: c'est du droit d'auteur. Si on est l'auteur (ou l'ayant-droit) d'un code, on est le seul à avoir le droit d'y mettre une licence. Or donner l'autorisation à quiconque d'utiliser ou modifier son code dans un autre code, quelque soit la licence de cet autre code, ne signifie pas qu'on donne l'autorisation d'un changement de sa licence. On se retrouve simplement avec un mix de licences dans le code final.
Il suffit de se référer à la base de ces licences, le droit d'auteur/copyright, la loi en somme, pour que cela paraisse juste évident.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: roadmap trop importante ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 10.
Je pense que cette news (et les liens officiels pour compléter) sont suffisants pour te rendre heureux alors, non? ;-)
Je crois pas qu'on ait oublié les nouvelles fonctionnalités. :P
Sinon je voulais noter que la mise-à-jour de GTK+, c'est énormément plus que de l'interface pure. Déjà c'est des fonctionnalités en pagaille. J'ai commencé une meilleure prise en charge de HiDPI dans GIMP 2.10, mais GTK+ >= 3 va énormément simplifier les choses pour une bien meilleure prise en charge des densités d'écran diverses. De même pour une bien meilleure prise en charge des tablettes graphiques qui est vachement problématique dans GIMP 2.x à ce jour. Notamment on aura enfin du hotplug (à l'heure actuelle, la tablette doit être branchée avant de démarrer GIMP pour être détectée/active), de bien meilleures détections de périphériques, et on pourra travailler sur la proposition de meilleurs configurations par défaut, etc. Y a aussi la prise en charge native de Wayland (pour l'instant, ça passe par XWayland). Et bien sûr l'accès à plein de nouveaux widgets (ce qui n'est pas juste esthétique mais utile). Une prise en charge des variantes de thèmes natives (comme les thèmes clairs et sombres) qui ne sont plus des thèmes différents, mais un même thème avec une variante (ce n'est pas juste esthétique; énormément de personnes considèrent les thèmes sombres comme une fonctionnalité essentielle, en particulier pour un logiciel de graphisme). Des thèmes bien plus maintenables en CSS.
Et j'en oublie.
De plus l'interface, c'est aussi la simplicité d'usage ("l'utilisabilité" chère aux designers, "usability" en anglais). Et franchement, c'est pas rien.
Très bien. Y a pas de problèmes. Déjà si tu fais un don au projet GIMP, c'est super cool et je t'en remercie.
Je rappelle cependant que les contributions de ZeMarmot, c'est pas juste "faire de l'animation" avec GIMP, ni même "faire du dessin", loin de là. 99% des changements qu'on a apportés sont super utiles à tous. Et je parle même pas du débugging quotidien (donc de la stabilité notamment) et de la revue de code importante qu'on fait. Voir aussi nos comptes-rendus de la 2.9.4 et 2.9.6 notamment (on en avait pas fait pour la 2.9.2 bien qu'on contribuait déjà, et pas encore fait celui de la 2.9.8).
Le logiciel est un tout (y a pas une partie "photo" dissociée d'une partie "dessin"), et pour pouvoir dessiner convenablement, on a besoin d'un logiciel bon globalement et donc nous l'améliorons globalement.
Bon c'était ma minute marketing, parce qu'il faut bien. Mais si tu n'es toujours pas convaincu de notre utilité, je vais pas faire mon lourd. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Énorme!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 6.
Y a du soft-proofing qui permet de voir l'image convertie dans un profil colorimétrique de sortie (qui peut typiquement être un profil CMYK d'imprimante). Mais l'image de travail (cad les pixels) reste RGB.
Il s'agit d'un plug-in tiers, n'est-ce pas? Dans ce cas, je pense que ça devrait marcher, oui. L'API reste compatible entre 2.8 et 2.10 (ce sera une autre histoire à partir de GIMP 3 où on fera un peu de ménage de vieilles API dépréciées, mais vous avez le temps en années!), donc les plug-ins doivent toujours fonctionner. Quoique, je suis pas sûr ce que GIMP fait si plusieurs plug-ins essaient de s'enregistrer pour le même format avec les APIs standards. Donc à vérifier.
Dans tous les cas, je conseille à ce logiciel de se mettre à jour et donc plutôt passer par la nouvelle API pour se déclarer comme gérant les fichiers de type RAW: gimp_register_file_handler_raw().
Cela permettra d'être traité par GIMP au même titre que les autres, d'être disponible dans les préférences (utile en cas d'installation de plusieurs logiciels de ce type pour sélectionner son préféré), etc.
Ce que nous avons fait avec darktable et RawTherapee n'est absolument pas un "contrat d'exclusivité". Tout logiciel de développement de RAW est invité à se joindre à la fête et à pouvoir communiquer avec GIMP pour le traitement des RAW.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Excellent travail.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 4.
En fait, c'est juste une page 404, donc n'importe quel page inexistante de gimp.org affichera l'animation. ;-)
Genre: https://www.gimp.org/bonjour
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: roadmap trop importante ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 7.
Ce n'est pas exclus, on en parlait lors de notre réunion Wilber Week (cherche "GTK+4" dans le lien).
À ce jour, GTK+4 n'est pas sorti et il ne faut donc pas mettre la charrue avant les bœufs, surtout que c'est encore vachement instable (par nature de pas être sorti!).
À suivre…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Une build !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 6.
J'avais noté une fois la liste de dépendances (obligatoires et optionnelles) pour quasi l'ensemble des options de GIMP sous Linux (il manque que webkitgtk mais c'est parce que nous nous basons sur une trop vieille version à cause de GTK+2, qui commence à disparaître des distributions depuis cette année), avec une Fedora 27:
À mettre en correspondance aux bons paquets sur une autre distrib.
Puis tu dois compiler toi-même libmypaint, babl, GEGL et enfin GIMP (dans cet ordre, sauf libmypaint qui peut être compilé n'importe quand tant que c'est avant GIMP).
L'ensemble du processus, compilation comprise se fait en moins de 30 minutes sur ma machine de ~5 ans (bonne machine néanmoins: i7, 8GB de RAM et SSD) et j'ai vu des compilations de GIMP vachement plus rapides sur de meilleures machines.
Voilà avec ça, je crois que ça devrait pas prendre trop de temps. :-)
Bien sûr, sur d'autres distributions moins à jour que Fedora, il n'y a pas à douter que tu devras probablement compiler d'autres dépendances (peut-être lcms2 voire libpng; il m'est déjà arrivé d'avoir à compiler Exiv2/GExiv2 mais ça date un peu et j'espère que toutes les distribs se sont mises à jour depuis) mais ça reste rapide (je pense que sur une distrib moderne, tu peux largement compiler GIMP et les dépendances absentes du système de paquet en moins d'une heure).
C'est pas compliqué. Je maintiens le flatpak officiel de GIMP sur flathub (mais c'est la version stable, pas de build dév; politique flathub). J'ai déjà les fichiers "manifest" pour un flatpak dev et un nightly et je mets à jour un dépôt privé pour ceux-ci que je fournis pour l'instant juste aux donateurs (et aux gens qui m'en font la demande en privé). La raison est que mon "serveur" est en fait un vieux desktop dans la cave de l'association LILA, qui peine à tourner (le paquet entier compile en 24h dessus, alors qu'il compile en moins de 2h sur flathub — c'est plus que ce que je disais plus haut, mais y a plus de dépendances à compiler dans ce cas là et c'est surtout à cause de webkit qui prend à lui seul 99% du temps de compilation!), tellement vieux qu'il a aidé à trouver et tester un bug de flatpak pour des vieux x86 sans SSE (de mémoire)! Donc je peux pas m'en servir pour soutenir la charge de millions d'utilisateurs de GIMP qui veulent la dernière version.
Je recherche donc une solution. On va peut-être pouvoir fournir ce dépôt sur les serveurs de GIMP mais c'est pas encore clair/sûr (je n'ai pas l'accès perso aux serveurs de download de GIMP; et volontariat, tout ça, j'ai du mal à chopper l'info auprès de ceux qui ont l'accès).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: roadmap trop importante ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 8.
On l'utilise sur de la petite prod (utilisation quotidienne mais par une personne) depuis environ 2 ans.
C'est en effet très stable (mon object n°1).
Ensuite il faut garder en mémoire que ça reste une version de développement quand même et nous on peut se le permettre plus facilement car je suis là. Il m'est arrivé (une unique fois) d'avoir à "sauver" des fichiers XCF corrompus par un bug. Un artiste non-codeur seul n'aurait vraisemblablement pas pu le faire. Mais de manière général, c'est vrai pour toute production de film (récente, donc avec utilisation de technos numériques). Si tu regardes les génériques de tout film, y a toujours des équipes de développeurs (principalement pour développer les logiciels internes, je pense, mais on peut imaginer qu'ils seront aussi présent pour sauver des fichiers en cas de bourdes et qu'ils peuvent aider les artistes ponctuellement au besoin).
Nous on est juste la version réduite avec équipe de 1 artiste + 1 dév. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Excellent travail.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 3.
Oui, c'est une bonne évolution design cette illumination. Ça a été codé par un nouveau développeur super actif depuis un an (Ell), qui est apparu et soudain s'est mis à contribuer plein de code de super niveau. Ça fait plaisir.
Oups! En effet, c'est l'adresse sur le site testing quand la news était encore en brouillon. Le bon lien:
https://www.gimp.org/news/2017/12/12/gimp-2-9-8-released/
Si un gentil modo pouvait mettre à jour!
Eheheh. Oui ça c'est un petit cadeau de ZeMarmot aussi. ;-)
On a contribué cette animation pour la page 404 y a quelques temps en profitant de l'occasion pour découvrir les animations SVG (il me semblait avoir fait un journal à ce sujet, mais je le retrouve pas).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: roadmap trop importante ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 10. Dernière modification le 15 décembre 2017 à 02:24.
Je crois que cette phrase de mon article répond à ta question:
En gros, une entreprise (ou autre entité unique qui gère un logiciel avec des employés) va avoir sa roadmap interne et elle priorise plus facilement certains trucs. Ce n'est pas forcément mieux pour tout. Cela peut d'ailleurs provoquer des conflits avec la communauté quand certains aspects sont trop strictement contrôlés par cette entité, voire quand des refus (ou non-intégration sans refus clair) de fonctionnalités se produisent sans raison claire (par exemple, le rapport de bug de la fonctionnalité WebP dont je donne un lien plus haut vers le bugzilla de Mozilla est à un moment complètement parti en vrille car il y a des patchs depuis plus d'un an et beaucoup de gens attendent que Mozilla finissent la revue et l'intègre; au final le bug est passé lecture seule pour stopper la montée en troll).
Ils ont des employés, ils ont une roadmap probablement assez directive, ils s'y tiennent, et parfois s'ils ont le temps, ils se permettent de regarder un peu ce que fait la communauté.
Dans le cas de GIMP, c'est complètement différent. Pourquoi? Parce qu'y a aucun manager pour dire "c'est la roadmap, c'est comme ça, vous obéissez", et aucun employé pour suivre cette roadmap (qu'il peut discuter, mais au final s'il veut garder son job et que ses arguments sont refusés, il suivra). La "roadmap" de GIMP est donc totalement fluide et cible mouvante. Si tu préfères, on peut presque dire qu'il n'y a pas vraiment de roadmap (dit-il en donnant un lien). Elle est "presque" faite après coup. Ou plutôt puisqu'on se base quasi-essentiellement sur le volontariat, elle dépend des contributeurs du moment. Si y a un contributeur très impliqué qui un jour décide que telle fonctionnalité est sa priorité, alors cela rentre plus ou moins naturellement dans notre roadmap. Bon sauf si la dite-fonctionnalité est totalement tordue et que les autres dévs la refusent… en particulier le mainteneur qui aura le dernier mot (il y a quand même une "vision" du logiciel, disons qu'elle est plus fluide que dans un logiciel commercial).
Pour 2.10, le seul vrai item de la roadmap initiale selon moi, le fil directeur, c'était — je pense — le port de GEGL. Quasiment tout le reste, c'était des choses qui sont simplement arrivées naturellement pendant ce port car des gens (les dévs core ou des contributeurs externes) ont proposés ces améliorations. Quasi rien de ce que vous lisez dans cette news n'était initialement prévu (du moins, pas noir sur blanc comme un plan clair et net).
Le port GEGL en particulier a pris beaucoup de temps car c'est un sujet compliqué, et comme tu le dis, y a peu de développeurs. Lors de mes premiers builds (fin 2012, quand j'ai commencé à contribuer avec quelques patchs mineurs), le gros du port vers GEGL avait déjà été fait, mais GIMP 2.9 était tout simplement inutilisable au quotidien. Les opérations et surtout la peinture sur canevas était incroyablement lentes (tu faisais un trait puis tu allais faire un café le temps que ça apparaisse, ou presque ;p). Les choses se sont progressivement améliorées mais cela a pris du temps. Pendant ce temps là, quand les gens proposaient des patchs pour des nouvelles fonctionnalités super cools, ben le projet allait pas les refuser (sinon les gens proposent plus de patchs et y a pas de nouveaux dévs!).
En gros, tu ne peux pas refuser des fonctionnalités en demandant aux gens de bosser sur autre chose. Si un gars nous propose un patch géniale sur une fonctionnalité révolutionnaire, tu ne vas pas lui dire "ah c'est pas dans notre roadmap, désolé. Par contre, on remarque que tu es un développeur doué. Tu voudrais pas plutôt coder sur GEGL ou le port de GEGL dans GIMP?". Tu fais ça, le gars se barre (en gueulant ou silencieusement suivant les tempéraments), tu entends plus parler de lui et tu viens de tirer un trait sur ta fonctionnalité révolutionnaire.
Par contre, si tu te dis "c'est vraiment trop cool, faut qu'on intègre ça", ben tu te prends un peu de temps pour faire de la revue, commenter le code, demander des corrections, puis l'intégrer, probablement rajouter du code autour pour rendre le truc encore plus génial, etc. Au final, oui tu as utilisé du temps (qui peut-être aurait pu être utilisé pour le port de GEGL… ou pas! On rappelle: volontariat, les gens bossent sur ce qu'ils veulent), ça n'a pas fait avancer GEGL, mais tu as une méga fonctionnalité à la fin. Et le nouveau contributeur, peut-être même qu'il va rester dans le coin et proposer d'autres fonctionnalités géniales. Ou pas. Peut-être qu'il va vouloir aider au port GEGL. Ou pas. Peut-être qu'il va se barrer et on va jamais le revoir. C'est 90% des cas mais ça reste mieux que refuser la fonctionnalité et le gars se barre dans 100% des cas, et en plus on perd une fonctionnalité.
Et surtout, les nouvelles fonctionnalités n'impactent en rien (ou rarement) le port vers GEGL. Donc les refuser sous prétexte que ce n'est pas dans la roadmap n'a aucun intérêt. Refuser une fonctionnalité super cool car GEGL est lent, ou que d'autres parties de GIMP ne sont pas encore portées n'améliore pas ces aspects problématiques (ça n'empire pas non plus. En gros, rien à voir, fils unique, quoi…). Par contre bien sûr, on demande à ce que les nouvelles fonctionnalités soient bien basées sur GEGL (si pertinent). On veut pas intégrer une fonctionnalité basée sur 2.8 et devoir la porter après coup. Là oui, ce serait aller à reculons.
Je suppose que tu parles de sorties avec de nouvelles fonctionnalités. Non parce que sinon, GIMP a des sorties tous les 3 à 6 mois (on est à la version 2.8.22, ça fait 12 sorties depuis 2012, c'est plutôt fréquent!). ;-)
Donc oui, je suis d'accord avec toi; notre problème est qu'on fait partie de ces logiciels de la vieille époque qui ont des majeures, mineurs, avec une sémantique des versions, et en particulier: pas de nouvelles fonctionnalités dans une mineure. Depuis les logiques de sortie ont changés dans beaucoup de logiciels jusqu'au point de même faire sauter les logiques de majeures/mineures tout court (beaucoup de logiciels incrémentent simplement à chaque sortie).
On était bloqué par le port de GEGL. Comme je l'ai dit, pendant plusieurs années, c'était trop lent, ou trop imparfait, etc. Mais on est bien conscient du problème et on a décider de faire évoluer notre mode de sortie après la 2.10 car nous entamerons alors un nouveau port qui peut être à nouveau long: le port vers GTK+3.
Nous avons donc décidé et annoncé officiellement en début d'années que nous assouplirons la règle "pas de nouvelle fonctionnalité dans des sorties mineures" après GIMP 2.10.
C'est une évolution que je pousse depuis 2014 (voir par exemple ce compte-rendu de LGM, section "Les réunions GIMP"), et j'ai finalement réussi à faire progresser cela jusqu'à une officialisation.
Donc oui, GIMP aura des sorties de fonctionnalités plus régulières à partir de 2.10. Il y a de fortes chances que nous assouplissons encore plus la logique des versions après GIMP 3. En tous cas, c'est personnellement dans ce sens là que je pousse.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Excellent travail.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 8. Dernière modification le 14 décembre 2017 à 21:26.
Merci!
Clairement. On n'utilise plus la 2.8 depuis presque 2 ans. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pour Zemarmot on peut éviter les intermédiaires
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Vent de révolte sur Patreon qui profite à Liberapay. Évalué à 7.
En effet! LILA est une association loi 1901 à laquelle vous pouvez faire des dons ponctuels ou réguliers à "l'ancienne" (virements bancaires, etc.).
Merci Philippe pour être un de nos sponsors d'or et pour soutenir le projet depuis si longtemps! :)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: ZeMarmot ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Vent de révolte sur Patreon qui profite à Liberapay. Évalué à 7.
P.S.: quant à mon explication sur le travail apporté par chaque nouvelle plateforme, mon avis n'a pas changé. C'est toujours embêtant de gérer plusieurs plateformes. Déjà pour les nouvelles à dupliquer (même en copier-coller, faut en général refaire la mise-en-page) mais aussi pour le contenu "statique" qu'il ne faut pas oublier de mettre à jour partout quand quelque chose change, ainsi que la gestion des donateurs, etc.
Mais avec les changements de Patreon, on a perdu 14 patrons pour 71$ de dons en une seule journée (au moment où j'ai regardé, ça a peut-être empiré depuis hier), soit plus de 10% des dons. Et comme c'est pas la première fois qu'on me parle de Liberapay, ben on a décidé de tenter.
En plus, le fait qu'il n'y a pas de nouvelles (sur cette plateforme, il revient aux donateurs de se tenir au courant) ni de gestion des donateurs (car entièrement anonymes) simplifie beaucoup les choses par rapport à mes réticences plus haut.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: ZeMarmot ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Vent de révolte sur Patreon qui profite à Liberapay. Évalué à 2.
En effet, on vient de créer cette page liberapay pour ZeMarmot, mais on ne l'a pas encore annoncée en dehors de twitter.
J'ai passé une bonne partie de mon samedi à hacker (cf. https://git.gnome.org/browse/gimp/log/) et n'ai pas pris le temps de rédiger une news. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Un don simple
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le projet ZeMarmot a besoin de votre soutien. Évalué à 10.
Il est en fait possible de faire des dons via d'autres moyens que ces plateformes, notamment via paypal (contact chez libreart.info) ou même en virement bancaire ou chèque à l'association LILA dont le projet principal pour l'instant est ZeMarmot. Pour une liste de moyens de donation à LILA: https://libreart.info/fr/donate
Les plateformes sont intéressantes pour la gestion et aussi la visibilité (certaines personnes ont tendance à contribuer principalement parce qu'elle voit que beaucoup d'autres donnent), mais il est clair que les dons directs n'ont pas les frais de ces plateformes, donc c'est intéressant. Nous avons déjà quelques donateurs qui donnent ainsi (en ponctuel et même en récurrent avec virement mensuel).
En tous les cas, merci beaucoup pour ce journal. En effet je n'avais pas relayé l'appel aux dons. Déjà parce que quand je l'ai lancé, j'avais plus accès au compte linuxfr (même si j'ai rapidement retrouvé le mot de passe, genre le lendemain ou surlendemain); et puis j’étais un peu fatigué, faut dire ce qui est. En plus j'ai fait beaucoup de journaux sur linuxfr déjà, alors je me dis qu'à force, ça vous soûlerait! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Licence
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Le Frido : un livre, libre, de mathématiques pour l’agrégation. Évalué à 8.
C'est en effet une raison très valide. Il est tout à fait vrai que les Creative Commons n'ont pas cette notion de "source" et c'est souvent ennuyeux. Cela rend beaucoup d'œuvres théoriquement réutilisables pour modification beaucoup moins utiles, voire parfois carrêment inutilisables dans les faits pour modification. Du genre une vidéo sera quasiment toujours dans un format compressé avec perte (à tel point qu'on ne dit même plus "avec perte" pour les codecs vidéos tellement cela paraît évident); enfin je dis "quasiment" pour pas qu'on me ressorte un contre-exemple atypique, mais dans les faits, on exporte toujours des vidéos compressées avec perte pour les cas classiques.
Il existe toutefois des codecs sans perte, comme Huffyuv et beaucoup de codecs avec perte classiques ont une option pour le rendre sans perte (même si c'est quasi-jamais utilisé; la liste est assez longue tout de même d'après Wikipédia). Mais franchement, qui utilise ça? Dans le médical peut-être? (bon je suis sûr qu'y a des cas d'utilisation bien sûr, sinon ça existerait pas!)
Et puis même si les vidéos étaient sans perte, ce n'est pas pareil que d'accéder aux fichiers vraiment source, notamment pour changer les effets, la composition, les transitions, etc. Sans compter que pour charger un fichier vidéo sans perte (qui sera énorme. Des fois, même avec de la perte, selon les options de compression, des vidéos peuvent faire plusieurs GBs pour 30 secondes!), le traiter et extraire des parties sera déjà une gageure. Ce ne sera jamais pareil qu'un film découpé en sources multiples bien plus faciles à traiter.
Tout ça pour dire que oui, je suis d'accord, la notion de "source" comme référence pour les modifications manque cruellement dans les CCs.
Art Libre a également cette notion de source. Dans leur texte légal, ils appellent cela les "originaux".
Par contre ils ne définissent pas précisément ce qu'est un "original" (hormis que c'est à utiliser comme référence pour les modifications) et cela reste au choix de l'auteur. En particulier ils ne vont pas limiter les "originaux" à des formats faits pour la modification, donc pas de considération technique. Il reste donc possible pour un artiste de "présenter" un PDF comme étant l'original. Je dirais que c'est matière à controverse, mais dans tous les cas, c'est beaucoup moins précis que la définition FDL.
Pour nuancer mon propos, la FDL donne quelques exemples de "copies transparentes" (les "originaux" d'Art Libre) et je suis pas trop d'accord avec certains:
Le gras est de moi. Autant je suis tout assez d'accord pour la partie texte (on notera toutefois qu'ils incluent le PDF si désigné spécifiquement pour de la modification), autant pour les images, du PNG et du JPG? Je dirais que ça peut être acceptable, mais là aussi avec des cas. Le PNG, oui si l'auteur a travaillé en 16-bit par canal ou moins, sans calque de texte, sans vecteur nécessaire pour modification, etc. Le JPG étant compressé donc destructif par nature par contre ne me semble une source/copie transparente acceptable dans aucun cas (bon à part si on parle d'un JPG sorti directement d'un appareil photo, comme source aussi utilisée par le créateur de l'œuvre sous FDL; mais s'il la modifie, la source de son œuvre finale devrait être un XCF, ORA ou similaire).
Pour moi, la seule source acceptable sans conteste dans les 3 formats proposés est XCF. PNG le sera toutefois dans beaucoup de cas, soyons clair. Mais cela reste à préciser car il y a aussi beaucoup de cas où un PNG est tout sauf une source acceptable.
Donc au final, même la FDL reste assez large sur son acceptation de ce qu'est une source et laisse pas mal à l'interprétation de l'auteur.
Si depuis quelques années maintenant. Si vous utilisez LAL 1.3 et CC by-sa 4.0, vous pouvez mélanger des œuvres de ces licences. Voir aussi la liste de compatibilité de Creative Commons. De même votre travail dérivé peut lui-même être dans une des licences compatibles de la licence de l'œuvre source.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 3.
Dans la théorie tu as tout à fait raison.
Dans la pratique, avoir une organisation temporelle simple devant les yeux (classer les données par années et mois, et à l'intérieur par évènements dans mon cas; dans le cas de quelqu'un d'autre ça peut être une autre organisation, du moment que ça a un sens pour la personne, c'est ce qui compte; chacun son truc) me permet de retrouver des données auxquelles je pense plus (mais ça veut pas dire qu'elle ne m'intéressent pas; on oublie, même des choses qu'on aime!). C'est simple, c'est clair et surtout c'est visuel. Des tags, c'est une sorte de trucs un peu brouillard. D'ailleurs c'est marrant car la représentation visuelle la plus classique, c'est… un nuage de tags! Comme quoi… Souvent on va mettre en plus gros les tags les plus utilisés, mais cela n'est pas utile pour chercher. On ne cherche pas forcément ce qu'on fait le plus (cette représentation est plus utile pour les tiers qui veulent savoir les trucs dont tu parles le plus, donc bien dans un blog, mais pas pour soi).
Combien de fois j'ai cherché des trucs et je me dis, c'est quoi comme tag que j'ai mis? J'en essaie 2 ou 3 avant de trouver le bon. Le truc, c'est que dans la vie, on a plus que 3 ou 4 catégories à retenir. On en a des centaines. On se souviendra seulement de comment on taggue les trucs les plus courants qu'on fait quotidiennement. Mais sorti de là, c'est… le brouillard! Quand j'ai des dossiers physiques dans des classeurs, j'ai pas besoin de mémoriser le titre du classeur. Je sais qu'il est placé vers la droite de mon armoire, je lis 2 ou 3 titres, je le trouve, je le sors, et dedans j'ai rangé les choses par date ou alphabétiquement ou autre. C'est facile et je trouve ce que je cherche. Dans des dossiers numériques, c'est pareil. Si tous mes fichiers sont taggués par contre, ça m'obligerait à essayer de me souvenir des tags précis des milliers de trucs que je fais, dont certains une seule fois dans ma vie.
Le truc classique, c'est aussi d'avoir plusieurs tags qui sont en fait les mêmes car on se souvient pas bien de ce qu'on a écrit les fois précédentes (logiciels libres, logiciel libre, free software, FOSS, FLOSS… autant de variantes que je pourrais utiliser!). Franchement les blogs sont toujours plein de duplication de tags légèrement différents. Sans compter les fautes d'orthographe or de typo. Si en tapant vite, j'inverse des lettres, genre "onël", dans mon répertoire 2017/12/, ben quand je chercherai mes photos, je comprendrais tout de suite que c'était une typo, je corrige puis je regarde mes photos (ça ne m'a pris 1 seconde de plus pour corriger). Si les tags sont le seul moyen de retrouver mes photos par contre, je tape "noël 2017" et là… rien! Hop je me dis, ça y est, j'ai perdu les photos. Peut-être que je peux essayer de les retrouver en jouant avec d'autres tags, et avec un peu de chance je les récupère toutes et corrige tous les tags, mais ce sera pas juste quelques secondes que j'aurais perdu. Probablement plus 30 minutes.
En fait, si un jour les assistants personnels sont réellement intelligents, c'est moins grave. On n'a plus besoin de mémoriser le tag précis. On dira "je suis allé voir ce spectacle le mois dernier, tu peux me le retrouver", et il te retourner le truc taggué "danse" car c'était un spectacle de danse. Ou il corrigera tes fautes d'orthographe et de typo. Mais comme je l'ai dit, je ne crois pas que l'IA deviendra réellement intelligente un jour. On peut essayer de faire corriger des mots avec des dictionnaires et en comparant des distances de mot; on peut créer des catégories sémantiques; on peut améliorer de plein de façon après coup en découvrant les limitations au fur et à mesure. Mais ça ne sera jamais parfait. Enfin c'est ce que je pense. On verra dans 10 ans.
Quoiqu'il en soit, ce sont des trucs cools à étudier, à développer et à utiliser. Mais à ce jour, ça ne remplace pas mon organisation personnelle des fichiers. Ça la complète éventuellement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 10. Dernière modification le 27 septembre 2017 à 19:14.
Tout ce que vous dites tous est vrai. Mais pour moi, toutes ces choses là viennent en complément d'une organisation classique. Les reconnaissances de visage fonctionnent bien mais ne sont pas parfaites. Les dates sont toujours bonnes sur un portable mais voir une date erronnée sur un appareil photo dont on a enlevé la batterie trop longtemps est encore très courant. Le GPS est dispo sur certains appareils photo haut de gamme (donc cher) mais pas tous, loin de là. La catégorisation automatique (de visage, voyage, sujets, etc.) marche bien mais pas parfaitement. On en sait quelque chose, cela fait des années quand on a tous de la catégorisation dans les emails (antispam) et que les faux-positifs comme les faux-négatifs continuent à apparaître. Et ce, même chez Google (comme chez n'importe quel fournisseur).
Or ces quelques faux-positifs et négatifs même s'il y en a juste quelques uns sont déjà quelques uns de trop. Si tu demandes toutes les photos de noël avec Tati Marie et qu'il en manque quelques unes car la reconnaissance de visage n'a pas marché bien, ou bien parce qu'elles ont été prises avec un appareil qui n'avait pas la bonne date, ben ce sont potentiellement des photos perdues à jamais (mais qui continuent à prendre de la place sur ton disque) et tu n'en sauras jamais rien. Tu ne peux même pas aller les chercher à la main puisque dans ce monde où tout est taggué et reconnu automatiquement, toutes les photos sont en vrac dans un répertoire (ou plusieurs répertoires créés automatiquement) qui contient donc des milliers voire dizaines de milliers de photos au fil des ans.
Si par contre, après Noël, tu as mis toutes tes photos dans un répertoire
Pictures/2017/12/soiree-noel/par exemple, ça ne t'empêche pas d'avoir un assistant pour obtenir en un instant toutes les photos de Noël qui montrent Tati Marie, mais alternativement tu peux aussi jeter un œil toi-même dans ton répertoire qui ne contient que quelques dizaines de photos, et les faire défiler en quelques minutes (voire juste regarder vite fait l'aperçu dans le dossier). Garder un contrôle sur tes fichiers et ton organisation ne t'empêche absolument pas de les tagguer, d'avoir de la reconnaissance dessus, d'utiliser les méta-données quand elles sont présentes (et valides), et d'avoir un assistant électronique pour les retrouver. Mais au moins tu peux toujours revenir aux bases.Franchement mes emails, heureusement que j'ai des filtres (créés à l'ancienne pour une gestion à l'ancienne par répertoire) et pas juste une organisation automatique (gmail fait ça maintenant l'organisation automatique, ça marche globalement mais y a plein d'erreurs). De même heureusement que je regarde encore de temps en temps la boîte spam car je retrouve régulièrement des emails valides (encore une fois, sur ma boîte principale auto-hébergée comme sur ma boîte gmail que j'utilise pour des contacts par exemple lorsque je veux pas leur donner mon email principal immédiatement; là par exemple je viens de jeter un œil et j'ai découvert une réponse d'un imprimeur à qui j'avais demandé un devis la semaine dernière! Je pensais qu'ils n'avaient pas répondu mais en fait ça a fini en spam… heureusement que j'ai vu. Et on parle de Google).
Donc oui tous ces assistants, ces catégorisations automatiques, etc. c'est vraiment super cool. Ça aide. Mais ça ne remplace pas l'organisation manuelle à ce jour. En fait je vais même oser le dire: je pense que ça ne remplacera jamais totalement une organisation manuelle pour la simple raison que l'intelligence artificielle… n'est pas de l'intelligence! C'était ma spécialité à l'université et en fait c'est juste des stats principalement. La plupart des algorithmes qu'on trouve extraordinaires (réseaux de neurones, filtres bayésien, modèles de markov cachés… un peu tout type d'algo utilisés en reconnaissance de forme ou en décision…) sont dérivées de théories probabilistes et statistiques. Or s'il y a une chose dont on peut être sûr, c'est que des méthodes statistiques ne seront jamais vraies dans 100% des cas; mais dans la plupart, oui. C'est un peu la définition même de ce que sont les statistiques.
Alors certes je n'ai plus vraiment étudié l'IA depuis la fac. Qui sait, peut-être que dans certains labos, ils sont super proches de donner la conscience aux IAs qui penseront vraiment d'elle même et pas avec des stats (mais ce jour là, je suis pas sûr qu'elle seront jouasses d'être nos "assistants personnels", nos esclaves en somme). Si ça arrive, j'aurais eu tort. Car à ce jour, je ne crois pas que ça puisse arriver, justement car j'ai vu, étudié et implémenté ce genre de trucs et que pour moi, c'est tout sauf intelligent (enfin les humains qui ont créé ces systèmes sont intelligents, pas les logiciels). Et je doute vraiment qu'on arrive un jour à créer une vraie conscience (je sais, c'est à la mode de dire l'inverse et d'avoir peur de la révolte des ordis).
Conclusion: oui à tous ces trucs pour nous aider, mais non ça ne remplace pas une organisation humaine en plus en tous cas dès que les données sont considérées un tant soit peu importantes et qu'en perdre un peu régulièrement n'est pas acceptable.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et synergy ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 4.
Je me rappelle que quand j'avais testé Wayland, des trucs qui n'étaient pas censé marcher marchaient (mais je ne saurais plus dire quoi). Et quand j'en avais parlé avec un dév Wayland, on me disait que c'était sûrement normal pour une application X (GIMP utilise encore GTK+2, donc n'est pas un client Wayland), qui passait donc par XWayland, ce qui contournait des restrictions Wayland.
Peut-être est-ce ce qui t'arrive et peut-être ce contournement des restrictions a-t-il été corrigé depuis dans les versions suivantes (ce qui explique que d'autres n'ont plus ce comportement dans des versions plus récentes).
J'aimerais bien aussi. Cela fait partie de ces choses où j'ai découvert à GUADEC que certains autres développeurs n'avaient pas du tout la même vision que moi. Pour certains, les extensions sont un hack qui ferait mieux de ne pas exister. Pour d'autres (comme toi et moi), c'est super important et il faudrait donc créer une API stable.
Je pense que la seule chose qui manque est une personne qui prenne le sujet en main, crée une API publique et surtout la maintienne dans le temps. Le fait est que si la plupart des core devs ne considère pas l'API comme devant être publique, alors ils n'ont aucune raison à se faire chier à ne pas la changer quand ils ont besoin.
Ce sont les gens qui font le Logiciel Libre. Tout ce qu'il faut, c'est donc des gens qui poussent dans la direction que tu veux (et ça peut être toi-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: Et synergy ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 2.
Je ne sais pas. Ma connaissance de Wayland est très limitée et s'arrête un peu à ces utilisations de base. Une appli peut/pourra-t-elle demander à ne pas apparaître dans une capture d'écran? Est-ce prévu? Aucune idée. Mais ça pourrait exister, je pense, oui (opinion à prendre avec des pincettes. N'allez pas dire que quelqu'un vous a dit que c'est prévu ou je ne sais quoi! Je ne suis Wayland que de loin).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 4.
Quand il parle de "grand public" qui fait des commits/du versionning, ça me fait penser aux gens dans les bureaux (donc pas le grand grand public, mais quand même pas mal de monde) qui nomment leurs fichiers
nom-de-fichier-30-01-2017.odt, en gros avec une date. Cela leur permet de revenir en arrière à divers points dans le temps s'ils ont fait une erreur, effacer des trucs sans trop de peur, etc. C'est un peu le commit du pauvre quoi. Ces gens font du versionnement sans s'en rendre compte. C'est d'ailleurs assez marrant car il me semble que la plupart des logiciels de traitement de texte et tableur ont du versionnement intégré de nos jours (on peut faire des snapshots directement dans le même fichier), mais très peu le savent/l'utilisent. Tiens encore y a quelques jours, pour un projet quelqu'un m'a donné un fichier tableur imprimé et le nom du fichier était noté en haut de page. Sans surprise, la date était dans le nom de fichier. Bon ensuite je sais pas si c'est de cela qu'il parle (première fois que j'entends parler de "GED" mais un tour sur Wikipédia me fait dire que c'est autre chose).On va aussi faire des commits en modifiant des images. Les personnes habituées, voire qui ont déjà perdu des données, vont souvent sauvegarder leur travail à diverses étapes.
Etc.
Donc il n'a pas tout à fait tort, même si je ne dirais pas que c'est tout le monde non plus. Quant à automatiser cela pour les gens, l'exemple du traitement de texte/tableur est assez symptomatique du fait que même lorsque les fonctionnalités existent, les gens ne les utilisent pas forcément. Ils reviennent aux bases qu'ils connaissent: diverses versions du même fichier côte à côte et visible dans un répertoire.
Au moins un des designers GNOME (Jimmac) pense aussi ainsi, du moins y a un an, la dernière fois qu'on s'est vus. On a eu une discussion à ce sujet et perso je ne suis pas convaincu. Ne pas avoir de concept de "sauver les fichiers", c'est aussi ne pas avoir de concept de répertoire, voire de ranger tout court, ni de nom de fichier. En gros, y a plus vraiment de concept de fichiers. Pour moi, les téléphones sont l'exemple parfait de cela car c'est la première tentative réelle de la disparition du concept de fichier. Au final, les gens font constamment des photos par exemple, et le jour où ils veulent t'en retrouver une, ils se mettent à scroller comme des malades: "attends, c'était y a pas longtemps. Hmmm… je pense que c'est avant d'aller ici… ah attends j'ai dû passer, c'était clairement après ça…" (au bout de 10 minutes, soit ils ont trouvés, soit ils ont abandonnés en te disant que de toutes façons, c'était pas si important). Franchement c'est pas un type d'organisation des données que je veux voir apparaître dans mon ordi principal.
Cela ne peut marcher qu'avec une certaine rigueur, en taggant ses données immédiatement dès qu'on la crée. Mais au final tagger pour recherche ultérieure ou sauver avec un nom de fichier et dans un répertoire donné, quelle différence? Très vraiment. Si on se souvient plus comment on a taggué, on retrouvera pas la donnée, de même que si on se souvient plus on l'a mise. Dans les deux cas, un peu de rigueur est nécessaire.
Alors j'espère qu'on ne verra pas ces disparitions de concept trop rapidement dans GNOME. Ensuite je peux être surpris, qui sait! Peut-être arriveront-ils à le faire avec un design génial.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et synergy ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 10.
GIMP fait toujours des captures d'écran. Simplement il y a eu un intervalle entre les premiers OS sous Wayland et la mise à jour nécessaire de GIMP pour Wayland (pour être plus précis pour GNOME Shell sous Wayland).
Maintenant c'est implémenté mais ce sera disponible dans GIMP 2.10 seulement.
Dans l'optique sécurité de Wayland, je trouve cette protection assez sensé. En gros, toutes les applications auront le droit de faire des captures d'écran (et pas seulement des applications privilégiées), mais elles doivent passer par une API dbus et ce sera le compositeur (ou Window Manager, je sais pas trop qui a la charge de ça) qui se charge de faire la capture pour l'application. Ce que cela signifie est notamment que l'application n'a pas d'accès direct et ne peut pas regarder l'écran en douce. Il doit "demander". Ce que va faire l'OS alors n'est pas d'interdire mais le faire en avertissant l'utilisateur (que ce soit par une popup, un flash de l'écran, un bruit… quelque chose, libre aux designers de décider). En gros, tu peux plus faire un screenlogger qui va faire des captures régulières de l'écran en "loucedé". On pourra toujours faire des captures, mais simplement si le compositeur/window manager est bien designé, il avertira l'utilisateur.
De même, en cas de capture d'une zone de l'écran, ce sera aussi le compositeur/window manager qui gèrera la récupération de coordonnées. Ainsi typiquement dans l'API de GNOME shell, l'application utiliserait la méthode
SelectArea, en conséquence de quoi le shell se mettra typiquement dans un mode interactif de récupération d'une zone rectangulaire (classiquement, le curseur change, éventuellement des instructions apparaissent, et l'utilisateur est invité à glisser la souris pour créer une zone rectangulaire). En retour de cette méthode dbus, des coordonnées sont retournées au programme si l'action s'est faite avec succès. Le programme peut alors appeler la méthode dbusScreenshotAreaavec ces paramètres. Il n'y a plus de code dans l'application pour la récupération de coordonnées (puisque l'application n'a plus de visibilité non plus sur sa position dans l'écran et ne peut évaluer cette info) ni pour la prise de capture d'écran ou de zone d'écran elle-même.Je trouve cela plutôt bien. La logique n'est pas d'interdire mais d'avertir l'utilisateur quand des actions à risque sont entreprises (capture d'écran, keylogging, etc.). Certaines choses sont encore impossibles mais cela ne veut pas dire que c'est fait exprès. Simplement que l'API n'a pas encore été écrite.
Pour moi, le seul problème embêtant est que ces APIs ne soient pas au niveau du protocole mais de chaque implémentation. Ainsi GIMP peut bien maintenant faire des captures d'écran sous GNOME Shell, mais pas forcément sous d'autres implémentations au dessus de Wayland. Cela nous obligera à tester diverses APIs jusqu'à ce qu'une marche. J'aurais préféré une API commune.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Darktable et Lightroom
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Portage de Darktable sous Windows. Évalué à 7.
Il y a effectivement des styles plus abruptes que d'autre. C'est aussi beaucoup car certains en ont assez de se répéter. Ce que je t'ai dit notamment, tu lis en gros la même chose dans les articles officiels (1 et 2) que je trouve posés, détaillés et bien argumentés (et non revêches).
Je fais beaucoup d'efforts pour être didactique et patient car je sais que ça manque parfois. Mais cela a un coût non négligeable, ne serait-ce que par le temps que ça me prend pour faire ce type de réponses, temps que je préférerais passer à coder. D'autres développeurs font le choix inverse, et je le comprends bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Darktable et Lightroom
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Portage de Darktable sous Windows. Évalué à 10.
As-tu un lien? On connaît assez bien les dévs Darktable. On les a rencontré lors de Libre Graphics Meeting et ils traînent sur le canal IRC de GIMP depuis longtemps (au passage GIMP utilise désormais Darktable et Rawtherapee comme greffons pour ouvrir les images RAW) et je peux dire qu'ils n'ont jamais été contre une version Windows. Par contre ils voulaient que ce soit bien fait. Et ça voulait dire avoir au moins un développeur Windows pour faire le taff. Ils n'avaient pas ça et ne souhaitaient pas le faire eux-même car c'était un boulot conséquent (imaginez bien qu'on parle de support pour un OS majeur!) alors qu'ils n'utilisent même pas le dit OS.
Je vais prendre un exemple que je connais bien mieux: GIMP. Depuis des années, on a quasi aucun développeur Windows, et même les patchs de passage sont rares. À comparer avec Linux, qui est l'OS de tous les développeurs qui restent et contribuent régulièrement et pour laquelle version nous avons aussi des patchs de passage très réguliers. Par contre effectivement je pense que si on faisait des stats, on a bien plus de bugs pour GIMP seulement reproduisibles sous Windows. En gros, GIMP sous Windows est bien moins stable et a beaucoup plus de bugs, mais n'a quasi aucun développeur. Les bugs, quand ils sont corrigés (après être restés des mois sans que personne ne les confirme car souvent tout ce qu'on peut dire, c'est qu'on ne peut reproduire le problème sous Linux), le sont des mois voire années après quand quelqu'un soudainement arrive à comprendre un problème sans le reproduire ou qu'on prenne du temps à installer une VM Windows pour tester/débugguer par exemple. J'en ai corrigé pas mal comme ça, et c'est vraiment contraignant, prend du temps, et est peu satisfaisant.
Depuis quelques mois, on a enfin un dév compétent sous Windows qui a l'air de rester dans le coin et qui nous fait des patchs réguliers. C'est bien mais soyons clair, c'est pas grand chose pour rendre GIMP sous Windows vraiment bon.
Notez que GIMP sous MacOS, c'est à peine mieux. On a un dév qui le maintient dans le peu de temps qu'il a (en plus il vient d'avoir un enfant) et beaucoup de gens qui se plaignent mais quasi personne se prend en main pour patcher (je me souviens même de rapports de bug d'un gars qui nous expliquait qu'il était un utilisateur pro de GIMP et que certains bugs étaient inacceptables car étant aussi développeur, il "savait" que c'était super facile à corriger mais refusait de le faire lui-même car il n'avait pas le temps). Tiens pour l'histoire, j'ai corrigé un bug MacOS y a quelques jours et comme je n'ai pas d'ordi Apple (ni la possibilité de lancer MacOS en VM ni même de cross-compiler, non pas car ces choses ne sont pas possibles techniquement mais parce qu'Apple l'interdit), ben je l'ai fait à l'aveugle en lisant des APIs et exemples sur le web, ai dû pousser un truc totalement à l'aveuglette et ai demandé au rapporteur du bug de tester pour moi. Je peux dire que c'est clairement pas une situation propice au travail de qualité!
Perso si j'étais bien payé, ça me dérangerait pas d'en faire beaucoup plus et d'essayer même de corriger tous les bugs Windows et MacOS. Mais je suis pas payé du tout, alors franchement la plupart du temps j'ai juste envie d'ignorer tout bug que je ne peux reproduire sous Linux car ça me prend 10 fois plus de temps qu'un bug Linux.
Au final sans développeurs suffisamment présents, ces 2 OS sont une plaie pour le développement. C'est facile d'expliquer "l'utilité" d'une nouvelle prise en charge d'un OS à ceux qui donnent vraiment du temps pour développer, mais je t'assure que ce n'est pas très pertinent, à part si c'est aussi accompagné d'une aide réelle au développement: c'est à dire en donnant de son temps aussi. Ça apporte certes plus d'utilisateurs, donc plus de visibilité, mais de mon expérience, proportionnellement très peu enclins à contribuer malheureusement. ;-(
Voilà, j'espère que je suis un peu plus clair sur le "prix" d'un tel développement. Mon but n'est pas d'être abrupte mais d'expliquer leur rejet (totalement compréhensible) depuis des années. Compiler pour Windows n'est pas un problème, mais la prise en charge réelle, c'est autre chose. Si tu as eu l'impression que les développeurs se sont moqués de toi, ma supposition est que tu as mal compris ou que tu l'as mal pris et donc le sens a changé dans ton esprit. Ou alors ils étaient dans un mauvais jour, ça peut arriver à tous. Parce que non, ils n'ont jamais été contre Darktable pour Windows, par contre oui les dévs du moment ne voulaient pas le faire eux-même car ils n'utilisent pas cet OS, tout simplement. Et on peut difficilement leur en vouloir pour ça. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Typos
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Pythran 0.8.2 — compilation de noyaux scientifiques écrits en Python. Évalué à 8.
Il manque aussi un 's' à:
:-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vice amiral mais pas futé
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Revue de presse de l’April pour la semaine 35 de l’année 2017. Évalué à 10.
Alors j'imagine que tu sors d'une grande école, donc je ne veux pas te fâcher… mais je suis pas du tout d'accord avec toi. La compétence n'a rien à voir avec ton école. Être un bon dirigeant n'a non plus rien à voir avec ton école. D'ailleurs ça tombe bien, j'ai un super contre-exemple à ton affirmation! :-) Le vice-amiral Coustillière sort de l'École Navale (promotion 81), une des 4 grandes écoles militaires. Donc si on s'arrête à ton affirmation, alors embaucher Coustillière aurait dû éviter l'écueil de l'avoir embauché. :P
Plus sérieusement, y a cette vision totalement erroné et terrible que les grandes écoles, c'est l'élite de la nation. D'ailleurs dès la prépa, c'est le discours qu'on te sert régulièrement (je trouve cela à vomir avec le recul). C'est terrible et ça forme surtout beaucoup de gens hautains et suffisants (pas tous heureusement, mais beaucoup), bien que sans compétences exceptionnelles. Des gars sortis de grandes écoles qui sont vraiment nuls, j'en ai vu plein. Attention, je dis pas non plus qu'il y a un lien de cause à effet non plus. Simplement des gens qui ne travaillent pas bien, de même que des gens extrêmement compétents, tu en as plein partout, et cela ne dépend juste pas de l'école.
J'ai travaillé avec des développeurs très doués, dont certains qui n'ont même pas fait d'études supérieures du tout! Ils ont simplement commencé à travailler plus tôt, et ça leur confère même une sacré avance (franchement on apprend 10000 fois plus en "faisant" qu'en écoutant des cours ou avec des TPs de 2h qui survolent des concepts).
J'ai aussi connu le coup du petit jeune qui sort à peine de grande école, genre Polytechnique, et qui est direct dans un poste de consultant pour "changer les choses". Comme c'est ce pour quoi il est embauché… ben il essaie de changer les choses, quoi. Il ne connaît rien à comment ça marchait jusque là, ce qui marchait moins bien et plutôt bien, mais il change, c'est tout… Il fait virer des gens, fait des changements de postes, fait des changements d'outils, crée des réunions constamment qui empêche de faire le vrai travail, rend la vie terrible et donne envie aux gens (qui étaient heureux de leur boulot jusque là) de démissionner.
Donc non, franchement non. L'école n'a rien à voir avec la compétence. Et être dirigeant ne doit surtout pas nécessiter de sortir d'une grande école. Il y a des bons en grandes écoles comme des mauvais. De même qu'il y a des bons en université comme des mauvais. De même pour les sans-diplômes! Et non, je ne considère même pas qu'il y a des "tendances". La seule raison pour laquelle on aura plus de gens de grandes écoles en haut poste en France est justement car beaucoup vont penser ainsi et vont donc embaucher avec de tels critères (absurdes, selon moi), ce n'est donc pas une preuve.
Enfin voilà, je veux pas donner l'impression d'être contre le principe des grandes écoles. Mais je pense vraiment qu'on s'en est créée une vision totalement erronée en France.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Licence?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal --== GUIDE DE L'ADMINISTRATEUR LINUX ==--. Évalué à 10.
Tout à fait! C'est un point qui étonne toujours quand on explique que le code sous BSD reste sous BSD même s'il est au milieu de code GPL (par exemple). On m'a demandé de donner un cours invité à l'université il y a quelques mois, dont un sur la "gouvernance du Logiciel Libre" où j'ai parlé rapidement de licences… En réponse à une question, j'ai évoqué ce point que les licences d'un code ne changent pas (sauf avec permission explicite bien sûr, comme MIT qui en effet permet le "sublicense") et les professeurs eux-même étaient étonnés et étaient persuadés que j'avais tort car cela va à l'encontre de la simplification des licences que tout le monde entend.
Mais en fait, c'est très simple: c'est du droit d'auteur. Si on est l'auteur (ou l'ayant-droit) d'un code, on est le seul à avoir le droit d'y mettre une licence. Or donner l'autorisation à quiconque d'utiliser ou modifier son code dans un autre code, quelque soit la licence de cet autre code, ne signifie pas qu'on donne l'autorisation d'un changement de sa licence. On se retrouve simplement avec un mix de licences dans le code final.
Il suffit de se référer à la base de ces licences, le droit d'auteur/copyright, la loi en somme, pour que cela paraisse juste évident.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]