Si je ne peux pas exagérer, comment veux-tu que je lance un troll dans des conditions décentes ?
Moi, pour ce que j'ai vu : j'ai voulu faire une page en XUL. Il a fallu pour ça, du XML, du js, du css, du html, du rdf. La meme chose avec une structure plus "classique" de page web : js, css, html. J'ai deux éléments, XML certes, mais dont il faut connaître le schéma (faire des aller retour vers la doc pour comprendre comment qu'on actualise un Tree -par exemple- n'est pas une option : je veux que ma page marche, et qu'elle soit prête à temps). D'ailleurs à la même époque, j'en connais qui avaient fait une interface web en XUL. Ça date de 2 ans. L'interface n'est plus accessible avec les dernières versions de Firefox -du moins sous windows, cad la cible visée, et solaris- (la 1.5 plantait déjà, la 2.0 aussi, avec un pourcentage d'occupation mémoire assez important). Mon appli web js/css/html classique, elle, tient toujours.
X langages : oui, tous ou presque se résument à du XML, du js, et 2/3 trucs. Mettons que je maîtrise le XML. Il faut que j'apprenne toutes les grammaires liées à chaque XML, et celles-ci ne sont pas toujours intuitives (pour moi, et c'est purement subjectif).
Imaginons : je veux faire une visionneuse d'images png :
avec Xulrunner&Co, il faut que j'installe Xulrunner (facile, quoique mon dernier essai sous mac os, qui remonte à un peu plus d'un an, n'avait pas du tout été concluant, mais je crois savoir que ça a fortement progressé de ce côté là). Il me faut ensuite comprendre/connaître toutes les grammaires, apprendre au minimum le js, css, html. Il y a au minimum 2 langages (js, XML), et plusieurs API/grammaires.
Avec un bon vieux perl, je dois installer perl (soit), tk (par exemple). Ensuite, je dois apprendre perl, et comprendre/connaître juste l'api de base de tk. Il n'y a qu'un langage, et une api.
Pour moi, y'a pas photo : je connais assez de js, css, html, et assez de perl, pour penser aller plus vite à faire mon appli en perl/tk qu'en xul. Et il existe des perl2exe.
Chacun a ses avantages, et ses inconvénients. C'est pour ça que je dis que XUL est une idée formidable, mais ça ne me convient absolument pas. D'autant que j'ai dans de nombreux langages des générateurs qui me permettent de construire la base de mes sources plus rapidement.
C'est aussi en ça que je dis que XUL pêche par son absence de combinaison IDE/Framework.
Pour finir : je persiste : si je veux améliorer Xulrunner en réalisant par exemple une sorte d'IB à la XCode/GNUStep, il faut quand même avoir plus que de sérieuses bases dans l'ensemble des technos mises en oeuvre. Et ça, ce n'est clairement pas accessible à tout le monde.
Conclusion : collaborer à des projets comme XUL, c'est une super méthode d'apprentissage pluri-disciplinaire avant de pouvoir maîtriser l'engin.
[^] # Re: Une pièce du puzzle
Posté par iznogoud . En réponse à la dépêche Adobe libère sa machine virtuelle ActionScript 3. Évalué à 5.
Moi, pour ce que j'ai vu : j'ai voulu faire une page en XUL. Il a fallu pour ça, du XML, du js, du css, du html, du rdf. La meme chose avec une structure plus "classique" de page web : js, css, html. J'ai deux éléments, XML certes, mais dont il faut connaître le schéma (faire des aller retour vers la doc pour comprendre comment qu'on actualise un Tree -par exemple- n'est pas une option : je veux que ma page marche, et qu'elle soit prête à temps). D'ailleurs à la même époque, j'en connais qui avaient fait une interface web en XUL. Ça date de 2 ans. L'interface n'est plus accessible avec les dernières versions de Firefox -du moins sous windows, cad la cible visée, et solaris- (la 1.5 plantait déjà, la 2.0 aussi, avec un pourcentage d'occupation mémoire assez important). Mon appli web js/css/html classique, elle, tient toujours.
X langages : oui, tous ou presque se résument à du XML, du js, et 2/3 trucs. Mettons que je maîtrise le XML. Il faut que j'apprenne toutes les grammaires liées à chaque XML, et celles-ci ne sont pas toujours intuitives (pour moi, et c'est purement subjectif).
Imaginons : je veux faire une visionneuse d'images png :
avec Xulrunner&Co, il faut que j'installe Xulrunner (facile, quoique mon dernier essai sous mac os, qui remonte à un peu plus d'un an, n'avait pas du tout été concluant, mais je crois savoir que ça a fortement progressé de ce côté là). Il me faut ensuite comprendre/connaître toutes les grammaires, apprendre au minimum le js, css, html. Il y a au minimum 2 langages (js, XML), et plusieurs API/grammaires.
Avec un bon vieux perl, je dois installer perl (soit), tk (par exemple). Ensuite, je dois apprendre perl, et comprendre/connaître juste l'api de base de tk. Il n'y a qu'un langage, et une api.
Pour moi, y'a pas photo : je connais assez de js, css, html, et assez de perl, pour penser aller plus vite à faire mon appli en perl/tk qu'en xul. Et il existe des perl2exe.
Chacun a ses avantages, et ses inconvénients. C'est pour ça que je dis que XUL est une idée formidable, mais ça ne me convient absolument pas. D'autant que j'ai dans de nombreux langages des générateurs qui me permettent de construire la base de mes sources plus rapidement.
C'est aussi en ça que je dis que XUL pêche par son absence de combinaison IDE/Framework.
Pour finir : je persiste : si je veux améliorer Xulrunner en réalisant par exemple une sorte d'IB à la XCode/GNUStep, il faut quand même avoir plus que de sérieuses bases dans l'ensemble des technos mises en oeuvre. Et ça, ce n'est clairement pas accessible à tout le monde.
Conclusion : collaborer à des projets comme XUL, c'est une super méthode d'apprentissage pluri-disciplinaire avant de pouvoir maîtriser l'engin.