... c'est qu'ils sont toujours à la traîne par rapport à la bibliothèque qu'ils encapsulent et encore quand ils sont dispo. Et pour ce qui est du multi plateforme, on repassera. La plupart des bindings ont des dépendances supplémentaires qui coincent sur les autres plateformes. PyQt a besoin de Sip. Qt4 est dispo depuis longtemps sous Windows et *nix mais pourtant toujours pas moyen de faire du PyQt (avec la version GPL de Qt) sous Windows : Sip n'est pas pret. Pour ce qui est de QtRuby n'en parlons même pas : Il dépend de Smoke... qui fait partie de KDEBindings. En voiture Simone, il n'y a plus qu'à porter tout le bousin pour faire une pauvre fenêtre avec un bouton. Au final ça va plus vite de coder direct en C++.
Pour Gtk, les choses se passent un peu mieux, il me semble (du C "normal", non customisé ça passe déjà mieux), mais il n'empêche que pour profiter d'une nouvelle version (surtout sous autre chose que Linux) il faut quand même attendre.
Enfin avec les bindings on profite des bugs de la bibliothèque plus des bugs du binding. On se retrouve parfois avec un code qui merde en GtkRuby et qui passe en C alors que normalement on fait exactement la même chose.
# Le problème avec les bindings...
Posté par Croconux . En réponse au journal Langages pour desktop. Évalué à 3.
Pour Gtk, les choses se passent un peu mieux, il me semble (du C "normal", non customisé ça passe déjà mieux), mais il n'empêche que pour profiter d'une nouvelle version (surtout sous autre chose que Linux) il faut quand même attendre.
Enfin avec les bindings on profite des bugs de la bibliothèque plus des bugs du binding. On se retrouve parfois avec un code qui merde en GtkRuby et qui passe en C alors que normalement on fait exactement la même chose.