Sortie de GIMP 2.10.28 et nouvelles autour du projet

Posté par  (site web personnel, Mastodon) . Édité par Ysabeau 🧶 🧦, Pierre Jarillon et Benoît Sibaud. Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes :
75
4
oct.
2021
Graphisme/photo

GIMP 2.10.28 est sortie. Il s’agit d’une version corrective principalement. Nous focalisons l’ajout de nouvelles fonctionnalités principalement sur les versions de développement (2.99.x).

Note : les esprits vifs auront remarqué que nous avons sauté GIMP 2.10.26. Un bug de fichier s’y est glissé et nous nous en sommes rendu compte après avoir estampillé la version dans le dépôt de sources. Nous ne recommandons pas de compiler et d’utiliser GIMP 2.10.26.

Les grands axes

  • Des corrections de bogues, notamment pour Windows ; voir ci-dessous pour les détails.
  • L’ancrable Tableau de bord prend maintenant en charge l’affichage mémoire pour OpenBSD.
  • Amélioration des performances de GIMP sur macOS Big Sur. Ces dernières étaient déjà appliquées séparément et expérimentalement dans nos paquets macOS depuis GIMP 2.10.22. L’expérience ayant été concluante, nous avons intégré ces changements de code dans notre base de code principale.
  • Les greffons suivants ont eu des correctifs: C-source, DICOM, GIF, PS, Sunras, BMP, DDS, PSD, TIFF, Gimpressionist, l’afficheur de métadonnées et plusieurs scripts script-fu, de même que l’interpréteur script-fu lui-même.
  • Des problèmes d’accessibilité dans des thèmes ont été corrigés, tel que des retours visuels au passage du pointeur ou des couleurs problématiques.
  • Une nouvelle fonction Script-Fu (dir-make) permet maintenant de créer des répertoires depuis des scripts.

Sommaire

Pour une liste de changements plus complète, nous suggérons de se référer au fichier NEWS disponible dans le dépôt, ou encore de regarder les logs de développement.

Contributeurs de code : bootchk, Des McGuinness, Ian Martins, Jacob Boerema, Jehan, Lloyd Konneker, Luca Bacci, Marc Espie, Massimo Valentini, Michael Bazzinotti, Michael McLaughlin, Øyvind Kolås, saul, Simon McVittie et Stanislav Grinkov.

Contributeurs de thème : Kevin Payne et Stanislav Grinkov.

Contributeurs de scripts de compilation : Marco Spiess et Mario Daniel Ruiz Saavedra.

Nouvelles de l’équipe

Jacob Boerema est devenu co-mainteneur du dépôt du manuel (gimp-help) après en avoir porté les scripts à Python 3 et les avoir substantiellement améliorés.

Stanislav Grinkov est maintenant un développeur principal (avec accès au dépôt).

Des McGuinness et Lloyd Konneker ont reçu l’accès « reporter » dans notre forge Gitlab, ce qui leur permet d’aider à la gestion et maintenance des rapports en leur donnant droit de les labelliser, fermer, rouvrir, déplacer…

nmat a reçu l’accès « reporter»  également, mais sur le dépôt du site web (gimp-web) pour son aide constante dans la maintenance du site web.

Traducteurs

Des 82 langues dans lesquelles GIMP est disponible, 14 ont été mises à jour : catalan, chinois (Chine), croate, néerlandais, allemand, italien, lituanien, polonais, russe, slovène, espagnol, suédois, ukrainien et vietnamien.

L’installeur Windows, quant à lui, contient maintenant des traductions vietnamienne et lituanienne, le rendant disponible en 34 langues.

Traducteurs sur GIMP 2.10.26/28: Alexandre Prokoudine, Anders Jonsson, Aurimas Černius, Boyuan Yang, Daniel Mustieles, Hannie Dumoleyn, Jordi Mas, Luna Jernberg, Marco Ciampa, Milo Ivir, Ngọc Quân Trần, Matej Urbančič, Philipp Kiemle, Piotr Drąg, Rodrigo Lledó, Tim Sabsch et Yuri Chornoivan.

Windows n’est plus en manque d’amour 💕

