Tu peux ne pas être d'accord avec eux, mais leur position se tient. Qaund tu dis:
on ne veut pas donner cette possibilité aux utilisateurs…
Ce n'est pas vrai. Ce qu'ils ne veulent pas, c'est mettre une solution de contournement pour régler un problème qui se situe ailleurs. C'est toujours le même problème: soit on contourne les bugs avec des verrues logicielles, et on se retrouve avec un code à la Frankenstein, soit on adopte la ligne stricte de corriger un problème là où il se situe.
Le premier choix est pragmatique, le second idéaliste. C'est ce dernier choix que fait GNOME. On peut trouver ça inconscient, cela entraîne une certaine oppression à court terme de l'utilisateur, j'en suis tout à fait conscient pour l'avoir ressentie aussi moi-même.
Mais je pense tout de même que c'est l'approche la plus payante sur le long terme. Par exemple, PulseAudio a mis au jour des bugs dans ALSA. Plutôt que de les contourner dans PulseAudio, ces bugs ont été corrigés directement dans ALSA. Tout le monde en a bénéficié. Même si PulseAudio disparaît et est remplacé par autre chose, même si on utilise directement ALSA sans passer par PulseAudio, on bénéficie aussi de ces correctifs. Le fait de ne pas contourner ces bugs et de décider de les laisser apparents est une manière de mettre le problème sous les projecteurs et forcer sa résolution par le ou les projets correspondants. En pratique, cela veut dire qu'en tant qu'utilisateur, ce truc va te saouler pendant 6 mois voire un an, le temps que le vrai problème soit corrigé au bon endroit. Ça fait mal, c'est pénible, et cela délègue l'obligation de contourner le problème à l'utilisateur. Mais c'est ce qui permet aussi de solidifier les fondations du logiciel plutôt que de les affaiblir.
L'approche "Frankenstein" quant à elle, pousse à avoir de multiples projets qui vont contourner les mêmes bugs (le .desktop d'une application qui ne déclare pas le type mime géré par l'appli affectera tous les desktops, pas juste GNOME), causant une duplication des efforts néfaste car les gens auraient pu employer leur temps à corriger d'autres bugs. On se retrouve aussi avec du code moins lisible, plus difficilement maintenable et on peut facilement se retrouver avec des effets de bords difficiles à prévoir (même si dans ton exemple précis, j'en conviens, la modification est très confinée). L'autre soucis de cette approche est politique: si tu fais une exception à la règle, elle est immédiatement utilisée comme modèle par d'autres personnes qui veulent une solution de contournement pour leur problème spécifique.
Pour ce qui est de GTK 3, j'aimerais en savoir un peu plus si tu veux bien. J'ai moi même fait la publicité de ton installateur GTK 3 pour Windows, et bien que ne l'utilisant pas, je te remercie pour ton travail, car il est important.
Quand tu dis:
Ce toolkit est dorénavant maintenu par des gens qui partagent les mêmes opinions, refuseront vos modifications
Effectivement, il est essentiellement maintenu par des gens de GNOME, une situation décriée par eux-même depuis plusieurs années, car ils sont en sous-effectifs. Depuis le retrait de Tor Lillqvist du poste de mainteneur GTK Windows, personne n'a pris le relais pour faire le boulot. Et je pense que l'équipe GTK serait plus que ravie d'avoir des contributeurs pour GTK Windows. Ce n'est pas par mauvaise volonté que ça n'avance pas, c'est juste qu'il n'y a plus personne pour faire le boulot. Aussi je m'étonne que tu parles de "refus de modifications". Tu as un exemple particulier en tête pour GTK ?
[^] # Re: Association de fichiers
Posté par liberforce (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.8 : deux ans déjà !. Évalué à 6.
Tu peux ne pas être d'accord avec eux, mais leur position se tient. Qaund tu dis:
Ce n'est pas vrai. Ce qu'ils ne veulent pas, c'est mettre une solution de contournement pour régler un problème qui se situe ailleurs. C'est toujours le même problème: soit on contourne les bugs avec des verrues logicielles, et on se retrouve avec un code à la Frankenstein, soit on adopte la ligne stricte de corriger un problème là où il se situe.
Le premier choix est pragmatique, le second idéaliste. C'est ce dernier choix que fait GNOME. On peut trouver ça inconscient, cela entraîne une certaine oppression à court terme de l'utilisateur, j'en suis tout à fait conscient pour l'avoir ressentie aussi moi-même.
Mais je pense tout de même que c'est l'approche la plus payante sur le long terme. Par exemple, PulseAudio a mis au jour des bugs dans ALSA. Plutôt que de les contourner dans PulseAudio, ces bugs ont été corrigés directement dans ALSA. Tout le monde en a bénéficié. Même si PulseAudio disparaît et est remplacé par autre chose, même si on utilise directement ALSA sans passer par PulseAudio, on bénéficie aussi de ces correctifs. Le fait de ne pas contourner ces bugs et de décider de les laisser apparents est une manière de mettre le problème sous les projecteurs et forcer sa résolution par le ou les projets correspondants. En pratique, cela veut dire qu'en tant qu'utilisateur, ce truc va te saouler pendant 6 mois voire un an, le temps que le vrai problème soit corrigé au bon endroit. Ça fait mal, c'est pénible, et cela délègue l'obligation de contourner le problème à l'utilisateur. Mais c'est ce qui permet aussi de solidifier les fondations du logiciel plutôt que de les affaiblir.
L'approche "Frankenstein" quant à elle, pousse à avoir de multiples projets qui vont contourner les mêmes bugs (le .desktop d'une application qui ne déclare pas le type mime géré par l'appli affectera tous les desktops, pas juste GNOME), causant une duplication des efforts néfaste car les gens auraient pu employer leur temps à corriger d'autres bugs. On se retrouve aussi avec du code moins lisible, plus difficilement maintenable et on peut facilement se retrouver avec des effets de bords difficiles à prévoir (même si dans ton exemple précis, j'en conviens, la modification est très confinée). L'autre soucis de cette approche est politique: si tu fais une exception à la règle, elle est immédiatement utilisée comme modèle par d'autres personnes qui veulent une solution de contournement pour leur problème spécifique.
Pour ce qui est de GTK 3, j'aimerais en savoir un peu plus si tu veux bien. J'ai moi même fait la publicité de ton installateur GTK 3 pour Windows, et bien que ne l'utilisant pas, je te remercie pour ton travail, car il est important.
Quand tu dis:
Effectivement, il est essentiellement maintenu par des gens de GNOME, une situation décriée par eux-même depuis plusieurs années, car ils sont en sous-effectifs. Depuis le retrait de Tor Lillqvist du poste de mainteneur GTK Windows, personne n'a pris le relais pour faire le boulot. Et je pense que l'équipe GTK serait plus que ravie d'avoir des contributeurs pour GTK Windows. Ce n'est pas par mauvaise volonté que ça n'avance pas, c'est juste qu'il n'y a plus personne pour faire le boulot. Aussi je m'étonne que tu parles de "refus de modifications". Tu as un exemple particulier en tête pour GTK ?