Posté par Psychofox (Mastodon) .
Évalué à 10.
Dernière modification le 22 août 2023 à 09:47.
Alors qu'en fait depuis tout ce temps, il fallait simplement utiliser TK et si possible avec un langage stable comme tcl ou perl5[1] qui ne cassent pas la compatibilité tous les 4 matins.
Le problème c'est que seuls les dinosaures continuent à les utiliser.
[1] la communauté a même préféré changer le nom de perl 6 pour que perl reste perl
Et les gens qui ne disent rien vont juste cramer des années hommes à mettre à jour leurs applis parce que chez Gnome on s'en balec de la rétrocompatibilité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Et pourtant, ça doit être facile vu que personne ne semble vouloir donner un coup de main, car c'est bien connu, si c'était difficile, les gens aideraient au lieu de poster des platitudes sur un site de news.
Bah on va te dire que c'est de ta faute, qu'il faut patcher tes systèmes toutes les semaines pour gérer la dette technique au fil de l'eau …
sauf que … il faut comprendre un truc: les devs n'ont pas forcément le temps d'adapter leur code à toutes les versions des frameworks sous-jacents : leur job c'est de développer de nouvelles fonctionnalités. Ca ne veut pas dire qu'il faut rester dans l'immobilisme par rapport aux couches basses, mais que plus les couches sont basses, olus il faut qu'elles soient stables dans le temps (je ne suis pas sûr que les devs gnome seraient content si la libc cassait la rétropcompatibilité et changeait tous les 4 matins).
Vu le nombre de programme qui n'utilisent que des API POSIX et qui suivent la LSB, je pense que ton affirmation sur "les couches hautes veulent des couches basses stables" est non vérifiable en pratique.
Par exemple, va demander le support d'un code en python 2, parce que c'est stable. On va te rire au nez (alors que c'est encore supporté par des distributeurs).
Je ne suis pas sûr de comprendre ou tu veux en venir (mais peut-être parce que moi-ùmême je n'ai pas forcément été clair non plus dans ce que je voulais exprimer).
LA stabilité ne signifie pas forcément l'immobilisme. On peut être suffisamment stable en mintenant la rétrocompatibilité au maximum, et ne se limiter qu'aux breaking changes réellements essentiels, tout en continuant à avancer et à fournir des nouvelles fonctionnalités.
Python est un bon exemple : je ne suis pas un fan de python, je ne suis pas non plus convaincu par certains changements apportés par Python3, mais il faut reconaître que la transition entre Python 2 et python 3 s'est faite en douceur. Python 2 et python 3 ont été maintenus suffisamment longtemps pour que les gens puissent apporter les changements à leur code. Python2 fournissait des bibliothèques (future, six) permettant d'écrire du code proche de python 3. Et de ce point de vue, que l'on aime ou pas Python, tout a été fait pour que la transition se fasse dans les meilleures conditions.
A l'opposé il existe des outils et des frameworks (GTK est souvent cité pour ça, mais ça a été aussi le cas de certains frameorks Javascript côté serveur ou côté client) qui ont eu quelques soucis de manque de rétrocompatibilité, pour lesquels les devs (enfin ceux que je connaissais) se sont plaint de devoir passer plus de temps à gérer les changements des couches basses et à réécrire du code qui fonctionnait très bien jusqu'aux changements en question plutôt que de développer leurs fonctionnalités (et manque de bol ils ont eu à ce moment là à gérer des changements sur plusieurs dépendances qui se sont étalées suffisamment longtemps pour que ça pénalise leur travail).
J'ai moi-même bossé dans une équipe qui développait des composants pour un outil de déploiement qui utilisait Ansible en couche basse, et une des contraintes que l'on s'était imposé c'était de n'introduire des breaking changes uniquement quand c'était nécessaire, et de maintenir suffisamment longtemps les versions N-1 (en terme de correction de bugs) pour laisser suffisamment de temps aux utilisateurs pour faire la transition (leur métier n'étant pas de s'adapter aux outils de déploiement, mais d'écrire du code et de le déployer (avec l'infra sous-jacente) de la manière la plus simple qui soit.
La stabilité ne signifie pas forcément l'immobilisme
Non, mais l'immobilisme entraîne la stabilité. Tout le reste, c'est juste des ajustements de paramètres avec des tradeoffs (techniquement, l'immobilisme aussi, c'est juste un cas extrême).
D'un coté, tu as la stabilité absolu d'un code qui ne change pas. De l'autre, tu as le fait de gérer qu'une version, la version HEAD (méthode à la Google, qui a aussi des outils de refactoring en masse).
Tout le reste, c'est choisir qui va faire le travail, avec bien sur tout le monde qui pense que idéalement, c'est quelqu'un d'autre qui va devoir bosser vu que y a déjà eu du travail pour le changement.
A l'opposé il existe des outils et des frameworks (GTK est souvent cité pour ça, mais ça a été aussi le cas de certains frameorks Javascript côté serveur ou côté client) qui ont eu quelques soucis de manque de rétrocompatibilité, pour lesquels les devs (enfin ceux que je connaissais) se sont plaint de devoir passer plus de temps à gérer les changements des couches basses et à réécrire du code qui fonctionnait très bien jusqu'aux changements en question plutôt que de développer leurs fonctionnalités (et manque de bol ils ont eu à ce moment là à gérer des changements sur plusieurs dépendances qui se sont étalées suffisamment longtemps pour que ça pénalise leur travail).
Tu crois que les développeurs de GTK s'amusent à réécrire leur API pour emmerder le monde ?
Les couches graphiques, que ce soit le matériel comme la gestion sous Linux (genre l'arrivée de Wayland) a nécessité de gros ajustements. De la même façon que OpenGL a été mis au placard pour privilégier une nouvelle API : Vulkan. C'est compliqué de maintenir en parallèle plusieurs versions de GTK, surtout qu'ils manquent de bras, et ce n'est pas facile de garder la rétrocompatibilité qui fonctionne bien tout en proposant de nouvelles fonctionnalités ou la prise en charge de nouveaux éléments.
Ce ne sont pas de mauvais développeurs, mais ils manquent de ressources et il y a plusieurs critères à prendre en compte pour tenir le bon équilibre. Et tout projet logiciel prend ce type de décisions, parfois le curseur est mis sur autre chose car la priorité du projet et ses ressources sont différents.
C'est dommage pour les développeurs impactés mais c'est la vie d'un projet logiciel qui veut ça, et il y a des alternatives avec des avantages et inconvénients propres si nécessaires.
Posté par Psychofox (Mastodon) .
Évalué à 5.
Dernière modification le 23 août 2023 à 19:31.
Les couches graphiques, que ce soit le matériel comme la gestion sous Linux (genre l'arrivée de Wayland) a nécessité de gros ajustements. De la même façon que OpenGL a été mis au placard pour privilégier une nouvelle API : Vulkan.
Je serais tenté de dire que l'appli n'en a rien a carer de ce qu'il se passe derrière. Le toolkit pourrait évoluer et supporter un nouveau type d'affichage comme wayland, du hdpi et d'autres joyeusetés tout en maintenant une API stable.
Par exemple GNUSTEP a ajouté le support de wayland, mais n'a pas changé de version majeure et tu n'as pas à faire un effort de réécriture/portage de ton appli pour les nouvelles versions.
Si GTK casse la compatibilité tous les 4 à 10 ans c'est par choix, pas par obligation. Un choix qui a sans doute ses avantages mais personne ne leur mets un flingue sur la tempe en leur disant de tout casser.
Si GTK casse la compatibilité tous les 4 à 10 ans c'est par choix, pas par obligation. Un choix qui a sans doute ses avantages mais personne ne leur mets un flingue sur la tempe en leur disant de tout casser.
C'est probablement plus par nécessité. Casser la compatibilité c'est devoir de nouveau documenter, faire du support en plus, se prendre un paquet de remarques dont les plus bruyantes seront les plus offensantes, se tenir une réputation,… Vu le peu de monde qui tiennent la baraque ils ont parfaitement conscience de ce que ça entraîne et pleins de gens prennent sur eux de leur rappeler régulièrement.
Mais ils ont un ensemble de fonctionnalités et d'autres critères qui entrent en ligne de compte. Est-ce qu'il faut pour autant être outrancier comme on le voit plus haut en disant qu'ils n'en ont rien à faire ?
Comme tu le dis, gnustep fait mieux et je suis sûr que tcl/tk reste compatible avec les versions sorties sous Napoléon. Si personne ne met de gun sur la tempe des développeurs de gtk, personne ne met de couteau sous la gorge de leurs utilisateurs pour qu'ils continuent de l'utiliser. C'est qu'il doit bien avoir une qualité ou deux.
Tout projet propose un ensemble, des fonctionnalités, un support, des performances, un maintient dans le temps, etc. Juger sur un critère unique en ignorant la vue d'ensemble est par nature biaisée.
Parce que sur le web c'est mieux avec jquery, dojo, coffeescript, dart, angularjs, angular, react, vue, svelte,… ? Les développeurs fuient le manque de rétrocompatibilité pour encore plus de changements ?
C'est soit gtk soit le web ? Les autres toolkit graphiques sont vraiment si mauvais qu'ils ne sont pas une option ?
Les développeurs de toutes les plateformes font du web, c'est quoi gtk est entraine avec lui toute la profession ?
La stratégie de l'échec?
Quand on suppose qu'autant de gens ont des comportements irrationnels (à la fois les développeurs de gtk et leurs utilisateurs voir tout développeur ?) c'est :
Affirmation sans preuve peut être nié sans argument et tout ce qui utilise un framework par dessus (incluant les bootstrap, less, sass, tailwind…) ne rentre pas dedans vu qu'il faut les maintenir. Si les gens utilisaient réellement vanilla la stack web, on ne parlerait pas de javascript fatigue. C'est le seul écosystème où le problème est devenu suffisamment pesant pour qu'ils l'identifient comme ça.
Tu mélanges les couches. Le "socle" html/js/css est au même niveau que gtk et est très rétrocompatible.
Ou c'est l'assembleur du web ?
Ce qui est reproché à gtk c'est d'obliger les développeurs à réécrire tout ou parti au fil des versions. Si tu n'utilise pas de manière vanilla la stack web tu aura le même problème avec tes frameworks et toolkit. C'est bien beau que l'assembleur soit le même mais il n'est pas réutilisable d'une version à l'autre. Donc les développeurs ne sont pas plus avancés.
Si les gens utilisaient
Tu raisonnes souvent par supposition :-)
J'utilise des tournures qui mettent en évidence que j'en fais. Parce que ni toi ni moi n'avançons d'éléments plus concret.
La rétrocompatibilité est capitale dans le succès de pleins de technos (html/js/css, java, postgresql, android, opengl…).
Et x86, amd64,… La critique porte sur la qualité de vie des développeurs. Le développeurs web qui utilise la stack web vanilla n'aura pas de problème dès qu'il utilise un truc genre bootstrap ça va devenir coton. Pour java et postgresql ça va, pour android par contre le sdk a pas mal changé et maintenant google te pousse à aller vers kotlin pour se débarrasser de leur ersatz de java, pour opengl pendant longtemps c'était déjà la compatibilité qui était compliquée…
Posté par Psychofox (Mastodon) .
Évalué à 4.
Dernière modification le 24 août 2023 à 10:24.
Combien de ces frameworks webs ont été complètement abandonnés et ne reçoivent plus de support?
Il me semble que si tu regardes des frameworks populaires relativement vieux, je crois que seul angularjs est abandonné (et c'est très récent). React a 10 ans et sort des versions majeures régulièrement, qui introduisent des breaking changes mais qui n'imposent pas forcément de tout réécrire.
Alors on n'a pas encore une vue similaire à GTK sur 25 ans et le web ça reste grosso modo beaucoup de fragmentation et des gens qui veulent tout réinventer régulièrement, mais le contexte est différent.
Combien de ces frameworks webs ont été complètement abandonnés et ne reçoivent plus de support?
Comme je l'ai dis une bonne moitié sont soit abandonnés soit en passe de l'être depuis un certains temps. Ils sont considérables comme de la dette technique et peuvent te claquer dans les doigts du jour au lendemain. Ne pas avoir de plan de migration (et la commencer), serait vraiment s'acheter des problèmes.
Parce que sinon à se train là continue d'utiliser gtk2, elle est toujours disponible dans les distributions (debian ou arch par exemple) et la dernière version n'a que 2 ans
React a 10 ans et sort des versions majeures régulièrement, qui introduisent des breaking changes mais qui n'imposent pas forcément de tout réécrire.
Je ne connais pas bien React, mais pour angular ils ont changé plusieurs fois de compilateurs et c'est loin d'être sans conséquence le dernier en date, Ivy, est arrivé par défaut avec la version 9 de début 2020.
Parce que sinon à se train là continue d'utiliser gtk2, elle est toujours disponible dans les distributions (debian ou arch par exemple) et la dernière version n'a que 2 ans
Tu noteras que c'est un peu de ça que parlait l'article mentionné dans le lien.
Quand je dis que ce serait bizarre que les développeurs fuis la volatilité pour avoir la même chose sur le web, me dire que eux au moins même les trucs moribonds ont encore un peu de développement. C'est pareil pour gtk qui lui a du coup un support qui est plus vieux que Phoenix ne soit lancé.
C'est pas moi qui est lancé la carte web hein, c'est devnewton.
Selon moi le web est populaire parce que le natif multiplateforme, c'est dur (malgré les toolkits/frameworks censés le faciliter), ça demande beaucoup de support, que sur le web il n'y a (hors canary release) qu'une version à la fois à supporter et que tout le déploiement et cycle de vie est géré en amont. Et que ça se prête bien aux méthodes agiles.
Et qu'en plus, c'est un truc qui s'apprend facilement dans son coin en local, pas besoin d'infrastructure de compilation non plus.
Si tu n'utilise pas de manière vanilla la stack web tu aura le même problème avec tes frameworks et toolkit.
Ce n'est pas du tout le même problème.
Encore une fois tu mélanges les couches:
une API de base qui casse, ton programme ne se lance même plus ;
un framework de haut niveau qui casse, tu peux vivre longtemps avec une vieille version tant que les API de base qu'il utilise ne bouge pas.
Pour java et postgresql ça va, pour android par contre le sdk a pas mal changé et maintenant google te pousse à aller vers kotlin pour se débarrasser de leur ersatz de java, pour opengl pendant longtemps c'était déjà la compatibilité qui était compliquée…
Tu vois, tu reconnais que la perte de rétrocompatibilité est un problème :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
une API de base qui casse, ton programme ne se lance même plus
Elle ne change pas par magie. Tu met à jour gtk et paf. Je te propose d'essayer de prendre un projet angular pré-ivy et de le mettre à jour ou de changer de version majeure de bootstrap pour voir si ça continue de se lancer.
un framework de haut niveau qui casse, tu peux vivre longtemps avec une vieille version tant que les API de base qu'il utilise ne bouge pas.
Pour le moment tu en est à pouvoir vivre 21 ans avec gtk2.
Arrête avec Angular, tu mélanges cadriciel de haut niveau et API de base, je te l'ai déjà dit plusieurs fois :-)
Répéter des bêtises ne les rendra pas plus vraies pour autant. Gtk est une bibliothèque au même titre que vue par exemple (dont le passage de la 2 à la 3 à demandé à tout récrire). Gtk n'est pas une api de base de linux. C'est l'un des différents toolkit graphique au même titre que tcl ou qt. Xlib ou xcb sont déjà plus incontournables en étant la partie cliente des serveurs graphiques là on est dans des api de base.
Mais surtout surtout. La critique c'est d'avoir à récrire son application quand tu dois le faire si c'est à cause de ton langage, d'une "api de base", d'une bibliothèque, etc n'a pas vraiment de différences. C'est la fréquence de tes réécritures qui est un problème. Ah ce petit jeu tu aura pu utiliser gtk2 20 ans et plus encore car elle est toujours dans debian et rhel.
Si tu es persuadé que Vue et Gtk c'est pareil, que coder une appli avec xlib c'est la meme chose qu'utiliser html/js/css et que la rétrocompatibilité n'est pas importante, forcément tout va bien.
Les gens qui maintiennent des applis sur le long terme vivent dans un monde moins enchanté 🧙♂️.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Posté par barmic 🦦 .
Évalué à 2.
Dernière modification le 24 août 2023 à 22:05.
Je ne vois pas de contre argument. Tu affirme des choses. Tu fais des parallèles qui n'existent que dans ta tête. Tu esquive quand tu semble être au pied du mur. Et tu t'attaque à ma personne quand tu ne sais plus quoi répondre.
Parce qu'inventer des concepts et donner à des bibliothèques des responsabilités qu'elles n'ont pas, c'est facile mais ça ne va pas t'aider si effectivement, tu cherches à faire du maintiens long-terme. Passer plus de temps à comprendre l'écosystème que tu utilise et moins de temps à se morfondre que les autres ils font tout pour t'embêter sera bien plus bénéfique à pour résoudre tes difficultés de support.
La partie où il affirme que gtk3 est abandonné alors que le support existe toujours ?
Oú il préfère penser à un complot plutôt que de chercher la vérité ?
Celui où il fait des procès d'intention ?
Celui où il préfère tordre le bras des développeurs gtk et des mainteneurs de distribution plutôt que de simplement choisir un toolkit graphique qui lui convient mieux ?
Posté par Psychofox (Mastodon) .
Évalué à 3.
Dernière modification le 25 août 2023 à 09:37.
La partie où il affirme que gtk3 est abandonné alors que le support existe toujours ?
T'as pas vraiment lu hein?
Je cite:
_This sounds like bad news, but there is a silver lining here: while they’re mucking about with GTK 4, they aren’t breaking GTK 3.
The ongoing transition to GTK 4 gives us an opportunity here. The GTK 3 ABI is finally a stable target, and it’s still pre-installed in most distributions because lots of built-in apps haven’t upgraded yet. If we can get a sufficient number of binary apps depending on it, distributions will be forced to maintain it and even pre-install it “forever”_
Oú il préfère penser à un complot plutôt que de chercher la vérité ?
Il parle d'attitude militante des developpeurs de logiciel libres et il a clairement une vision de developpeur de logiciel propriétaire, ce qu'il est si tu lis sa page linkedin. Il estime qu'on devrait pouvoir fournir un binaire de son application à un instant T et ne pas s'attendre à ce qu'elle soit cassée quelques années plus tard juste parce que les versions mineures du toolkit sortis et livrés entre temps par les distrib le casse.
C'est une opinion que l'on peut partager ou non. Même dans le monde proprio ils ne sont pas d'accord. Microsoft tente au possible de ne jamais rien casser et c'est une des choses qu'ils font très bien avec le corollaire qu'une installation de l'OS qui ne contient presque aucun logiciel prend énormément de place sur le disque, Apple décide qu'ils peuvent décider que les developpeurs doivent fournir une nouvelle application régulièrement ou elle ne sera plus installable via leur store.
L'ironie derrière c'est que c'est un des cas de figure où flatpak peut aider.
T'as le droit de ne pas être d'accord avec son avis, c'est pas une raison pour mentir et lui inventer des délires complotistes qu'il n'a pas formulé.
Note que du côté de l'utilisateur final, toutes les applis web qui ont été écrites avec ces frameworks à un moment donné continuent de fonctionner. Et au final même si il y en a un plus à la mode à un instant T, ça ne veut pas dire que:
les autres frameworks sont abandonnés par leurs mainteneurs/devs
tous les developeurs abandonnent les autres du jour au lendemain pour réécrire leur app sur celui à la mode.
Du coup on passe du point de vu du développeur d'application à l'utilisateur final.
les autres frameworks sont abandonnés par leurs mainteneurs/devs
De ce que j'ai cité à la va vite tu en a tout de même une petite moitié qui sont soit abandonnées soit dans un état de maintenance à peine en vie et ça ne compte pas les bibliothèques qui ajoutent du bruit à ça comme moment par exemple.
tous les developeurs abandonnent les autres du jour au lendemain pour réécrire leur app sur celui à la mode.
Quand on suppose qu'autant de gens ont des comportements irrationnels (à la fois les développeurs de gtk et leurs utilisateurs voir tout développeur ?) c'est :
Tu es le seul à parler d'irrationnalité.
Soit dit en passant, tu mentionnes les utilisateurs. Mais ils ne choisissent pas vraiment le toolkits de leurs applis. En général ils choisissent un bureau et des applis qu'ils aiment et elles sont fournies dans des toolkits divers et variés aussi bien en terme de version.
Les gens s'en contrecarrent que kde plasma est en QT4/QT5 ou QT6. Ils l'utilisent parce qu'il répond à leur besoin. Pareil pour Gnome/XFCE/mate/cinnamon et GTK. Et à part les applis en motifs ou java swing qui jurent souvent esthétiquement, les distributions ont fait en sorte d'avoir des moteurs de thèmes de toolkits qui font que les différences esthétiques s'effacent.
Les utilisateurs, ça leur en touchaient une sans faire bouger l'autre d'utiliser Gimp qui en GTK2 tout ce temps. Et je suis sûr que peu d'entre eux savent dire quelle appli utilise quelle version de toolkit.
J'ai mis un moment sur les comportement décrit. Les développeurs d'application continueraient d'utiliser gtk car les développeurs de gtk les braqueraient. Les développeurs de gtk prendraient casseraient la compatibilité par inconvenance presque par plaisir et n'auraient rien à faire des conséquences. etc
Soit dit en passant, tu mentionnes les utilisateurs.
Pardon je parlais des utilisateurs de la bibliothèque gtk. Personne n'avait encore parlé des utilisateurs finaux donc ça me paraissait clair.
Les gens s'en contrecarrent que kde plasma est en QT4/QT5 ou QT6.
Dire que c'est un choix, le répéter ad nauseam en ignorant sciemment que tout choix se fait dans un contexte et dire plus haut (ce n'est pas toi mais ça fait partie de la discussion) qu'ils n'en n'ont rien à faire, contribue à pousser ce genre d'idée.
Tu ne questionne pas le pourquoi est-ce qu'ils cassent la compatibilité, d'où est-ce que ça vient, non tu me présente comme un choix indépendant de toute contrainte technique. Au mieux tu dis que gnustep le fait ils doivent pouvoir le faire comme si les 2 bibliothèques avaient les mêmes objectifs/scopes/projets.
Pour ta pique personnelle, j'essaie de ne pas critiquer les personnes mais les discours. On pourrait discuter pour devnewton, mais c'était une manière de parler du fameux rasoir d'ockham (je conviens que ça n'était pas parfait). Tu remarquera l'ironie de demander un débat sain, juste après avoir lancer une attaque ad hominem.
Tout le monde fait des applis webs parce que tu as pas à gérer les copies pirates, parce que tu va cibler une plateforme (Chrome) et pas 2 (Mac et Windows, on va pas se leurrer sur les PdM du reste)
Tout projet propose un ensemble, des fonctionnalités, un support, des performances, un maintient dans le temps, etc. Juger sur un critère unique en ignorant la vue d'ensemble est par nature biaisée.
Non, c'est exactement ce que je dis plus haut, c'est un choix.
# oublié de préciser...
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 21 août 2023 à 18:05.
…l'article est de 2021.
# oublié de préciser
Posté par tisaac (Mastodon) . Évalué à 6.
On en a déjà discuté ;-)
Surtout, ne pas tout prendre au sérieux !
[^] # Re: oublié de préciser
Posté par Maderios . Évalué à 2.
Un journal sur flatpak qui date d'hier
# L'histoire se répète
Posté par David Delassus (site web personnel) . Évalué à 8.
Il y a 10 ans, on entendait les gens dire qu'il fallait développer pour GTK2 et pas GTK3.
Il y a 20 ans, on entendait les gens dire qu'il fallait développer pour GTK1 et pas GTK2.
Dans 10 ans, on entendra les gens dire qu'il faut développer pour GTK4 et pas GTK5.
https://link-society.com - https://kubirds.com
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 22 août 2023 à 09:47.
Alors qu'en fait depuis tout ce temps, il fallait simplement utiliser TK et si possible avec un langage stable comme tcl ou perl5[1] qui ne cassent pas la compatibilité tous les 4 matins.
Le problème c'est que seuls les dinosaures continuent à les utiliser.
[1] la communauté a même préféré changer le nom de perl 6 pour que perl reste perl
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 6.
zut, il y'a les devs COBOL/TK et Fortran/motif qui moinssent. On les a oublié.
[^] # Re: L'histoire se répète
Posté par David Delassus (site web personnel) . Évalué à 8.
Pour info, le module Python tkinter est inclus dans la librairie standard.
Quand j'ai besoin d'une GUI pour un script Python, c'est vers ce dernier que je m'oriente :)
https://link-society.com - https://kubirds.com
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Et les gens qui ne disent rien vont juste cramer des années hommes à mettre à jour leurs applis parce que chez Gnome on s'en balec de la rétrocompatibilité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par Misc (site web personnel) . Évalué à 8.
Et pourtant, ça doit être facile vu que personne ne semble vouloir donner un coup de main, car c'est bien connu, si c'était difficile, les gens aideraient au lieu de poster des platitudes sur un site de news.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Chacun sa spécialité, moi je fais dans le retrogaming en ce moment : maintenir en vie des consoles qui ont 30 ou 40 ans, c'est pas rien niveau LTS !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par David Delassus (site web personnel) . Évalué à 3.
C'est pour ça que je kiffe le Semantic Versionning.
Sinon, 10 ans, pour un dev JS c'est du LTS :)
https://link-society.com - https://kubirds.com
[^] # Re: L'histoire se répète
Posté par totof2000 . Évalué à 4.
Bah on va te dire que c'est de ta faute, qu'il faut patcher tes systèmes toutes les semaines pour gérer la dette technique au fil de l'eau …
sauf que … il faut comprendre un truc: les devs n'ont pas forcément le temps d'adapter leur code à toutes les versions des frameworks sous-jacents : leur job c'est de développer de nouvelles fonctionnalités. Ca ne veut pas dire qu'il faut rester dans l'immobilisme par rapport aux couches basses, mais que plus les couches sont basses, olus il faut qu'elles soient stables dans le temps (je ne suis pas sûr que les devs gnome seraient content si la libc cassait la rétropcompatibilité et changeait tous les 4 matins).
[^] # Re: L'histoire se répète
Posté par Misc (site web personnel) . Évalué à 3.
Vu le nombre de programme qui n'utilisent que des API POSIX et qui suivent la LSB, je pense que ton affirmation sur "les couches hautes veulent des couches basses stables" est non vérifiable en pratique.
Par exemple, va demander le support d'un code en python 2, parce que c'est stable. On va te rire au nez (alors que c'est encore supporté par des distributeurs).
[^] # Re: L'histoire se répète
Posté par totof2000 . Évalué à 3.
Je ne suis pas sûr de comprendre ou tu veux en venir (mais peut-être parce que moi-ùmême je n'ai pas forcément été clair non plus dans ce que je voulais exprimer).
LA stabilité ne signifie pas forcément l'immobilisme. On peut être suffisamment stable en mintenant la rétrocompatibilité au maximum, et ne se limiter qu'aux breaking changes réellements essentiels, tout en continuant à avancer et à fournir des nouvelles fonctionnalités.
Python est un bon exemple : je ne suis pas un fan de python, je ne suis pas non plus convaincu par certains changements apportés par Python3, mais il faut reconaître que la transition entre Python 2 et python 3 s'est faite en douceur. Python 2 et python 3 ont été maintenus suffisamment longtemps pour que les gens puissent apporter les changements à leur code. Python2 fournissait des bibliothèques (future, six) permettant d'écrire du code proche de python 3. Et de ce point de vue, que l'on aime ou pas Python, tout a été fait pour que la transition se fasse dans les meilleures conditions.
A l'opposé il existe des outils et des frameworks (GTK est souvent cité pour ça, mais ça a été aussi le cas de certains frameorks Javascript côté serveur ou côté client) qui ont eu quelques soucis de manque de rétrocompatibilité, pour lesquels les devs (enfin ceux que je connaissais) se sont plaint de devoir passer plus de temps à gérer les changements des couches basses et à réécrire du code qui fonctionnait très bien jusqu'aux changements en question plutôt que de développer leurs fonctionnalités (et manque de bol ils ont eu à ce moment là à gérer des changements sur plusieurs dépendances qui se sont étalées suffisamment longtemps pour que ça pénalise leur travail).
J'ai moi-même bossé dans une équipe qui développait des composants pour un outil de déploiement qui utilisait Ansible en couche basse, et une des contraintes que l'on s'était imposé c'était de n'introduire des breaking changes uniquement quand c'était nécessaire, et de maintenir suffisamment longtemps les versions N-1 (en terme de correction de bugs) pour laisser suffisamment de temps aux utilisateurs pour faire la transition (leur métier n'étant pas de s'adapter aux outils de déploiement, mais d'écrire du code et de le déployer (avec l'infra sous-jacente) de la manière la plus simple qui soit.
[^] # Re: L'histoire se répète
Posté par nud . Évalué à 2.
Définis "nécessaire".
[^] # Re: L'histoire se répète
Posté par Misc (site web personnel) . Évalué à 3.
Non, mais l'immobilisme entraîne la stabilité. Tout le reste, c'est juste des ajustements de paramètres avec des tradeoffs (techniquement, l'immobilisme aussi, c'est juste un cas extrême).
D'un coté, tu as la stabilité absolu d'un code qui ne change pas. De l'autre, tu as le fait de gérer qu'une version, la version HEAD (méthode à la Google, qui a aussi des outils de refactoring en masse).
Tout le reste, c'est choisir qui va faire le travail, avec bien sur tout le monde qui pense que idéalement, c'est quelqu'un d'autre qui va devoir bosser vu que y a déjà eu du travail pour le changement.
[^] # Re: L'histoire se répète
Posté par Renault (site web personnel) . Évalué à 4.
Tu crois que les développeurs de GTK s'amusent à réécrire leur API pour emmerder le monde ?
Les couches graphiques, que ce soit le matériel comme la gestion sous Linux (genre l'arrivée de Wayland) a nécessité de gros ajustements. De la même façon que OpenGL a été mis au placard pour privilégier une nouvelle API : Vulkan. C'est compliqué de maintenir en parallèle plusieurs versions de GTK, surtout qu'ils manquent de bras, et ce n'est pas facile de garder la rétrocompatibilité qui fonctionne bien tout en proposant de nouvelles fonctionnalités ou la prise en charge de nouveaux éléments.
Ce ne sont pas de mauvais développeurs, mais ils manquent de ressources et il y a plusieurs critères à prendre en compte pour tenir le bon équilibre. Et tout projet logiciel prend ce type de décisions, parfois le curseur est mis sur autre chose car la priorité du projet et ses ressources sont différents.
C'est dommage pour les développeurs impactés mais c'est la vie d'un projet logiciel qui veut ça, et il y a des alternatives avec des avantages et inconvénients propres si nécessaires.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Gtk 4 dépends d'OpenGL, ça veut dire qu'il faudra le mettre au placard bientôt ?
https://docs.gtk.org/gtk4/overview.html
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 23 août 2023 à 19:31.
Je serais tenté de dire que l'appli n'en a rien a carer de ce qu'il se passe derrière. Le toolkit pourrait évoluer et supporter un nouveau type d'affichage comme wayland, du hdpi et d'autres joyeusetés tout en maintenant une API stable.
Par exemple GNUSTEP a ajouté le support de wayland, mais n'a pas changé de version majeure et tu n'as pas à faire un effort de réécriture/portage de ton appli pour les nouvelles versions.
Si GTK casse la compatibilité tous les 4 à 10 ans c'est par choix, pas par obligation. Un choix qui a sans doute ses avantages mais personne ne leur mets un flingue sur la tempe en leur disant de tout casser.
[^] # Re: L'histoire se répète
Posté par Renault (site web personnel) . Évalué à 3.
Pas forcément pour une partie de l'API.
Une autre partie de l'API tient bien d'autres considérations aussi, les principes de design et en particulier des applications GNOME ont aussi évolué.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 3.
C'est probablement plus par nécessité. Casser la compatibilité c'est devoir de nouveau documenter, faire du support en plus, se prendre un paquet de remarques dont les plus bruyantes seront les plus offensantes, se tenir une réputation,… Vu le peu de monde qui tiennent la baraque ils ont parfaitement conscience de ce que ça entraîne et pleins de gens prennent sur eux de leur rappeler régulièrement.
Mais ils ont un ensemble de fonctionnalités et d'autres critères qui entrent en ligne de compte. Est-ce qu'il faut pour autant être outrancier comme on le voit plus haut en disant qu'ils n'en ont rien à faire ?
Comme tu le dis, gnustep fait mieux et je suis sûr que tcl/tk reste compatible avec les versions sorties sous Napoléon. Si personne ne met de gun sur la tempe des développeurs de gtk, personne ne met de couteau sous la gorge de leurs utilisateurs pour qu'ils continuent de l'utiliser. C'est qu'il doit bien avoir une qualité ou deux.
Tout projet propose un ensemble, des fonctionnalités, un support, des performances, un maintient dans le temps, etc. Juger sur un critère unique en ignorant la vue d'ensemble est par nature biaisée.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
En cassant la rétrocompatibilité de ton toolkit, tu pointes un fusil vers tes utilisateurs Marche avec moi ou casse toi faire des applis web.
Résultat, tout le monde fait des applis web.
La stratégie de l'échec?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 3.
Ce que tu dis n'a aucun sens.
Parce que sur le web c'est mieux avec
jquery,dojo,coffeescript,dart,angularjs,angular,react,vue, svelte,… ? Les développeurs fuient le manque de rétrocompatibilité pour encore plus de changements ?C'est soit gtk soit le web ? Les autres toolkit graphiques sont vraiment si mauvais qu'ils ne sont pas une option ?
Les développeurs de toutes les plateformes font du web, c'est quoi gtk est entraine avec lui toute la profession ?
Quand on suppose qu'autant de gens ont des comportements irrationnels (à la fois les développeurs de gtk et leurs utilisateurs voir tout développeur ?) c'est :
Je ne me permettrais pas d'émettre d'hypothèse.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Tu peux faire plein de suppositions, mais html/css/js est aujourd'hui le "toolkit" le plus populaire et le plus rétrocompatible.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 2.
Affirmation sans preuve peut être nié sans argument et tout ce qui utilise un framework par dessus (incluant les bootstrap, less, sass, tailwind…) ne rentre pas dedans vu qu'il faut les maintenir. Si les gens utilisaient réellement vanilla la stack web, on ne parlerait pas de javascript fatigue. C'est le seul écosystème où le problème est devenu suffisamment pesant pour qu'ils l'identifient comme ça.
D'ailleurs tu ne me fera pas croire quelque chose au quel tu ne crois même pas toi-même puisque tu appel de tes vœux un "low javascript"
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par David Delassus (site web personnel) . Évalué à 2.
J'adore le titre de l'article :
Comme si HTMX et Alpine.JS n'avaient pas besoin de JS.
https://link-society.com - https://kubirds.com
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Tu mélanges les couches. Le "socle" html/js/css est au même niveau que gtk et est très rétrocompatible.
Tu raisonnes souvent par supposition :-)
La rétrocompatibilité est capitale dans le succès de pleins de technos (html/js/css, java, postgresql, android, opengl…).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 1.
Ou c'est l'assembleur du web ?
Ce qui est reproché à gtk c'est d'obliger les développeurs à réécrire tout ou parti au fil des versions. Si tu n'utilise pas de manière vanilla la stack web tu aura le même problème avec tes frameworks et toolkit. C'est bien beau que l'assembleur soit le même mais il n'est pas réutilisable d'une version à l'autre. Donc les développeurs ne sont pas plus avancés.
J'utilise des tournures qui mettent en évidence que j'en fais. Parce que ni toi ni moi n'avançons d'éléments plus concret.
Et x86, amd64,… La critique porte sur la qualité de vie des développeurs. Le développeurs web qui utilise la stack web vanilla n'aura pas de problème dès qu'il utilise un truc genre bootstrap ça va devenir coton. Pour java et postgresql ça va, pour android par contre le sdk a pas mal changé et maintenant google te pousse à aller vers kotlin pour se débarrasser de leur ersatz de java, pour opengl pendant longtemps c'était déjà la compatibilité qui était compliquée…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 24 août 2023 à 10:24.
Combien de ces frameworks webs ont été complètement abandonnés et ne reçoivent plus de support?
Il me semble que si tu regardes des frameworks populaires relativement vieux, je crois que seul angularjs est abandonné (et c'est très récent). React a 10 ans et sort des versions majeures régulièrement, qui introduisent des breaking changes mais qui n'imposent pas forcément de tout réécrire.
Alors on n'a pas encore une vue similaire à GTK sur 25 ans et le web ça reste grosso modo beaucoup de fragmentation et des gens qui veulent tout réinventer régulièrement, mais le contexte est différent.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 1.
Comme je l'ai dis une bonne moitié sont soit abandonnés soit en passe de l'être depuis un certains temps. Ils sont considérables comme de la dette technique et peuvent te claquer dans les doigts du jour au lendemain. Ne pas avoir de plan de migration (et la commencer), serait vraiment s'acheter des problèmes.
Parce que sinon à se train là continue d'utiliser gtk2, elle est toujours disponible dans les distributions (debian ou arch par exemple) et la dernière version n'a que 2 ans
Je ne connais pas bien React, mais pour angular ils ont changé plusieurs fois de compilateurs et c'est loin d'être sans conséquence le dernier en date, Ivy, est arrivé par défaut avec la version 9 de début 2020.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 3.
Tu noteras que c'est un peu de ça que parlait l'article mentionné dans le lien.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 1.
Oui mais c'est à toi que je répond.
Quand je dis que ce serait bizarre que les développeurs fuis la volatilité pour avoir la même chose sur le web, me dire que eux au moins même les trucs moribonds ont encore un peu de développement. C'est pareil pour gtk qui lui a du coup un support qui est plus vieux que Phoenix ne soit lancé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 3.
C'est pas moi qui est lancé la carte web hein, c'est devnewton.
Selon moi le web est populaire parce que le natif multiplateforme, c'est dur (malgré les toolkits/frameworks censés le faciliter), ça demande beaucoup de support, que sur le web il n'y a (hors canary release) qu'une version à la fois à supporter et que tout le déploiement et cycle de vie est géré en amont. Et que ça se prête bien aux méthodes agiles.
Et qu'en plus, c'est un truc qui s'apprend facilement dans son coin en local, pas besoin d'infrastructure de compilation non plus.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
J'ai pris plus loin d'autres exemples que le web (java, opengl, postgres…) qui montre qu'une bonne rétrocompatibilité fait beaucoup pour le succès.
Ce n'est bien sûr pas le seul critère de choix.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 2.
gtk n'est pas un succès ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ce n'est pas du tout le même problème.
Encore une fois tu mélanges les couches:
Tu vois, tu reconnais que la perte de rétrocompatibilité est un problème :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 2.
Elle ne change pas par magie. Tu met à jour gtk et paf. Je te propose d'essayer de prendre un projet angular pré-ivy et de le mettre à jour ou de changer de version majeure de bootstrap pour voir si ça continue de se lancer.
Pour le moment tu en est à pouvoir vivre 21 ans avec gtk2.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 24 août 2023 à 18:31.
( Arrête avec Angular, tu mélanges cadriciel de haut niveau et API de base, je te l'ai déjà dit plusieurs fois :-) )
Gtk 2 sera maintenu jusqu'à 2044 ???
Je le croyais mort.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 2.
Répéter des bêtises ne les rendra pas plus vraies pour autant. Gtk est une bibliothèque au même titre que vue par exemple (dont le passage de la 2 à la 3 à demandé à tout récrire). Gtk n'est pas une api de base de linux. C'est l'un des différents toolkit graphique au même titre que tcl ou qt. Xlib ou xcb sont déjà plus incontournables en étant la partie cliente des serveurs graphiques là on est dans des api de base.
Mais surtout surtout. La critique c'est d'avoir à récrire son application quand tu dois le faire si c'est à cause de ton langage, d'une "api de base", d'une bibliothèque, etc n'a pas vraiment de différences. C'est la fréquence de tes réécritures qui est un problème. Ah ce petit jeu tu aura pu utiliser gtk2 20 ans et plus encore car elle est toujours dans debian et rhel.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 1. Dernière modification le 24 août 2023 à 21:47.
Si tu es persuadé que Vue et Gtk c'est pareil, que coder une appli avec xlib c'est la meme chose qu'utiliser html/js/css et que la rétrocompatibilité n'est pas importante, forcément tout va bien.
Les gens qui maintiennent des applis sur le long terme vivent dans un monde moins enchanté 🧙♂️.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 24 août 2023 à 22:05.
Je ne vois pas de contre argument. Tu affirme des choses. Tu fais des parallèles qui n'existent que dans ta tête. Tu esquive quand tu semble être au pied du mur. Et tu t'attaque à ma personne quand tu ne sais plus quoi répondre.
Parce qu'inventer des concepts et donner à des bibliothèques des responsabilités qu'elles n'ont pas, c'est facile mais ça ne va pas t'aider si effectivement, tu cherches à faire du maintiens long-terme. Passer plus de temps à comprendre l'écosystème que tu utilise et moins de temps à se morfondre que les autres ils font tout pour t'embêter sera bien plus bénéfique à pour résoudre tes difficultés de support.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Relis la partie "The GTK problem" dans le lien.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 1.
La partie où il affirme que gtk3 est abandonné alors que le support existe toujours ?
Oú il préfère penser à un complot plutôt que de chercher la vérité ?
Celui où il fait des procès d'intention ?
Celui où il préfère tordre le bras des développeurs gtk et des mainteneurs de distribution plutôt que de simplement choisir un toolkit graphique qui lui convient mieux ?
C'est de cette partie là que tu parle ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Tu ne veux pas admettre que Gtk a des soucis avec la rétrocompatibilité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 25 août 2023 à 09:37.
T'as pas vraiment lu hein?
Je cite:
_This sounds like bad news, but there is a silver lining here: while they’re mucking about with GTK 4, they aren’t breaking GTK 3.
The ongoing transition to GTK 4 gives us an opportunity here. The GTK 3 ABI is finally a stable target, and it’s still pre-installed in most distributions because lots of built-in apps haven’t upgraded yet. If we can get a sufficient number of binary apps depending on it, distributions will be forced to maintain it and even pre-install it “forever”_
Aucun complot n'est mentionné. Il cite l'expérience d'autres devs par contre avec les multiple cassage de GTK3 lors des releases mineures:
https://blogs.gnome.org/mortenw/2014/06/23/how-does-one-create-a-gtk-application/
Il parle d'attitude militante des developpeurs de logiciel libres et il a clairement une vision de developpeur de logiciel propriétaire, ce qu'il est si tu lis sa page linkedin. Il estime qu'on devrait pouvoir fournir un binaire de son application à un instant T et ne pas s'attendre à ce qu'elle soit cassée quelques années plus tard juste parce que les versions mineures du toolkit sortis et livrés entre temps par les distrib le casse.
C'est une opinion que l'on peut partager ou non. Même dans le monde proprio ils ne sont pas d'accord. Microsoft tente au possible de ne jamais rien casser et c'est une des choses qu'ils font très bien avec le corollaire qu'une installation de l'OS qui ne contient presque aucun logiciel prend énormément de place sur le disque, Apple décide qu'ils peuvent décider que les developpeurs doivent fournir une nouvelle application régulièrement ou elle ne sera plus installable via leur store.
L'ironie derrière c'est que c'est un des cas de figure où flatpak peut aider.
T'as le droit de ne pas être d'accord avec son avis, c'est pas une raison pour mentir et lui inventer des délires complotistes qu'il n'a pas formulé.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 1.
Affirmer sans plus preuve que ce que les autres font est fait pour te nuire est la définition d'un argument complotiste.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 4.
Ça tombe bien il n'a jamais formulé ça.
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 4.
Note que du côté de l'utilisateur final, toutes les applis web qui ont été écrites avec ces frameworks à un moment donné continuent de fonctionner. Et au final même si il y en a un plus à la mode à un instant T, ça ne veut pas dire que:
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 2.
Du coup on passe du point de vu du développeur d'application à l'utilisateur final.
De ce que j'ai cité à la va vite tu en a tout de même une petite moitié qui sont soit abandonnées soit dans un état de maintenance à peine en vie et ça ne compte pas les bibliothèques qui ajoutent du bruit à ça comme moment par exemple.
Qu'est-ce que ça change aux utilisateurs finaux ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 4.
Tu es le seul à parler d'irrationnalité.
Soit dit en passant, tu mentionnes les utilisateurs. Mais ils ne choisissent pas vraiment le toolkits de leurs applis. En général ils choisissent un bureau et des applis qu'ils aiment et elles sont fournies dans des toolkits divers et variés aussi bien en terme de version.
Les gens s'en contrecarrent que kde plasma est en QT4/QT5 ou QT6. Ils l'utilisent parce qu'il répond à leur besoin. Pareil pour Gnome/XFCE/mate/cinnamon et GTK. Et à part les applis en motifs ou java swing qui jurent souvent esthétiquement, les distributions ont fait en sorte d'avoir des moteurs de thèmes de toolkits qui font que les différences esthétiques s'effacent.
Les utilisateurs, ça leur en touchaient une sans faire bouger l'autre d'utiliser Gimp qui en GTK2 tout ce temps. Et je suis sûr que peu d'entre eux savent dire quelle appli utilise quelle version de toolkit.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 2.
J'ai mis un moment sur les comportement décrit. Les développeurs d'application continueraient d'utiliser gtk car les développeurs de gtk les braqueraient. Les développeurs de gtk prendraient casseraient la compatibilité par inconvenance presque par plaisir et n'auraient rien à faire des conséquences. etc
Pardon je parlais des utilisateurs de la bibliothèque gtk. Personne n'avait encore parlé des utilisateurs finaux donc ça me paraissait clair.
Alors pour le coup je pense que oui parce que QuickTime sur Mac et KDE sur linux c'est pas vraiment la même chose. Mais on est complètement d'accord, pourquoi en avoir du coup fais mention quand on parle de web ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 4.
Zenitram sors de ce corps!
Peut-être que le débat serait plus sain en éviter prêter aux gens des propos qu'ils n'ont pas formulés.
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . Évalué à 2.
Dire que c'est un choix, le répéter ad nauseam en ignorant sciemment que tout choix se fait dans un contexte et dire plus haut (ce n'est pas toi mais ça fait partie de la discussion) qu'ils n'en n'ont rien à faire, contribue à pousser ce genre d'idée.
Tu ne questionne pas le pourquoi est-ce qu'ils cassent la compatibilité, d'où est-ce que ça vient, non tu me présente comme un choix indépendant de toute contrainte technique. Au mieux tu dis que gnustep le fait ils doivent pouvoir le faire comme si les 2 bibliothèques avaient les mêmes objectifs/scopes/projets.
Pour ta pique personnelle, j'essaie de ne pas critiquer les personnes mais les discours. On pourrait discuter pour devnewton, mais c'était une manière de parler du fameux rasoir d'ockham (je conviens que ça n'était pas parfait). Tu remarquera l'ironie de demander un débat sain, juste après avoir lancer une attaque ad hominem.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par Misc (site web personnel) . Évalué à 2.
Tout le monde fait des applis webs parce que tu as pas à gérer les copies pirates, parce que tu va cibler une plateforme (Chrome) et pas 2 (Mac et Windows, on va pas se leurrer sur les PdM du reste)
[^] # Re: L'histoire se répète
Posté par Psychofox (Mastodon) . Évalué à 3.
Non, c'est exactement ce que je dis plus haut, c'est un choix.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.