On est bien d'accord sur les faits, mais on en tire des conclusions entièrement différentes.
Le meilleur exemple en est quand tu dis:
Qt5 est quasiment source compatible avec Qt4.
Donc voilà, du point de vue des développeurs de toolkits, pour sortir une nouvelle version du toolkit sans causer trop de problèmes, il suffit d'être "quasiment source compatible".
C'est là que je ne suis pas du tout d'accord: pour moi, la barre en termes de compatibilité est bien plus haut. Il faut aussi préserver à 100.00% la compatibilité binaire descendante: les binaires compilés pour Qt4 doivent continuer de s'exécuter sans aucune modification sous Qt 5, Qt 6, et ainsi de suite jusqu'à ce que vraiment presque plus personne n'ait de binaires Qt4 à faire tourner. Et, chose très importante, il doit rester possible d'utiliser les différentes versions simultanément, dans la même application.
Il y a différentes façon d'atteindre cet objectif. La façon Microsoft, qui est la première direction où regarder puisque c'est ce qu'il y a de plus proche techniquement et qu'ils ont un certain succès commercial, c'est simplement de continuer de distribuer des binaires des anciennes versions de leurs SDK, et de concevoir leurs interfaces pour permettre d'utiliser de multiples versions simultanément. C'est comme si les distributions binaires de Qt5 contenaient une copie des binaires de Qt4.
Android et Apple aussi continuent de distribuer leurs vieux SDK binaires avec les nouveaux.
Idem pour les distributions binaires d'implémentations d'OpenGL, qui sont les championnes de la compatibilité descendante, une application OpenGL 1.0 d'il y a presque vingt ans pouvant encore tourner sans recompilation sur n'importe quelle machine ayant des pilotes OpenGL.
Si les toolkits libres veulent être pris au sérieux, il faut qu'ils fassent la même chose. Dans mon journal, j'ai donné un exemple concret montrant en quoi le fait que GTK3 ne fait pas ça, est une grande cause de problèmes pour Firefox.
Du coup, le coût réel d'accroître un toolkit pour y include des choses come QVector et QList, est plus important dans ma vision des choses que dans la tienne, car ce gonflement va être multiplié par un certain facteur pour garantir la compatibilité au fil des années.
Je ne rentre pas plus dans le détail de ta réponse parce que je pense que le point important de désaccord était celui-ci.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à -1. Dernière modification le 12 octobre 2012 à 19:02.
On est bien d'accord sur les faits, mais on en tire des conclusions entièrement différentes.
Le meilleur exemple en est quand tu dis:
Donc voilà, du point de vue des développeurs de toolkits, pour sortir une nouvelle version du toolkit sans causer trop de problèmes, il suffit d'être "quasiment source compatible".
C'est là que je ne suis pas du tout d'accord: pour moi, la barre en termes de compatibilité est bien plus haut. Il faut aussi préserver à 100.00% la compatibilité binaire descendante: les binaires compilés pour Qt4 doivent continuer de s'exécuter sans aucune modification sous Qt 5, Qt 6, et ainsi de suite jusqu'à ce que vraiment presque plus personne n'ait de binaires Qt4 à faire tourner. Et, chose très importante, il doit rester possible d'utiliser les différentes versions simultanément, dans la même application.
Il y a différentes façon d'atteindre cet objectif. La façon Microsoft, qui est la première direction où regarder puisque c'est ce qu'il y a de plus proche techniquement et qu'ils ont un certain succès commercial, c'est simplement de continuer de distribuer des binaires des anciennes versions de leurs SDK, et de concevoir leurs interfaces pour permettre d'utiliser de multiples versions simultanément. C'est comme si les distributions binaires de Qt5 contenaient une copie des binaires de Qt4.
Android et Apple aussi continuent de distribuer leurs vieux SDK binaires avec les nouveaux.
Idem pour les distributions binaires d'implémentations d'OpenGL, qui sont les championnes de la compatibilité descendante, une application OpenGL 1.0 d'il y a presque vingt ans pouvant encore tourner sans recompilation sur n'importe quelle machine ayant des pilotes OpenGL.
Si les toolkits libres veulent être pris au sérieux, il faut qu'ils fassent la même chose. Dans mon journal, j'ai donné un exemple concret montrant en quoi le fait que GTK3 ne fait pas ça, est une grande cause de problèmes pour Firefox.
Du coup, le coût réel d'accroître un toolkit pour y include des choses come QVector et QList, est plus important dans ma vision des choses que dans la tienne, car ce gonflement va être multiplié par un certain facteur pour garantir la compatibilité au fil des années.
Je ne rentre pas plus dans le détail de ta réponse parce que je pense que le point important de désaccord était celui-ci.