l'inertie du code l'emporte sur la migration vers une nouvelle librairie
Tout le monde a bien conscience que c'est compliqué de changer, que ça prends des années.
Qt permettrait de le faire par étapes en se mélangeant au code historique.
Ça c'est déjà fait pour les MFC, Motif et Java AWT/Swing.
quel serait l’intérêt pour eux de le faire ?
On tourne en rond là...
Utiliser un toolkit comme Qt permet d'externaliser beaucoup de code à des gens dont c'est le métier, qui ont le temps, les compétences et les ressources pour le faire beaucoup mieux que toi.
Ça permet de te concentrer sur l'essentiel, sur ton cœur de métier qui n'est pas de développer et maintenir une librairie graphique complète.
Et les arguments du type "une nouvelle librairie que tu ne connais pas" et "tu ne maîtrises pas l'évolution" tiennent plus de NIH qu'autre chose. On parle de Qt hein : LGPL, open gouvernance, très bien documenté ect...
Subsurface, VLC, Wireshark, LXDE, OpenShot, Stellarium, Autodesk Maya, Ubuntu Unity, TortoiseHg... ont bien réussis à changer pour Qt.
Que va t'il se passer s'ils continuent avec leur toolkit interne ?
Le toolkit va continuer de vieillir gentiment : moins jolie que la concurrence, widgets pauvres, pas d’accélération, pas d'animation, moins bonne intégration avec les futurs versions de Windows, OS X...
Temps consacrer à la maintenance et à l’évolution de VCL
Temps de développement important pour ajouter/améliorer des fonctionnalités à LO : exemple de rapidité de développement avec Qt : http://www.youtube.com/watch?v=_6_F6Kpjd-Q, je doute que ça soit aussi rapide et facile avec VCL...
Rebuter les potentiels contributeurs : les gens connaissent les toolkits couramment utilisés, pas VCL
J'ai travaillé dans des entreprises qui n'ont pas toujours fait évoluer leurs outils et librairies : build system custom en Perl, librairie graphique développée en interne, base de données interne...
Ces outils avaient un intérêt 10-15 ans auparavant mais sont devenu un frein important par la suite.
En revanche on est bien d'accord que la priorité est de nettoyer le code avant de pouvoir faire un changement de cette importance. Mais apparemment remplacer VCL pour Qt n'est clairement pas à l'ordre du jour :-/
Et ce n'est pas parceque je ne contribuerais probablement jamais à LO que je n'ai pas le droit de faire des analyses à son sujet.
[^] # Re: remarques
Posté par tanguy_k (site web personnel) . En réponse à la dépêche LibreOffice 4.2.0 est disponible. Évalué à 10.
Tout le monde a bien conscience que c'est compliqué de changer, que ça prends des années.
Qt permettrait de le faire par étapes en se mélangeant au code historique.
Ça c'est déjà fait pour les MFC, Motif et Java AWT/Swing.
On tourne en rond là...
Utiliser un toolkit comme Qt permet d'externaliser beaucoup de code à des gens dont c'est le métier, qui ont le temps, les compétences et les ressources pour le faire beaucoup mieux que toi.
Ça permet de te concentrer sur l'essentiel, sur ton cœur de métier qui n'est pas de développer et maintenir une librairie graphique complète.
Et les arguments du type "une nouvelle librairie que tu ne connais pas" et "tu ne maîtrises pas l'évolution" tiennent plus de NIH qu'autre chose. On parle de Qt hein : LGPL, open gouvernance, très bien documenté ect...
Subsurface, VLC, Wireshark, LXDE, OpenShot, Stellarium, Autodesk Maya, Ubuntu Unity, TortoiseHg... ont bien réussis à changer pour Qt.
Que va t'il se passer s'ils continuent avec leur toolkit interne ?
J'ai travaillé dans des entreprises qui n'ont pas toujours fait évoluer leurs outils et librairies : build system custom en Perl, librairie graphique développée en interne, base de données interne...
Ces outils avaient un intérêt 10-15 ans auparavant mais sont devenu un frein important par la suite.
En revanche on est bien d'accord que la priorité est de nettoyer le code avant de pouvoir faire un changement de cette importance. Mais apparemment remplacer VCL pour Qt n'est clairement pas à l'ordre du jour :-/
Et ce n'est pas parceque je ne contribuerais probablement jamais à LO que je n'ai pas le droit de faire des analyses à son sujet.