Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 3.0 RC1 du 6 novembre 2024 (en anglais).
Nous sommes très heureux de partager la première version candidate de la très attendue GIMP 3.0 ! Nous avons travaillé dur depuis notre dernière mise à jour de développement pour la préparer, et nous avons hâte que tout le monde puisse enfin voir le résultat.
Nouvel écran de démarrage de la version candidate, par Sevenix (CC by-sa 4.0) - GIMP 3.0 RC1
Alors, qu’est-ce qu’une « version candidate » (release candidate, RC, en anglais) exactement ? Une version candidate est quelque chose qui pourrait être prêt à être GIMP 3.0, mais nous voulons que la communauté la plus large la teste en premier et rapporte les problèmes qu’elle trouve. Si les retours des utilisateurs ne révèlent que des bugs mineurs et faciles à corriger, nous résoudrons ces problèmes et publierons le résultat sous la forme de GIMP 3.0. Cependant, nous espérons et nous nous attendons à ce qu’un public beaucoup plus large essaie la 3.0 RC1 — y compris de nombreuses personnes qui n’ont utilisé que la 2.10 jusqu’à présent. Si des bugs et des régressions importants sont découverts et nécessitent des modifications de code substantielles, nous devrons peut-être publier une deuxième version candidate pour des tests plus approfondis.
Sommaire
- Nouveaux graphismes
- Invasion de l’espace colorimétrique
- Finalisation de l’API publique
- Mises à jour de l’édition non destructive
- Interface utilisateur
- Greffons
- GEGL et babl
- Statistiques de sortie
- Modifications futures du processus de publication
- Autour de GIMP
- Télécharger GIMP 3.0 RC1
- Et ensuite ?
Nouveaux graphismes
Icônes de Wilber
Le logo actuel de Wilber a été créé par Jakub Steiner pour GIMP 2.6 en 2008 ! Bien qu’il s’agisse toujours d’un logo fantastique, les tendances en matière de design ont quelque peu changé au cours des seize dernières années et l’apparence plus détaillée de Wilber détonne sur les ordinateurs de bureau modernes.
C’est pourquoi, en collaboration avec d’autres contributeurs, Aryeom a développé notre nouveau logo pour GIMP 3.0 !
Nouvelle icône de Wilber, par Aryeom (CC by-sa 4.0)
Si vous souhaitez en savoir plus sur les choix de conception, d’utilisation et les variantes de conception, veuillez consulter notre guide du logo. Nous avons également documenté l’histoire du logo Wilber.
Écran de démarrage (Splash Screen)
Notre magnifique nouvel écran d’accueil (présenté en haut de cet article) a été créé par le contributeur et artiste de longue date Sevenix ! Vous pouvez voir plus de ses réalisations sur sa page d’art personnelle.
À l’avenir, nous prévoyons de changer plus souvent l’image de démarrage pour mettre en valeur toutes sortes d’œuvres créées avec GIMP (photographie, illustration, design…).
À ce sujet, nous avons aussi créé une page d’archive des écrans de démarrage pour garder en mémoire les œuvres présentes et passées contribuées par des artistes au projet.
Améliorations du thème d’icônes Legacy
L’une des principales améliorations apportées par le portage GTK3 est que les icônes vectorielles de l’interface utilisateur s’adaptent désormais plus proprement à vos préférences. Cependant, notre thème d’icônes Legacy était principalement constitué d’images raster (PNG), il ne pouvait donc pas tirer parti du système de mise à l’échelle de GTK3. Le contributeur Denis Rangelov a relevé le défi de taille de recréer les icônes d’outils Legacy en SVG. Désormais, les deux thèmes d’icônes de GIMP sont superbes sur les écrans HiDPI !
Icônes d’outils du thème Legacy Icon à l’échelle par Denis Rangelov (CC by-sa 4.0)
Le travail n’est pas terminé, car de nombreuses icônes ne sont toujours pas adaptatives et certaines icônes sont toujours manquantes. Denis a exprimé son intérêt à continuer d’améliorer le thème d’icônes Legacy, nous espérons donc le renommer Classic lorsque ce projet sera terminé, pour montrer qu’il est désormais bien maintenu.
Invasion de l’espace colorimétrique
L’un des changements clés de la version 2.99.18 a été l’amélioration massive de la gestion des couleurs dans GIMP. Comme ce travail n’était pas entièrement terminé dans la version 2.99.18, il a constitué un obstacle majeur à la sortie de la version 3.0 RC1.
Depuis cette version, nous avons trouvé et corrigé un certain nombre de bugs et de zones manquantes qui devaient être compatibles avec l’espace colorimétrique. Nous avons également examiné les rapports de l’experte en couleurs Elle Stone pour nous assurer que les valeurs de couleur affichées par GIMP sont aussi précises que possible. En même temps, il est très important de garantir que les fichiers de projet XCF créés dans GIMP 2.10 et avant s’afficheront de la même manière lorsqu’ils sont ouverts dans 3.0. Par exemple, l’un des premiers logos Google a été créé dans GIMP — et si vous ouvrez le fichier de projet XCF d’origine dans GIMP 3.0 RC1, il apparaît toujours de la même manière qu’à sa création en 1998 !
Par conséquent, nous avons examiné en profondeur les différents modes de calque pour garantir que l’engagement en matière de compatibilité soit conservé pour cette version.
L’invasion de l’espace colorimétrique est un projet de longue haleine, qui se poursuivra après la sortie de GIMP 3.0.
Finalisation de l’API publique
Une autre tâche qui devait être terminée avant la sortie de la version 3.0 est de finaliser l’API publique. Depuis notre dernier article, nous avons terminé les changements majeurs restants — le remplacement de toutes les instances de nos structures de couleurs personnalisées GimpRGB par la GeglColor mieux gérée en termes de couleurs et l’amélioration de nos formats de tableau afin que le nombre d’éléments n’ait pas à être spécifié séparément. Ce travail a été un long processus de la part de Jehan et Lloyd Konneker, avec beaucoup de tests de bon fonctionnement et de retours de la part d'Anders Jonsson.
En outre, un certain nombre de fonctions ont été ajoutées, renommées ou supprimées de l’API publique par rapport à la version 2.10. Par exemple, un ancien patch de Massimo Valentini ajoute gimp-context-get-emulate-brush-dynamics et gimp-context-set-emulate-brush-dynamics, qui permettent aux développeurs de scripts et de greffons d’utiliser le paramètre Émuler la dynamique du pinceau lors de la peinture. D’autre part, les différentes fonctions gauss ont toutes été regroupées en une seule fonction, plug-in-gauss. Bien que ce changement nécessite quelques mises à jour dans les scripts existants, les développeurs ont désormais un contrôle plus direct sur l’effet de flou gaussien plutôt que de s’appuyer sur des valeurs prédéfinies cachées.
L’API étant désormais stable, les développeurs de greffons et de scripts peuvent commencer à porter leurs scripts 2.10 basés sur cette version. Vous pouvez trouver la documentation initiale de l’API sur notre site de développement. Nous avons l’intention d’ajouter davantage de tutoriels et de guides de portage sur le site pendant la phase de publication. Nous vous encourageons également à consulter les greffons Script-fu et Python dans notre référentiel pour voir des exemples fonctionnels de la nouvelle API.
Mises à jour de l’édition non destructive
Depuis notre dernière mise à jour, nous avons continué à apporter des améliorations et des corrections de bugs à notre code de filtre non destructif. Bon nombre de ces problèmes ont été signalés par Sam Lester lors du développement et des tests de ses filtres GEGL tiers.
Bien que les filtres non destructifs aient été un ajout très populaire à GIMP 3.0, certains des premiers utilisateurs ont demandé que nous fournissions un moyen de revenir au flux de travail destructif d’origine. Par conséquent, nous avons ajouté une case à cocher facultative « Fusionner les filtres » au bas des filtres NDE. Si cette case est cochée, le filtre sera immédiatement fusionné après sa validation. Notez que les filtres ne peuvent pas être appliqués de manière destructive sur des groupes de calques — dans ces cas, l’option de fusion des filtres n’est pas disponible.
Exemple de filtre avec la case à cocher « Merge Filter » (Fusionner les filtres) - GIMP 3.0 RC1
Dans le même ordre d’idées, Jehan a également implémenté le stockage de la version des filtres dans les fichiers de projet XCF de GIMP. Cela nous permettra de mettre à jour les filtres à l’avenir sans affecter l’apparence des anciens fichiers de projet lorsqu’ils sont ouverts. Des travaux supplémentaires seront nécessaires dans GEGL pour implémenter complètement cette fonctionnalité, mais cela peut être fait après la version 3.0 sans affecter les fichiers de projets existants.
Interface utilisateur
GIMP 3.0 RC1 contient plusieurs mises à jour de l’interface utilisateur. Par exemple, davantage d’aspects du GUI peuvent désormais tirer parti des fonctionnalités de sélection multiple implémentées par Jehan dans les versions antérieures de 2.99.
Nous avons également restauré la possibilité d’utiliser la molette de défilement de la souris pour parcourir les différents onglets de dialogue ancrables. Cette fonctionnalité existait dans GTK2 mais supprimée dans GTK3. À la demande d’un utilisateur, nous avons réimplémenté cette fonctionnalité dans GIMP lui-même sur la base d’une implémentation similaire dans geany.
Au cours du développement, nous avons reçu un rapport indiquant que le défilement des crédits dans notre boîte de dialogue À Propos pouvait provoquer une gêne en raison de son mouvement. Par conséquent, nous avons ajouté un code pour vérifier le paramètre « Animation réduite » de votre système d’exploitation et désactiver ces animations dans GIMP selon vos paramètres de préférence.
Greffons
Comme nous sommes en période de gel des fonctionnalités depuis la dernière version 2.99, la plupart des modifications apportées aux greffons ont été des mises à jour d’API et des corrections de bugs (certaines d’entre elles pour des problèmes qui étaient assez anciens). Cependant, quelques améliorations plus petites ont été implémentées.
BMP
Le format BMP prend désormais en charge les images 64 bits par pixel. Le nouveau contributeur Rupert Weber nous a aidé à ajouter la prise en charge de l’importation correcte de ce format BMP. Il a également soumis des correctifs avec plus de corrections pour notre greffon BMP et notre pipeline de test.
TIFF
Depuis GIMP 2.99.16, nous pouvons importer des fichiers TIFF avec des calques au format Photoshop. Cependant, le programme Alias/Autodesk Sketchbook a créé sa propre norme pour enregistrer les calques, ce qui n’était pas compatible. Comme cela a été signalé comme un bug dans notre outil de suivi des problèmes, nous avons également ajouté la prise en charge du chargement de calques à partir de fichiers TIFF enregistrés au format Sketchbook.
GEGL et babl
GEGL et babl ont tous deux connu un certain nombre de mises à jour depuis leurs dernières versions en février.
GEGL 0.4.50 introduit plusieurs nouveaux filtres créés par Sam Lester.
Lueur intérieure (Inner Glow)
Biseau (Bevel)
Styles GEGL (GEGL Styles)
Vous pouvez y accéder via l’outil Opérations GEGL ou en les recherchant avec le raccourci d’action de recherche /.
Øyvind Kolås a apporté un certain nombre de corrections de bugs et d’améliorations à la stabilité de GEGL. Plusieurs modifications ont également été apportées en rapport avec l’invasion de l’espace colorimétrique dans GIMP, comme l’ajout de méthodes pratiques pour obtenir et définir les GeglColor dans les modèles de couleurs HSV(A) et HSL(A), implémentées par Alx Sa. Jacob Boerema et son étudiant du Google Summer of Code (GSoC) Varun Samaga B L ont fusionné un certain nombre d’améliorations à la version OpenCL des filtres. Bien que GIMP n’active toujours pas OpenCL par défaut, leur travail nous rapproche beaucoup de la possibilité de le faire. Nous discuterons de ces améliorations dans un prochain article.
babl 0.1.110 a également reçu quelques contributions au cours de ce cycle. Jehan a implémenté de nouveaux processus de conversion entre les modèles de couleurs RVB et HSL, ce qui améliore les performances d’un certain nombre de filtres par rapport à GIMP 2.99.18. Il a également corrigé certaines parties du code qui se comportaient différemment selon que votre processeur prenait en charge SSE2 ou non. Øyvind Kolås a amélioré la précision de plusieurs sections de code lors de la conversion de valeurs à virgule flottante en valeurs entières. De plus, Lukas Oberhuber a trouvé et corrigé une fuite de mémoire et Jacob Boerema a corrigé un problème où les images avec Not a Number/NaN pouvaient provoquer un plantage.
Statistiques de sortie
Depuis GIMP 2.99.18, dans le dépôt principal de GIMP :
- 384 rapports ont été fermés comme CORRIGÉS.
- 442 demandes de fusion ont été acceptées.
- 1892 commits ont été poussés.
- 31 traductions ont été mises à jour : basque, biélorusse, brésilien portugais, anglais britannique, bulgare, catalan, chinois (Chine), chinois (Taïwan), danois, néerlandais, galicien, géorgien, allemand, grec, hongrois, islandais, italien, coréen, letton, norvégien nynorsk, polonais, portugais, russe, serbe, serbe (latin), slovène, espagnol, suédois, turc, ukrainien, vietnamien.
72 personnes ont contribué à des modifications ou des correctifs au code de base de GIMP 3.0.0 RC1 (l’ordre
est déterminé par le nombre de commits ; certaines personnes sont dans plusieurs groupes) :
- 27 développeurs pour coder le code principal : Jehan, Alx Sa, Jacob Boerema, bootchk, Anders Jonsson, Øyvind Kolås, Cheesequake, cheesequake, Niels De Graef, Idriss Fekir, Simon Budig, lillolollo, lloyd konneker, Andre Klapper, Andrzej Hunt, Bruno, Joachim Priesner, Nils Philippsen, Alfred Wingate, Bruno Lopes, Elle Stone, Kamil Burda, Luca Bacci, Mark Sweeney, Massimo Valentini, Oleg Kapitonov, Stanislav Grinkov, megakite.
- 15 développeurs de greffons ou modules : Alx Sa, Jehan, Lloyd Konneker, bootchk, Jacob Boerema, Anders Jonsson, Nils Philippsen, Andrzej Hunt, Andre Klapper, Rupert, Bruno Lopes, Daniel Novomeský, Mark Sweeney, Stanislav Grinkov, lillolollo .
- 42 traducteurs : Martin, Yuri Chornoivan, Luming Zh, Rodrigo Lledó, Kolbjørn Stuestøl, Ekaterine Papava, Cheng-Chia Tseng, Sabri Ünal, Marco Ciampa, Tim Sabsch, Jordi Mas, Alexander Shopov, Anders Jonsson, Alan Mortensen, Asier Sarasua Garmendia, Sveinn í Felli, Andi Chandler, Balázs Úr, dimspingos, Juliano de Souza Camargo, Ngọc Quân Trần, Vasil Pupkin, Alexandre Prokoudine, Bruce Cowan, Jürgen Benvenuti, Nathan Follens, Милош Поповић, Balázs Meskó, Christian Kirbach, Daniel, Emin Tufan Cetin, Fran Dieguez, Guntupalli Karunakar, Hugo Carvalho, Jehan, Philipp Kiemle, Piotr Drąg, Robin Mehdee, Rūdolfs Mazurs, Seong-ho Cho, Víttor Paulo Vieira da Costa, Ayesha Akhtar.
- 7 créateurs de ressources (icônes, thèmes, curseurs, écran de démarrage, métadonnées… même si une bonne partie d’entre eux ont été déplacés vers le référentiel
gimp-data) : Alx Sa, Jehan, Bruno Lopes, Anders Jonsson, Jacob Boerema, bootchk, nb1 . - 10 contributeurs à la documentation : Jehan, Bruno, Lloyd Konneker, Alx Sa, Bruno Lopes, Anders Jonsson, bootchk, Lukas Oberhuber, Andre Klapper, Jacob Boerema.
- 11 contributeurs pour la compilation, l’empaquetage ou l’intégration continue : Bruno Lopes, Jehan, bootchk, Alx Sa, Lloyd Konneker, Jacob Boerema, Niels De Graef, Alfred Wingate, Lukas Oberhuber, Michael Schumacher, Anders Jonsson.
Contributions sur d’autres dépôts dans GIMPverse :
- babl 0.1.110 est composé de 22 commits par 7 contributeurs : Øyvind Kolås, Jehan, Bruno Lopes, Anders Jonsson, Biswapriyo Nath, Jacob Boerema, Lukas Oberhuber.
- GEGL 0.4.50 est composé de 204 commits par 33 contributeurs : Øyvind Kolås, Sam Lester, Martin, Varun Samaga B L, Yuri Chornoivan, Luming Zh, Rodrigo Lledó, Jehan, Jordi Mas, Anders Jonsson, Kolbjørn Stuestøl, Marco Ciampa, Sabri Ünal, Bruno Lopes, Alan Mortensen, Asier Sarasua Garmendia, Ekaterine Papava, Bruce Cowan, Lukas Oberhuber, Tim Sabsch, psykose, Alexandre Prokoudine, Alx Sa, Andi Chandler, Andre Klapper, ArtSin, Daniel Șerbănescu, Jacob Boerema, Joe Locash, Morgane Glidic, Niels De Graef, dimspingos, lillolollo.
- ctx a enregistré 616 commits depuis la sortie de la version 2.99.18 par 2 contributeurs : Øyvind Kolås, Ian Geiser.
-
gimp-data(nouveau référentiel contenant des images, des splashes, des icônes et d’autres données binaires pour le logiciel) ont eu 76 commits par 7 contributeurs : Jehan, Aryeom, Bruno, Alx Sa, Denis Rangelov, Anders Jonsson, Bruno Lopes. - La version
gimp-macos-build(scripts d’empaquetage pour macOS) a eu 41 commits par 3 contributeurs : Lukas Oberhuber, Bruno Lopes, Jehan. - La version flatpak a compté 38 commits de 4 contributeurs : Bruno Lopes, Jehan, Hubert Figuière, Will Thompson.
- Notre site Web principal a enregistré 60 commits depuis la sortie de la version 2.10.38 par 5 contributeurs : Jehan, Alx Sa, Andre Klapper, Bruno Lopes et Denis Rangelov.
- Notre site Web de développeur a enregistré 33 commits depuis la sortie de la version 2.10.38 par 5 contributeurs : Bruno Lopes, Jehan, Lloyd Konneker, Alx Sa, Lukas Oberhuber.
- Notre documentation 3.0 a enregistré 928 commits depuis la version 2.99.18 par 14 contributeurs : Andre Klapper, Kolbjørn Stuestøl, Jacob Boerema, Alan Mortensen, Yuri Chornoivan, Jordi Mas, Marco Ciampa, Anders Jonsson, Sabri Ünal, dimspingos, Alx Sa, Andi Chandler, Daniel, Nathan Follens.
N’oublions pas de remercier toutes les personnes qui nous aident à trier dans Gitlab, à signaler les bugs et à discuter des améliorations possibles avec nous.
Notre communauté est également profondément reconnaissante envers les guerriers d’Internet qui gèrent nos divers canaux de discussion ou comptes de réseaux sociaux tels que Ville Pätsi, Liam Quin, Michael Schumacher et Sevenix !
Note : compte tenu du nombre de parties dans GIMP et de la façon dont nous obtenons des statistiques via le script git, des erreurs peuvent se glisser dans ces statistiques. N’hésitez pas à nous dire si nous avons oublié ou mal classé des contributeurs ou des contributions.
Modifications futures du processus de publication
Nous sommes bien conscients que le chemin vers GIMP 3.0 a été long et que les utilisateurs de GIMP 2.10 n’ont pas eu accès à toutes les nouvelles fonctionnalités sur lesquelles nous avons travaillé au fil des ans. À l’avenir, nous restructurerons notre processus de développement pour réduire le temps entre les versions. Comme mentionné brièvement dans notre feuille de route 3.0, nous voulons nous concentrer sur des versions plus petites et axées sur les fonctionnalités. Cela signifie que nous visons la sortie de GIMP 3.2 dans l’année qui suit la sortie finale de 3.0, plutôt qu’en 2050 comme on le dit souvent en plaisantant ! Des micro-versions avec des corrections de bugs peuvent survenir entre-temps.
Des versions plus petites avec quelques « grosses » fonctionnalités nous permettront également de tester plus en profondeur chaque changement, améliorant encore la stabilité de chaque version. Au cours du processus de développement de la version 3.0, des développeurs comme Jacob Boerema, Lloyd Konneker, Bruno Lopes et Jehan ont créé et amélioré nos processus de tests automatisés pour détecter et identifier les bugs plus tôt. Nous parlerons plus en détail de ces améliorations dans de futurs articles.
Autour de GIMP
Miroirs de téléchargement
Depuis notre dernière actualité, 8 nouveaux miroirs ont été proposés à GIMP par :
- Sahil Dhiman, Inde
- FCIX, en République Dominicaine, en Australie et 2 aux USA.
- Taiwan Digital Streaming Co., Taïwan
- OSSPlanet, Taïwan
- Shrirang Kahale, Inde
Cela nous amène à un total de 56 miroirs du monde entier !
Carte des miroirs GIMP dans le monde, générée à partir de MirrorBits
Les miroirs sont importants, car ils aident le projet en répartissant la charge des dizaines de milliers de téléchargements quotidiens. De plus, en ayant des miroirs répartis dans le monde entier, nous faisons en sorte que tout le monde puisse avoir un accès rapide au téléchargement de GIMP.
Modifications de l’infrastructure
Bruno Lopes a véritablement pris des initiatives pour améliorer notre processus de construction et d’empaquetage sur plusieurs plateformes.
Au cours de l’été, il a créé une version expérimentale d’AppImage (comme détaillé dans un article d’actualité précédent). Si vous souhaitez l’améliorer davantage et, espérons-le, le rendre disponible en téléchargement standard, veuillez nous contacter ! Bruno a également créé des scripts de construction flatpak pour rendre le processus de création de votre propre flatpak GIMP beaucoup plus facile.
Beaucoup de travail a été fait pour améliorer notre présence sur le Microsoft Store pour la version 3.0. Notre application GIMP 2.10 n’était pas entièrement intégrée à la plateforme du store en raison de certaines limitations — il s’agit en réalité simplement d’un wrapper pour notre installateur GIMP existant. Par conséquent, elle ne se mettait pas automatiquement à jour pour les utilisateurs et il n’était pas possible d’automatiser les installations avec des outils comme Microsoft Intune. Grâce aux nombreux efforts de Bruno, nous aurons une nouvelle application GIMP dans le Microsoft Store qui résout ces problèmes (et bien d’autres) pour la version finale de GIMP 3.0. À partir de maintenant, nous disposons également d’une version séparée de GIMP (Preview) qui vous permet d’installer des versions de développement de manière similaire au flatpak Bêta sur Linux. Vous pouvez l’essayer sur ce lien vers le Microsoft Store pour GIMP (Preview).
(Pour des raisons techniques et de maintenance décrites ici, les binaires 32 bits ne seront pas disponibles dans les nouveaux paquets MSIX de GIMP, ce qui supprime malheureusement la prise en charge du greffon TWAIN hérité dans les paquets x64 et arm64 utilisés pour la numérisation rapide. Si vous dépendez de ceux-ci, le programme d’installation .exe prend toujours en charge les processeurs 32 bits. Cependant, la prise en charge de cette architecture devrait être abandonnée à l’avenir)
En outre, l’installateur Windows standard a été mis à jour pour une conception plus moderne. Il vous permet également d’installer des paquets de langue individuels et de démarrer GIMP immédiatement après la fin de l’installation. Pour les plus férus de technologie, les scripts de build Windows ont également été portés pour utiliser PowerShell, et les scripts de build croisés peuvent désormais s’exécuter localement.
En raison des changements et des mises à jour de notre infrastructure de création de logiciels, nous avons dû augmenter la configuration minimale requise pour le système d’exploitation MacOS à Big Sur (MacOS 11).
Accord d’hébergement fiscal de la Fondation GNOME
Plus tôt cette année, la Fondation GNOME a annoncé un accord de parrainage fiscal avec GIMP. Tout cela est dû au travail acharné de Jehan pendant de nombreux mois. Nos objectifs avec cet accord sont de pouvoir proposer un financement stable pour les développeurs intéressés par un travail à long terme sur GIMP par le biais de bourses, et de fournir des moyens plus faciles pour les gens de contribuer au développement de GIMP. Ce travail est toujours en cours, nous ferons donc une annonce plus détaillée une fois que tout sera stabilisé.
Traductions
Grâce à des traducteurs bénévoles, nous disposons désormais d’une traduction de GIMP en bengali ! Si vous souhaitez traduire GIMP dans votre propre langue ou participer à une traduction existante, vous pouvez découvrir comment ici.
Télécharger GIMP 3.0 RC1
Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :
- Paquets Linux flatpaks pour x86 et ARM (64 bits) avec des nightly-builds permettant de suivre l’avancement des développements
- Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
- Paquet MSIX (aperçu GIMP) pour x86 (64 bits uniquement) et ARM (64 bits)
- Paquets macOS DMG pour le matériel Intel
- Paquets macOS DMG pour le matériel Apple Silicon
D’autres paquets réalisés par des tiers sont évidemment attendus (paquets de distributions Linux ou *BSD, etc.).
Et ensuite ?
Nous entrons maintenant dans la dernière étape de cette version majeure : les candidats à la version finale ! Bien qu’il soit toujours possible d’espérer obtenir une Release Candidate correcte du premier coup, l’expérience nous dit que cette RC1 — qui est le résultat de plus de 6 ans de travail — comportera possiblement des problèmes, des bugs, probablement des plantages désagréables. C’est là que nous avons besoin de vous tous ! Nous comptons sur tout le monde pour trouver et signaler les problèmes afin que la version 3.0.0 puisse vraiment être considérée comme stable. 🤗
Certains petits bugs peuvent être considérés comme secondaires (bien que nous acceptions toujours les rapports pour tous les bugs, même les plus petits !), car la perfection n’existe pas vraiment dans les logiciels. Il y a d’autres choses en particulier que nous voulons vraiment détecter, comme :
- toute incohérence ou problème dans l’API (elle restera stable pour toute la série v3, donc s’il y a des problèmes à trouver, c’est maintenant ; nous voulons un framework de greffon robuste) ;
- bugs lors de la lecture ou du rendu de fichiers XCF existants créés par d’anciennes versions stables de GIMP ;
- plantages ;
- régressions ;
- migration correcte de la configuration à partir des versions stables précédentes.
Nous ne donnons pas d’estimation de date pour la sortie de la version 3.0.0, tout d’abord parce que nous ne pouvons pas le savoir avec certitude, ensuite parce qu’à chaque fois que nous le faisons, les médias semblent simplement survoler chaque avertissement de notre texte et transformer nos mots en promesses indéfectibles. Sachez simplement que nous voulons également que cela se produise le plus tôt possible, c’est-à-dire lorsque nous pourrons considérer que notre logiciel est suffisamment stable.
N’oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, afin de donner en retour et d’accélérer le développement de GIMP. L’engagement de la communauté aide le projet à se renforcer ! 💪🥳
# dénote != détonne
Posté par esdeem . Évalué à 6 (+5/-1). Dernière modification le 15 novembre 2024 à 09:59.
Je trouve cela plutôt détonnant d'utiliser dénoter à la place de dénoter.
Utiliser dénoter à la place de détonner dénote un manque de compréhension du sens de ces mots.
Définitions courtes (wiktionnaire):
- détonner: v.i. (Sens figuré) Contenir des choses qui ne sont pas dans le ton général, en parlant des choses ou des personnes.
- dénoter: v.t. indiquer comme caractéristique
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: dénote != détonne
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5 (+3/-0).
Deux fois un même petit effet de correcteur automatique peut-être ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: dénote != détonne
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0).
ça pourrait être pire. « détoner: S’enflammer subitement avec bruit, faire explosion. » https://fr.wiktionary.org/wiki/d%C3%A9toner
[^] # Re: dénote != détonne
Posté par vpo . Évalué à 3 (+2/-0).
En tout cas c'est vrai que ça serait bien si un modérateur pouvait corriger :
Par :
l’apparence plus détaillée de Wilber détonne sur les ordinateurs de bureau modernes.
[^] # Re: dénote != détonne
Posté par esdeem . Évalué à 5 (+3/-0).
Je dirais plutôt que ça dénote de ma part un un lapsus déton(n)ant!
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: dénote != détonne
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Corrigé, merci.
# Merci
Posté par esdeem . Évalué à 8 (+6/-0).
Tout est dans le titre! :-)
Merci pour ce compte rendu détaillé et fort intéressant de la sortie de cette Release Candidate qui annonce une belle version stable de Gimp 3.0.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
# GTK 4
Posté par sbillois . Évalué à 2 (+3/-1).
Quand est prévu le passage à GTK 4 ? 😜
Je plaisante, cette nouvelle est chouette :)
[^] # Re: GTK 4
Posté par Yarma22 . Évalué à 6 (+6/-0). Dernière modification le 17 novembre 2024 à 14:07.
Blague à part, parce qu'effectivement le travail de portage vers GTK 3 commencé il y a maintenant 4 ans fut considérable, est-il prévu de porter GIMP vers GTK 4 ? La roadmap ne semble pas en faire mention.
La première version stable de GTK 4 est sortie peu ou prou au moment où débutait le portage vers GTK 3. Avec du recul, aurait-il été plus judicieux à l'époque de sauter une version et commencer un portage vers GTK 4 ?
À défaut de refaire l'histoire, pourrait-on d'ores et déjà considérer un portage vers GTK 5 pour éviter de se retrouver dans une situation similaire, GIMP 2.10 datant tout de même de 2018 ? Loin de moi l'idée de critiquer, je me demande simplement quel est le point de vue des développeurs sur la question.
Il est effectivement fait mention d'une volonté de se "concentrer sur des versions plus petites et axées sur les fonctionnalités", ce qui est évidemment une super nouvelle. Mais cela ne change rien au fait que GTK 3 (la version 3.24 est sortie il y a déjà 6 ans et en est maintenant à sa 43ème version mineure) finira un jour ou l'autre par ne plus être maintenue.
Dans tous les cas, un énorme bravo à toutes les personnes impliquées dans le projet et la sortie de cette version bien plus que symbolique. GIMP est un véritable étendard du logiciel libre sur environnement de bureau et vous pouvez être fiers du travail accompli jusqu'à présent.
[^] # Re: GTK 4
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10 (+31/-0).
C'est pas une priorité. On fait un logiciel de création graphique, pas une démo technique d'un toolkit graphique. Et passer du temps à changer d'infra juste pour changer d'infra n'est pas la partie marrante (ni ce qu'attendent la plupart des gens qui créent avec GIMP), pour au final passer surtout du temps à réparer les régressions, les nouveaux bugs…
Mais hormis cela, oui bien sûr que c'est prévu à terme. Cela reste une dette technique de rester sur une version qui n'évolue plus.
J'aurais juste bien aimé que les dévs GTK soient un peu plus conservateurs et ne cassent pas fondamentalement leur interface à chaque fois.
Certains sortent cela en effet parfois. Comme si c'était trivial de faire un port d'une version majeure à une autre de GTK. On raconte aussi qu'il serait plus facile à porter de GTK+3 à GTK4 que de GTK+2 à GTK+3.
Alors moi je veux bien, mais on a déjà repéré plusieurs problèmes majeurs, et rien que d'y penser, j'ai mal à la tête. Par exemple, avec GTK4, on perd les menus. Ils ont décidé que les menus à l'ancienne étaient peu utilisés (seulement tous les logiciels majeurs que j'utilise ont des menus! Faut croire que c'était pas assez! 🙄) et trop compliqué. À la place, ils conseillent maintenant d'utiliser des menus popover (le fameux menu hamburger quoi). Puisqu'on n'est pas d'accord, ça veut dire qu'on va devoir réimplementer les barres de menu et tous les autres composants de telles interfaces, les intéractions, etc. Quand je vois déjà le boulot que j'ai fait entre GIMP 2 et GIMP 3 pour changer le code des actions et des menus (avec aussi plein de nouveau code côté GIMP car ça avait déjà commencé à disparaître côté GTK), et notamment que plein de mon nouveau code va déjà partir à la poubelle quand on va passer à GTK4, ça me fait un peu mal.
En fait, plus ça va et plus GTK semble cibler les logiciels simples (les "apps"). Tout ce qui est complexe, type "logiciel métier" ne semble plus trop les intéresser. Ils comprennent pas apparemment qu'un logiciel comme GIMP avec plus de 200 filtres, des dizaines d'outils, fenêtres détachables et ancrables pour des fonctionnalités avancées, et ainsi de suite, a besoin de menus et sous-menus organisés, et pas juste un mini menu hamburger.
Déjà qu'ils ont décidé de retirer les tooltips (info-bulles) sur les éléments de menu dans GTK+3 parce qu'ils considèrent que ce n'est pas une bonne idée. Pour ça aussi, j'ai du faire pas mal de code additionnel pour faire notre propre code de génération de menu. Non parce que c'est sûr que pour des "apps" avec 3 actions au nom explicite, je peux comprendre qu'on trouve les infos bulles inutiles. Mais pour un logiciel métier à la pointe du graphisme, avec beaucoup de filtres qui sortent du monde académique, ben pouvoir expliciter des usages principaux ou des descriptions plus détaillés pour certaines actions n'est pas du luxe. Et c'est pas juste qu'il faudrait trouver un meilleur nom pour l'action. Beaucoup de ces noms sont communs entre tous ces logiciels et ont un nom certes scientifique mais passé dans les normes. Que ce soit un flou gaussien, ou un filtre passe-haut, ou autre… Et même les filtres avec des noms plus "sympas" pour le grand public, une petite description un peu plus longue n'est vraiment pas du luxe.
Le second autre gros point noir qui va demander beaucoup de travail est la disparition de GtkTreeView. Alors on pourrait rétorquer que c'est juste une dépréciation (depuis 4.10) et qu'on pourrait donc juste de contenter de garder ce code pour GIMP 4. Sauf que tout développeur sait que garder du code déprécié jusqu'à la dernière seconde n'est pas idéal (sauf dans certains cas, par exemple si le but est d'avoir du code qui marche à la fois dans de vieilles versions et de nouvelles d'une dépendance; mais ce sera pas le cas ici). Notamment si on ne veut pas être noyé de messages de dépréciation en compilant son code (qui a le mauvais goût de cacher les vrais messages problématiques, qui soulignent des bugs dans le code, noyés sous la masse). Encore une fois, on nous dit que les logiciels modernes n'utilisent pas de vue en arborescence. 🤦♂️ Alors on nous dit que si on veut vraiment simuler une vue en arborescence, on peut utiliser une view en liste et y mettre des "expanders" (les widgets pour cacher du contenu derrière un titre avec le petit triangle à cliquer) à la main, plutôt qu'avoir une structure de vue en arbre faite pour.
Bien sûr, on utilise la vue en arbre partout: que ce soit les calques, mais aussi dans pas mal d'autres endroits du code. Bon pour pas mal de bouts de code, la recommandation d'utiliser une liste avec des "expanders" sera vraisemblablement un hack suffisant. Mais pour les parties où la logique en arborescence est vraiment un élément structurel fondamental (justement les calques par exemple), on devra sûrement faire du nouveau code à nous pour faire ça bien, propre conceptuellement et performant. Et je sais déjà que ce sera pas une balade dans le parc.
Enfin bon, en conclusion: passer d'une version de GTK à une autre n'est pas une partie de plaisir, surtout s'ils s'amusent à retirer des fonctionnalités fondamentales à chaque fois.
Et dans les faits, en écumant les forums, on se rend compte que tous les gens qui utilisent vraiment GIMP de manière approfondie voire professionnelles semblent à peine faire attention aux montées de la version du toolkit. C'est pas vraiment ça qui les intéresse ou qui leur permet de faire du meilleur boulot. Ceux qui font le plus de remarques à ce sujet semblent être ceux qui utilisent GIMP de manière anecdotique (voire pas du tout pour certains, on le voit à ce qu'ils disent sur des trucs qui ne sont plus vrais depuis des années, voire décennies) et qui s'arrêtent au visuel. D'ailleurs c'est un peu comme Wayland. Tous les professionnels que l'on rencontrent (dont nous-même!) persistons à utiliser X11. Parce que malgré toutes les promesses de monts et merveilles de Wayland, il y a encore trop de fonctionnalités de base manquantes dans Wayland, dont la correction colorimétrique qui est encore et toujours en discussion et notamment parce que je me suis bien rendu compte que cela mélange des besoins très différents; notamment ils accordent énormément d'importance aux usages de type "je veux juste des couleurs les plus pêtantes possible parce que j'ai un écran à gamut large" (typiquement: je joue à des jeux vidéos et j'en veux plein la tronche, ou je vends des télés et je veux que les explosions dans ma télé se voient plus que dans celle du concurrent) et non pas "je veux des couleurs correctes" (par exemple si je suis un professionnel du graphisme). Mais il y a aussi encore trop régulièrement des problèmes avec les tablettes graphiques, ou bien des problèmes de stabilité (au point que certains se mettent à échanger des astuces pour lancer GIMP par XWayland; Krita de leur côté ont carrêment hardcodé l'usage de XWayland en disant que Krita ne prend pas en charge Wayland pour l'instant donc les gens ne peuvent même pas lancer le logiciel en pur Wayland).
Enfin bon, nouveau tout de suite n'est pas forcément mieux. Que ce soit pour GTK ou Wayland.
En vrai, on fait cela depuis 2018, c'est à dire depuis GIMP 2.10.0. On a sorti 20 versions stables (2.10.0 à 2.10.40), soit à peu près 3 par an, à chaque fois avec de nouvelles fonctionnalités en pagaille. La seule différence, c'est qu'à ce moment, on avait rompu avec notre système de versionnement historique pour accepter de nouvelles fonctionnalités sur des sorties "micro" (qui jusque là étaient seulement pour les corrections de bugs), parce qu'il avait déjà été décidé que 2.10 serait la dernière version mais qu'on voulait pouvoir sortir des changements majeurs plus souvent (par tous les X années).
La différence là est qu'on revient sur ce changement. Les sorties micro (troisième nombre) seront à nouveau des sorties de correction de bug uniquement, et additionnellement à cela, on sortira des versions mineures (second nombre) plus vite, avec les fonctionnalités. C'est donc un mix de comment cela fonctionnait en 2.10 et avant (2.8, 2.6…).
Encore une fois, tous ceux qui utilisent vraiment GIMP au quotidien et ont suivi les évolutions ont bien vu que ce n'est pas la partie la plus innovante, puisque c'est déjà ce qu'on faisait depuis 2018. Si on change, c'est surtout parce que tous ceux qui regardent de loin racontent un peu de fariboles et répandent partout que GIMP a pas évolué depuis la version 2.10. Ensuite y a pire. Y a ceux qui prétendent que GIMP n'a pas changé depuis la version 2.0 (ceux-là se fient au premier chiffre seulement), et le pire, c'est quand c'est repris dans de plus gros médias (oui, j'ai bien vu qu'ils ont mis un petit paragraphe au milieu admettant quelques versions "intermédiaires", mais bon clairement le titre et le reste de l'article est là pour dire "il s'est quasi rien passé depuis 20 ans"; ce serait comique si c'était pas également un peu frustrant, alors qu'on fait des sorties avec de gros changements tous les quelques mois depuis des années déjà 😅).
Merci. 💌
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK 4
Posté par Maderios . Évalué à 6 (+4/-0).
Merci pour cette longue mise au point. Quand on lit sur Numerama "Cette mouture (Gimp 3, NDLR) doit succéder à GIMP 2.0, qui date du mois de mars 2004", il est évident que les gens qui ont écrit l'article ne connaissent rien au sujet, ce qui est un comble pour un site qui se présente comme "média de référence sur la société numérique". Je me demande d'ailleurs comment une telle désinformation a pu germer dans leur esprit. C'est tellement énorme que je me demande si c'est vraiment involontaire.
[^] # Re: GTK 4
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10 (+10/-0).
J'ai lu ça plein de fois sur plein de forums (genre reddit) qui sont remplis de haters qui vont prendre le fait qu'il y a pas eu de mise à jour depuis 2.0 (d'après eux, c'est logique puisque c'est +1 sur la version majeure 🙄) comme preuve que GIMP est mort et que les développeurs sont trop lents ("20 ans pour faire une seule sortie du logiciel!" 😱) avec toutes les blagues sur notre évidente incompétence. Ceux qui sont un peu moins de mauvaise foi (mais quand même) vont juste dire 2.10 donc "seulement" 6 ans. Mais bon c'est faux aussi. Tous ceux qui utilisent GIMP plus que pour du crop et de la rotation, et qui suivent un minimum les mises-à-jour savent qu'on en a tous les quelques mois (on peut aussi simplement aller jeter un œil sur le site qui a des news à chaque sortie), et à chaque fois avec de vrais grosses fonctionnalités, des améliorations de prise en charge de format, etc. etc.
Mais bon on finit par s'y habituer car à côté de cela, y a ceux qui utilisent réellement justement et qui disent plein de bonnes choses (même si c'est un peu noyé par les haters qui vont jusqu'à nous souhaiter du mal bien trop souvent; je sais pas comment certains arrivent à vivre avec eux-même quand je vois le niveau de méchanceté parfois). D'ailleurs un truc que j'adore lire de temps en temps, ce sont les avis sur le Microsoft Store. Là on a vraiment une majorité de commentaires super sympas, de gens qui disent utiliser GIMP, que ce soit pour des hobbys, pour des trucs simples, ou professionnellement, depuis des années et disent devoir beaucoup à GIMP. Ça fait chaud au cœur. Je pense que c'est la différence entre lire les vrais avis des gens qui utilisent (sur un "store", ce sont en général plutôt ceux qui utilisent qui commentent) vs. un forum générique, surtout sur l'IT ou le libre, où chacun pense qu'ils doivent avoir un avis sur tout… surtout sur ce qu'ils n'utilisent pas (faut croire).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK 4
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
mais c'est quoi leur intérêt là-dedans ? Ça fait partie des trucs qui me dépassent.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: GTK 4
Posté par Maderios . Évalué à 8 (+6/-0).
C'est les mêmes gus qui passent leurs journées sur twitter à cracher et insulter tout ce qu'ils ne comprennent pas. Là, on pourrait faire un HS plus ou moins politique mais vaut mieux s'arrêter là :)
[^] # Re: GTK 4
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Numerama c'est léger tout de même. Ils se considèrent peut-être comme un média de référence (libre à eux). Mais, c'est une référence au ras des pâquerettes.
C'est peut-être une maladresse de rédaction cela dit.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: GTK 4
Posté par freem . Évalué à 6 (+4/-0). Dernière modification le 18 novembre 2024 à 16:09.
Tout ça est assez ironique quand on sait que GTK est à l'origine Gimp ToolKit.
Blague à part, plaçons le disclaimer: je n'utilise pas gimp, je n'ai jamais réussi dans mes quelques essais, mais c'est de ma faute, je ne pense pas avoir l'usage d'un logiciel aussi poussé de toute façon.
De ce que j'en ai vu quand j'ai essayé (sans objectif réel en tête, juste voir un peu comment il marche) il était plutôt bien foutu par contre, et clairement les menus organisés et les tooltips dans un tel logiciel sont vitaux.
Cela dis, je considère ne pas passer a gtk4 comme un plutôt bon choix, et ce, sans même savoir ce que tu as révélé. Tout simplement parce que mes écrans sont trop petits et trop vieux, les applications gtk "modernes" ont des boutons dont le ratio d'efficacité est hyper faible, genre le bouton est vide aux 2/3 avec un interstice avant le prochain de plusieurs millimètres (sauf pour le navigateurs web, je suppose qu'ils modifient la totalité du bullshit gtk pour ça).
C'est simple, en fait.
Si une application m'intéresse, si elle dépend de gtk2, je n'y vois aucun problème. Si elle dépend de gtk3, je vais chercher une alternative, déjà, mais j'arrive encore a tolérer ça. Par exemple pour solvespace, d'un autre côté… la préparation du portage à GTK4 à commencé, et les emmerdes avec.
Gtk4, j'ai essayé. Ca a dégagé immédiatement.
D'ailleurs je ne sais pas comment je vais faire pour solvespace. Je sais qu'il y a du travail pour avoir d'autres toolkits, ça pourrais bien être ma bouée. Par chance, solvespace est un logiciel simple (du point de vue de l'interface utilisateur, j'entend) donc migrer le code ne sera pas trop pénible (je n'y ai pour l'instant contribué qu'un seul patch et 2-3 rapports de bugs, je ne suis vraiment pas autorité sur le sujet).
Je suis conscient de l'énorme difficulté et chronophagie de faire ce que je vais suggérer, mais il serait peut-être malgré tout plus simple de cesser de dépendre de gtk?
Evidemment, il n'existe pas d'outil parfait, et peut-être que gtk reste malgré tout pertinent pour une application de bureau qui soit plus qu'un hello world, mais franchement, je savais pas qu'ils avaient drop le support de ces fonctionnalités (tooltips, menu, treeview) je m'attendais vraiment pas à ça.
Donc, non seulement c'est une plaie à utiliser sur un écran un peu ancien, mais en plus ça ne supporte plus des fonctionnalités de base?
Hors sujet, je me demande comment wxWidget s'en sors, de nos jours, du coup.
Ce toolkit est principalement un frontal pour divers toolkits, selon l'OS, et sous linux c'est gtk3 (malheureusement, bien que de mémoire ils aient un support limité de X11 en direct) mais wxHexEditor a toujours ses menu.
Je ne sais pas s'il y avait des tooltips avant, c'est un encore logiciel simple. Mais bon, perso, je déteste le menu hamburger. En même temps, déjà IRL je suis pas fan des hamburger, mais aussi et surtout, il est impossible de deviner ce que ces trois traits superposés peuvent bien vouloir dire. On ne le sais que parce que quelqu'un nous l'a dit, c'est tout le contraire de ce qu'une interface devrais être: intuitive. Je suppose qu'ils se sont aperçu en vrai que leur espacement dans les menus bouffait tellement de place a cause de leurs thème débile que ça en devenait inutilisable, donc ils ont "corrigé" le symptôme plutôt la cause, probablement parce que ça impliquerait d'admettre que leur ergonomie est a chier et qu'ils se sont plantés sur toute la ligne.
Ce choix de gtk ne fait confirmer mon opinion de longue date sur ce toolkit.
Ah, et pour les imbéciles… je suppose qu'il faudrait que reddit mettre en avant un immense bandeau pour rediriger les incultes (l'inculture se soigne, y'a un espoir. L'imbécilité, non.) vers une description de semver.
[^] # Re: GTK 4
Posté par Stéphane Ascoët (site web personnel) . Évalué à 4 (+3/-0). Dernière modification le 18 novembre 2024 à 16:55.
Ils font comme tout le monde quoi… c'est quand même le monde à l'envers que ce soit à vous de reprogrammer du code d'interface, à la place les bibliothèques graphiques sont censées faciliter la vie, surtout, que, comme le rappelle Freem, Gimp descend originellement de GTK !
Je ne suis même pas surpris…
Tiens ça me rappelle DLFP ;-)
[^] # Re: GTK 4
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
Quand on lit la section que tu cites, certes ils justifient ce choix aussi parce qu'il y a peu d'utilisateurs, mais ils insistent aussi beaucoup sur le fait que ces notions nécessitent aussi beaucoup d'effort de maintenance pour eux en rendant le code complexe.
GTK semble souffrir d'un manque de contributeurs aussi (comme tant de LL, GIMP inclus), je peux comprendre qu'ils prennent de telles décisions s'ils jugent cela nécessaire aussi. J'ignore à quel point ils pourraient être ouverts à leur réintroduction si quelqu'un prend cela en charge correctement.
Je ne vois en tout cas pas de décision en terme de design qui font qu'ils sont hostiles à de tels menus ou des interfaces conçues ainsi.
[^] # Re: GTK 4
Posté par Yarma22 . Évalué à 3 (+3/-0).
Un grand merci Jehan pour ta réponse très détaillée. Cela correspond bien à l'idée que je m'en faisais, mais c'est super d'avoir le point de vue des premiers concernés !
C'est bien le point que je voulais soulever. Et d'après ta réponse, cela va relever une fois de plus du parcours du combattant.
À long-terme, cette tendance à la simplification de GTK, quelles qu'en soient les raisons (considérations ergonomiques, simplification du code à des fins de maintenance) et qu'on les considère bonnes ou mauvaises, est une bombe à retardement pour les applications de bureau complexes telles que GIMP.
Non seulement cela alourdi considérablement la charge de travail des développeurs d'applications pour toutes les raisons que tu cites, mais cela va inéluctablement conduire à une plus grande fragmentation du code et à une moindre intégration de ces applications avec l'environnement de bureau. En effet, les applications seront forcées de ré-implémenter chacune à leur manière ces mêmes fonctionnalités, sans aucune garantie d'homogénéité entre elles (e.g. rendu visuel, navigation au clavier, etc.). Cela ne fera qu'impacter l'expérience des utilisateurs, ce qui est un comble pour GNOME GTK.
De telles discussions existent-elles avec les mainteneurs de GTK ? Renault soulève qu'ils sont probablement peu nombreux, mais en considérant tout le travail fourni par les développeurs d'applications pour recréer ces fonctionnalités, il est vraiment dommage que cela ne puisse pas être mutualisé en amont.
Pour répondre à Renault, au delà de la simplification du code, il y a probablement des considérations ergonomiques derrière ces disparitions, à commencer par la démocratisation des écrans tactiles. Cependant, il semble à l'heure actuelle illusoire d'envisager une utilisation productive de logiciels aussi complexes que GIMP autrement qu'à la souris et au clavier.
Pour reprendre mon point précédent, dans l'idéal, GTK pourrait continuer à offrir ces fonctionnalités. Prenons l'exemple du menu burger, cela pourrait être le comportement par défaut lorsque l'on installe GIMP et il contiendrait l'ensemble des menus de premier niveau (ce qui évidemment nécessite un clic supplémentaire à chaque fois que l'on accède au menu). Et ce même widget pourrait également afficher le menu au format horizontal et de manière permanente, ce qui serait disponible via un paramètre dans les préférences.
Évidemment, cela nécessite que l'ensemble des fonctionnalités du menu de GIMP soient implémentées dans GTK (case à cocher, boutons radio, icônes personnalisées, etc.). Mais une fois encore, il serait dommage que le travail fourni par les développeurs d'applications ne puisse pas être mutualisé.
La situation est probablement bien plus complexe que je ne la décris ci-dessus. Et comme tu le dis si bien, dans l'idéal les développeurs d'applications devraient pouvoir se concentrer sur les fonctionnalités de leur logiciel et non sur le toolkit. Mais cela ne semble pas être le cas à l'heure actuelle. Je trouve juste vraiment dommage que l'on se retrouve dans cette situation qui, au final, ne profite à personne.
Tout à fait ! Il suffit d'ailleurs de suivre les dépêches que tu publies régulièrement sur le sujet et que je lis toujours avec autant de plaisir, à défaut d'utiliser toutes les fonctionnalités en question. J'espère que mon message ne laissait pas entendre le contraire :)
[^] # Re: GTK 4
Posté par Stéphane Ascoët (site web personnel) . Évalué à 8 (+7/-0).
C'est même un retour en arrière de plusieurs dizaines d'années, aussi bien côté développeur que utilisateur (les fameuses critiques : "sous Linux, aucune application n'a les mêmes ergonomies et styles graphiques" !
[^] # Re: GTK 4
Posté par Maderios . Évalué à 8 (+6/-0).
Il me semble que QT s'en tire mieux que GTK question unité visuelle et ergonomie. Le passage de QT5 à QT6 passe presque inaperçu (pour les applis que j'utilise).
[^] # Re: GTK 4
Posté par Yarma22 . Évalué à 4 (+4/-0).
Tout à fait ! Je ne disais pas autrement, c.f.:
D'où ma question, les mainteneurs de GTK ont-ils conscience de ce problème ? À titre personnel, j'apprécie le virage abordé par GNOME en termes d'ergonomie depuis la version 3. Et j'entends bien les besoins de se conformer aux nouveaux usages, à commencer par le tactile. Mais en compliquant la tâche des développeurs d'applications complexes, celles nécessitant un véritable environnement de bureau pour être exploitées correctement, et en augmentant la fragmentation ergonomique et visuelle des applications, ils sont en train de tuer l'environnement de bureau Linux à petit feu. À commencer par le leur, GNOME !
[^] # Re: GTK 4
Posté par Okki (site web personnel, Mastodon) . Évalué à 10 (+10/-1).
Pour les menus traditionnels, ça semble être désormais GtkPopoverMenuBar.
Quant à la dépréciation de GtkTreeView, on ne peut pas obtenir le même résultat avec les nouveaux GtkListView et GtkColumnView ? Quand on lit les différents articles de blog sur le sujet, ils semblaient rechercher la parité fonctionnelle…
[^] # Re: GTK 4
Posté par Yarma22 . Évalué à 1 (+0/-0).
Désolé, j'ai inutilé ton commentaire en tentant de cliquer sur les liens avec mes gros doigts depuis mon smartphone. Ah, les joies du tactiles 🙈
S'il m'était possible de changer mon vote, je t'aurais au contraire pertinenté !
[^] # Re: GTK 4
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
J'ai pertinenté pour compenser :-)
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Illustrations de Gimp
Posté par Stéphane Ascoët (site web personnel) . Évalué à 1 (+0/-0). Dernière modification le 15 novembre 2024 à 11:47.
Dommage que des variantes ne soient plus utilisées. Et il manque des images dans l'histoire des écrans d'accueil, seront-elles ajoutés plus tard ?
# Plugins dont gmic
Posté par Le Pnume . Évalué à 7 (+5/-0).
Si certain d'entre vous sont au fait du développement de plugins pour Gimp (ou si David Tschumperlé passe par ici) Savez vous si c'est un gros boulot pour migrer les plugins mais surtout Gmic pour Gimp3 ?
[^] # Re: Plugins dont gmic
Posté par David Tschumperlé (site web personnel) . Évalué à 10 (+11/-0).
Bonjour,
Oui à priori nous sommes en train de tester une version du plug-in G'MIC pour gimp 3.
Une première version est en cours de test : https://discuss.pixls.us/t/on-the-road-to-3-5/44490/40
(sous Windows par contre).
Il y a des bugs qui restent mais ça devrait déjà être utilisable. Et on espère pouvoir avoir des contributeurs par la suite qui peuvent proposer des améliorations.
Donc en tout cas, on a bon espoir d'avoir un G'MIC qui tourne pour gimp 3 correctement un de ces jours :)
[^] # Re: Plugins dont gmic
Posté par Le Pnume . Évalué à 3 (+1/-0). Dernière modification le 15 novembre 2024 à 16:17.
Cool, merci pour cette réponse rapide.
Comme je suis sous Debian Stable et carrément égoïste, vous avez un peu de temps devant vous :-)
# Colorimétrie
Posté par ekyo . Évalué à 2 (+0/-0).
Je viens de tomber sur cette news : https://www.phoronix.com/news/Wayland-Color-Management-Nears
Je ne suis pas familier avec ce domaine, mais il semblerait que wayland se dote bientôt d'un protocole de gestion de la colorimétrie.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.