> Mais avec Glade et Qt Designer il faut tout de meme programmer en > dur les actions que vont avoir l'interface sur le reste du programme.
Sans blague ? Tu veux dire qu'il ne t'ecrit pas ton programme tout seul, tu as encore du code a ecrire ? Mon dieu, c'est atroce. Vivement l'IDE qui comprend tout seul ce que tu veux faire, et ou tu n'as meme pas besoin de toucher le clavier.
> XUL est plus puissant qu'un truc comme libglade car il va encore plus
> loin au niveau de la separation de l'interface et du programme.
> XUL a ete pense depuis le debut dans cette optique.
Ok, on peut faire des boutons et des machins en XUL. Mais on peut deja le faire avec Qt Desgner. Sous KDE, les menu d'une application et sa barre d'outils sont aussi definis par un fichier XML donc on est a mon avis au meme niveau que XUL.
Mais si tu crois que faire une interface grapnique, c'est faire un programme tu te trompes. Mon experience de programmation en Qt et de KDE, c'est que l'interface devient facile a coder. Il reste plus qu'a faire l'intelligence et pour ca, XUL ne peut pas t'aider.
De plus, si tu veux faire un programme evolue, tu as besoin d'avoir un controle tres precis de tes elements graphiques, et souvent, tu es amenu a en inventer. J'aimerai voir un KOffice, KDevelop ou khtml ecrit en XUL. Pour khtml, je sens venir le "mais il y a gecko justement". Et bien non, gecko, c'est un composant de mozilla ecrit un C avec les Netscape Portable Library, il n'apporte rien de plus en terme de facilite de develloppement par rapport a Qt. C'est juste que l'interface est plus facilement modifiable, mais c'est aussi le cas avec Qt si tu utilises des .ui charges dynamiquement.
Citation du "joy of XUL" sur le site de Mozilla, a propos du calendrier ecrit en XUL:
<<
the UI code is written in JavaScript, [...] the interaction logic worked with no effort. However, since the libical library is written in C, more significant effort was required to migrate this component to the other platforms.
>>
Donc en resume, c'est tout pareil que Qt, sauf que tu as du C et du javascript pour developper ton appli. L'avantage de Qt, c'est qu'au moins, la portabilite est _tres_ facile, contrairement a l'exemple donne ici.
Pour ce qui est de la legerete de XUL, firebird prend 27 mo de memoire en ce moment sur ma machine windows alors que opera qui fait la meme chose tourne autour de 12 Mo. Et Komodo, l'IDE d'ActiveState developpe en technos mozilla est un IDE les plus lents que j'ai jamais utilise (ceci dit, c'etait avant d'utiliser des IDE full java). Donc, je suis tres scriptique face a cet argument.
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Philippe F (site web personnel) . En réponse à la dépêche GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration. Évalué à 2.
Sans blague ? Tu veux dire qu'il ne t'ecrit pas ton programme tout seul, tu as encore du code a ecrire ? Mon dieu, c'est atroce. Vivement l'IDE qui comprend tout seul ce que tu veux faire, et ou tu n'as meme pas besoin de toucher le clavier.
> XUL est plus puissant qu'un truc comme libglade car il va encore plus
> loin au niveau de la separation de l'interface et du programme.
> XUL a ete pense depuis le debut dans cette optique.
Ok, on peut faire des boutons et des machins en XUL. Mais on peut deja le faire avec Qt Desgner. Sous KDE, les menu d'une application et sa barre d'outils sont aussi definis par un fichier XML donc on est a mon avis au meme niveau que XUL.
Mais si tu crois que faire une interface grapnique, c'est faire un programme tu te trompes. Mon experience de programmation en Qt et de KDE, c'est que l'interface devient facile a coder. Il reste plus qu'a faire l'intelligence et pour ca, XUL ne peut pas t'aider.
De plus, si tu veux faire un programme evolue, tu as besoin d'avoir un controle tres precis de tes elements graphiques, et souvent, tu es amenu a en inventer. J'aimerai voir un KOffice, KDevelop ou khtml ecrit en XUL. Pour khtml, je sens venir le "mais il y a gecko justement". Et bien non, gecko, c'est un composant de mozilla ecrit un C avec les Netscape Portable Library, il n'apporte rien de plus en terme de facilite de develloppement par rapport a Qt. C'est juste que l'interface est plus facilement modifiable, mais c'est aussi le cas avec Qt si tu utilises des .ui charges dynamiquement.
Citation du "joy of XUL" sur le site de Mozilla, a propos du calendrier ecrit en XUL:
<<
the UI code is written in JavaScript, [...] the interaction logic worked with no effort. However, since the libical library is written in C, more significant effort was required to migrate this component to the other platforms.
>>
Donc en resume, c'est tout pareil que Qt, sauf que tu as du C et du javascript pour developper ton appli. L'avantage de Qt, c'est qu'au moins, la portabilite est _tres_ facile, contrairement a l'exemple donne ici.
Pour ce qui est de la legerete de XUL, firebird prend 27 mo de memoire en ce moment sur ma machine windows alors que opera qui fait la meme chose tourne autour de 12 Mo. Et Komodo, l'IDE d'ActiveState developpe en technos mozilla est un IDE les plus lents que j'ai jamais utilise (ceci dit, c'etait avant d'utiliser des IDE full java). Donc, je suis tres scriptique face a cet argument.
Pour resumer le fond de ma pensee: XUL, c'est bien pour des applications relativement simples, qui peuvent tout aussi bien etre ecrites en Visual Basic, PyQt voire Kommander (http://quanta.sourceforge.net/main2.php?snapfile=snap02(...)).
Quand tu dois coder des choses complexes, tu as besoin d'un vrai toolkit, et c'est la ou tu apprecie la puissance d'un vrai truc comme Qt ou Gtk.