Le problème, c'est que depuis des décennies, l'écologie – en particulier l'écologie politique – a été la chasse gardée d'associations et de partis qui sont dans le dogme et pas dans le consensus scientifique. Pire, ces gens là ont tellement réussi à prendre l'ascendant sur le mot « écologie » que toute proposition, fusse-t-elle étayée, qui sort de leur dogme, est considérée comme hérétique et dénoncée comme telle en place publique – même si la voix de l'écologie à base scientifique se fait de plus en plus entendre. On parle ici de gens qui sont prêts à raconter absolument tout et n'importe quoi dans le but de soutenir leur lutte, et ce même si ça va à la fois contre le consensus scientifique et toute forme d'acceptabilité sociale. On parle ici de gens qui n'imaginent pas que l'on puisse penser comme eux, et qui ne sont pas dans une démarche positive, qui ne cherchent pas à convaincre et à montrer les aspects positifs des actions qu'ils préconisent ; non : pour eux, toute parole qui ne suit pas leur dogme doit être tue1, et si on pense différemment c'est obligatoirement qu'on a tord. Le fait de convaincre du bien-fondé des opinions, celui de rassurer sur le fait que certaines mesures n'auront pas les conséquences délétères que l'on pourrait imaginer surtout si on s'y mets tôt avec assez de moyens, rien de tout ça n'entre en ligne de compte, et pour cause : on est censés être déjà convaincu du bien-fondé de toutes ces mesures – ou être idiot.
Dans le cadre de l'écologie politique, c'est encore pire : à ces dogmes se superposent le dogme de l'opposition : « Puisque les écologistes proposent X et qu'on est dans l'opposition, alors on va proposer l'inverse de X » – et ce sans la moindre considération pour ce qui serait intéressant pour la population et les écosystèmes. C'est comme ça qu'on arrive à des « débats » dans lesquels, par exemple, certains soutiennent qu'il faut impérativement se débarrasser des centrales électriques nucléaires, d'autres qu'il faudrait arrêter d'investir dans les énergies renouvelables et construire massivement des centrales nucléaires… sans jamais que personne ne se rappelle que le vrai problème, c'est d'abord et avant tout de se débarrasser des énergies fossiles, l'électricité nucléaire ou les énergies renouvelables n'état qu'un moyen pour atteindre ce but.
Et donc on en arrive en effet à une situation extrêmement frustrante, une lutte complètement hypocrite, à base de dogmes sans trop de rapports avec le consensus scientifique, où chacun défend son bout de gras parce que c'est son_ bout de gras, et pas parce que c'est une solution pour le bien commun.
Heureusement on entends de plus en plus – mais toujours pas assez – des partisans d'une écologie scientifique, beaucoup moins dogmatique2 dans son approche du sujet. Certains ont fait une image pour présenter la différence :
L'une des différences majeures, c'est que l'écologie scientifique ne propose quasiment jamais une solution miracle, mais très souvent un ensemble de chemins possibles avec leurs avantages et inconvénients ; à la chose politique de choisir lequel de ces chemins emprunter à partir de ces données. Comme exemple, on pourrait donner les différents de production électrique en 2050 par RTE.
À titre personnel, autant je trouve l'écologie politique « traditionnelle » absolument insupportable, autant l'écologie scientifique me passionne. Si je devais donner un point d'entrée dans le sujet, ça serait sans doute l'excellente chaine Le Réveilleur.
Par exemple, en faisant en sorte que les réunions d'information du public ne puissent pas se tenir parce que les militants empêchent les différents orateurs de prendre la parole – c'est doublement pratique, parce que non seulement aucune voix discordante ne peut être tenue, mais en plus ça permet de râler sur le fait qu'aucune réunion d'information publique n'a été faite. ↩
Mais pas toujours dépourvue de dogmes. Par contre, je ne parle ici que d'une véritable écologie scientifique. Ceci, en particulier, en exclut les scientistes, des dogmatiques qui sont persuadés qu'on peut faire un peu n'importe quoi parce que « la science » apportera des solutions. Notez d'ailleurs que certains points de dogmes écologistes sont aussi scientistes, par exemple quand certaines solutions proposées impliquent la mise en service massive et rapide de technologies qui sont à peine à l'état du démonstrateur aujourd'hui – je pense par exemple au stockage massif de l'électricité. ↩
La question derrière ma remarque, c'est que je ne sais pas si Nashorn (ou Rhino) faisaient partie de l'API standard, ni si le tooling fait partie de l'API standard.
C'est une question ouverte, pas une affirmation, et je vois des arguments dans les deux sens.
Pour moi si tu faisais : java -jar appli.jar avec java8 et qu'en mettant à jour java la commande tel quelle ne fonctionne plus c'est un problème de rétrocompatibilité.
Dans ce cas pour moi on ne parle pas de la même chose. Je parle de la rétrocompatibilité des ABI et API uniquement, pas de la plateforme en entier.
Pour les sealed, tous les enum sont sealed. J'ai découvert pour l'occasion que tu pouvais mock un enum avant (et qu'on avait un test qui s'en servait), c'est une (très) mauvaise idée amha, mais tu ne peux plus à partir de java17.
On a jamais pu étendre un enum. Si un outil de test se servait d'une bidouille pour forcer quelque chose de normalement impossible (ici : créer une classe de mock qui étends l'enum) et que ça finit par péter, c'est pas de chance, mais pour moi c'est pas un problème de rétrocompatibilité : le comportement n'avait jamais été prévu ni officialisé.
Parce que non seulement ils cassent la compatibilité, mais en plus ils déprécient des parties (le plus connu c'est quand ils ont souhaité déprécier sun.misc.Unsafe).
Pour moi déprécier sun.** n'est pas « casser la rétrocompatibilité », puisque Sun puis Oracle ont toujours dit que ces packages étaient à usage interne, ne faisaient pas partie de l'API et ne devaient pas être utilisés. D'ailleurs des programmes qui utilisaient ces classes ne fonctionnaient pas sur des JVM non-Sun/Oracle, à commencer par la JVM d'IBM.
Mais du coup tu entends quoi par « sainte » ?
Le fait que Java n'hésite pas à faire des doublons d'API, mais surtout des montages compliqués, des tonnes de sucre syntaxique qui masquent des pièges et finissent par aboutir à des demi-solutions bancales et peu pratiques. Par exemple et sans réfléchir : tout le système de boxing/unboxing, le type erasure dans les generics, la (non) gestion des checked exceptions dans les lambda – qui en plus n'a pas de solution élégante dans l'API standard.
Quel est le remplacement de HashMap ?
En fait il fallait lire HashTable (qui a été remplacée par HashMap justement).
Pour Protégé, le problème vient en fait d'Apache Felix, une dépendance qu'ils ont dans une vieille version et qui a besoin d'une version spécifique pour fonctionner avec Java 9+. Alors pourquoi cette bibliothèque a besoin d'une version spécifique Java 9+ et n'est pas rétrocompatible ? C'est pas très clair, mais je dirais que c'est à cause des changements de comportements dans le classloader. Je me permet aussi d'émettre un doute sur la qualité du code de Protégé : le fichier de démarrage force la taille de la pile à 16 Mo (!) par défaut, ce qui est gigantesque et extrêmement inhabituel.
Pour ImageJ, ils utilisent assez massivement le moteur JS intégré à Java… qui a changé et finalement été supprimé. Là effectivement, c'est dommage, ils ont parié sur une solution non pérenne pour leur outil.
OMERO je ne sais pas, le projet a l'air assez verrouillé.
Freeplane, je n'ai pas trouvé de vrais tickets sur une incompatibilité avec Java 17. Ceux que je trouve sont soit des gens qui ont essayé de faire tourner ce programme graphique avec un JRE headless, soit des vérifications préliminaires qui plantent, mais qui ne semblent avoir été qu'une vérification un peu trop stricte du numéro de version de Java (le fait qu'il ne validait que 8, 11 à 16 me fait penser que les développeurs forçaient un peu violemment une version « officiellement supportée » du JRE).
Dans les deux premiers cas, on est un peu sur des cas aux limites : l'ABI est compatible, l'API est compatible, mais quelque chose dans les outils et/ou la configuration externe fait que ça ne fonctionne plus. C'est clairement une rupture de compatibilité, mais à quel point c'est imputable à une non rétrocompatibilité de l'ABI ou de l'API de Java ?
Même question que ci-dessus : est-ce que tu as des exemples ?
Je vois bien des problèmes de rétrocompatibilité (dans le sens : une vieille classe ne tourne plus sur une JVM récente) avec le passage de Java EE à Jakarta et le retrait de Nashorn.
Pour les modules et les sealed, je vois bien les problèmes de compatibilité mais je n'ai pas entendu parler de problèmes de _rétro_compatiblité au sens ci-dessus. Il y a bien des cas où tu es obligé d'ajouter des dépendances de modules d'API standard pour utiliser de vieilles classes dans un code récent qui utilise les modules, mais pour moi c'est un problème de compatibilité et pas de rétrocompatibilité, dans le sens où la vieille classe elle-même fonctionnera sans modification. Je n'ai pas non plus trouvé d'exemples après une recherche rapide ni n'en ait subi, donc si tu en as je prends.
Enfin et surtout, « sainte » ≠ « absolue » hein. Il y a des ruptures de compatibilité – il suffit d'aller sur les releases notes pour les voir, changez le numéro de version dans l'URL pour voir les autres, à partir de Java 10. Mais ça n'est que des changements dans les outils et options externes. Les rares changements d'API sont soit sur des API internes – je ne vais pas plaindre les gens dont le code a pété parce qu'ils utilisaient sun.misc.BASE64Decoder soit des trucs fondamentalement pétés depuis longtemps, soit des problèmes de sécurité, comme les récentes protections sur la réflexion, qui a bien mis le bazar dans les codes qui fonctionnaient précisément à cause de ce manque de protection, comme au hasard certains mods Minecraft.
Et surtout, je n'ai vu aucun changement d'ABI, ce qui est quand même le sujet d'origine.
Un truc qui me gonfle avec la gestion de la compatibilité de Java, c'est qu'il semble y avoir une horreur à déprécier officiellement des trucs malgré la présence de remplacements depuis des décennies. Aujourd'hui, mi-2022, tu peux écrire du code complet à base de Vector, HashMap, Date et autres objets qui ont des remplacements bien plus pratiques sans que le langage ne te sorte le moindre avertissement. Que ces antiquités soient conservées pour la compatibilité, OK, mais elles n'ont plus rien à faire dans un code actuel.
C'est peut-être ça qui manque à un langage qui veut garder autant de rétrocompatibilité que possible : un moyen de marquer une sorte de soft deprecated, qui indique que la fonctionnalité va être conservée pour compatibilité mais ne devrait plus être utilisée dans du code moderne – avec un indicateur la nouvelle méthode. Je pense que ça aiderait pas mal à améliorer la qualité de code, en particulier de tous les projets faits dans des usines à code où les développeurs n'en ont pas grand-chose à faire de suivre les nouveautés du langage.
La viticulture, qui consacre trop souvent des terres fertiles à la production de boissons à faible valeur alimentaire ;
Je ne sais pas si l'exemple est très pertinent : beaucoup de viticultures ont été développées sur des terrains complètement pourris (très secs, caillouteux, en forte pente… certaines vignes sont plantées à la barre à mine !), sur lesquels il est pratiquement impossible de faire pousser quoi que ce soit d'autre.
Si tu as une statistique des vignes à vin qui squattent des terres bonnes à une agriculture plus généraliste, ça m'intéresse.
De ce que je comprends de la spécification, Java est aussi beaucoup plus tolérant que C++ sur ce qu'on peut changer dans les binaires sans casser l'ABI.
Et malgré ça, la Sainte Rétrocompatibilité de Java (ou même de la seule JVM) – que l'on parle de l'ABI ou de l'API standard ici – n'est pas sans poser de problèmes.
En ce qui concerne les agressions sur la voie publique de nuit, tous les témoignages dont j'ai connaissance se sont déroulés à des endroits parfaitement éclairés, et souvent pas complètement déserts. Ça inclus les témoignages de gens que je connais personnellement et les cas assez graves pour remonter dans les journaux locaux.
Donc je comprends ton argument, mais je doute qu'on puisse réellement en déduire quoi que ce soit.
Quand on vit dans certains quartier on voit bien la dérence entre zones eclairees zt zones non éclairées.
Ça c'est une impression qui revient très souvent (et qui conduit à des pétitions quand l'éclairage est éteint en fin de nuit). Le problème est surtout de déterminer à quel point c'est une impression, et à quel point c'est un fait.
La question est très courante et a même fait l'objet d'une question au gouvernement en 2019 (page 183 numérotée 403). Par contre contrairement à ce que je disais de souvenir dans mon message précédent, les retours qu'on a sur ce point ne sont pas des études (au sens plus ou moins scientifique – ou alors sont franchement douteuses) mais des témoignages de maires et autres responsables de la sécurité de lieux où l'éclairage à été coupé. Cf par exemple ici, ici, ici, ici, ici, ici ou encore là – sélection totalement au pif qui ne prétends absolument pas être exaustive.
Le dernier lien donne d'ailleurs des statistiques :
Les données de la gendarmerie et des compagnies d’assurances sur
les liens entre sécurité et éclairage public sont pourtant très parlantes :
80% des cambriolages ont lieu le jour
55% des cambriolages sont commis entre 14 et 17 heures.
99% des délits et méfaits nocturnes ont lieu dans des rues parfaitement éclairées
Pour les cambriolages nocturnes, c'est surtout les entreprises qui sont attaquées la nuit, les particuliers plutôt en journée… c'est logique, on cambriole quand les gens ont le plus de chance de ne pas être chez eux.
Bref, il n'y a peut-être pas de consensus au sens « consensus scientifique » pour dire que la suppression de l'éclairage public dégrade la sécurité. Par contre, on a quand même un très bon faisceau d'indice en ce sens, quand bien même ça irait contre une idée extrêmement commune et très ancienne.
Les sources que je trouve donnent des efficacités lumineuses tantôt meilleures pour les LED (en progression très rapide), tantôt meilleure pour les lampes à vapeur de sodium. Par contre, la durée de vie théorique des LED est presque toujours meilleure.
Cela dit, comme les lampes à vapeur de sodium se font remplacer presque partout en constatant des économies importantes, on peut supposer que les modèles commerciaux sont réellement rentables.
Les LED posent aussi des problèmes. Souvent les nouveaux lampadaires éclairent trop – par exemple, en bas de chez moi c'est tellement bien éclairé qu'on est au-dessus des normes requises dans un bureau ; d'autre part la lumière à large spectre des LED provoque beaucoup plus de perturbations que le rayonnement presque monochromatique des ampoules à vapeur de sodium, que ce soit sur la faune ou sur les astronomes.
Mais surtout, on éclaire beaucoup trop nos rues la nuit, souvent toutes les rues et toute la nuit dans les villes, alors qu'on pourrait très bien commencer par enlever la moitié des réverbères et couper le reste. Soit une partie de la nuit, soit en les activant par détecteurs quand quelqu'un passe, soit… en les coupant complètement, on a presque tous des lampes de poches dans nos poches maintenant. Quant à la sécurité – l'une des principales raisons de cette débauche d'éclairage depuis que l'éclairage public existe – toutes les études sur le sujet montre qu'en fait il n'a pratiquement aucun effet…
Dans l’absolu, je n’ai rien contre ces proverbes. Certains me semblent mêmes plutôt pertinents hors du cadre de Go – langage que je ne pratique pas.
Par contre, il faut les prendre pour ce qu’ils sont : des proverbes à l’attention des développeurs Go. S’ils peuvent être utiles dans ce cadre, rien ne dit qu’ils le soient encore au-delà, et l’appréciation est à faire au cas par cas avant de les sortir de leur contexte. Hélas, j’ai croisé plusieurs zélateurs de Go qui s’en servent comme d’une espèce de dogme universel, et qui peuvent être très pénibles avec ça. Heureusement, ce n’est qu’une minorité de la communauté Go – bruyante1, mais une minorité quand même.
Bref, si vous utilisez ces proverbes, assurez-vous d’abord qu’ils soient pertinents dans le contexte, surtout si la discussion ne parle pas de Go à priori.
Vous voyez, les admirateurs de Linux qui répondent toujours « Oui mais Linux remplacera bien ton M$ windaube » à n’importe quelle question concernant Windows, ou les fans de Rust qui postent des tickets « On devrait réécrire ce projet en Rust » un peu partout ? Ben l’équivalent, mais pour Go. Ne soyez pas ces pénibles, le principal impact de ces comportements est de faire fuir vos interlocuteurs. ↩
Comme Java, dont la seconde version de l'API de gestion temporelle est une quasi repompe de Joda Time, ou qui reprends à sa sauce des concepts déjà essayés dans Kotlin. Si Joda Time a disparu en pratique par réintroduction dans le standard, Kotlin lui continue à vivre sa vie en parallèle, donc là aussi différents futurs pour les modèles sont possibles.
Bref, le changement n'est pas énorme, il avait déjà prévu de partir !
De mon point de vue, perdre le contributeur principal de la fonctionnalité clé du produit, c’est énorme. Même si s’il a déjà prévu de partir – surtout s’il a déjà prévu de partir, en fait, parce que ça veut dire qu’il n’y a même plus tellement d’espoir que la communication reprenne.
Ce qui est intéressant aussi est que tous les exemples que tu donnes et qui ne vont pas, sont les apports d'Aurélien. Donc les défauts d'interface que tu soulèves dans ton commentaire est son travail.
Soyons sérieux deux minutes : ça n’est pas le cas. Je veux bien croire que la profusion de modules soit une conséquence de son travail, mais il propose une solution dans son fork pour la corriger au moins en partie (PS : et que l’organisation des options de ses propres modules ne soit pas meilleure que les autres). Par contre, les options en vrac au sein des modules, c’est comme ça depuis très longtemps ; cf par exemple le manuel de darktable 2.0 (décembre 2015) dans lequel on retrouve pléthore de ces cas, dont l’exemple du module d’exposition que j’ai cité.
Enfin, sur ce point :
Concernant les critiques de l'interface, elles sont connues mais elles sont aussi le revers (tu l'évoque d'ailleurs dans ton article très bien, du choix de darktable : apporter des traitements puissants et à la main de l'utilisateur de bout en bout.
La métaphore de l’avion est intéressante et pertinente : contrairement à une voiture, un avion laisse l’accès à énormément de paramètres – même s’il y a beaucoup, beaucoup d’automatismes en sous-main. Ça veut dire qu’effectivement, l’interface de pilotage des avions est chargée d’énormément de fonctionnalités. Par contre, ça ne veut absolument pas dire que tout est en vrac. Au contraire : les avions font l’objet d’études ergonomiques assez poussées pour que ce qui est le plus important et le plus utile au quotidien soit le plus accessible possible, tout comme les éléments de sécurité. Et ça peut aller loin : par exemple, les commandes de volets – primordiales pour l’atterrissage – sont souvent d’une forme spécifique reconnaissable au toucher dans un cockpit enfumé, et cette commande peut être munie de sûretés physiques qui empêchent de faire par mégarde certaines manœuvres qui seraient dangereuses.
Et donc, oui, la philosophie de darktable impose que l’utilisateur ait accès à beaucoup de contrôles. Ça n’implique pas que tous ces contrôles doivent avoir la même priorité et la même facilité d’accès.
Le design de darktable a été énormément amélioré avec le thème gris – en plus de résoudre des problèmes de risques quant à la luminosité perçue des photos traitées, et ça c’est une excellente chose. Par contre, d’un point de vue utilisateur, son ergonomie est encore très perfectible. Pour moi, on est très loin de « quelques rugosités restantes ».
Je pense très honnêtement que le prochain axe d’amélioration de darktable est là-dessus. Le problème, c’est que les ergonomes dans le monde open-source, c’est rarissime – et ça demande d’être assez résistant pour se prendre les déluges de commentaires de powerusers qui ne supportent pas qu’on supprime ou même qu’on rende un peu plus difficile d’accès des options qu’ils sont les seuls à utiliser, cf le cas de Gnome par exemple. De même, un des outils très pratiques pour savoir quelles sont les fonctionnalités réellement utilisées (et donc détecter celles qui sont importantes, ou détecter les échecs de découvert de fonctionnalité) c’est de tracer tout ça et d’envoyer les données dans un outil centralisé… ce qui est quelque chose qui est généralement très mal vu dans le monde du libre. Ça impose donc de passer par des sondages, des retours d’expériences en corrigeant le fait que c’est pas ceux qui crient le plus fort qui sont majoritaires, etc. qui sont des choses longues et complexes à faire, et qu’à peu près personne n’est prêt à faire de façon bénévole pour un projet libre.
Bref, j’espère tout de même un futur radieux à darktable malgré ces problèmes internes au projet, et que les prochaines versions seront aussi de grande qualité, et que vous pourrez progresser sur l’ergonomie.
Je vous aiderais bien sur tout ça, mais d’une part mes connaissances en ergonomie sont limitées, et d’autre part je n’ai déjà pas le temps de réaliser le quart de mes projets actuels.
Ma dernière phrase sur le futur de darktable, c’était plutôt à prendre dans le sens : les deux points de vue (et façon de faire) n’ont pas l’air conciliable, et je trouverais très dommage pour le projet que vous vous engueuliez au point que l’upstream ne profite plus des améliorations d’Aurélien sur la partie colorimétrique.
Concernant ses positions, sa façon de les présenter est clairement excessive et peu productive, et de mon point de vue il fait des montagnes de trucs qui n’en valent clairement pas la peine.
Cela dit, je pense qu’il y a un fond de vérité dans ce qu’il dit : l’interface de darktable est extrêmement touffue et pas toujours adaptée aux photographes. Certain détails et fonctionnement sont clairement des « trucs de développeur » (comme les icônes « et/ou » du nouveau filtre de couleur). Plus généralement, les deux difficultés d’accès que je trouve à darktable d’un point de vue ergonomie1 sont :
La profusion de modules dont beaucoup fond doublons (notamment à cause du double fonctionnement relatif à l’affichage ou à la scène). Il y a bien les réglages pour sélectionner des ensembles cohérents de modules, mais ça reste quand même très facile de mélanger (cf d’autres commentaires sous cette même dépêche, par exemple).
Le mélange complet, dans l’interface des modules, des options « généralement utiles » et des options « on l’a mis parce que ça peut servir mais normalement vous n’avez pas à y toucher.
Je détaille le point 2 avec un exemple. Si j’ai besoin d’utiliser l’égaliseur de ton, en traitement relatif à la scène, j’aurai sans doute besoin d’aller régler les compensations d’exposition et de contraste du masque pour avoir un masque cohérent. Mais ça, c’est les options n°6 et 7 de l’onglet « masque ». Les deux premières, c’est le choix de l’estimateur de luminance et la méthode de préservation des détails, qui sont deux options d’usage franchement rare.
Ça peut même provoquer facilement des problèmes : dans le module d’exposition, il y a en accès direct une « correction du niveau du noir » qui donne très envie de s’en servir pour augmenter la densité… ce qu’il ne faut surtout pas faire parce que ça pose plein de problèmes ensuite. En fait, un usage « légitime » de cette option est rare, est-ce qu’elle a besoin d’être aussi visible ? (Il y a bien un avertissement, mais encore faut-il y faire attention… ou même le voir : je peux jouer avec ce curseur en le survolant et en actionnant la molette sans que la popup apparaisse).
D’une manière générale, il y a de grosses avancées (le thème gris neutre apparu il y a quelques versions est beaucoup plus propre que ce qu’il y avait avant), il y a beaucoup d’aides de partout, mais on a encore beaucoup besoin de lire des tooltips ou la doc pour des trucs qui ne devraient pas en avoir besoin.
Il y a aussi des fonctionnalités qui sont développées d’une façon qui me fait dire qu’elles n’ont pas été testées par des non-développeurs, ou que les retours n’ont pas (encore) été intégrés. Dans les fonctionnalités de la v4.0.0 que je range là-dedans, il y a le mapping d’exposition/colorimétrie (soyons clairs : pour moi la fonctionnalité est géniale, et totalement inutilisable), ou à plus petite échelle, la très bonne idée du nom de couleur qui ne s’affiche pas au survol du patch qui montre la couleur sélectionnée (elle ne s’affiche qu’au survol des chiffres à côté, le survol du patch ne montre que la tooltip « cacher/montrer le grand patch de couleur », idem pour ledit grand patch).
PS : j’ai l’impression qu’il y a un début de travail en ce sens avec des options de module planquées dans un sous-menu déroulant – comme « coefficients des canaux » dans « balance des blancs », mais ça mériterait d’être généralisé.
Ce genre de retour m’a été confirmé par ma mère, photographe professionnelle de 60 ans, qui a testé darktable et s’est retrouvée noyée dans les boutons, menus et tout. Outre l’apprentissage du système de couleur, sa principale difficulté était de retrouver les réglages pour faire ce qu’elle voulait, même quand elle savait quel module et en gros quels curseurs utiliser pour arriver à ses fins. Et du coup elle reste sur l’outil de « dérawtisation » fourni par son fournisseur de matériel photographique2.
En résumé : beaucoup de mauvaise communication dans tout ça j’ai l’impression, et c’est dommage : il y a pour moi de vrais axes d’amélioration ergonomique pour darktable, et pour transformer son côté « jouet pour développeur » sur certains aspect en « outil pour photographe ».
Je mets de côté le choix de montrer tous les traitements et de pouvoir les activer/désactiver/modifier, parce que c’est le choix du logiciel ; et le fait de devoir (ré)apprendre le fonctionnement des traitements de couleur, parce que ces traitements sont pour moi la plus grande force de darktable. Et aucun de ces deux points ne se règle complètement ou même principalement par l’ergonomie. ↩
Qui, d’un point de vue ergonomie et performances, est une bouse absolue qu’il faut qu’Aurélien ne voie jamais sous peine de faire une crise cardiaque :D Sans déconner, je ne sais pas comment ils font pour avoir un outil activement développé et aussi inefficace. Non, je ne donnerai pas la marque. ↩
L’un des problèmes de darktable actuellement, c’est qu’il y a des modules qui traitent l’image par rapport à la scène (le flux « moderne ») et d’autres par rapport à l’image (dans Lab, le flux « ancien »). Or, mélanger ces deux types de modules, c’est risquer des résultats imprévus, en particulier dans la gestion des couleurs.
Les modules suivant fonctionnent dans Lab et ne devraient pas être utilisés si votre flux de travail est basé sur la scène :
Attention, ce billet a dix ans maintenant, et la solution proposée n’est plus d’actualité. La solution moderne et propre proposée consiste à changer les seuils dans Filmique (cf mon lien pour les détails) est valable quel que soit la méthode de reconstruction des hautes lumières sélectionnée. Par contre, elle est un peu plus longue et délicate que les raccourcis évoqués dans la dépêche.
Après avoir vu sa vidéo, je le trouve un peu raide quand même dans ses commentaires. Il y a plein de points sur lesquels il a raison, mais je pense qu’il surestime les problèmes posés à l’utilisateur final, parce qu’il y a certaines modifications qu’il juge gênantes qui sont en fait pratiquement invisibles. Je pense en particulier à la possibilité de réorganiser les modules, aux filtres de collections (pliés par défaut chez moi, je n’avais même pas vu qu’ils existaient alors qu’il râle plusieurs fois sur le fait que ça prendrait « un tiers de la colonne de gauche »…), au sélecteur d’étoiles qu’il trouve peu ergonomique alors que je le trouve beaucoup plus pratique que la solution précédente, ou encore au palanquées d’options que l’immense majorité des gens se contenteront d’ignorer. Ah, et aussi les lenteurs de l’interface, qui est quelque chose que je n’ai jamais constaté – même si je veux bien croire que d’un point de vue technique, on pourrait faire beaucoup mieux.
(Digression : c’est un truc de développeur, ça, les options par tombereaux. Ça peut se justifier pour certains types d’utilisateurs qui ont besoin/envie – beaucoup « envie » en fait – de configurer chaque pixel et chaque comportement de leur outil, mais pour l’immense majorité des gens dans l’immense majorité des utilisations, l’immense majorité des options n’est que du bruit. C’est quelque chose dont les développeurs feraient bien de se rappeler, tout comme ils feraient bien de se rappeler qu’une option, c’est aussi du code pour la gérer, et plein de possibilité d’interactions imprévues qui viennent avec).
Ce qui m’inquiète surtout, c’est que ce qu’il explique et la position des développeurs upstream ne présagent rien de bon pour le futur de darktable…
Cela dit, j’ai regardé vite fait le pourquoi du comment, et les mécanismes qu’il décrit qui ont conduit aux problèmes en question (notamment, des décisions collégiales là où ça n’a pas de sens) sont un problème hélas classique des projets libres – en tous cas de ceux qui sont développés par plus de une personne.
J’espère que son fork va pouvoir montrer des choses intéressantes qui pourront être remontées dans le projet principal.
Je crois aussi que c’est lui qui est principalement derrière les modules Filmique et la modernisation du pipeline graphique, j’espère que ça ne va pas le dégouter de continuer à contribuer sur ces points.
J'ai vu que les notes de version ont été traduites, donc je me suis dit que ça valait le coup d'essayer quelque chose d'un peu différent, surtout pour un logiciel dont ça n'est pas évident de l'extérieur de comprendre à quoi il sert. Tant mieux si ça plait !
… Sinon tu peux aussi admettre que tu n'aimes pas le média et son contenu pour des raisons qui te sont propres et qui tu ne détaillera pas, et qui par conséquent tu ne leur donneras pas le moindre centime.
Ça serait tout à fait acceptable, et plus honnête que les tentatives de "justifications" qui tu nous sors là.
[^] # Re: Je m'en fiche de plus en plus.
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Hypocrisie d'énergie . Évalué à 10.
Le problème, c'est que depuis des décennies, l'écologie – en particulier l'écologie politique – a été la chasse gardée d'associations et de partis qui sont dans le dogme et pas dans le consensus scientifique. Pire, ces gens là ont tellement réussi à prendre l'ascendant sur le mot « écologie » que toute proposition, fusse-t-elle étayée, qui sort de leur dogme, est considérée comme hérétique et dénoncée comme telle en place publique – même si la voix de l'écologie à base scientifique se fait de plus en plus entendre. On parle ici de gens qui sont prêts à raconter absolument tout et n'importe quoi dans le but de soutenir leur lutte, et ce même si ça va à la fois contre le consensus scientifique et toute forme d'acceptabilité sociale. On parle ici de gens qui n'imaginent pas que l'on puisse penser comme eux, et qui ne sont pas dans une démarche positive, qui ne cherchent pas à convaincre et à montrer les aspects positifs des actions qu'ils préconisent ; non : pour eux, toute parole qui ne suit pas leur dogme doit être tue1, et si on pense différemment c'est obligatoirement qu'on a tord. Le fait de convaincre du bien-fondé des opinions, celui de rassurer sur le fait que certaines mesures n'auront pas les conséquences délétères que l'on pourrait imaginer surtout si on s'y mets tôt avec assez de moyens, rien de tout ça n'entre en ligne de compte, et pour cause : on est censés être déjà convaincu du bien-fondé de toutes ces mesures – ou être idiot.
Dans le cadre de l'écologie politique, c'est encore pire : à ces dogmes se superposent le dogme de l'opposition : « Puisque les écologistes proposent X et qu'on est dans l'opposition, alors on va proposer l'inverse de X » – et ce sans la moindre considération pour ce qui serait intéressant pour la population et les écosystèmes. C'est comme ça qu'on arrive à des « débats » dans lesquels, par exemple, certains soutiennent qu'il faut impérativement se débarrasser des centrales électriques nucléaires, d'autres qu'il faudrait arrêter d'investir dans les énergies renouvelables et construire massivement des centrales nucléaires… sans jamais que personne ne se rappelle que le vrai problème, c'est d'abord et avant tout de se débarrasser des énergies fossiles, l'électricité nucléaire ou les énergies renouvelables n'état qu'un moyen pour atteindre ce but.
Et donc on en arrive en effet à une situation extrêmement frustrante, une lutte complètement hypocrite, à base de dogmes sans trop de rapports avec le consensus scientifique, où chacun défend son bout de gras parce que c'est son_ bout de gras, et pas parce que c'est une solution pour le bien commun.
Heureusement on entends de plus en plus – mais toujours pas assez – des partisans d'une écologie scientifique, beaucoup moins dogmatique2 dans son approche du sujet. Certains ont fait une image pour présenter la différence :
L'une des différences majeures, c'est que l'écologie scientifique ne propose quasiment jamais une solution miracle, mais très souvent un ensemble de chemins possibles avec leurs avantages et inconvénients ; à la chose politique de choisir lequel de ces chemins emprunter à partir de ces données. Comme exemple, on pourrait donner les différents de production électrique en 2050 par RTE.
À titre personnel, autant je trouve l'écologie politique « traditionnelle » absolument insupportable, autant l'écologie scientifique me passionne. Si je devais donner un point d'entrée dans le sujet, ça serait sans doute l'excellente chaine Le Réveilleur.
Par exemple, en faisant en sorte que les réunions d'information du public ne puissent pas se tenir parce que les militants empêchent les différents orateurs de prendre la parole – c'est doublement pratique, parce que non seulement aucune voix discordante ne peut être tenue, mais en plus ça permet de râler sur le fait qu'aucune réunion d'information publique n'a été faite. ↩
Mais pas toujours dépourvue de dogmes. Par contre, je ne parle ici que d'une véritable écologie scientifique. Ceci, en particulier, en exclut les scientistes, des dogmatiques qui sont persuadés qu'on peut faire un peu n'importe quoi parce que « la science » apportera des solutions. Notez d'ailleurs que certains points de dogmes écologistes sont aussi scientistes, par exemple quand certaines solutions proposées impliquent la mise en service massive et rapide de technologies qui sont à peine à l'état du démonstrateur aujourd'hui – je pense par exemple au stockage massif de l'électricité. ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Google forke C++. Évalué à 2.
La question derrière ma remarque, c'est que je ne sais pas si Nashorn (ou Rhino) faisaient partie de l'API standard, ni si le tooling fait partie de l'API standard.
C'est une question ouverte, pas une affirmation, et je vois des arguments dans les deux sens.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Google forke C++. Évalué à 4.
Dans ce cas pour moi on ne parle pas de la même chose. Je parle de la rétrocompatibilité des ABI et API uniquement, pas de la plateforme en entier.
On a jamais pu étendre un enum. Si un outil de test se servait d'une bidouille pour forcer quelque chose de normalement impossible (ici : créer une classe de mock qui étends l'enum) et que ça finit par péter, c'est pas de chance, mais pour moi c'est pas un problème de rétrocompatibilité : le comportement n'avait jamais été prévu ni officialisé.
Pour moi déprécier
sun.**n'est pas « casser la rétrocompatibilité », puisque Sun puis Oracle ont toujours dit que ces packages étaient à usage interne, ne faisaient pas partie de l'API et ne devaient pas être utilisés. D'ailleurs des programmes qui utilisaient ces classes ne fonctionnaient pas sur des JVM non-Sun/Oracle, à commencer par la JVM d'IBM.Le fait que Java n'hésite pas à faire des doublons d'API, mais surtout des montages compliqués, des tonnes de sucre syntaxique qui masquent des pièges et finissent par aboutir à des demi-solutions bancales et peu pratiques. Par exemple et sans réfléchir : tout le système de boxing/unboxing, le type erasure dans les generics, la (non) gestion des checked exceptions dans les lambda – qui en plus n'a pas de solution élégante dans l'API standard.
En fait il fallait lire
HashTable(qui a été remplacée parHashMapjustement).La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Google forke C++. Évalué à 5.
Je suis curieux, alors j'ai creusé un peu.
Dans les deux premiers cas, on est un peu sur des cas aux limites : l'ABI est compatible, l'API est compatible, mais quelque chose dans les outils et/ou la configuration externe fait que ça ne fonctionne plus. C'est clairement une rupture de compatibilité, mais à quel point c'est imputable à une non rétrocompatibilité de l'ABI ou de l'API de Java ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Google forke C++. Évalué à 4.
Même question que ci-dessus : est-ce que tu as des exemples ?
Je vois bien des problèmes de rétrocompatibilité (dans le sens : une vieille classe ne tourne plus sur une JVM récente) avec le passage de Java EE à Jakarta et le retrait de Nashorn.
Pour les modules et les sealed, je vois bien les problèmes de compatibilité mais je n'ai pas entendu parler de problèmes de _rétro_compatiblité au sens ci-dessus. Il y a bien des cas où tu es obligé d'ajouter des dépendances de modules d'API standard pour utiliser de vieilles classes dans un code récent qui utilise les modules, mais pour moi c'est un problème de compatibilité et pas de rétrocompatibilité, dans le sens où la vieille classe elle-même fonctionnera sans modification. Je n'ai pas non plus trouvé d'exemples après une recherche rapide ni n'en ait subi, donc si tu en as je prends.
Enfin et surtout, « sainte » ≠ « absolue » hein. Il y a des ruptures de compatibilité – il suffit d'aller sur les releases notes pour les voir, changez le numéro de version dans l'URL pour voir les autres, à partir de Java 10. Mais ça n'est que des changements dans les outils et options externes. Les rares changements d'API sont soit sur des API internes – je ne vais pas plaindre les gens dont le code a pété parce qu'ils utilisaient
sun.misc.BASE64Decodersoit des trucs fondamentalement pétés depuis longtemps, soit des problèmes de sécurité, comme les récentes protections sur la réflexion, qui a bien mis le bazar dans les codes qui fonctionnaient précisément à cause de ce manque de protection, comme au hasard certains mods Minecraft.Et surtout, je n'ai vu aucun changement d'ABI, ce qui est quand même le sujet d'origine.
Un truc qui me gonfle avec la gestion de la compatibilité de Java, c'est qu'il semble y avoir une horreur à déprécier officiellement des trucs malgré la présence de remplacements depuis des décennies. Aujourd'hui, mi-2022, tu peux écrire du code complet à base de
Vector,HashMap,Dateet autres objets qui ont des remplacements bien plus pratiques sans que le langage ne te sorte le moindre avertissement. Que ces antiquités soient conservées pour la compatibilité, OK, mais elles n'ont plus rien à faire dans un code actuel.C'est peut-être ça qui manque à un langage qui veut garder autant de rétrocompatibilité que possible : un moyen de marquer une sorte de soft deprecated, qui indique que la fonctionnalité va être conservée pour compatibilité mais ne devrait plus être utilisée dans du code moderne – avec un indicateur la nouvelle méthode. Je pense que ça aiderait pas mal à améliorer la qualité de code, en particulier de tous les projets faits dans des usines à code où les développeurs n'en ont pas grand-chose à faire de suivre les nouveautés du langage.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Oui
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Hypocrisie d'énergie . Évalué à 10.
Juste pour répondre à ceci :
Je ne sais pas si l'exemple est très pertinent : beaucoup de viticultures ont été développées sur des terrains complètement pourris (très secs, caillouteux, en forte pente… certaines vignes sont plantées à la barre à mine !), sur lesquels il est pratiquement impossible de faire pousser quoi que ce soit d'autre.
Si tu as une statistique des vignes à vin qui squattent des terres bonnes à une agriculture plus généraliste, ça m'intéresse.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Google forke C++. Évalué à 4.
De ce que je comprends de la spécification, Java est aussi beaucoup plus tolérant que C++ sur ce qu'on peut changer dans les binaires sans casser l'ABI.
Et malgré ça, la Sainte Rétrocompatibilité de Java (ou même de la seule JVM) – que l'on parle de l'ABI ou de l'API standard ici – n'est pas sans poser de problèmes.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et surtout...
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Hypocrisie d'énergie . Évalué à 6.
En ce qui concerne les agressions sur la voie publique de nuit, tous les témoignages dont j'ai connaissance se sont déroulés à des endroits parfaitement éclairés, et souvent pas complètement déserts. Ça inclus les témoignages de gens que je connais personnellement et les cas assez graves pour remonter dans les journaux locaux.
Donc je comprends ton argument, mais je doute qu'on puisse réellement en déduire quoi que ce soit.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et surtout...
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Hypocrisie d'énergie . Évalué à 10.
Ça c'est une impression qui revient très souvent (et qui conduit à des pétitions quand l'éclairage est éteint en fin de nuit). Le problème est surtout de déterminer à quel point c'est une impression, et à quel point c'est un fait.
La question est très courante et a même fait l'objet d'une question au gouvernement en 2019 (page 183 numérotée 403). Par contre contrairement à ce que je disais de souvenir dans mon message précédent, les retours qu'on a sur ce point ne sont pas des études (au sens plus ou moins scientifique – ou alors sont franchement douteuses) mais des témoignages de maires et autres responsables de la sécurité de lieux où l'éclairage à été coupé. Cf par exemple ici, ici, ici, ici, ici, ici ou encore là – sélection totalement au pif qui ne prétends absolument pas être exaustive.
Le dernier lien donne d'ailleurs des statistiques :
Pour les cambriolages nocturnes, c'est surtout les entreprises qui sont attaquées la nuit, les particuliers plutôt en journée… c'est logique, on cambriole quand les gens ont le plus de chance de ne pas être chez eux.
Bref, il n'y a peut-être pas de consensus au sens « consensus scientifique » pour dire que la suppression de l'éclairage public dégrade la sécurité. Par contre, on a quand même un très bon faisceau d'indice en ce sens, quand bien même ça irait contre une idée extrêmement commune et très ancienne.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et surtout...
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Hypocrisie d'énergie . Évalué à 10.
Les sources que je trouve donnent des efficacités lumineuses tantôt meilleures pour les LED (en progression très rapide), tantôt meilleure pour les lampes à vapeur de sodium. Par contre, la durée de vie théorique des LED est presque toujours meilleure.
Cela dit, comme les lampes à vapeur de sodium se font remplacer presque partout en constatant des économies importantes, on peut supposer que les modèles commerciaux sont réellement rentables.
Les LED posent aussi des problèmes. Souvent les nouveaux lampadaires éclairent trop – par exemple, en bas de chez moi c'est tellement bien éclairé qu'on est au-dessus des normes requises dans un bureau ; d'autre part la lumière à large spectre des LED provoque beaucoup plus de perturbations que le rayonnement presque monochromatique des ampoules à vapeur de sodium, que ce soit sur la faune ou sur les astronomes.
Mais surtout, on éclaire beaucoup trop nos rues la nuit, souvent toutes les rues et toute la nuit dans les villes, alors qu'on pourrait très bien commencer par enlever la moitié des réverbères et couper le reste. Soit une partie de la nuit, soit en les activant par détecteurs quand quelqu'un passe, soit… en les coupant complètement, on a presque tous des lampes de poches dans nos poches maintenant. Quant à la sécurité – l'une des principales raisons de cette débauche d'éclairage depuis que l'éclairage public existe – toutes les études sur le sujet montre qu'en fait il n'a pratiquement aucun effet…
La connaissance libre : https://zestedesavoir.com
# Ce sont des proverbes de développement Go, et pas un dogme universel
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Go proverbs. Évalué à 7.
Dans l’absolu, je n’ai rien contre ces proverbes. Certains me semblent mêmes plutôt pertinents hors du cadre de Go – langage que je ne pratique pas.
Par contre, il faut les prendre pour ce qu’ils sont : des proverbes à l’attention des développeurs Go. S’ils peuvent être utiles dans ce cadre, rien ne dit qu’ils le soient encore au-delà, et l’appréciation est à faire au cas par cas avant de les sortir de leur contexte. Hélas, j’ai croisé plusieurs zélateurs de Go qui s’en servent comme d’une espèce de dogme universel, et qui peuvent être très pénibles avec ça. Heureusement, ce n’est qu’une minorité de la communauté Go – bruyante1, mais une minorité quand même.
Bref, si vous utilisez ces proverbes, assurez-vous d’abord qu’ils soient pertinents dans le contexte, surtout si la discussion ne parle pas de Go à priori.
Vous voyez, les admirateurs de Linux qui répondent toujours « Oui mais Linux remplacera bien ton M$ windaube » à n’importe quelle question concernant Windows, ou les fans de Rust qui postent des tickets « On devrait réécrire ce projet en Rust » un peu partout ? Ben l’équivalent, mais pour Go. Ne soyez pas ces pénibles, le principal impact de ces comportements est de faire fuir vos interlocuteurs. ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Google forke C++. Évalué à 9.
+1, et on peut multiplier les exemples.
Comme Java, dont la seconde version de l'API de gestion temporelle est une quasi repompe de Joda Time, ou qui reprends à sa sauce des concepts déjà essayés dans Kotlin. Si Joda Time a disparu en pratique par réintroduction dans le standard, Kotlin lui continue à vivre sa vie en parallèle, donc là aussi différents futurs pour les modèles sont possibles.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Mon retour
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 4.
Dans un post d'Aurélien, je ne sais plus où exactement.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Un calendrier bourgeois
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Calendrier républicain (script de conversion des dates). Évalué à 4.
C'est tout à fait logique, la révolution française ayant été surtout une révolution bourgeoise et libérale.
Pour qui ça intéresse, je conseille cette excellente série de vidéos, qui en plus fournit les sources pour aller vérifier ce qui y est dit.
La connaissance libre : https://zestedesavoir.com
# « Bref, c'est plus compliqué que ça en a l'air. »
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Calendrier républicain (script de conversion des dates). Évalué à 8.
La conclusion « Bref, c'est plus compliqué que ça en a l'air. » peut être considérée comme une vérité générale dès qu’on touche à quoi que ce soit qui ait un rapport avec la gestion temporelle.
Faites très attention à ce que vous faites, et ne vous lancez jamais dans des calculs hasardeux à base de
const HOUR_IN_SECONDS = 3600.La connaissance libre : https://zestedesavoir.com
[^] # Re: r-darktable
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 8. Dernière modification le 11 juillet 2022 à 23:47.
De mon point de vue, perdre le contributeur principal de la fonctionnalité clé du produit, c’est énorme. Même si s’il a déjà prévu de partir – surtout s’il a déjà prévu de partir, en fait, parce que ça veut dire qu’il n’y a même plus tellement d’espoir que la communication reprenne.
Soyons sérieux deux minutes : ça n’est pas le cas. Je veux bien croire que la profusion de modules soit une conséquence de son travail, mais il propose une solution dans son fork pour la corriger au moins en partie (PS : et que l’organisation des options de ses propres modules ne soit pas meilleure que les autres). Par contre, les options en vrac au sein des modules, c’est comme ça depuis très longtemps ; cf par exemple le manuel de darktable 2.0 (décembre 2015) dans lequel on retrouve pléthore de ces cas, dont l’exemple du module d’exposition que j’ai cité.
Enfin, sur ce point :
La métaphore de l’avion est intéressante et pertinente : contrairement à une voiture, un avion laisse l’accès à énormément de paramètres – même s’il y a beaucoup, beaucoup d’automatismes en sous-main. Ça veut dire qu’effectivement, l’interface de pilotage des avions est chargée d’énormément de fonctionnalités. Par contre, ça ne veut absolument pas dire que tout est en vrac. Au contraire : les avions font l’objet d’études ergonomiques assez poussées pour que ce qui est le plus important et le plus utile au quotidien soit le plus accessible possible, tout comme les éléments de sécurité. Et ça peut aller loin : par exemple, les commandes de volets – primordiales pour l’atterrissage – sont souvent d’une forme spécifique reconnaissable au toucher dans un cockpit enfumé, et cette commande peut être munie de sûretés physiques qui empêchent de faire par mégarde certaines manœuvres qui seraient dangereuses.
Et donc, oui, la philosophie de darktable impose que l’utilisateur ait accès à beaucoup de contrôles. Ça n’implique pas que tous ces contrôles doivent avoir la même priorité et la même facilité d’accès.
Le design de darktable a été énormément amélioré avec le thème gris – en plus de résoudre des problèmes de risques quant à la luminosité perçue des photos traitées, et ça c’est une excellente chose. Par contre, d’un point de vue utilisateur, son ergonomie est encore très perfectible. Pour moi, on est très loin de « quelques rugosités restantes ».
Je pense très honnêtement que le prochain axe d’amélioration de darktable est là-dessus. Le problème, c’est que les ergonomes dans le monde open-source, c’est rarissime – et ça demande d’être assez résistant pour se prendre les déluges de commentaires de powerusers qui ne supportent pas qu’on supprime ou même qu’on rende un peu plus difficile d’accès des options qu’ils sont les seuls à utiliser, cf le cas de Gnome par exemple. De même, un des outils très pratiques pour savoir quelles sont les fonctionnalités réellement utilisées (et donc détecter celles qui sont importantes, ou détecter les échecs de découvert de fonctionnalité) c’est de tracer tout ça et d’envoyer les données dans un outil centralisé… ce qui est quelque chose qui est généralement très mal vu dans le monde du libre. Ça impose donc de passer par des sondages, des retours d’expériences en corrigeant le fait que c’est pas ceux qui crient le plus fort qui sont majoritaires, etc. qui sont des choses longues et complexes à faire, et qu’à peu près personne n’est prêt à faire de façon bénévole pour un projet libre.
Bref, j’espère tout de même un futur radieux à darktable malgré ces problèmes internes au projet, et que les prochaines versions seront aussi de grande qualité, et que vous pourrez progresser sur l’ergonomie.
Je vous aiderais bien sur tout ça, mais d’une part mes connaissances en ergonomie sont limitées, et d’autre part je n’ai déjà pas le temps de réaliser le quart de mes projets actuels.
La connaissance libre : https://zestedesavoir.com
[^] # Re: r-darktable
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 8. Dernière modification le 11 juillet 2022 à 21:26.
Merci à vous deux pour vos commentaires !
Ma dernière phrase sur le futur de darktable, c’était plutôt à prendre dans le sens : les deux points de vue (et façon de faire) n’ont pas l’air conciliable, et je trouverais très dommage pour le projet que vous vous engueuliez au point que l’upstream ne profite plus des améliorations d’Aurélien sur la partie colorimétrique.
Concernant ses positions, sa façon de les présenter est clairement excessive et peu productive, et de mon point de vue il fait des montagnes de trucs qui n’en valent clairement pas la peine.
Cela dit, je pense qu’il y a un fond de vérité dans ce qu’il dit : l’interface de darktable est extrêmement touffue et pas toujours adaptée aux photographes. Certain détails et fonctionnement sont clairement des « trucs de développeur » (comme les icônes « et/ou » du nouveau filtre de couleur). Plus généralement, les deux difficultés d’accès que je trouve à darktable d’un point de vue ergonomie1 sont :
Je détaille le point 2 avec un exemple. Si j’ai besoin d’utiliser l’égaliseur de ton, en traitement relatif à la scène, j’aurai sans doute besoin d’aller régler les compensations d’exposition et de contraste du masque pour avoir un masque cohérent. Mais ça, c’est les options n°6 et 7 de l’onglet « masque ». Les deux premières, c’est le choix de l’estimateur de luminance et la méthode de préservation des détails, qui sont deux options d’usage franchement rare.
Ça peut même provoquer facilement des problèmes : dans le module d’exposition, il y a en accès direct une « correction du niveau du noir » qui donne très envie de s’en servir pour augmenter la densité… ce qu’il ne faut surtout pas faire parce que ça pose plein de problèmes ensuite. En fait, un usage « légitime » de cette option est rare, est-ce qu’elle a besoin d’être aussi visible ? (Il y a bien un avertissement, mais encore faut-il y faire attention… ou même le voir : je peux jouer avec ce curseur en le survolant et en actionnant la molette sans que la popup apparaisse).
D’une manière générale, il y a de grosses avancées (le thème gris neutre apparu il y a quelques versions est beaucoup plus propre que ce qu’il y avait avant), il y a beaucoup d’aides de partout, mais on a encore beaucoup besoin de lire des tooltips ou la doc pour des trucs qui ne devraient pas en avoir besoin.
Il y a aussi des fonctionnalités qui sont développées d’une façon qui me fait dire qu’elles n’ont pas été testées par des non-développeurs, ou que les retours n’ont pas (encore) été intégrés. Dans les fonctionnalités de la v4.0.0 que je range là-dedans, il y a le mapping d’exposition/colorimétrie (soyons clairs : pour moi la fonctionnalité est géniale, et totalement inutilisable), ou à plus petite échelle, la très bonne idée du nom de couleur qui ne s’affiche pas au survol du patch qui montre la couleur sélectionnée (elle ne s’affiche qu’au survol des chiffres à côté, le survol du patch ne montre que la tooltip « cacher/montrer le grand patch de couleur », idem pour ledit grand patch).
PS : j’ai l’impression qu’il y a un début de travail en ce sens avec des options de module planquées dans un sous-menu déroulant – comme « coefficients des canaux » dans « balance des blancs », mais ça mériterait d’être généralisé.
Ce genre de retour m’a été confirmé par ma mère, photographe professionnelle de 60 ans, qui a testé darktable et s’est retrouvée noyée dans les boutons, menus et tout. Outre l’apprentissage du système de couleur, sa principale difficulté était de retrouver les réglages pour faire ce qu’elle voulait, même quand elle savait quel module et en gros quels curseurs utiliser pour arriver à ses fins. Et du coup elle reste sur l’outil de « dérawtisation » fourni par son fournisseur de matériel photographique2.
En résumé : beaucoup de mauvaise communication dans tout ça j’ai l’impression, et c’est dommage : il y a pour moi de vrais axes d’amélioration ergonomique pour darktable, et pour transformer son côté « jouet pour développeur » sur certains aspect en « outil pour photographe ».
Je mets de côté le choix de montrer tous les traitements et de pouvoir les activer/désactiver/modifier, parce que c’est le choix du logiciel ; et le fait de devoir (ré)apprendre le fonctionnement des traitements de couleur, parce que ces traitements sont pour moi la plus grande force de darktable. Et aucun de ces deux points ne se règle complètement ou même principalement par l’ergonomie. ↩
Qui, d’un point de vue ergonomie et performances, est une bouse absolue qu’il faut qu’Aurélien ne voie jamais sous peine de faire une crise cardiaque :D Sans déconner, je ne sais pas comment ils font pour avoir un outil activement développé et aussi inefficace. Non, je ne donnerai pas la marque. ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: Si on ne comprend pas c'est que
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 9.
Le pouvoir du BÉPO :)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Mon retour
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 7.
L’un des problèmes de darktable actuellement, c’est qu’il y a des modules qui traitent l’image par rapport à la scène (le flux « moderne ») et d’autres par rapport à l’image (dans
Lab, le flux « ancien »). Or, mélanger ces deux types de modules, c’est risquer des résultats imprévus, en particulier dans la gestion des couleurs.Les modules suivant fonctionnent dans
Labet ne devraient pas être utilisés si votre flux de travail est basé sur la scène :La connaissance libre : https://zestedesavoir.com
[^] # Re: La solution propre au problème de la reconstruction des couleurs qui donne du magenta
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 6.
Attention, ce billet a dix ans maintenant, et la solution proposée n’est plus d’actualité. La solution moderne et propre proposée consiste à changer les seuils dans Filmique (cf mon lien pour les détails) est valable quel que soit la méthode de reconstruction des hautes lumières sélectionnée. Par contre, elle est un peu plus longue et délicate que les raccourcis évoqués dans la dépêche.
La connaissance libre : https://zestedesavoir.com
# La solution propre au problème de la reconstruction des couleurs qui donne du magenta avec Filmique
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 6.
Voici la solution propre au problème de la reconstruction des couleurs qui donne du magenta avec Filmique (vidéo Youtube en anglais avec un accent français).
La « solution » que je donne dans la dépêche est en fait la version « simple et sale qui consiste à planquer la poussière sous le tapis ».
La connaissance libre : https://zestedesavoir.com
[^] # Re: r-darktable
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 7. Dernière modification le 11 juillet 2022 à 10:59.
Après avoir vu sa vidéo, je le trouve un peu raide quand même dans ses commentaires. Il y a plein de points sur lesquels il a raison, mais je pense qu’il surestime les problèmes posés à l’utilisateur final, parce qu’il y a certaines modifications qu’il juge gênantes qui sont en fait pratiquement invisibles. Je pense en particulier à la possibilité de réorganiser les modules, aux filtres de collections (pliés par défaut chez moi, je n’avais même pas vu qu’ils existaient alors qu’il râle plusieurs fois sur le fait que ça prendrait « un tiers de la colonne de gauche »…), au sélecteur d’étoiles qu’il trouve peu ergonomique alors que je le trouve beaucoup plus pratique que la solution précédente, ou encore au palanquées d’options que l’immense majorité des gens se contenteront d’ignorer. Ah, et aussi les lenteurs de l’interface, qui est quelque chose que je n’ai jamais constaté – même si je veux bien croire que d’un point de vue technique, on pourrait faire beaucoup mieux.
(Digression : c’est un truc de développeur, ça, les options par tombereaux. Ça peut se justifier pour certains types d’utilisateurs qui ont besoin/envie – beaucoup « envie » en fait – de configurer chaque pixel et chaque comportement de leur outil, mais pour l’immense majorité des gens dans l’immense majorité des utilisations, l’immense majorité des options n’est que du bruit. C’est quelque chose dont les développeurs feraient bien de se rappeler, tout comme ils feraient bien de se rappeler qu’une option, c’est aussi du code pour la gérer, et plein de possibilité d’interactions imprévues qui viennent avec).
Ce qui m’inquiète surtout, c’est que ce qu’il explique et la position des développeurs upstream ne présagent rien de bon pour le futur de darktable…
La connaissance libre : https://zestedesavoir.com
[^] # Re: r-darktable
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 7.
Je n’était pas au courant donc, pas grand-chose.
Cela dit, j’ai regardé vite fait le pourquoi du comment, et les mécanismes qu’il décrit qui ont conduit aux problèmes en question (notamment, des décisions collégiales là où ça n’a pas de sens) sont un problème hélas classique des projets libres – en tous cas de ceux qui sont développés par plus de une personne.
J’espère que son fork va pouvoir montrer des choses intéressantes qui pourront être remontées dans le projet principal.
Je crois aussi que c’est lui qui est principalement derrière les modules Filmique et la modernisation du pipeline graphique, j’espère que ça ne va pas le dégouter de continuer à contribuer sur ces points.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et aussi…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Darktable 4.0.0 est sorti. Évalué à 3.
Merci à vous deux.
J'ai vu que les notes de version ont été traduites, donc je me suis dit que ça valait le coup d'essayer quelque chose d'un peu différent, surtout pour un logiciel dont ça n'est pas évident de l'extérieur de comprendre à quoi il sert. Tant mieux si ça plait !
La connaissance libre : https://zestedesavoir.com
[^] # Re: Inportent
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Next INpact lance un S.O.S.. Évalué à 9.
… Sinon tu peux aussi admettre que tu n'aimes pas le média et son contenu pour des raisons qui te sont propres et qui tu ne détaillera pas, et qui par conséquent tu ne leur donneras pas le moindre centime.
Ça serait tout à fait acceptable, et plus honnête que les tentatives de "justifications" qui tu nous sors là.
La connaissance libre : https://zestedesavoir.com