> Ah si t'as l'énorme avantage de pouvoir appeler facilement un API en C depuis n'importe quel langage
Donc l'interet d'avoir Gnome en C, c'est de ne pas programmer en C. Super ! C'est con pour tous les mecs naifs qui ont ecrit des programmes Gnome/Gtk en C. En fait, ils se sont trompes, il fallait qu'ils utilisent plutot un binding.
Je prefere le choix de KDE: pour programmer des bonnes applis, on prend un bon langage. Le C++ offrait et offre toujours beaucoup de possibilites et permettait d'avancer rapidement et proprement dans le developpement d'un bureau de qualite.
Il y avait un petit inconvenient au niveau des bindings mais il faut relativiser : comme le C++ est un langage globalement de bonne qualite, le besoin de binding est beaucoup plus faible (c'est pour ca qu'il n'y a pas d'empoignades sur KDE a propos de C# ou Java. Le C++ satisfait deja une tres grande partie des developpeurs KDE et ils ne ressentent pas autant que Gnome le besoin de passer a un langage plus moderne).
Par ailleurs, malgre cet avantage certain, les bindings de Gtk ont ete certes plus nombreux au depart, mais tres souvent pas maintenu sur le long terme, de qualite inegale, et tres peu ont inclus a la fois les bilbiotheques Gtk et Gnome. L'apparente facilite de generer des bindings en C a ete contrebalancee par la necessite de les generer a la main et donc de les maintenir. L'absence d'infos suffisante dans les .h empechait d'automatiser completement cette tache (cf les problemes cites plus haut) qui ont fait que avoir des bindings a jour sur Gnome a ete une gagure. Il faut attendre gobject pour avoir un truc propre.
Au final, KDE a pondu un systeme de generation de binding qui s'affranchit des problemes du C++ et permet de generer des bindings pour plusieurs langages de facon automatise. Ils ont eu directement la bonne approche.
En choisissant le bon langage des le depart, on a gagne sur les deux tableaux:
- on programme avec KDE dans un langage moderne
- on a une generation de binding automatisee
> Il faut voir aussi qu'à l'époque du choix de C par Gnome le C++ n'était pas vraiment standardisé dans les compilos (je précises dans les compilos)
Pourtant, deja a l'epoque, Qt compilait out-of-the-box sur toutes les architectures majeurs, et tous les compilos majeurs. Donc c'etait peut-etre pas la panacee, mais ca marchait tres bien. C'est sur que un truc comme boost on libsig++ qui utilise les template de facon majeure n'aurait surement pas compile a l'epoque. Ca tombe bien, Qt utilise justement tres peu les template.
Maintenant, qu'on peut se lacher un peu plus au niveau du C++, Qt fournit aussi des trucs sympas, genre :
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 2.
Donc l'interet d'avoir Gnome en C, c'est de ne pas programmer en C. Super ! C'est con pour tous les mecs naifs qui ont ecrit des programmes Gnome/Gtk en C. En fait, ils se sont trompes, il fallait qu'ils utilisent plutot un binding.
Je prefere le choix de KDE: pour programmer des bonnes applis, on prend un bon langage. Le C++ offrait et offre toujours beaucoup de possibilites et permettait d'avancer rapidement et proprement dans le developpement d'un bureau de qualite.
Il y avait un petit inconvenient au niveau des bindings mais il faut relativiser : comme le C++ est un langage globalement de bonne qualite, le besoin de binding est beaucoup plus faible (c'est pour ca qu'il n'y a pas d'empoignades sur KDE a propos de C# ou Java. Le C++ satisfait deja une tres grande partie des developpeurs KDE et ils ne ressentent pas autant que Gnome le besoin de passer a un langage plus moderne).
Par ailleurs, malgre cet avantage certain, les bindings de Gtk ont ete certes plus nombreux au depart, mais tres souvent pas maintenu sur le long terme, de qualite inegale, et tres peu ont inclus a la fois les bilbiotheques Gtk et Gnome. L'apparente facilite de generer des bindings en C a ete contrebalancee par la necessite de les generer a la main et donc de les maintenir. L'absence d'infos suffisante dans les .h empechait d'automatiser completement cette tache (cf les problemes cites plus haut) qui ont fait que avoir des bindings a jour sur Gnome a ete une gagure. Il faut attendre gobject pour avoir un truc propre.
Au final, KDE a pondu un systeme de generation de binding qui s'affranchit des problemes du C++ et permet de generer des bindings pour plusieurs langages de facon automatise. Ils ont eu directement la bonne approche.
En choisissant le bon langage des le depart, on a gagne sur les deux tableaux:
- on programme avec KDE dans un langage moderne
- on a une generation de binding automatisee
> Il faut voir aussi qu'à l'époque du choix de C par Gnome le C++ n'était pas vraiment standardisé dans les compilos (je précises dans les compilos)
Pourtant, deja a l'epoque, Qt compilait out-of-the-box sur toutes les architectures majeurs, et tous les compilos majeurs. Donc c'etait peut-etre pas la panacee, mais ca marchait tres bien. C'est sur que un truc comme boost on libsig++ qui utilise les template de facon majeure n'aurait surement pas compile a l'epoque. Ca tombe bien, Qt utilise justement tres peu les template.
Maintenant, qu'on peut se lacher un peu plus au niveau du C++, Qt fournit aussi des trucs sympas, genre :