> On ne peut donc pas programmer en KDE sans être dépendant de Qt ?
Non.
> Logiquement, dans le boulot de KDE, le but est un peu de faire en sorte que le programmeur qui fait du KDE n'a pas à prendre en compte des considérations de bas niveau (niveau Qt).
Non plus. Qt n'est pas si "bas niveau" que ça.
> Là c'est comme imposer un changement dans le langage C sous prétexte qu'on va faire tourner le programme sur un nouveau processeur.
Non, rien à voir. Qt n'est pas un langage.
> Je ne vois vraiment pas en quoi le passage à Qt3 impose un changement d'API sur KDE, le prochain KDE pourrait tout simplement être capable de se servir de Qt3, son API à lui restant compatible.
Ça voudrait dire wrapper toutes les classes Qt. C'est techniquement possible, mais parfaitement inutile, et le résultat serait mauvais.
Par exemple, dans Qt2 on avait QArray et QVector, maintenant dans Qt3 on a QValueVector et QPtrVector, et leur APIs ont légèrement changé (en mieux). Ces classes sont couramment utilisées dans les libs et les applis KDE. Selon toi, il aura fallu creer KArray et KVector dès le début de KDE pour assurer la compatibilité ? C'est un casse-tête sans nom, et complètement inefficace (tu ne peux plus profiter des améliorations de l'API).
[^] # Re: La course au numéros
Posté par Guillaume Laurent . En réponse à la dépêche KDE 3.0. Évalué à 1.
Non.
> Logiquement, dans le boulot de KDE, le but est un peu de faire en sorte que le programmeur qui fait du KDE n'a pas à prendre en compte des considérations de bas niveau (niveau Qt).
Non plus. Qt n'est pas si "bas niveau" que ça.
> Là c'est comme imposer un changement dans le langage C sous prétexte qu'on va faire tourner le programme sur un nouveau processeur.
Non, rien à voir. Qt n'est pas un langage.
> Je ne vois vraiment pas en quoi le passage à Qt3 impose un changement d'API sur KDE, le prochain KDE pourrait tout simplement être capable de se servir de Qt3, son API à lui restant compatible.
Ça voudrait dire wrapper toutes les classes Qt. C'est techniquement possible, mais parfaitement inutile, et le résultat serait mauvais.
Par exemple, dans Qt2 on avait QArray et QVector, maintenant dans Qt3 on a QValueVector et QPtrVector, et leur APIs ont légèrement changé (en mieux). Ces classes sont couramment utilisées dans les libs et les applis KDE. Selon toi, il aura fallu creer KArray et KVector dès le début de KDE pour assurer la compatibilité ? C'est un casse-tête sans nom, et complètement inefficace (tu ne peux plus profiter des améliorations de l'API).
> Alors, qu'est-ce que je n'ai pas compris ?
Comment est construit KDE.