24-07-22, 01:10
(Modification du message : 24-07-22, 02:41 par aurelienpierre.)
On nage en pleine fallacie de l'inclusivité bidon.
En ce moment, bouger le curseur dans l'interface table lumineuse de mon fork de darktable (22 000 lignes en moins par rapport à la version upstream) fait monter l'utilisation du CPU entre 11 à 20 %. En comparaison, l'ensemble de mon environnement de bureau (KDE plasma) consomme 8 à 17 % en remuant la souris sur les icônes système.
Mon CPU, c'est un Xeon cadencé à 4.2 Ghz. Dans quelle dimension alternative est-ce qu'il est acceptable d'allouer autant de puissance à la seule interface graphique pour faire strictement rien (remuer la souris) ? Ça donne quoi pour les gens qui ont des i5 cadencés à moins de 3 GHz ?
La raison, c'est qu'on a beaucoup trop de widgets Gtk faits maison, codés n'importe comment, qui capturent beaucoup trop d'événements utilisateur pour des raisons souvent cosmétiques et pour des fonctionnalités anecdotiques. Point barre. Ça c'est pour les perf.
Maintenant l'utilisabilité. Un logiciel, c'est une boîte à outils. On pourrait se dire qu'avoir dans notre boîte à outils toutes les dimensions de clés plates entre 6 et 25 mm, ça nous prépare à toutes les éventualités. La réalité, c'est que :
1. certaines dimensions ne serviront jamais,
2. certaines dimensions serviront peu,
3. celles que servent peu ou pas sont peut-être inutilisables, en fait on n'en sait rien vu que… on s'en sert peu ou pas.
4. des clés plates en chrome-vanadium, ça finit vite par peser… faut la traîner la boîte,
5. la clé dont on a besoin est toujours celle planquée dans le fond, et pour y accéder, il faut vider tout le contenu de la boîte par terre. C'est frustrant, ça fait perdre du temps, et au final "être prêt à tout" nous met en retard tout le temps.
Et bien sûr, les clés plates, c'est juste une partie des outils. Ensuite, on a les clés allen, les tournevis, etc.
La solution, c'est d'avoir seulement les dimensions courantes, et une ou deux clés à molette pour les cas exotiques. Voire de s'arranger avec une pince multiprise pour tenir les écrous vraiment hors catégorie. Ça n'a rien d'original, le principe remonte au système Gribeauval, qui date du XVIIIe siècle (https://www.cairn.info/revue-gerer-et-co...age-41.htm).
Dans darktable, la clé à molette, c'est la possibilité de scripter en Lua pour les usages de niche. Mais refuser de faire le tri entre les fonctionnalités d'usage courant et les fonctionnalités exotiques, c'est dégrader l'interface pour tout le monde. Le meilleur endroit pour cacher un arbre, c'est au milieu de la forêt. Depuis 2 ans, on est en train de planquer toujours plus profond les fonctionnalités essentielles derrière les fonctionnalités qui servent à 3 mecs, mais qui demandent 2000 lignes de code et qui capturent tous les événements mouse_moved, même pour les utilisateurs qui n'en ont rien à faire.
Parce que, encore une fois, un widget Gtk consomme de la puissance CPU qu'il soit visible ou caché. Au minimum parce qu'il peut être mappé à des raccourcis clavier et parce qu'on doit changer sa couleur de fond quand la souris le survole, et Gtk n'a aucun mécanisme pour éviter de redessiner les éléments non visibles dans la fenêtre.
Se planquer derrière le fait que, quoi qu'on fasse, certains ne seront pas contents, est encore une fallacie. L'objectif, c'est la loi de Pareto, le 80/20. darktable sert à trier ce qui sort de la carte mémoire et à transformer des raw en images finales. Tout ce qui ne sert pas directement cet objectif est de l'overhead et doit être limité au minimum.
Tous les retours utilisateurs ne sont pas à prendre au pied de la lettre. Tous les usages ne sont pas valides. Certains utilisateurs ont des workflows inutilement compliqués et on n'a pas à leur donner plus d'outils pour être encore plus inefficaces : ils doivent changer leur méthode de travail.
Mais en termes d'utilisateurs, les seuls avec lesquels on interagit sont sur Github. C'est à dire principalement des programmeurs, actuels ou retraités, parce que Github est une plateforme d'hébergement de code et intimide les non-programmeurs. C'est un énorme biais d'échantillon, par rapport à une majorité silencieuse de gens qui ne parlent pas forcément anglais et ne savent pas comment utiliser Github. D'autant que pour comprendre ce dont l'utilisateur a besoin à travers ce qu'il veut (spoiler alert : les gens sont incapables d'exprimer clairement leurs besoins, faut leur tirer les vers du nez pire qu'une enquête de police judiciaire), y a un effort à fournir et c'est un métier : designer.
En bref, tout merger et tout garder pour faire plaisir à tout le monde, ça emmerde tout le monde est c'est d'une naïveté folle. La vie c'est des choix.
Après, faut encore discuter de la qualité du design sur les fonctionnalités "mises à jour". Par exemple, depuis le bordel MIDI, les touches numériques ne sont pas détectées pareil suivant qu'on utilise le pavé numérique ou la barre numérique au dessus des lettres. En clair, attribuer des étoiles à des images via le clavier est cassé, sauf pour les utilisateurs qui penseront à configurer le pavé numérique comme alternative. En plus, moi, sur clavier BÉPO, les touches numériques au dessus du texte sont détectées comme Maj+&, Maj+é, Maj+", etc. Ah mais on peut configurer des triple-clics et des cliqué-déplacés, génial. Un sens des priorités qui m'échappe : on casse des fonctionnalités basiques pour introduire des fonctionnalités totalement secondaires, tout est fait en dépit du bon sens. Avant ça, on utilisait les accels Gtk qui décodaient les caractères correctement, peu importe la touche physique utilisée. Vive le progrès.
Et ben non. Merde. Je refuse ces conneries. Le projet darktable est mort, tué par une bande de Gaston Lagaffe qui jouent à coder. Photographes amateurs, devenus développeurs amateurs, devenus designers amateurs… la médiocrité à tous les étages. L'interface a toujours été son point faible, mais là on atteint des sommets de stupidité. Je bosse pas à l'éducation nationale, je pratique pas le 10/20 pour l'effort et la médaille en chocolat. Un outil marche ou il ne marche pas, et les excuses ne m'intéressent pas.
Ah ça, le projet est actif. Pour s'agiter, ça s'agite. Pleins de gens qui bossent sans direction commune et sans axes d'améliorations définis, qui codent des trucs qui créent plus de problèmes qu'ils n'en règlent, et qui demandent toujours plus de travail pour corriger des bugs parfois très sournois… C'est pas compliqué, un projet qui demande une quantité de travail croissante au cours du temps a un problème fondamental, surtout s'agissant d'un projet informatique, parce que le principe de l'informatique est d'automatiser des trucs, pas de créer du travail. Qu'on ne me raconte pas que 15 mecs qui agitent les bras sans méthode, ça fait un projet en bonne santé. Il suffit d'ouvrir le code source et de lire… En 4 ans on a eu… 3 réécritures complètes de la table lumineuse ? Remarque, c'est toujours plus facile de réécrire que de dénouer les spaghetti.
Au moins, un cancer, ça s'arrête à la mort du patient. La croissance anarchique des fonctionnalités de darktable n'aura pas ce privilège.
En ce moment, bouger le curseur dans l'interface table lumineuse de mon fork de darktable (22 000 lignes en moins par rapport à la version upstream) fait monter l'utilisation du CPU entre 11 à 20 %. En comparaison, l'ensemble de mon environnement de bureau (KDE plasma) consomme 8 à 17 % en remuant la souris sur les icônes système.
Mon CPU, c'est un Xeon cadencé à 4.2 Ghz. Dans quelle dimension alternative est-ce qu'il est acceptable d'allouer autant de puissance à la seule interface graphique pour faire strictement rien (remuer la souris) ? Ça donne quoi pour les gens qui ont des i5 cadencés à moins de 3 GHz ?
La raison, c'est qu'on a beaucoup trop de widgets Gtk faits maison, codés n'importe comment, qui capturent beaucoup trop d'événements utilisateur pour des raisons souvent cosmétiques et pour des fonctionnalités anecdotiques. Point barre. Ça c'est pour les perf.
Maintenant l'utilisabilité. Un logiciel, c'est une boîte à outils. On pourrait se dire qu'avoir dans notre boîte à outils toutes les dimensions de clés plates entre 6 et 25 mm, ça nous prépare à toutes les éventualités. La réalité, c'est que :
1. certaines dimensions ne serviront jamais,
2. certaines dimensions serviront peu,
3. celles que servent peu ou pas sont peut-être inutilisables, en fait on n'en sait rien vu que… on s'en sert peu ou pas.
4. des clés plates en chrome-vanadium, ça finit vite par peser… faut la traîner la boîte,
5. la clé dont on a besoin est toujours celle planquée dans le fond, et pour y accéder, il faut vider tout le contenu de la boîte par terre. C'est frustrant, ça fait perdre du temps, et au final "être prêt à tout" nous met en retard tout le temps.
Et bien sûr, les clés plates, c'est juste une partie des outils. Ensuite, on a les clés allen, les tournevis, etc.
La solution, c'est d'avoir seulement les dimensions courantes, et une ou deux clés à molette pour les cas exotiques. Voire de s'arranger avec une pince multiprise pour tenir les écrous vraiment hors catégorie. Ça n'a rien d'original, le principe remonte au système Gribeauval, qui date du XVIIIe siècle (https://www.cairn.info/revue-gerer-et-co...age-41.htm).
Dans darktable, la clé à molette, c'est la possibilité de scripter en Lua pour les usages de niche. Mais refuser de faire le tri entre les fonctionnalités d'usage courant et les fonctionnalités exotiques, c'est dégrader l'interface pour tout le monde. Le meilleur endroit pour cacher un arbre, c'est au milieu de la forêt. Depuis 2 ans, on est en train de planquer toujours plus profond les fonctionnalités essentielles derrière les fonctionnalités qui servent à 3 mecs, mais qui demandent 2000 lignes de code et qui capturent tous les événements mouse_moved, même pour les utilisateurs qui n'en ont rien à faire.
Parce que, encore une fois, un widget Gtk consomme de la puissance CPU qu'il soit visible ou caché. Au minimum parce qu'il peut être mappé à des raccourcis clavier et parce qu'on doit changer sa couleur de fond quand la souris le survole, et Gtk n'a aucun mécanisme pour éviter de redessiner les éléments non visibles dans la fenêtre.
Se planquer derrière le fait que, quoi qu'on fasse, certains ne seront pas contents, est encore une fallacie. L'objectif, c'est la loi de Pareto, le 80/20. darktable sert à trier ce qui sort de la carte mémoire et à transformer des raw en images finales. Tout ce qui ne sert pas directement cet objectif est de l'overhead et doit être limité au minimum.
Tous les retours utilisateurs ne sont pas à prendre au pied de la lettre. Tous les usages ne sont pas valides. Certains utilisateurs ont des workflows inutilement compliqués et on n'a pas à leur donner plus d'outils pour être encore plus inefficaces : ils doivent changer leur méthode de travail.
Mais en termes d'utilisateurs, les seuls avec lesquels on interagit sont sur Github. C'est à dire principalement des programmeurs, actuels ou retraités, parce que Github est une plateforme d'hébergement de code et intimide les non-programmeurs. C'est un énorme biais d'échantillon, par rapport à une majorité silencieuse de gens qui ne parlent pas forcément anglais et ne savent pas comment utiliser Github. D'autant que pour comprendre ce dont l'utilisateur a besoin à travers ce qu'il veut (spoiler alert : les gens sont incapables d'exprimer clairement leurs besoins, faut leur tirer les vers du nez pire qu'une enquête de police judiciaire), y a un effort à fournir et c'est un métier : designer.
En bref, tout merger et tout garder pour faire plaisir à tout le monde, ça emmerde tout le monde est c'est d'une naïveté folle. La vie c'est des choix.
Après, faut encore discuter de la qualité du design sur les fonctionnalités "mises à jour". Par exemple, depuis le bordel MIDI, les touches numériques ne sont pas détectées pareil suivant qu'on utilise le pavé numérique ou la barre numérique au dessus des lettres. En clair, attribuer des étoiles à des images via le clavier est cassé, sauf pour les utilisateurs qui penseront à configurer le pavé numérique comme alternative. En plus, moi, sur clavier BÉPO, les touches numériques au dessus du texte sont détectées comme Maj+&, Maj+é, Maj+", etc. Ah mais on peut configurer des triple-clics et des cliqué-déplacés, génial. Un sens des priorités qui m'échappe : on casse des fonctionnalités basiques pour introduire des fonctionnalités totalement secondaires, tout est fait en dépit du bon sens. Avant ça, on utilisait les accels Gtk qui décodaient les caractères correctement, peu importe la touche physique utilisée. Vive le progrès.
Et ben non. Merde. Je refuse ces conneries. Le projet darktable est mort, tué par une bande de Gaston Lagaffe qui jouent à coder. Photographes amateurs, devenus développeurs amateurs, devenus designers amateurs… la médiocrité à tous les étages. L'interface a toujours été son point faible, mais là on atteint des sommets de stupidité. Je bosse pas à l'éducation nationale, je pratique pas le 10/20 pour l'effort et la médaille en chocolat. Un outil marche ou il ne marche pas, et les excuses ne m'intéressent pas.
Ah ça, le projet est actif. Pour s'agiter, ça s'agite. Pleins de gens qui bossent sans direction commune et sans axes d'améliorations définis, qui codent des trucs qui créent plus de problèmes qu'ils n'en règlent, et qui demandent toujours plus de travail pour corriger des bugs parfois très sournois… C'est pas compliqué, un projet qui demande une quantité de travail croissante au cours du temps a un problème fondamental, surtout s'agissant d'un projet informatique, parce que le principe de l'informatique est d'automatiser des trucs, pas de créer du travail. Qu'on ne me raconte pas que 15 mecs qui agitent les bras sans méthode, ça fait un projet en bonne santé. Il suffit d'ouvrir le code source et de lire… En 4 ans on a eu… 3 réécritures complètes de la table lumineuse ? Remarque, c'est toujours plus facile de réécrire que de dénouer les spaghetti.
Au moins, un cancer, ça s'arrête à la mort du patient. La croissance anarchique des fonctionnalités de darktable n'aura pas ce privilège.
Aurélien, photographe portraitiste, spécialiste calcul.
Développeur de filmique, égaliseur de tons, balance couleur, etc.
darktable est mon métier, pensez à m'aider :
Développeur de filmique, égaliseur de tons, balance couleur, etc.
darktable est mon métier, pensez à m'aider :