Changer les DPI ça revient à changer les dimensions de l'image (en pixel) au final non ? Je ne vois pas trop la différence avec un redimensionnement du coup… Est-ce que tu peux m'expliquer quel est le besoin exact ? :)
Pour mozjpeg, j'ai compilé la dernière version disponible sur leur dépôt (https://github.com/mozilla/mozjpeg) et, étant donné que c'est un fork de libjpeg-turbo, ça fournit les mêmes outils.
Du coup j'ai utilisé le jpegtran compilé pour améliorer l'optimisation de mes images de test après les avoir compressées avec Guetzli (l'avantage étant qu'il s'agit ici d'une transformation sans perte de qualité supplémentaire).
J'ai essayé Guetzli en CLI, c'était affreusement lent, beaucoup plus que Yoga. Il y a un truc pour l'accélérer ?
Ça m'étonne beaucoup que ça soit plus lent que YOGA étant donné que j'utilise directement Guetzli comme bibliothèque derrière (via le binding Python PyGuetzli).
J'ai déjà fait quelques testes avec libjpegturbo et mozjpeg, clairement mozjpeg est plus intéressant : il me permet de gratter entre 2% et 7% supplémentaires sur l'encodage fait par Gueutzli (avec les options -optimize et -progressive qui sont sans perte) :)
L'option de redimensionnement existe déjà dans YOGA mais n'est pour le moment accessible qu'en ligne de commande. Je vais rajouter cette option dans la prochaine version de l'interface graphique, je me suis juste concentré sur l'essentiel pour la v1.0 :)
Au vu de ce que ces deux logiciels intègrent comme bibliothèques, je pense qu'ils peuvent fournir le même taux de compression que YOGA pour les JPEG et pour les PNG (à condition de rester sur de l'encodage sans perte pour ce dernier).
Globalement les outils comme ImageOptim s'appuient à peu près tous sur les mêmes bibliothèques, et les petites différences qu'il peut y avoir viennent surtout des réglages utilisés sur chacun des encodeurs…
D'ailleurs je profite de ce commentaire pour apporter quelques news sur YOGA… :)
Pour les JPEGs,
YOGA tient maintenant compte de l'orientation de l'image (pour ne plus la sortir de travers)
et je suis en train de regarder pour améliorer encore un peu la compression (en utilisant Guetzli puis en faisant un encodage progressif du résultat).
Pour les PNG
j'ai déjà apporté une petite amélioration récemment (dans certains cas rares YOGA pouvait générer des images peu plus grosses en sortie qu'en entrée, mais ce n'est plus possible, et il fera maintenant quasi systématiquement mieux d'au moins quelques octets ou au pire l'image fera le même poids)
et je regarde aussi la possibilité de rajouter une option de compression PNG à perte (en utilisant pngquant pour réduire le nombre de couleurs puis en filtrant le résultat avec ZopfliPNG puis en compressant avec Zopfli).
J'ai des trucs à regarder du côté du WebP aussi mais pas sûr que j'ai le temps de m'en occuper pour la prochaine version :)
Ça fait des années que je « traîne » ici en « lecture seule » et depuis quelque temps j'ai activé le mode « lecture écriture » (j'ai enfin créé un compte quoi :p).
Merci à tout ceux qui lisent, à ceux qui commentent, à ceux écrivent des dépêches ou des journaux, aux modérateurs et autres administrateurs… Bref à tout ceux qui permettent à ce site d'exister :)
Pour ce qui est de la conservation des métadonnées, on me l'a déjà demandé sur Mastodon, j'ai donc ouvert une issue sur le sujet. Mais c'est clairement pas la priorité et c'est beaucoup moins simple qu'il n'y parait. :)
Et pour le redimensionnement des images, l'option existe en ligne de commande mais elle n'a pas encore été implémentée dans l'interface graphique. Je compte bien l'ajouter à terme. ;)
Je pense que le problème doit être réglé dans la version actuelle du paquet (je n'ai par contre pas encore eu le temps de tester car il fait trop chaud pour que j'allume mon PC ce weekend, mais je regarderais ça lundi)
Étant donné qu'il s'agit de la toute première version, il y a effectivement certaines limitations (volontaires) dans les fonctionnalités afin de se concentrer sur le principal et être en mesure de sortir quelque chose de minimal mais de fonctionnel. Je compte bien travailler à améliorer pas mal des points évoqués par la suite.
le thème ne s'intègre pas avec le thème de l'OS (couleur de la fenêtre, icônes de gestion de la fenêtre…), ce n'est pas problématique, mais ça peut faire un peu bizarre sur certains environnements. Par exemple mon gestionnaire de fenêtre est réglé pour mettre les icônes en haut à gauche, du coup j'ai dans l'ordre : "croix" pour fermer la fenêtre, "moins" pour la réduire, "plus" pour l'agrandir, "plus" pour ajouter une image dans la liste, "moins" pour enlever une image de la liste. Ca me semblerait plus logique de mettre les boutons de gestion des images ("plus", "moins", "corbeille", "optimize" et "reglages") dans une barre d'outils sous la barre de titre de la fenêtre, quitte à perdre 20 ou 30 pixels en hauteur.
Pour ce qui est d'ajuster le thème de l'application (couleurs / icônes) :
Sous Linux, le thème GTK par défaut est utilisé (mais il reste possible d'en forcer un autre via la configuration de GTK ou via une variable d’environnement).
Sous Windows j'ai ajouté un thème qui s'intègre mieux à la plateforme (même si ce n'est pas parfait).
Quoi qu'il en soit, je pense rendre le thème GTK configurable via les options de l'application, mais ce n'est pas la priorité.
Pour les boutons de la fenêtre / la possibilité d'utiliser la barre de titre du gestionnaire de fenêtre plutôt que les décorations côté client, je verrais ce que je peux faire à ce sujet ultérieurement. C'est typiquement le genre d'options qui sont compliquées à maintenir sur le long terme (des cas supplémentaires à tester et donc des sources de bugs).
lorsqu'on ajoute une longue liste d'images, et qu'on veut leur appliquer les mêmes réglages (par exemple du PNG vers WEBP 75%), faut se taper toutes les lignes une par une. C'est dommage qu'on ne puisse pas sélectionner plusieurs lignes et appliquer les mêmes réglages pour ces images sélectionnées, ça serait plus pratique pour du traitement en masse (ou alors il y a un autre moyen que je n'ai pas trouvé)
Il s'agit d'un fonctionnalité qu'il me parait impensable de ne pas ajouter à terme.
Je me suis limité volontairement à une sélection unique pour ne pas compliquer cette première version avec une multi-sélection qui aurait été implémenté trop rapidement. Il faut encore que je réfléchisse à la meilleur manière de le faire d'un point de vue ergonomique. Mais je vais y travailler. :)
Ajouter une option "Ecraser le fichier d'origine" pour ne pas avoir à renommer les fichiers optimisés (au risque et péril de l'utilisateur). Le fait que le logiciel ajoute automatiquement ".opti" avec l'extension n'est pas toujours pratique, par exemple si un script repasse derrière pour renommer les fichiers, c'est moins facile à détecter que s'il préfixe le nom. Donc donner la possibilité de mettre autre chose que "opti" et son emplacement serait sympa.
Là encore il s'agit d'un point sur lequel j'ai fait l'impasse pour cette première version. Je réfléchis à plusieurs options pour la suite :
Pouvoir définir un pattern de nom pour les fichiers de sortir,
Stocker les images de sortie sous le même nom dans un sous dossier,
Écraser le fichier d'entrée,
…
Écrire les fichiers de sortie dans un dossier temporaire et ouvrir l'explorateur de fichier dans ce dossier m'a également été suggéré…
Il faut encore que je réfléchisse quelles options je souhaite proposer et sous quelles formes :)
Il me reste pas mal de choses à explorer aussi bien au niveau de l'interface graphique que de la bibliothèque/CLI, et les améliorations arriverons au fil des versions. Le plus important pour moi était déjà d'être en mesure de sortir cette toute première version qui me servira de base pour les évolutions futures. :)
Lepton a l'air d'être très intéressant pour faire de l'archivage d'images JPEG, mais je ne pense pas qu'il soit pertinent de l'intégrer à YOGA : le but premier de YOGA est d'optimiser les images pour le Web, et Lepton n'est pas une technologie supportée par les navigateurs. :)
Dans notre cas on utilise ces modèles 3D pour des applications WebGL, ce qui nous donne des contraintes spécifiques :
utiliser les formats d'images supportés par les navigateurs permet de garantir une compatibilité la plus large possible sur toutes les plateformes,
le formats d'image comme le JPEG et surtout le WebP sont plus performants en terme de compression, et étant donné qu'il s'agit d'application web, les temps de transfère via le réseau sont à prendre en compte,
suivant les projets on peut avoir des besoins spécifiques liés à la chaîne de production.
Dans tous les cas, on garde ça sous le coude et peut être que sur un projet il sera plus pertinent d'utiliser ces formats là :)
Quand t'as un problème avec un paquet spécifique à une distribution, il vaut généralement mieux le remonter au maintainer, qui le fera remonter "upstream" si nécessaire.
Je me demande ce que fait imageOptim pour réduire autant le PNG (je sais qu'il est possible de réduire très légèrement les couleurs pour améliorer la compression sans que ça ne soit perceptible, peut être qu'il joue là dessus ?)
Pour ce qui est de Guetzli, il est à noter qu'il ne faut normalement pas descendre en dessous de 84% (la version originale de la bibliothèque bloque d'ailleurs toute valeur inférieure).
En tout cas j'ai encore des pistes à explorer pour améliorer toujours plus l'optimisation :D
Guetzli sort uniquement des JPEG baseline et effectivement, utiliser un encodage progressif (comme le fait MozJPEG) permettrait de gratter encore quelques pourcents. C'est une suggestion qui m'a été faite sur Reddit et je compte bien creuser le sujet !
Pour ce qui est des PNG, tout comme toi, j'utilisais optipng avant… Mais il n'y a clairement pas photo, Zopfli fait mieux ! :)
Juste une petite précision du coup, WebP est à priori un peu plus lourds à décoder que JPEG ou PNG, mais sur les machines d'aujourd'hui (que ce soit sur PC ou mobile), c'est assez négligeable :)
C'est pas vraiment déléguable, et les principales difficultés sont humaines et non techniques (Gitlab dispose d'un système de migration de projet depuis Github, même si on perd généralement l'attribution des issue et des PR).
Le développement GameBoy il faut que je trouve du temps pour m'y remettre, j'ai encore tellement d'aspects à explorer ! Et puis j'aimerais bien sortir un véritable jeu GameBoy sur cartouche un de ces jours… :)
Pourquoi ne pas utiliser la forge officielle du projet Gnome ? C'est sous Gitlab CE : https://gitlab.gnome.org/
La raison est extrêmement simple : à l'époque où ce projet a été créé ainsi qu'à l'époque où il a été migré sur Github, GNOME ne disposait pas encore d'une instance Gitlab.
Migrer un projet d'une forge à une autre demande du temps et du travail ; je n'ai pas le temps ni la motivation de me lancer là-dedans pour le moment.
Pour de nouveaux projets liés à l’environnement GNOME, je considérerais bien sûr la possibilité de les hébergés sur l'instance Gitlab de GNOME, pour peu que les prérequis soient remplis¹.
du traçage des contributeurs et des visiteurs, aucune garantie ne peut être apportée quant à ce qu'il est fait des données collectées (exploitation, revente, transmission aux agences gouvernementales américaines, Patriot Act. Cloud Act., Prism…),
La GNOME Foundation est une association basée aux États-Unis. Je leur fais confiance pour ce qui est de ne pas tracer les contributeurs et de ne pas revendre leurs données. Par contre pour ce qui est des lois américaines, je pense qu'ils y sont soumis et que si le gouvernement leur demande des informations sur une personne ils n'auront pas d'autres choix que de coopérer (je peux me tromper sur ce point, je veux bien des liens vers des sources d'informations complémentaires si quelqu'un en a :)).
de l'exclusion : toute personne vivant dans un pays boycotté par le gouvernement américain, est empêchée de proposer ses contributions ; participation impossible des libristes ayant une éthique…
Il est vrai que contribuer sans avoir accès à Github est plus compliqué mais pas impossible. Je reste joignable par e-mail et un miroir du dépôt Git est disponible sur Launchpad :
¹ En pratique je m'inquiète surtout de la disponibilité et des capacités des shared runners pour la CI, notamment dans le cas où un runner Windows serait nécessaire pour la construction de version Windows de l'application (mais en pratique il devrait être possible d'exploiter la CI de Github pour une partie des tâches via un dépôt miroir (oui j'ai déjà pas mal réfléchi à la question^^)).
[^] # Re: Pourquoi ne pas ajouter la possibilité de retailler les images ?
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 2.
Changer les DPI ça revient à changer les dimensions de l'image (en pixel) au final non ? Je ne vois pas trop la différence avec un redimensionnement du coup… Est-ce que tu peux m'expliquer quel est le besoin exact ? :)
[^] # Re: Par rapport à la concurrence ?
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 1.
C'est étrange, par ce que YOGA utilise ZopfliPNG pour optimiser les PNGs donc les résultats devraient être assez similaires… :(
Tu pourrais me passer une image où cela se produit pour que je puisse reproduire et essayer de corriger ça ?
[^] # Re: Comparatif
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 2.
Pour mozjpeg, j'ai compilé la dernière version disponible sur leur dépôt (https://github.com/mozilla/mozjpeg) et, étant donné que c'est un fork de libjpeg-turbo, ça fournit les mêmes outils.
Du coup j'ai utilisé le
jpegtrancompilé pour améliorer l'optimisation de mes images de test après les avoir compressées avec Guetzli (l'avantage étant qu'il s'agit ici d'une transformation sans perte de qualité supplémentaire).Ça m'étonne beaucoup que ça soit plus lent que YOGA étant donné que j'utilise directement Guetzli comme bibliothèque derrière (via le binding Python PyGuetzli).
[^] # Re: Comparatif
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 1.
J'ai déjà fait quelques testes avec libjpegturbo et mozjpeg, clairement mozjpeg est plus intéressant : il me permet de gratter entre 2% et 7% supplémentaires sur l'encodage fait par Gueutzli (avec les options
-optimizeet-progressivequi sont sans perte) :)[^] # Re: Pourquoi ne pas ajouter la possibilité de retailler les images ?
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 4.
L'option de redimensionnement existe déjà dans YOGA mais n'est pour le moment accessible qu'en ligne de commande. Je vais rajouter cette option dans la prochaine version de l'interface graphique, je me suis juste concentré sur l'essentiel pour la v1.0 :)
[^] # Re: Comparatif
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 3.
Salut,
Au vu de ce que ces deux logiciels intègrent comme bibliothèques, je pense qu'ils peuvent fournir le même taux de compression que YOGA pour les JPEG et pour les PNG (à condition de rester sur de l'encodage sans perte pour ce dernier).
Globalement les outils comme ImageOptim s'appuient à peu près tous sur les mêmes bibliothèques, et les petites différences qu'il peut y avoir viennent surtout des réglages utilisés sur chacun des encodeurs…
D'ailleurs je profite de ce commentaire pour apporter quelques news sur YOGA… :)
Pour les JPEGs,
YOGA tient maintenant compte de l'orientation de l'image (pour ne plus la sortir de travers)
et je suis en train de regarder pour améliorer encore un peu la compression (en utilisant Guetzli puis en faisant un encodage progressif du résultat).
Pour les PNG
j'ai déjà apporté une petite amélioration récemment (dans certains cas rares YOGA pouvait générer des images peu plus grosses en sortie qu'en entrée, mais ce n'est plus possible, et il fera maintenant quasi systématiquement mieux d'au moins quelques octets ou au pire l'image fera le même poids)
et je regarde aussi la possibilité de rajouter une option de compression PNG à perte (en utilisant pngquant pour réduire le nombre de couleurs puis en filtrant le résultat avec ZopfliPNG puis en compressant avec Zopfli).
J'ai des trucs à regarder du côté du WebP aussi mais pas sûr que j'ai le temps de m'en occuper pour la prochaine version :)
# Merci
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Vingt-trois ans de LinuxFr.org. Évalué à 8.
Ça fait des années que je « traîne » ici en « lecture seule » et depuis quelque temps j'ai activé le mode « lecture écriture » (j'ai enfin créé un compte quoi :p).
Merci à tout ceux qui lisent, à ceux qui commentent, à ceux écrivent des dépêches ou des journaux, aux modérateurs et autres administrateurs… Bref à tout ceux qui permettent à ce site d'exister :)
[^] # Re: Conservation des métadonnées
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 3.
Pour ce qui est de la conservation des métadonnées, on me l'a déjà demandé sur Mastodon, j'ai donc ouvert une issue sur le sujet. Mais c'est clairement pas la priorité et c'est beaucoup moins simple qu'il n'y parait. :)
Et pour le redimensionnement des images, l'option existe en ligne de commande mais elle n'a pas encore été implémentée dans l'interface graphique. Je compte bien l'ajouter à terme. ;)
[^] # Re: Merci et question
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 1.
Je pense que le problème doit être réglé dans la version actuelle du paquet (je n'ai par contre pas encore eu le temps de tester car il fait trop chaud pour que j'allume mon PC ce weekend, mais je regarderais ça lundi)
[^] # Re: merci, et quelques remarques
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 6.
Merci pour vos retours !
Étant donné qu'il s'agit de la toute première version, il y a effectivement certaines limitations (volontaires) dans les fonctionnalités afin de se concentrer sur le principal et être en mesure de sortir quelque chose de minimal mais de fonctionnel. Je compte bien travailler à améliorer pas mal des points évoqués par la suite.
Pour ce qui est d'ajuster le thème de l'application (couleurs / icônes) :
Sous Linux, le thème GTK par défaut est utilisé (mais il reste possible d'en forcer un autre via la configuration de GTK ou via une variable d’environnement).
Sous Windows j'ai ajouté un thème qui s'intègre mieux à la plateforme (même si ce n'est pas parfait).
Quoi qu'il en soit, je pense rendre le thème GTK configurable via les options de l'application, mais ce n'est pas la priorité.
Pour les boutons de la fenêtre / la possibilité d'utiliser la barre de titre du gestionnaire de fenêtre plutôt que les décorations côté client, je verrais ce que je peux faire à ce sujet ultérieurement. C'est typiquement le genre d'options qui sont compliquées à maintenir sur le long terme (des cas supplémentaires à tester et donc des sources de bugs).
Il s'agit d'un fonctionnalité qu'il me parait impensable de ne pas ajouter à terme.
Je me suis limité volontairement à une sélection unique pour ne pas compliquer cette première version avec une multi-sélection qui aurait été implémenté trop rapidement. Il faut encore que je réfléchisse à la meilleur manière de le faire d'un point de vue ergonomique. Mais je vais y travailler. :)
Là encore il s'agit d'un point sur lequel j'ai fait l'impasse pour cette première version. Je réfléchis à plusieurs options pour la suite :
Il faut encore que je réfléchisse quelles options je souhaite proposer et sous quelles formes :)
Il me reste pas mal de choses à explorer aussi bien au niveau de l'interface graphique que de la bibliothèque/CLI, et les améliorations arriverons au fil des versions. Le plus important pour moi était déjà d'être en mesure de sortir cette toute première version qui me servira de base pour les évolutions futures. :)
[^] # Re: Lepton
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 4.
Lepton a l'air d'être très intéressant pour faire de l'archivage d'images JPEG, mais je ne pense pas qu'il soit pertinent de l'intégrer à YOGA : le but premier de YOGA est d'optimiser les images pour le Web, et Lepton n'est pas une technologie supportée par les navigateurs. :)
[^] # Re: du JPEG/PNG pour de la 3D ?
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 5.
Dans notre cas on utilise ces modèles 3D pour des applications WebGL, ce qui nous donne des contraintes spécifiques :
utiliser les formats d'images supportés par les navigateurs permet de garantir une compatibilité la plus large possible sur toutes les plateformes,
le formats d'image comme le JPEG et surtout le WebP sont plus performants en terme de compression, et étant donné qu'il s'agit d'application web, les temps de transfère via le réseau sont à prendre en compte,
suivant les projets on peut avoir des besoins spécifiques liés à la chaîne de production.
Dans tous les cas, on garde ça sous le coude et peut être que sur un projet il sera plus pertinent d'utiliser ces formats là :)
[^] # Re: Merci et question
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 4.
Quand t'as un problème avec un paquet spécifique à une distribution, il vaut généralement mieux le remonter au maintainer, qui le fera remonter "upstream" si nécessaire.
Dans le cas du paquet AUR de YOGA, le problème est connu et on est en train de travailler dessus avec le maintainer : https://github.com/wanadev/yoga/issues/35
:)
[^] # Re: Par rapport à la concurrence ?
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 2.
Je me demande ce que fait imageOptim pour réduire autant le PNG (je sais qu'il est possible de réduire très légèrement les couleurs pour améliorer la compression sans que ça ne soit perceptible, peut être qu'il joue là dessus ?)
Pour ce qui est de Guetzli, il est à noter qu'il ne faut normalement pas descendre en dessous de 84% (la version originale de la bibliothèque bloque d'ailleurs toute valeur inférieure).
En tout cas j'ai encore des pistes à explorer pour améliorer toujours plus l'optimisation :D
[^] # Re: Par rapport à la concurrence ?
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 2. Dernière modification le 17 juin 2021 à 22:55.
Guetzli sort uniquement des JPEG baseline et effectivement, utiliser un encodage progressif (comme le fait MozJPEG) permettrait de gratter encore quelques pourcents. C'est une suggestion qui m'a été faite sur Reddit et je compte bien creuser le sujet !
Pour ce qui est des PNG, tout comme toi, j'utilisais optipng avant… Mais il n'y a clairement pas photo, Zopfli fait mieux ! :)
[^] # Re: Coût du décodage ?
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 3.
Rha t'as été plus rapide que moi à répondre ! :D
Juste une petite précision du coup, WebP est à priori un peu plus lourds à décoder que JPEG ou PNG, mais sur les machines d'aujourd'hui (que ce soit sur PC ou mobile), c'est assez négligeable :)
[^] # Re: Envoi des CD
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primées d'avril 2021. Évalué à 3.
Salut, CD bien reçu, merci ! :D
[^] # Re: Bonne idée !
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Nautilus Terminal : un terminal intégré au navigateur de fichier de GNOME. Évalué à 3. Dernière modification le 11 mai 2021 à 23:32.
Un affichage arborescent ? Il y en a un dans Nautilus (après c'est peut être pas cette forme là que tu cherche ?) :
[^] # Re: Utiliser une forge libre, loyale et éthique ?
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Nautilus Terminal : un terminal intégré au navigateur de fichier de GNOME. Évalué à 3.
C'est pas vraiment déléguable, et les principales difficultés sont humaines et non techniques (Gitlab dispose d'un système de migration de projet depuis Github, même si on perd généralement l'attribution des issue et des PR).
[^] # Re: Non-fiction
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Nautilus Terminal : un terminal intégré au navigateur de fichier de GNOME. Évalué à 2.
Le développement GameBoy il faut que je trouve du temps pour m'y remettre, j'ai encore tellement d'aspects à explorer ! Et puis j'aimerais bien sortir un véritable jeu GameBoy sur cartouche un de ces jours… :)
[^] # Re: Utiliser une forge libre, loyale et éthique ?
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Nautilus Terminal : un terminal intégré au navigateur de fichier de GNOME. Évalué à 5.
La raison est extrêmement simple : à l'époque où ce projet a été créé ainsi qu'à l'époque où il a été migré sur Github, GNOME ne disposait pas encore d'une instance Gitlab.
Migrer un projet d'une forge à une autre demande du temps et du travail ; je n'ai pas le temps ni la motivation de me lancer là-dedans pour le moment.
Pour de nouveaux projets liés à l’environnement GNOME, je considérerais bien sûr la possibilité de les hébergés sur l'instance Gitlab de GNOME, pour peu que les prérequis soient remplis¹.
La GNOME Foundation est une association basée aux États-Unis. Je leur fais confiance pour ce qui est de ne pas tracer les contributeurs et de ne pas revendre leurs données. Par contre pour ce qui est des lois américaines, je pense qu'ils y sont soumis et que si le gouvernement leur demande des informations sur une personne ils n'auront pas d'autres choix que de coopérer (je peux me tromper sur ce point, je veux bien des liens vers des sources d'informations complémentaires si quelqu'un en a :)).
Il est vrai que contribuer sans avoir accès à Github est plus compliqué mais pas impossible. Je reste joignable par e-mail et un miroir du dépôt Git est disponible sur Launchpad :
https://code.launchpad.net/~flozz/nautilus-terminal/+git/nautilus-terminal/+ref/master
¹ En pratique je m'inquiète surtout de la disponibilité et des capacités des shared runners pour la CI, notamment dans le cas où un runner Windows serait nécessaire pour la construction de version Windows de l'application (mais en pratique il devrait être possible d'exploiter la CI de Github pour une partie des tâches via un dépôt miroir (oui j'ai déjà pas mal réfléchi à la question
^^)).[^] # Re: Paquet Manjaro
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Nautilus Terminal : un terminal intégré au navigateur de fichier de GNOME. Évalué à 4.
La série sur Pétrolette est effectivement assez intéressante :)
J'essayerais de refaire un article lors du passage à GTK 4… si j'y survis…
^^'Oui j'ai vu que le paquet Arch avait été marqué out-of-date, il va sûrement être mis à jour prochainement :)
[^] # Re: Non-fiction
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Nautilus Terminal : un terminal intégré au navigateur de fichier de GNOME. Évalué à 4.
Merci ! Ça reste l'un de mes articles préféré sur mon blog avec celui sur VIM :)
[^] # Re: Merci 2 fois ...
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Nautilus Terminal : un terminal intégré au navigateur de fichier de GNOME. Évalué à 3.
Effectivement, j'avais vu passé le fork pour Nemo ! :D
Par contre je ne sais pas à quel point il est maintenu / à jour par rapport à Nautilus Terminal :)
[^] # Re: Petite question
Posté par FLOZz (site web personnel, Mastodon) . En réponse à la dépêche Nautilus Terminal : un terminal intégré au navigateur de fichier de GNOME. Évalué à 7.
Salut,
Non effectivement il n'y a pas de touche pour passer le focus de Nautilus au terminal et inversement. Je note la suggestion pour plus tard :)