Alors que les contributeurs Windows ont été une denrée rare depuis des années, ces derniers temps ont vu une activité plus soutenue autour de ce système, aussi bien dans le code de GIMP même que des bibliothèques dont il dépend. Ainsi plusieurs bogues de longue date ont enfin connu une fin heureuse :

  • Des boîtes de fichiers très lents : cela se produisait avec des périphériques réseaux lents ou inaccessibles, des périphériques portables déconnectés ou même dans des cas bizarres de lecteurs disquettes (oui vous lisez bien) fantômes, configurés dans le BIOS (sur des machines récentes sans un tel périphérique évidemment). GLib utilisait une fonction inappropriée du système Windows, laquelle bloquait lorsqu’on essayait d’obtenir des informations sur de tels périphériques. C’est maintenant corrigé (en utilisant d’autres fonctions) ! (#913, glib!2020)
  • L’ouverture de fichiers dans certains logiciels tiers faisait planter GIMP : apparemment ces applications éditaient le champ de gestion des fichiers dans le registre Windows, alors que GLib surveillait le champ (mais « mal », il faut croire). (#6780, glib!2205, glib!2210)
  • GTK générait de mauvais caractères pour certaines dispositions de claviers avec un moteur de saisie (par exemple des caractères alphanumériques étaient interprétés en katakana demi-chasse avec le moteur de saisie japonais). (#1603, gtk!3741)
  • L’export de fichiers TIFF verrouillait des fichiers TIFF à cause d’un bogue du créateur de miniature de Windows (Explorer.exe obtenait un verrou sur le fichier et ne le lâchait plus). Puisque Microsoft ne semble pas vouloir corriger ce bogue depuis tant d’années, il a été décidé d’utiliser une autre logique pour intégrer des miniatures dans les images TIFF, en ajoutant une « image de résolution réduite » ("« reduced-resolution image* ») en seconde page du fichier TIFF, tel que le propose la spécification du format, au lieu d’ajouter une miniature subifd. Cela contourne Explorer et son problème de verrou sous Windows. Bien sûr, cela signifie que si un programme tiers ne lit pas les étiquettes TIFF correctement, il pourrait vouloir ouvrir l’image miniature comme une page additionnelle malgré l’annotation explicite. Si vous rencontrez ce problème, merci de le rapporter aux développeurs de ces outils tiers en leur conseillant de vérifier le type SubFile des pages du TIFF (tel qu’indiqué dans la spécification TIFF). (#3740)
  • GIMP empêchait certaines applications de démarrer quand ces programmes devaient inspecter des répertoires donnés, car GLib lisait les répertoires avec des permissions inadéquates. En fait ce problème est même corrigé depuis GIMP 2.10.24 (#4594, glib!1976)
  • Les logiciels Windows qui utilisent des fenêtres invisibles (par exemple pour les raccourcis avec mouvements de pointeurs, la capture d’écran, etc.) étaient régulièrement en conflit avec GTK, ce qui cassait certaines interactions (des clics ou glissés-déplacés notamment). Nous avions déjà fait un patch de Ell depuis 2017, qui a été utilisé sur toutes les versions GIMP 2.10.x. Cependant la maintenance de GTK2 étant arrêtée, notre patch ne servait qu’à nous, pour nos binaires, ce qui était d’autant plus dommage que le bogue existait aussi dans GTK3 et supérieur et pouvait donc profiter à d’autres logiciels. Ce correctif a ainsi été retravaillé et même amélioré par Luca Bacci. Le problème est donc dorénavant officiellement corrigé dans GTK3. (#1082, gtk!2767)

Nous aimerions remercier plus particulièrement Luca Bacci, Jacob Boerema, LRN, Ell, et tous les contributeurs qui ont suivi de près les bogues Windows pour permettre ces progrès, parfois sur plusieurs années!

Et macOS ?

Du côté macOS, la vie est beaucoup moins rose, avec une activité lente, sinon moribonde.

Nous rappelons donc que GIMP est fait par vous, oui vous tous et toutes 👆 qui lisez ceci. Nous avions aussi peu de développeurs Windows à une époque, ce qui clairement a beaucoup évolué. Il ne tient donc pas à grand-chose pour que la même chose se produise pour macOS. Si donc vous souhaitez améliorer la situation, venez nous voir !

Vous aurez ainsi peut-être remarqué que le paquet DMG pour GIMP 2.10.24 est sorti avec plusieurs mois de retard. En fait même, la seule raison pour laquelle le paquet est sorti (tout court) est parce que j’ai pris sur moi et ai passé plusieurs jours pour mettre à jour et réparer notre build sur un serveur distant, petit bout par petit bout, péniblement. Je n’ai même pas d’accès local à une machine macOS moi-même ni n’ai le moyen de lancer et tester le build créé à distance ! Ce sont donc des conditions de compilation et de test des plus précaires, loin de ce qu’il faudrait pour assurer un binaire de qualité.
Si nos empaqueteurs habituels (ou de nouveaux) ne reviennent pas s’occuper de cette nouvelle version, peut-être referais-je la même chose, mais sans donner une date de sortie ni encore une fois promettre une quelconque qualité.

Il va de soi que ce processus de sortie pour ce système d’exploitation n’est pas tenable. C’est encore pire pour nos versions de développement 2.99.x pour lesquelles nous n’avons jamais sorti de version macOS (alors que nous en sommes à la version 2.99.6).

Si vous voulez que cela change, vous savez ce qu’il vous reste à faire : rejoignez-nous! 🤗

GEGL et babl

Comme d’habitude, cette sortie est accompagnée de sorties de babl 0.1.88, début juillet, et GEGL 0.4.32, le même jour que GIMP 2.10.26.

Dans GEGL notamment, les opérations suivantes furent améliorées:

  • distance-transform : nouveau paramètre edge_handling permettant de choisir comment traiter les zones hors-image (au-dessus ou sous le palier ; c’est-à-dire infiniment blanc ou noir respectivement) pour le calcul de distance. (par woob)
  • negative-darkroom : paramètre de boost de contraste et d’ajustement de l’illuminant, amélioration du modèle d’émulsion de colorant, amélioration de l’interface, plus d’options préconfigurées pour papier noir et blanc et quelques accélérations de l’opération (par JonnyRobbie pour les fonctionnalités et Richard Kreckel pour les optimisations)
  • fill-path : traitement en couleurs RGB en 32-bit flottant et en CMYK en utilisant ctx comme moteur de rendu. (par Øyvind Kolås)

Le système de test a aussi été amélioré par John Marshall.

Télécharger GIMP 2.10.28

Comme d’habitude GIMP 2.10.28 est disponible sur le site GIMP officiel (gimp.org):

  • Le paquet Linux en flatpak a été publié immédiatement après la sortie du source ; quiconque l’avait déjà installé a sûrement déjà reçu la mise à jour avec les gestionnaires de logiciels (graphique ou en ligne de commande). Sinon pour rappel, la ligne de commande pour mettre à jour: flatpak update org.gimp.GIMP//stable

  • L’installeur Windows a été disponible quelques jours plus tard sur le lien ci-dessus.

  • Le paquet DMG pour macOS n’est pas encore disponible (peut-être bientôt… ou pas).

Et ensuite?

Il n’est pas dit que de nouvelles fonctionnalités excitantes ne feront pas une apparition dans des versions stables 2.10.x futures, mais clairement nous nous focalisons plus sur le développement de GIMP 3, comme on le voit. Vous avez peut-être entendu parler de certaines des nouveautés à venir si vous nous suivez sur les réseaux sociaux divers et variés ou si vous testez les nightlies de GIMP.

Sinon ce sera la surprise de GIMP 2.99.8 (très bientôt !), je suppose ! 🤫🎁

N’oubliez pas que vous pouvez faire des donations au projet mais surtout aussi financer plusieurs des développeurs, comme un moyen de soutenir le développement de GIMP. Cela inclut Øyvind Kolås sur Patreon (mainteneur de GEGL) ainsi que notre projet associatif ZeMarmot, et donc moi en tant que développeur et mainteneur de GIMP, sur Liberapay, Patreon… comme nous maintenons officiellement GIMP depuis quelque temps.

Nous rappelons en effet que soutenir les mainteneurs de GEGL et GIMP qui souhaitent travailler à temps plein sur nos projets de logiciel libre, permettrait la pérennisation de GIMP. Merci à vous ! 🥳

Aller plus loin

  • # Greffon G'MIC pour GIMP 2.10.28

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 04 octobre 2021 à 08:37.

    A noter que l'installation de GIMP 2.10.28 sous Windows "casse" la compatibilité avec le greffon G'MIC (en dernière version stable 2.9.9). La "faute" a des changements de versions de fichiers .dll fournis avec le nouvel installeur de GIMP (mais on peut aussi comprendre qu'ils mettent à jour aussi ces fichiers dès qu'ils peuvent). Ces problèmes de .dll ont déjà eu lieu dans le passé. C'est assez pénible les .dll sous Windows :)

    Nous avons réussi à mettre en place un installeur de G'MIC en version de développement (3.0.0_pre), qui fonctionne néanmoins avec GIMP 2.10.28. Mais ça reste une version en développement, qui peut évoluer et pas forcément à conseiller pour la stabilité.

    En passant, petite suggestion mineure :

    • distance-transform : nouveau paramètre edge_handling permettant de choisir comment traiter les zones hors-image (au-dessus ou sous le palier ; c’est-à-dire infiniment blanc ou noir respectivement) pour le calcul de distance. (par woob)

    En traitement d'images, je crois que tout le monde appellerait ça boundary_conditions, c'est le terme générique pour définir la façon dont on traite les bords dans tous les opérateurs de traitement d'images. C'est du coup un peu dommage de ne pas utiliser les termes classiques du domaine, notamment dans une bibliothèque de gestion/traitement d'images…

    • [^] # Re: Greffon G'MIC pour GIMP 2.10.28

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      mais on peut aussi comprendre qu'ils mettent à jour aussi ces fichiers dès qu'ils peuvent

      Il y a de cela bien sûr (correction des bugs dans les dépendances notamment… comme le montre cette dépêche, c'est important car plein de problèmes qu'on a eu sous Windows ont été récemment corrigé dans des bibliothèques utilisées), mais pas seulement. Il y a aussi la question de simplicité. Pour Windows, on se base beaucoup sur le dépôt de paquets MSYS2 qui est vraiment un super projet qui simplifie énormément le packaging pour Windows (on voit la différence avec macOS par exemple où on doit compiler la chaîne de dépendance complète). Donc pour un nouveau paquet, on se prend pas la tête: on prend la version proposée par MSYS2 (qui est en général la dernière version car ils sont très réactifs). 🤷

      Dans tous les cas, c'est certain que le problème de dépendances réutilisées par les plug-ins n'est pas idéal. Ça fait partie des trucs que je veux améliorer, mais ça va prendre du temps. Plus qu'une solution technique (car je crois pas qu'on puisse en trouver, sauf à décider de ne jamais mettre à jour les dépendances, ce qui n'est pas une bonne idée), je pense que ce sera une solution procédurale (avec des périodes de freeze ou d'alerte et une plateforme pour aider les plug-ins à se mettre à jour dans les temps). C'est dans ma TODO 📝 depuis un moment.

      En traitement d'images, je crois que tout le monde appellerait ça boundary_conditions, c'est le terme générique pour définir la façon dont on traite les bords dans tous les opérateurs de traitement d'images. C'est du coup un peu dommage de ne pas utiliser les termes classiques du domaine, notamment dans une bibliothèque de gestion/traitement d'images…

      Merci. J'ai ouvert un rapport de bug: https://gitlab.gnome.org/GNOME/gegl/-/issues/295

      Je doute que ça soit mis à jour dans le nom de la propriété, à cause du besoin de stabilité d'API (à moins que GEGL ait un système d'alias permettant de renommer une propriété en gardant aussi l'ancien nom; mais je crois pas qu'y ait ça), mais on peut au moins rajouter le terme dans la description de la propriété.

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

      • [^] # Re: Greffon G'MIC pour GIMP 2.10.28

        Posté par  (site web personnel) . Évalué à 10.

        La réponse :

        Øyvind "pippin" Kolås @ok · 16 hours ago
        Maintainer
        For naming parameters that end up in a UI I think "boundary conditions" is similarly obscure to "abyss policy". "Edge" and "handling" are more basic words in english and understandable by a wider group of people than "boundary conditions".

        Pas tellement étonné de la réponse (connaissant un peu le personnage ;) ).

        Par contre, je suis un peu plus étonné de la justification donnée. Je pensais (vraiment) que GEGL (qui veut dire pour rappel "GEneric Graphical Library") était une bibliothèque de programmation "générique" pour la manipulation et le traitement des images (en tout cas, c'est comme ça qu'elle est présentée sur l'article wikipedia dédié).

        Apparemment, c'est donc plutôt une bibliothèque de traitement d'images destinée à être appelée uniquement depuis des interfaces graphiques ? C'est pas très vendeur :)
        Et si ce n'est pas le cas (ce que je crois), pourquoi les noms des paramètres des fonctions devraient être forcément les mêmes que les noms des widgets que l'on présente à l'utilisateur d'une UI ?
        On peut imaginer avoir plusieurs niveaux de spécialisation des termes utilisés en fonction du public auquel on s'adresse. Il y a des chances pour qu'un développeur utilisant GEGL soit en moyenne un peu plus calé en traitement d'images (et connaisse donc les termes classiques boundary_conditions ou border_conditions) qu'un utilisateur de l'interface de GIMP.

        Mais bon, j'admets que je chipote un peu :)

        • [^] # Re: Greffon G'MIC pour GIMP 2.10.28

          Posté par  . Évalué à 7. Dernière modification le 05 octobre 2021 à 18:04.

          A propos des plugins et scripts c'est dommage que le site registry.gimp.org ne soit plus en ligne. Sur ma distrib c'est encore gimp 2.8 et beaucoup sont compatibles.

          On peut le retrouver sur :

          https://web.archive.org/web/20180419120958/http://registry.gimp.org/

          J'en ai un en tête c'est le script pour corriger les franges violettes Purple Fringe Fix. Curieusement webarchive ne veut afficher qu'une page à la lettre p, je l'ai trouvé en remontant dans le temps il fait 4ko.
          https://web.archive.org/web/20180627171610/http://registry.gimp.org/node/185

          Sans trop rentrer dans les détails les objectifs photo souffrent tous plus ou moins d'aberration chromatiques de deux sortes latérale et longitudinale. La longitudinale cela provoque des halos violets dans les zones à fort contraste, c'est une tuerie à corriger, le script le fait automatiquement en 2 secondes, des fois il faut deux passages avec les réglages par défaut, il passe avec gimp 2.8.

          Un plugin que je ne citerais pas se compile avec gimptool, il marche avec la version 2.8 et ne se compile plus avec la 2.10.

          C'était du boulot à faire ces plugins ou scripts et je trouve que c'est une qualité de Gimp.

          Il y en a d'autres endroits où on peut trouver des plugins et des scripts, mais c'est un peu éparpillé :

          http://gimpchat.com/viewtopic.php?f=9&t=18452

          Tant mieux que gimp évolue, je me doute bien que la compatibilité avec les anciens scripts ou plugins ne peut pas toujours être conservée.

        • [^] # Re: Greffon G'MIC pour GIMP 2.10.28

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Pas tellement étonné de la réponse (connaissant un peu le personnage ;) ).

          En fait je comprends ce qu'il veut dire. Il a tendance à ne pas aimer les comportements élitistes et il est vrai que je le suis assez dans cette démarche. Il y a notamment l'élitisme du langage en général et du vocabulaire des professionnels en particulier (dans le cas qui nous concerne). Perso même en tant que développeur, sortir des noms pour tout et n'importe quoi, ça m'insupporte assez. Et allez qu'on va nommer des "design patterns" pour n'importe quel truc de base. Des fois, y a des branquignoles qui savent à peine programmer, mais qui te disent "ah oui faut faire tel pattern". Moi je suis là "mais de quoi il parle?" En fait il parle en général d'un truc super basique que n'importe quel dév aura lu voire écrit dans du code un jour et se sera pas fait chier à nommer (et la personne aurait pu expliquer ce qu'elle voulait dire en mots courants, mais au lieu de cela, va juste te sortir un "nom" que tu es bien sûr censé connaître, sinon c'est toi le branquignole à ses yeux). Donc au lieu de coder, tu vas avoir quelques dévs hipster qui vont disserter pendant 1h dans un blog post pour expliquer et promouvoir un pattern et il deviendra alors primordial de connaître ce terme (j'ai ouï dire que de nos jours, dans des entrevues pour certaines grosses boîtes, on te demande d'expliquer des patterns… juste donnez moi du code pas des mots pour brasser du vent! 🙄 Franchement quand j'entends ça, je suis heureux de pas postuler pour ces entreprises).

          En fait j'ai un apriori négatif sur le besoin de donner des noms compliqués à des trucs simples qu'on pourrait dire en français (ou anglais ici!). Alors je dis pas que c'était ton cas, tu veux juste donner un nom générique assez commun dans le milieu. C'est aussi ce que beaucoup de dévs font quand ils veulent juste nommer un concept. Mais ça donne tout de même matière à réflexion sur le besoin de nommer différemment que le langage ne le permet plus simplement, avec des mots que tous comprennent (même les non-experts et les non-natifs anglais). Et moi c'est ainsi que je comprends sa réponse.

          Par contre, je suis un peu plus étonné de la justification donnée. Je pensais (vraiment) que GEGL (qui veut dire pour rappel "GEneric Graphical Library") était une bibliothèque de programmation "générique" pour la manipulation et le traitement des images (en tout cas, c'est comme ça qu'elle est présentée sur l'article wikipedia dédié).

          On utilise beaucoup l'introspection dans GIMP, et dans GEGL aussi. Donc notamment cela nous permet de générer des GUI à partir juste d'une opération GEGL (sans aucun code spécifique à cette opération). GIMP fait cela par défaut pour n'importe quelle opération (si quelqu'un ajoute une opération personnelle, GIMP la verra et générera une GUI dans GIMP même; c'est extrêmement puissant comme pouvoir). Maintenant on peut aussi créer des interfaces plus avancées et spécifiques. On le fait pour certaines opérations quand on pense qu'elles méritent mieux que ce que l'interface entièrement introspectée propose. Néanmoins même là, on va beaucoup utiliser l'introspection pour les termes, descriptions, etc. Y a-t-il en effet réellement un besoin de nommer différemment les mêmes choses dans l'API pour dév et dans l'interface graphique? N'est-ce pas mieux d'avoir des termes bien compréhensibles en anglais pour tous?

          C'est aussi ça la généricité. Avoir une interface qui marche aussi bien pour le CLI, le code, des interfaces graphiques…

          Notons que comme je disais, on utilise ça pas mal dans GIMP. Dernièrement j'ai aussi implémenté assez massivement des capacités d'introspection et de génération d'interface graphique pour les plug-ins (qui n'ont alors pas besoin de long code GTK; quelques dizaines de lignes de code et on a une interface équivalent à 600 lignes de GTK → je rigole pas, c'est en gros le ratio qu'on a eu quand j'ai porté le plug-in JPEG sur cette nouvelle API). Là aussi, les plug-ins vont déclarer des procédures avec des paramètres et des descriptions, qui vont servir autant d'interface de programmation (comme des procédures qui pourront être appelés depuis d'autres plug-ins par exemple) que de textes pour une GUI.

          Apparemment, c'est donc plutôt une bibliothèque de traitement d'images destinée à être appelée uniquement depuis des interfaces graphiques ? C'est pas très vendeur :)

          Pourquoi cela ne pourrait pas être les 2? 🙂

          En fait, c'est même très clairement les 2 dans notre cas!

          Et si ce n'est pas le cas (ce que je crois), pourquoi les noms des paramètres des fonctions devraient être forcément les mêmes que les noms des widgets que l'on présente à l'utilisateur d'une UI ?

          Je renverse la question: pourquoi cela devrait-il être différent? Après tout, pourquoi un nom ou une description serait-elle bonne dans un cas mais pas dans l'autre? Si un nom décrit bien un paramètre en API, elle le décrirait aussi bien en GUI. 😉

          Mais bon, j'admets que je chipote un peu :)

          Je pense aussi. 😛

          Perso je connaissais pas ce terme. Quand je regarde une opération, je regarde ce qu'elle fait, essaie de comprendre son algorithme/code, me documente… comment s'appelle tel ou tel paramètre, de toutes façons, je l'aurai oublié 5 minutes après (mais je me rappellerai le code et la logique longtemps car c'est ça qui m'intéresse dans le traitement d'image, pas les noms!). Sincèrement je saurais déjà même plus redire de tête le nom que tu as donné ou celui actuel sans scroller pour vérifier (je rigole pas). Et ce même si c'est le sujet principal de notre discussion! Par contre, je me rappelle que l'on parle d'un paramètre pour décider comment considérer les pixels hors des bords de l'image d'entrée. Ça me suffit. Comment ça s'appelle dans l'API, de toutes façons, je revérifierai encore lorsque j'aurai besoin de l'utiliser.

          Enfin bon, pour moi, je pense que ça a du sens de rajouter le terme que tu proposes dans la description (c'est ce que je propose) puisque c'est effectivement un nommage classique, comme ça ceux qui connaissent feront le rapprochement en effet. Mais ça ne me gêne pas plus que ça que la propriété n'ait pas ce nom en principal.

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

  • # activité lente, sinon moribonde du côté de macOS…

    Posté par  (site web personnel) . Évalué à 10.

    Du côté macOS, la vie est beaucoup moins rose, avec une activité lente, sinon moribonde.

    J’ai évoqué récemment certains déboires que je rencontre en essayant de porter un logiciel GTK sous macOS, mais ce que je n’ai pas partagé, c’est mon impression globale de ce système.

    Le dévelopment et la maintenance d’application libre sur macOS est moribonde, plus que sous Windows d’ailleurs. Il fut un temps (autour de 2004-2008) où beaucoup de Linuxiens, Libristes ou juste Unixiens pavanaient avec des Mac et bossaient principalement sur macOS, y trouvant, disaient-ils, un Unix de qualité blablabla. C’était une époque où le canal IRC GCU squad éjectaient les gens qui se connectaient avec des Unix très barbus comme Irix car propriétaire et donc « sale », mais accueillaient avec bienveillance et complicité ceux qui se connectaient avec un macOS en prétextant que ce n’était que « terreux ». D’autres dénonçaient justement de voir tant de macs (sous macOS) dans les conventions et autre événements de développeurs Linux.

    C’est peut-être une bonne nouvelle que les bureaux Linux comme GNOME soient suffisamment matures pour que la tendance se soit inversée, mais aujourd’hui, trouver un contributeur bénévole de logiciel libre sous mac est une illusion. macOS ne semble avoir majoritairement plus que deux types d’utilisateurs : 1. des consommateurs qui ne font que consommer, 2. des développeurs qui ne font que du consommable à la mode Apple (l’écosystème des iPhones est passé par là, ainsi que les pratiques associées). Pour résumer, on pourrait dire qu’il n’y a plus qu’un seul type de développeur sous macOS, le développeur qui est payé pour développer sous macOS (ça peut très bien lui plaire, ça ne change pas le constat). Et il se trouve que le coût de développement n’est pas anodin, tellement macOS devient de plus en plus spécifique. Il ne reste donc que des utilisateurs qui s’attendent à avoir les logiciels gratuits qui existent sous macOS que sous Windows et Linux alors que la seule économie qui subsiste est celle du développement non-gratuit, et que la charge de travail exige un développeur payé. Peut-être faudra-t-il faire payer les logiciels libres sous macOS ?

    Aujourd’hui il y a deux-trois projets qui permettent de réduire franchement les coûts de maintenance de logiciel libre sous Windows et macOS. Des projets comme MSYS2/MingW sous Windows et Homebrew ou MacPorts sous macOS permettent de répliquer l’essentiel des méthodes de travail existantes sous Linux sur ces systèmes d’exploitation. Pour NetRadiant et Unvanquished. J’ai intégralement réécrit les scripts de compilation de release de NetRadiant, et j’ai réécrit une grande partie des scripts de compilation de release pour Unvanquished, et toute la partie compilation est orchestrée par les mêmes outils quelque soit l’OS : un compilateur GCC ou Clang, CMake, BASH pour les scripts et commandes, SSH pour donner les ordres sur les divers systèmes, et des bibliothèques communes installables via un gestionnaire de paquet. À aucun moment il n’est nécessaire de mettre en œuvre un process de développement spécifique à base de Visual Studio ou de XCode. Personnellement que ce soit Linux, FreeBSD, macOS ou Windows, je peux produire un build de NetRadiant avec un même script qui se connecte via SSH aux divers systèmes de référence et reposent sur les mêmes outils qui ont été portés sur ces systèmes.

    Mais le port d’application libres sous macOS semble relever uniquement de la pure générosité, réalisé parce qu’il y a des utilisateurs qui réclament. Il existe bien des ports de bibliothèques comme GTK, mais le soin apporté pour macOS est très loin derrière le soin apporté pour Windows, et évidemment Linux. Je l’évoquait dans mon commentaire, mais pour certains cas d’usage comme les surfaces OpenGL dans GTK, même la branche de développement de GTK4 ne permet pas encore de faire certaines choses que l’on peut faire sous Linux et Windows.

    De plus, je trouve macOS mal fini dans les angles (note: mon expérience se limite à Mojave pour le moment), quand je travaille avec macOS j’ai l’impression d’utiliser une distribution non-mainstream maintenue par une équipe sous-dimensionnée. Il y a certainement de très bonnes applications, mais le sous-système d’une part, et le bureau de base d’autre part (avec les logiciels de base comme le gestionnaire de fichiers) est très très loin du niveau de finition d’un GNOME sur une distribution établie comme Ubuntu (je ne pratique pas la variante spécifique du bureau d’Ubuntu donc je ne peux pas donner mon avis). Pare exemple pour certains types de composants installables de macOS il n’y a même pas de procédure de désinstallation permettant de garantir que le système est revenu à son état initial. Par exemple le gestionnaire de fichier est très primitif dans sa manière de gérer des choses simples comme des icônes : il n’est pas rare de voir des icônes de nouveaux documents se placer par dessus des icônes d’autres documents et non à la suite, il faut souvent jouer à la fois des ascenseurs horizontaux et verticaux ce qui est très inconfortable, et j’ai dû ajouter moi-même un signet pour accéder au dossier utilisateur de base (${HOME}).

    Bref, une activité lente sinon moribonde sur macOS ? je ne suis pas surpris. Il y a des utilisateurs très demandeurs sur macOS, mais les contributeurs utilisant cet système sont introuvables, le système devient de plus en plus spécifique, et les outils et bibliothèques sont souvent d’une moins bonne qualité sous macOS.

    Aujourd’hui, il me semble que pour un développeur de logiciel libre utilisant quotidiennement Linux et utilisant dans son développement des technologies courantes sous Linux, en terme de facilité de développement on a Linux, suivi de Windows (grâce à MSYS2/Mingw), et beaucoup plus loin derrière macOS.

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

    • [^] # Re: activité lente, sinon moribonde du côté de macOS…

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      J'ai pourtant eu l'impression qu'il y a encore pas mal de gens qui apprécient ces systèmes plein d'artifices https://linuxfr.org/news/interview-de-sebastien-rohaut-auteur-de-livres-notamment-sur-linux#comment-1817447 Mais ce sont donc des personnes qui ne participent pas par le portage du coup ?

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: activité lente, sinon moribonde du côté de macOS…

        Posté par  (site web personnel) . Évalué à 10.

        J'ai pourtant eu l'impression qu'il y a encore pas mal de gens qui apprécient ces systèmes plein d'artifices
        Mais ce sont donc des personnes qui ne participent pas par le portage du coup ?

        Mon expérience est forcément limitée à… mon expérience (haha), donc avec plein de biais. Mais j’ai également l’impression qu’il y a encore pas mal de gens qui apprécient ces systèmes (macOS), mais je ne vois que des personnes qui ne participent pas par le portage.

        Je vois surtout des gens réclamer. Pour NetRadiant et pour XQF c’est pareil. De temps en temps quelqu’un passe et demande « quand est-ce qu’il y aura un binaire macOS ? » et voilà c’est tout. Maintenant que j’ai énormément bossé la compilation pour Windows et pour macOS au profit de NetRadiant et que j’ai déchargé ma connaissance dans des outils que j’ai écrit, peut-être que je pourrai utiliser les mêmes outils pour porter XQF, mais ce serait vraiment par chance parce qu’à cause d’un autre projet j’ai dû bosser cela. Pour Unvanquished c’est comme si on en avait toujours eu un binaire macOS, donc je n’ai pas vu des gens réclamer un portage, par contre je sais que personne dans l’équipe de développement ne développe pour macOS. Historiquement, une des têtes du projet (la direction est un triumvirat) avait un ordinateur financé par un tiers dans un autre cadre, et dans cet autre cadre il réclamait systématiquement un mac pour une seule raison : l’intention de garder macOS en double-boot pouvoir compiler Unvanquished pour macOS à l’occasion. Nous avons en fait un collaborateur qui utilise macOS mais il ne contribue pas de code et ne contribue pas au portage.

        Je vais même dire, certaines personnes qui réclament un portage macOS pendant plusieurs années sans se décourager n’utilisent même pas macOS sur des macs, mais sur des hackintosh, c’est dire à quel point c’est ingrat. Je fais en partie le portage de NetRadiant pour macOS pour des utilisateurs de macOS qui montent eux-même leur bécanes et pourraient tout aussi bien utiliser Linux.

        Que ce soit pour Unvanquished, NetRadiant, XQF et d’autres outils, en 10 ans, je n’ai jamais eu à faire la revue d’un contributeur de code macOS réalisé par un utilisateur de macOS.

        Une exception que j’ai relevée, c’est l’outil Crunch qui sert à convertir des images vers un format optimisé pour les cartes graphiques. Historiquement je me suis préoccupé de ce que la bibliothèque embarquable compile et tourne sous macOS à cause de NetRadiant (pour pouvoir lire dans NetRadiant les fichiers produits) mais je sais que l’outil de conversion ne compile pas pour macOS. J’ai récemment identifié un fork de quelqu’un qui ne nous a jamais contacté et qui semble être un développeur de jeu pour iPhones travaillant sous macOS et qui semble donc avoir terminé le portage. Un jour je fusionnerai ses patchs, et ce sera la première fois de ma vie que je fusionnerai un patch de portage macOS réalisé par un utilisateur de macOS pour son propre usage, la première fois en 10 ans et une poignée de projet, et de la part de quelqu’un qui ne contribue pas à nos projets ni ne nous a jamais contacté et ne partage pas nos intérêts à part produire des fichiers images optimisés pour GPU, il ne s’agit pas de contribuer à Unvanquished, le moteur Dæmon, NetRadiant ou autre logiciel libre que moi ou certains lecteurs de LinuxFr pourraient vouloir utiliser directement.

        En comparaison, un développeur d’Unvanquished et du moteur Dæmon qui a un des plus haut taux de contribution et de compétence réunis utilise Windows et Visual Studio comme environnement de développement principal, autant dire que non-seulement Windows est pris en charge, mais même ce dont ont peut se passer est pris en charge. Pour NetRadiant je ne me soucie que de la compatibilité MSYS2 à-la-Linux, parce c’est tout ce dont j’ai besoin, mais pour Unvanquished et Dæmon, je sais qu’un contributeur peut tout faire avec la méthode Microsoft, on est au delà du nécessaire.

        Pour Unvanquished et macOS ? Eh bien… le moteur compile et le jeu tourne, c’est tout. Je dis bien que seul le moteur de jeu Dæmon. Depuis deux ou trois ans, il n’est plus possible de compiler le code du jeu pour une raison que personne n’a vraiment investigué. Cela ne nous pose pas problème puisqu’avec la technologie NativeClient qu’on utilise encore, les binaires du jeu exécutés par le moteur sont indépendant du système d’exploitation (pour faire une analogie, c’est comme avoir un binaire java proprement fait qui est sensé tourner sur la JVM dès lors que la JVM est portée sur une plateforme), donc on compile le code du jeu une fois pour toute sur un système pris en charge (comme Linux), et puis après on compile les binaires du moteur pour Linux, Windows et macOS. Personne n’a jamais tenté de corriger la compilation du « game code » sous macOS, on a reçu des réclamations mais personne pour ne serait-ce qu’identifier ce qui ne marche pas et faire un rapport plus détaillé que « ça ne marche pas ». Il est probable que ce soit lié à l’abandon du 32-bit par macOS car si on produit des binaires indépendant du système d’exploitation, pour le moment on produit toujours une spécialisation i686/amd64 (ça devrait être corrigé avec WebAssembly, on est en train de migrer de NaCl vers Wasm).

        Porter des logiciels sous macOS est très ingrat sur plein d’aspects, déjà les utilisateurs qui se manifestent sont vraiment, vraiment, vraiment rares, de deux, ils ne contribuent pas du portage, de trois, ils n’utilisent peut-être même pas de mac fabriqué par Apple ! C’est à se demander pourquoi faire tant d’efforts.

        Je me souviens quand il était difficile de trouver des contributeurs Windows, je me souvient que GIMP souffrait beaucoup avec Windows d’une situation similaire à ce que GIMP souffre aujourd’hui avec macOS. Je me souviens aussi quand Darktable ne fournissait pas de binaires Windows, quand j’ai lu la première annoncé de WSL (Windows Subsystem for Linux) j’ai tout de suite pensé que ce serait une excellente manière de faire tourner Darktable sous Windows, mais en fait Darktable est arrivé en natif sous Windows presque en même temps que WSL.

        Mais pour Windows, non seulement on semble désormais trouver plus (+) de développeurs, mais

        • on peut faire de la cross-compilation sous Linux et tester avec Wine;
        • MSYS2/MingW fonctionne très bien sous Windows;
        • une licence Windows 10 PRO coûte 10€ sur Amazon, le double boot se fait depuis toujours;
        • la virtualisation de Windows est très aisée sous Linux;
        • le fait de compiler un dépôt git sur un disque réseau depuis une machine virtuelle Windows fonctionne très bien;
        • la disponibilité de Mesa sous Windows et de son émulation logicielle (llvmpipe) rend très aisée le test de composants graphiques OpenGL avec une prise en charge complète même sans pass-through.

        Pour macOS:

        • il n’y a pas encore de cross-compilation fonctionnelle, ni de couche de compatibilité pour Linux fonctionnelle, un jour Darling peut-être ? (hu, le certificat est expiré);
        • officiellement la seule méthode pour développer sous macOS consiste à acquérir un matériel Apple, et ça coûte plus cher qu’une licence Windows ou Linux (haha).
        • l’installation de macOS sur du matériel non-apple n’est pas aisée, et ce n’est pas sensé être fait;
        • la virtualisation de macOS n’est pas aisée (même si ça a été grandement simplifié via ce projet OSX-KVM), et ce n’est pas sensé être fait;
        • les performances de compilation d’un dépôt git sur un disque réseau depuis une machine virtuelle sont désastreuse, avec SSHFS (non officiel) sur FUSE pour mac, on rencontre facilement des crash nécessitant de rebooter et certaines fonctionnalités de système de fichier ne sont pas implémentées, avec le pilote smbfs natif de macOS c’est un gel systématique de l’OS qui se produit en moins de deux minutes;
        • l’émulation logicielle d’OpenGL sous macOS semble ne pas dépasser OpenGL 2.1 (donc pré-OpenGL core).

        Un utilisateur de logiciel gratuit qui demande un portage pour macOS réclame que le développeur achète un mac et travaille sur mac comme environnement de développement, comme ça, gratos, rien de moins.

        Pour un éditeur de logiciel payant, ceci peut n’être considéré que comme des achats de fournitures particulières, peut-être moins chères que certains logiciels, mais pour un contributeur bénévole de logiciel gratuit, le coût de développement pour macOS est énorme.

        Donc bref, bravo à GIMP et Jehan d’être si généreux 👍, je ne doute pas que de tels efforts sont remerciés par beaucoup d’ingratitude, à commencer par « même pas un merci ». 😏

        Message spécial à Jehan : l’intégration des « Pipelines » Microsoft Azure est plutôt efficace avec GitHub et prend désormais en charge macOS (exemple) donc tu peux éventuellement envisager de « profiter du système » en poussant un clone du dépôt GIMP de git sur GitHub et de pousser ta branche de développement macOS sur github pour valider la compilation gratuitement à chaque push de commit. Après tu reviendras à ta solution actuelle pour produire le binaire distribuable. Alors GitHub, Azure, tout ça oui c’est pas très « logiciel libre » mais bon il s’agit de produire un binaire macOS à la base… C’est déjà très très très sale. 😜

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

        • [^] # Re: activité lente, sinon moribonde du côté de macOS…

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          il n’y a pas encore de cross-compilation fonctionnelle, ni de couche de compatibilité pour Linux fonctionnelle, un jour Darling peut-être ? (hu, le certificat est expiré);

          J'ai déjà vu quelques projets de cross-compilation mais je n'y ai jamais jeté plus qu'un œil, tout simplement car c'est pas légal, pas par rapport à la loi mais aux règles/CGU d'Apple qui interdisent d'utiliser des logiciels Apple sur autre chose que le matos Apple; le problème étant que tous ceux que j'ai vu faire de la cross-compilation macOS à ce jour le font en proposant de copier les SDK officiels. Or même si on a une licence, c'est à dire qu'on copie le SDK depuis une machine Apple officielle qu'on a acheté, on n'a quand même pas le droit de l'utiliser sur une machine non-Apple.
          C'est écrit explicitement dans les conditions d'utilisation (gras ajoutés par mes soins, notons aussi que ce sont les CGUs de la dernière version de l'OS mais on trouve le même texte dans les CGUs des macOS précédents, du moins ceux que j'ai regardés au fil des ans):

          1. Permitted License Uses and Restrictions.

          A. Preinstalled and Single-Copy Apple Software License. Subject to the terms and conditions of this License, unless you obtained the Apple Software from the Mac App Store, through an automatic download or under a volume license, maintenance or other written agreement from Apple, you are granted a limited, non-exclusive license to install, use and run one (1) copy of the Apple Software on a single Apple-branded computer at any one time.

          […]

          B. Mac App Store License. If you obtained a license for the Apple Software from the Mac App Store or through an automatic download […] you are granted a limited, non-transferable, non-exclusive license:

          […]

          (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use

          J. Other Use Restrictions. The grants set forth in this License do not permit you to, and you agree not to, install, use or run the Apple Software on any non-Apple-branded computer, or to enable others to do so.

          C'est plutôt clair. Ils répètent encore et encore que leur logiciel doit tourner sur du matos de marque Apple.

          Si ça n'avait pas été le cas, il y a longtemps que j'aurais ajouté la prise en charge de macOS dans mon propre outil d'aide à la compilation croisée, crossroad. Techniquement il n'y a aucune raison que ce soit compliqué. C'est uniquement légal: ils veulent interdire ce cas d'usage. Ben tant pis pour eux! Je vais personnellement pas prendre le moindre même micro-risque pour un éditeur qui veut pas de moi (pire qui semble prendre l'aide des développeurs de logiciel libre — car soyons clair, permettre de compiler sur Linux pour macOS, ce serait un énorme coup de pouce à cet OS — pour un comportement indésirable).

          Quand on compare à Microsoft, qui non seulement fournissent gratuitement des VMs Windows, explicitement destinées au développement, mais en plus disent clairement dans leurs propres GCU que la licence Windows (notamment les licences OEM) peut être utilisée en environnement virtuel à la place d'être l'OS principal, sans préciser que ça doit être la même machine d'achat, ou même une machine qui fait tourner déjà Windows en environnement principal:

          (iv) Use in a virtualized environment. This license allows you to install only one instance of the software for use on one device, whether that device is physical or virtual. If you want to use the software on more than one virtual device, you must obtain a separate license for each instance.

          Je le sais d'autant plus que j'en ai fait l'expérience officielle il y a plus de 10 ans, quand j'ai contacté le revendeur d'un nouveau portable pour leur demander de m'envoyer une copie ISO de l'OS parce que je voulais installer Linux à la place et pouvoir lancer Windows en VM (c'est à dire que j'utilise bien la licence pour un usage unique mais au lieu de le faire en OS principal, c'est en VM). Ça n'avait posé aucun problème, ils m'ont envoyé l'ISO immédiatement en disant que ce n'est pas un problème. Ce ne sont donc absolument pas des nouvelles règles.

          En gros, Microsoft sait au moins comment jouer fair-play avec les autres joueurs alors qu'Apple veut absolument se la jouer perso, n'accepte que de l'Apple sur de l'Apple et refuse toute autre utilisation. Ben moi, je vais pas prendre le moindre risque à essayer de cross-compiler pour macOS dans ces conditions alors que l'éditeur me l'interdit explicitement. Tant pis pour eux! Ils perdent des développeurs.

          La possibilité de cross-compiler pour Windows a fait énormément pour nos capacités à corriger des problèmes pour Windows (quand on avait peu/presque pas de dévs).

          Donc bref, bravo à GIMP et Jehan d’être si généreux 👍, je ne doute pas que de tels efforts sont remerciés par beaucoup d’ingratitude, à commencer par « même pas un merci ». 😏

          En général, on aura plutôt des "comment osez-vous?" - "ce n'est pas acceptable", etc. Franchement c'est ce genre de remarques et réactions qui est le plus décevant. Des gens qui ne font que réclamer et se plaindre.

          Bon ensuite certains remercient quand même. Et puis en vrai, les gens qui nous gueulent dessus et font des remarques désobligeantes (comme s'ils appelaient un support qu'ils payaient très cher), y en a même chez les Linuxiens… et plus souvent qu'on n'aimerait. 😕 Donc en fait, ce n'est pas une particularité macOS les gens qui se comportent comme des "clients mécontents" plutôt que des contributeurs constructifs d'une communauté.

          Sinon pour mettre un peu d'eau dans le vin, depuis quelques jours, on a enfin un nouveau contributeur macOS (y a une sorte de malédiction, on n'a jamais plus d'un contributeur macOS à la fois; en tous cas depuis les presque 10 ans que je contribue!) qui est enfin en train de faire marcher la compilation de la version de dév (il a déjà réussi localement et y est presque sur le serveur de build)! 🙌
          Il a même déjà contribué quelques patchs dans le dépôt des sources de GIMP!

          Et cerise sur le gâteau, y a un second contributeur qui a commencé essayer de bosser sur le paquet stable (pas fait grand chose, en dehors de quelques tests hier, mais c'est déjà mieux que rien). On verra. Peut-être rompra-t-on la malédiction macOS cette année!

          En tous cas, dans mon expérience perso, en plus du manque de dév et du blocage de l'éditeur Apple (qui veut pas qu'on fasse quoi que ce soit sans avoir du matos Apple, pour forcer tout le monde à en acheter à prix fort), j'ai aussi remarqué une autre constante: Apple casse régulièrement son système d'une mise-à-jour à l'autre. Je parle pas de bugs comme on peut tous en avoir, non vraiment de casser exprès pour faire évoluer la technologie.

          Autant on peut critiquer Windows sur le bordel de son système qui se base sur des couches de vieilles technologies (dont certains se plaignent), mais ça a en fait un effet de bord très désirable: Windows est à fond sur la rétro-compatibilité. Bien sûr, ce n'est pas parfait, mais globalement ils essaient de ne pas casser de vieux binaires ou vieilles APIs pour rien et cela rend le développement bien plus stable. Autant sur macOS, j'ai l'impression qu'il fallait corriger des choses presque à chaque sortie de macOS à cause de nouvelles incompatibilités avec la version d'avant. C'est d'autant plus lourd sans développeur macOS dans notre cas! Et surtout cela n'est pas du tout adapté à un monde professionnel (dans le sens "logiciel de type professionnel/logiciel métier", comme GIMP, et non d'amusement comme un petit logiciel pour s'amuser à gribouiller) qui a besoin de stabilité et de bases solides.

          Un contributeur (non-dév, qui travaille dans l'audiovisuel) de longue date de GIMP a un jour dit que pour lui, macOS était devenu un OS-jouet, où on ne peut plus rien vraiment faire de sérieux car l'éditeur ne cherche plus du tout à garder/aider les logiciels métier ni à avoir un semblant de stabilité (absolument nécessaire en environnement professionnel). Ben je crois qu'il a raison. 🤷

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

    • [^] # Re: activité lente, sinon moribonde du côté de macOS…

      Posté par  . Évalué à 1.

      suivi de Windows (grâce à MSYS2/Mingw)

      Aujourd'hui c'est encore plus simple avec WSL2.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: activité lente, sinon moribonde du côté de macOS…

        Posté par  (site web personnel) . Évalué à 9.

        suivi de Windows (grâce à MSYS2/Mingw)

        Aujourd'hui c'est encore plus simple avec WSL2.

        Il est encore plus simple aujourd’hui de travailler et de mettre en pratique des méthodes de travail sous Windows comme si c’était Linux grâce à WSL2, oui.

        Mais je ne crois pas que WSL2 aide à produire des binaires natifs Windows, puisque le principe de WSL c’est de faire tourner des binaires Linux. À la rigueur ça donne accès aux outils de cross-compilation, mais autant utiliser MSYS2/MingW directement.

        Cela dit ton commentaire répond en partie à des points évoqués dans le fil de discussion partagé par Gil, où il se dit des choses comme « Au moins un mac de base reste un Unix qui te fournit un shell, python, perl, awk, les commandes de base (attention, syntaxe BSD), les clients ssh, etc. »
        Eh bien sur ce plan, Windows n’est plus vraiment en reste. Ça fait peut-être 10 ans que j’utilise des trucs comme Cygwin, et avec MSYS2 qui propose un gestionnaire de paquet utilisable comme sous linux (pacman de Arch Linux), c’est devenu vraiment très pratique. J’ai pu me servir de CoLinux il y a 15 ans, mais c’était trop séparé du système (même expérience que si on utilise une machine virtuelle), et avec Cygwin puis MSYS2, c’est devenu incroyablement pratique. J’ai eu des expériences très satisfaisantes avec Cygwin combiné avec un serveur X sous Windows (historiquement Xming, puis VcXsrv.

        Microsoft améliore très sérieusement la prise en charge de certaines méthodes de travail directement héritées de Linux, on est très loin des « Services For Unix » que je n’ai jamais vraiment pu exploiter correctement.

        WSL2 cela s’inscrit dans une dynamique où Microsoft ne veut pas voir son système de poste de travail utilisateur et de serveur être exclu de fait parce que Linux a gagné, que le monde tourne sur Unix/Linux et applique les méthodes de travail d’Unix/Linux. Personne n’est vraiment intéressé par un docker qui fournit un environnement NT avec un shell cmd.exe ou Powershell au lieu de Linux et Bash, et les gens et les entreprises veulent docker, et quand ils pensent docker, ils pensent Linux, les coreutils, etc. Microsoft a changé sa politique sur la création des liens symboliques après avoir migré sur Git comme le reste de l’industrie (avant seul l’administrateur avait ou pouvait avoir le droit d’en créer). Microsoft a même cédé sur le codage des fins de lignes des fichiers textes (même Notepad sait désormais correctement traiter les \n seuls comme des fins de ligne), ce qui permet désormais de convertir tous ses fichiers sources au format Unix sans mettre en place des conversions au checkout/commit.

        D’une certaine manière, avec sa syntaxe BSD, l’environnement du shell de macOS est plus éloigné de GNU/Linux (là ça fait particulièrement sens de citer GNU/Linux) que Windows avec Cygwin, MSYS2 ou WSL. Je disais que j’utilisais les mêmes scripts pour Linux, Windows, FreeBSD et macOS pour compiler NetRadiant, mais en fait ces scripts font deux spécialisations, une pour Linux et Windows, une autre pour FreeBSD et macOS. Dans le cas de NetRadiant la difficulté suivante étant que l’environnement de bureau (technologie d’affichage) est très différent sous macOS et moins bien pris en charge par GTK, ce qui fait que là où FreeBSD et macOS forment un cas particulier par rapport à Linux et Windows, macOS devient un sous-cas particulier de la particularité FreeBSD/macOS.

        Le truc dont je rêve désormais pour Windows, c’est un équivalent de rpath pour les chemins relatifs de bibliothèques. J’utilise actuellement la méthode de Microsoft qui est sensée la remplacer mais c’est vraiment pas un équivalent en terme de souplesse et de fonctionnalité. Il me manque peut-être des informations, mais actuellement je suis obligé de lister à l’avance les bibliothèques dont le chemin d’accès n’est pas par défaut, et le chemin de ces bibliothèques embarquées, bien que relatif, a beaucoup de contraintes. Au moins pour macOS, si les outils sont différents, les fonctionnalités sont globalement les mêmes et fonctionnent pareil, du moins pour mes besoins.

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

    • [^] # Re: activité lente, sinon moribonde du côté de macOS…

      Posté par  . Évalué à 9.

      Du côté macOS, la vie est beaucoup moins rose, avec une activité lente, sinon moribonde.

      Je ne pensais pas que c'était à ce point.

      Je suis développeur. J'utilise macOS et un peu GIMP.
      Je peux me dévouer et voir ce que je peux faire pour le package de GIMP pour macOS.
      Si il existe une machine de build GIMP pour macOS c'est déjà un (très) bon départ.

      Je fais déjà le package macOS pour Grisbi (Voir https://linuxfr.org/news/sortie-de-la-version-2-0-de-grisbi-logiciel-de-comptabilite) donc j'ai un peu d'expérience avec les applications GTK+ sur macOS. C'est pas simple (beaucoup moins que sur GNU/Linux) mais faisable.

      La liste gimp-developer-list semble avoir une activité raisonnable. C'est là que je fais ma proposition ? :-)

      • [^] # Re: activité lente, sinon moribonde du côté de macOS…

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        Depuis quelques jours, on a un nouveau contributeur qui essaie de compiler/faire marcher les versions de dév de GIMP (pour la première fois, pour autant qu'on le sache) et qui est plutôt sur la bonne voie.

        Ce qui ne veut pas dire qu'on ne veut pas de ton aide, au contraire. Plus on est, mieux c'est. Y a une sorte de malédiction sur macOS qui veut qu'on n'a jamais eu plus d'un dév à la fois (sérieux, j'ai jamais vu 2 dévs macOS pour GIMP en même temps, c'est pas une blague). La palme revient à un des mainteneurs du paquet mac qui a jeté l'éponge le jour où un autre est apparu et a commencé à proposer des scripts automatisables alors que le mainteneur du moment était injoignable depuis des mois et le paquet super en retard. Le gars est revenu un jour sur IRC, a poussé une gueulante comme si on faisait des trucs dans son dos et est jamais revenu. 🙄

        Enfin bon, donc oui, bienvenu. Je conseillerais de lire les scripts sur le dépôt gimp-macos-build et notre fork de gtk-osx. En particulier, tu trouveras une branche wip/lukaso/tests qui est ce sur quoi le nouveau contributeur bosse pour compiler la version de dév (les logs de la branche est bordélique car c'est en mode "on essaie des trucs", la version mergée devra bien sûr être nettoyée). Et déjà essayer de compiler localement.

        Puis tu peux aider à corriger les problèmes, un problème avec les icônes (voir aussi #6165).

        Ou bien on essaie de comprendre pourquoi glib 0.70.0 ne veut pas compiler (une version précédente marchait):

        [53/1098] Compiling C object glib/libglib-2.0.0.dylib.p/gregex.c.o
FAILED: glib/libglib-2.0.0.dylib.p/gregex.c.o 
/Applications/Xcode-12.5.1.app/Contents/Developer/usr/bin/gcc -Iglib/libglib-2.0.0.dylib.p -Iglib -I../../../../gtk/source/glib-2.70.0/glib -I. -I../../../../gtk/source/glib-2.70.0 -I/usr/local/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.12.sdk/usr/include -I/Users/distiller/gtk/inst/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu99 -O2 -g -D_GNU_SOURCE -fno-strict-aliasing -DG_ENABLE_DEBUG -Wimplicit-fallthrough -Wmisleading-indentation -Wstrict-prototypes -Wunused -Wno-unused-parameter -Wno-bad-function-cast -Wno-pedantic -Wno-format-zero-length -Werror=declaration-after-statement -Werror=format=2 -Werror=implicit-function-declaration -Werror=init-self -Werror=missing-include-dirs -Werror=missing-prototypes -Werror=pointer-arith -O3 -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.12.sdk -mmacosx-version-min=10.9 -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.12.sdk '-DG_LOG_DOMAIN="GLib"' -DGLIB_COMPILATION -fvisibility=hidden -MD -MQ glib/libglib-2.0.0.dylib.p/gregex.c.o -MF glib/libglib-2.0.0.dylib.p/gregex.c.o.d -o glib/libglib-2.0.0.dylib.p/gregex.c.o -c ../../../../gtk/source/glib-2.70.0/glib/gregex.c
../../../../gtk/source/glib-2.70.0/glib/gregex.c:25:10: fatal error: 'pcre.h' file not found
#include <pcre.h>
         ^~~~~~~~
1 error generated.
[54/1098] Compiling C object glib/libglib-2.0.0.dylib.p/gmain.c.o
[55/1098] Compiling C object glib/libglib-2.0.0.dylib.p/gshell.c.o
[56/1098] Compiling C object glib/libglib-2.0.0.dylib.p/gscanner.c.o
[57/1098] Compiling C object glib/libglib-2.0.0.dylib.p/gslice.c.o
[58/1098] Compiling C object glib/libglib-2.0.0.dylib.p/gsequence.c.o
ninja: build stopped: subcommand failed.
*** Error during phase build of glib: ########## Error running ninja   *** [17/34]

        (on a essayé d'autres trucs, sans succès pour l'instant… dont un truc qui finit avec un CERTIFICATE_VERIFY_FAILED quand ça essaie de télécharger libpcre; je me suis demandé si c'était à cause du prob de certificats racine de Let's Encryt de ces derniers jours)

        Si tu trouves des solutions à ces trucs, n'hésite pas à contribuer (en laissant des messages, voire en envoyant des patchs si tu trouves les problèmes, etc.).

        La liste gimp-developer-list semble avoir une activité raisonnable. C'est là que je fais ma proposition ? :-)

        C'est un bon endroit pour une entrée en matière. Ensuite le mieux est de rentrer dans les problèmes à bras le corps. Déjà compiler localement, ensuite essayer de proposer des patchs (qu'on peut tester sur le CI, c'est pour cela que je crée des branches de test wip/<nickname>/tests).

        Pour discuter plus directement, le mieux reste IRC (#gimp sur irc.gimp.org).

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

    • [^] # Re: activité lente, sinon moribonde du côté de macOS…

      Posté par  (site web personnel) . Évalué à 10.

      trouver un contributeur bénévole de logiciel libre sous mac est une illusion.

      Utilisateur (pas par choix) d’une machine Apple dans le cadre professionnel, j’ai essayé de contribuer à Inkscape, dont la version Mac OS aurait bien bien besoin d’un peu d’amour.

      Je ne suis pas développeur C++ et je n’espérais pas accomplir grand’chose, mais je pensais pouvoir au moins apporter quelques informations et résultats de tests qui auraient pu servir aux développeurs d’Inkscape — parce que pour l’instant, ils ne savent même pas exactement pourquoi Inkscape est si désespérément lent sous Mac OS.

      Sauf que… pour l’instant je n’ai même pas réussi à compiler Inkscape — non pire, je n’ai même pas réussi à installer ses dépendances !

      Pas sûr encore de bien comprendre quel est le problème (apparemment GTK3 et les nouveaux processeurs M1 de chez Apple ne sont pas très copains), mais clairement c’est pas demain que Inkscape aura un testeur pour Mac OS…

      De plus, je trouve macOS mal fini dans les angles

      Tu es gentil. Moi je trouve que c’est une bouse infâme qui n’est seulement rendue vaguement utilisable que par l’existence de MacPorts (dont je salue les développeurs au passage.)

      • [^] # Re: activité lente, sinon moribonde du côté de macOS…

        Posté par  (site web personnel, Mastodon) . Évalué à 7.

        ils ne savent même pas exactement pourquoi Inkscape est si désespérément lent sous Mac OS.

        On n'a peut-être pas la réponse complète, mais on en a une partie. Ce problème de lenteur arrivé avec BigSur (à part si tu parles d'un autre problème) où apparemment ils ont changé plein de trucs sur comment ça marche en interne (notamment pour l'affichage) était assez global (pas juste GTK, plein de logiciels ont été affectés apparemment).

        Voir par exemple:

        Voir par exemple les discussions sur ce bug, ce type de discussion sur forums Apple, etc.

        Pas sûr encore de bien comprendre quel est le problème (apparemment GTK3 et les nouveaux processeurs M1 de chez Apple ne sont pas très copains), mais clairement c’est pas demain que Inkscape aura un testeur pour Mac OS…

        En même temps, si même les dévs macOS arrivent pas à compiler, y a un problème à la base. C'est pas les dévs des autres OSes qui pourront vraiment les aider (ça devrait être l'inverse). 😛

        Enfin bon, je crois pas que tu disais ça ni l'inverse non plus. C'était juste une petite remarque.

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

        • [^] # Re: activité lente, sinon moribonde du côté de macOS…

          Posté par  (site web personnel) . Évalué à 7.

          On n’a peut-être pas la réponse complète, mais on en a une partie.

          Ça a peut-être changé au cours des trois derniers mois, mais dans ce message datant de juin les développeurs en étaient encore à devoir « identifier les coupables »… Il y a avait des pistes, certes, mais rien de vraiment précis — c’est justement là que j’espérais pouvoir aider.

          Tant mieux si depuis la liste des suspects a été réduite. :)

          En même temps, si même les dévs macOS arrivent pas à compiler, y a un problème à la base.

          Il y a méprise ! Il m’arrive d’écrire du code sous Mac OS dans le cadre de mon travail, mais je ne me qualifierai certainement pas de « développeur Mac OS ». :D

          Et je n’ai pas particulièrement envie de le devenir d’ailleurs, parce que mon impression est que ce système est particulièrement « hostile » aux développeurs (à part peut-être ceux qui font du « pur Apple » — ceux qui utilisent Xcode, développent en Objective-C, etc.)

  • # Contributeurs de code

    Posté par  . Évalué à 4.

    Contributeurs de code : bootchk, Des McGuinness, Ian Martins, Jacob Boerema, Jehan, Lloyd Konneker, Luca Bacci, Marc Espie, Massimo Valentini, Michael Bazzinotti, Michael McLaughlin, Øyvind Kolås, saul, Simon McVittie et Stanislav Grinkov.

    Oh… mitch (Michael Natterer) ne contribue plus à Gimp (cf https://linuxfr.org/news/entretien-avec-michael-natterer-mainteneur-de-gimp) ?

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 0. Dernière modification le 07 octobre 2021 à 19:41.

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

      • [^] # Re: Contributeurs de code

        Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 07 octobre 2021 à 01:30.

        Malheureusement mitch est inactif sur GIMP depuis un an (il a fait quelques commits et des releases en 2020, mais même là, il eu très peu d'activité sur tout 2020). Certains auront sûrement remarqué que cela correspond aux périodes de début de crises sanitaires et ce n'est pas un hasard. Toute son année 2020 et 2021 a été très dure pour lui car il a dû maintenir le business familial à flot (apparemment ça marche, sauf que ce fut très dur et éprouvant). Il nous dit qu'il n'a plus la force de coder après (ou pendant même… c'est bien d'être son propre boss!) le boulot.

        Il reste "dans le coin", c'est à dire qu'il est notamment sur IRC et parfois il répond même. On garde espoir qu'il revienne, notamment il nous dit qu'il veut nous retrouver à un Libre Graphics Meeting ou un Wilber Week (semaine de hacking entre nous) et que ça lui redonnera la passion, parce que rencontrer les gens tous les ans était une des choses qui le motivait le plus (or là ça fait 2 ans qu'on a abandonné toutes nos réunions; même lorsque LGM a voulu essayé de refaire une réunion physique cette année, on a considéré que ce n'était pas raisonnable de participer physiquement). Il est officiellement toujours le co-mainteneur avec moi (et comment! 24 ans qu'il contribue! C'est pas une pause de 1 an qui changerait son apport énorme; d'ailleurs c'est bien sûr lui qui m'a dit de prendre le rôle de co-mainteneur car il considérait que j'en assumais déjà les fonctions depuis un moment, juste sans le titre).

        Il n'est d'ailleurs pas le seul gros contributeur qui a disparu. Ell était un autre très gros contributeur des récentes années. Un gars super compétent et sympa. Malheureusement il a aussi soudainement disparu en septembre 2020. Juste plus de nouvelles d'un coup. On s'est même inquiété mais il répond même plus aux emails. Lui, on ne sait pas exactement pourquoi il est parti mais on a des hypothèses car il avait déjà disparu quelques mois en 2019 et il nous avait dit en revenant qu'il avait juste été complètement déçu du logiciel libre (à cause d'une sombre histoire de fork que l'on ne nommera pas et qui a bien montré le côté vilain de profiteurs qui sont simplement horribles envers autrui). Une hypothèse serait donc que cette nouvelle disparition soit pour la même ou une raison similaire. (on voit régulièrement des raisons d'êtres déçus du libre malheureusement, en plus sa disparition coïncide de quelques mois avec un autre truc pas cool qu'on a vécu mais dont on peut pas parler publiquement; c'est peut-être ça aussi, ou un mix…) 🤷

        C'est vraiment dommage car ce furent des années d'or vers 2016-2019, où entre mitch, Ell et moi qui faisions chacun environ un tiers du gros du code (bon mitch faisait en fait toujours plus!), on avait un peu une dream team. Et surtout en plus d'être compétents, ces 2 personnes sont de bonnes personnes humainement (je sais que pour certains, ça n'importe pas, mais pour moi, c'est un critère primordial pour du travail collaboratif dans de bonnes conditions; je dirais même sans hésiter que c'est plus important que la compétence pure). Franchement j'espère revivre cette période dans le futur (c'est à dire qu'ils reviennent, et d'autres gros contributeurs même espérons!), ça me manque. C'est un peu dur seul depuis un an (bon on a quelques nouveaux contributeurs, dont certains doués — un notamment qui contribue de plus en plus donc c'est génial! 🙌 — mais personne encore qui remplace complètement le niveau de compétence et de passion de mes 2 compères). 😩

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

        • [^] # Re: Contributeurs de code

          Posté par  . Évalué à 1.

          Merci Jehan, pour cette explication sur le développement de Gimp.
          Force et courage à toi
          A+

        • [^] # Re: Contributeurs de code

          Posté par  (site web personnel) . Évalué à 4.

          Je découvre ton commentaire seulement maintenant et je comprends ta tristesse d'avoir perdu cette collaboration productive et stimulante, et, je le comprends aussi, cette compagnie de personnes de qualité. Je te souhaite que tu retrouves cette expérience joyeuse, avec eux ou d'autres :)

  • # Commentaire supprimé

    Posté par  . Évalué à -3. Dernière modification le 17 octobre 2021 à 15:19.

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

    • [^] # No comment

      Posté par  (site web personnel) . Évalué à 2.

      Compte créé le 17/10/2021

      Compte fermé

      Très constructif. Un employé Adobe ?

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: No comment

        Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 17 octobre 2021 à 18:26.

        Un vulgaire spam qui a sévi par ailleurs ! Rien à voir avec Adobe.

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

Suivre le flux des commentaires

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