XULRunner est un environnement d'exécution d'applications XUL, XUL étant un langage de description d'interfaces graphiques. Une application XULRunner est typiquement codée en JavaScript. Une partie du code d'une application XULRunner peut néanmoins être déportée dans des composants XPCOM (codés en C++ le plus fréquemment). Pour mettre en œuvre un tel composant, on écrit généralement un fichier '.idl', décrivant son API, qui sert à générer les fonctions JavaScript au travers desquelles on accède au composant concerné.
Pour puissants et nombreux que sont les éléments disponibles avec XULRunner, ils ne permettent pas à une application d’accéder à toutes les ressources du système sur lequel elle est utilisée. Les composants XPCOM permettent de pallier à cela. Si l'on met en œuvre un tel composant, en utilisant C++, il peut s’avérer intéressant de coder l'intégralité de l'application en C++, pour éviter d'avoir à jongler entre ce dernier et JavaScript (entre autres avantages).
Il existe une abondante documentation, assortie de tutoriels et d'exemples, portant sur la manipulation des éléments disponibles avec XULRunner en JavaScript. A l'inverse, l'équivalent pour C++ est anémique, pour ne pas dire inexistant. Cela rend le développement d'une application XULRunner entièrement en C++ très compliqué, comme j'ai pu en faire l'expérience. Néanmoins, malgré les difficultés, c'est une approche que j'ai définitivement adoptée.
Pour éviter à ceux qui serait également intéressé par cette approche de se heurter aux mêmes difficultés que celles j'ai rencontrées, j'ai, pour commencer, mis en ligne le résultat de mes recherches sur le sujet sous la forme, à titre d'exemple, d'une d'application. Cette application montre comment il est possible de réagir à des évènements issus de l'interface XUL, de récupérer des information de cette interface (contenu d'un 'textbox' p. ex.), ou de modifier cette interface (remplir une 'textbox', p. ex.) et ce, uniquement en C++.
Cette application, qui fonctionne sous GNU/Linux, MacOS et Windows, est diffusée sous licence GNU GPL. Pour consulter les sources, ou bien les télécharger pour éventuellement les compiler, ça se passe sur cette page (http://zeusw.org/blog/?article14/).
# Intérêt
Posté par nud . Évalué à 7.
Quel est l'intérêt d'utiliser xulrunner ci c'est pour coder l'intégralité de l'application en C++ ?
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
oui, je me pose exactement la même question. D'après ce que j'ai compris, on n'a plus à utiliser de gestionnaire d'évènement ou autres trucs "webesque" de XulRunner. Et en gros, tout le code de l'appli est dans des libs externes en C/C++.
Et au final aussi, un truc à la XPCom à été recodé en passant par XPCom. Au final on a donc une couche qui transmet des appels vers les libs externe, donc comme XPCom. -> double couche logicielle pour accéder à la lib externe. à moins d'avoir rien compris au bidule :-)
Bon, sinon, de la doc sur XPCOM C++, elle existe quand même https://developer.mozilla.org/en/XPCOM. Et il y a aussi une alternative, pour accéder directement aux fonctions d'une lib : js-ctypes.
(hors sujet: CVS, c'est vraiment pénible, je recommande d'utiliser un gestionnaire de source récent :-p)
[^] # Re: Intérêt
Posté par reg . Évalué à 2.
Trois problèmes:
Xulrunner est est devenu un casse tête. Il a été sorti d'Ubuntu car “trop chiant à maintenir” et que “Firefox est capable de faire la même chose”, sauf que c'est pas le cas. Firefox ne remplace pas complètement XulRunner. La solution préconisé par Mozilla: faire des libs externes et utiliser js-ctype (avec FF)
js-ctyes c'est bien mais on dirait que pas grand monde l'utilise. La doc est plus que minimaliste et bon courage pour trouver les sources d'un soft l'utilisant.
Le plus dérangeant sans doute: la politique de Mozilla change souvent, il n'y a pas de point d'entrée précis ou l'on te dis “voilà la façon recommandée (ie. maintenue) de faire”. Il faut écumer les planet et blog pour avoir l'avis de différents protagonistes et parier sur une façon de faire.
Bref, à déconseiller à ceux qui ne l'utilisent pas encore.
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . Évalué à 7.
On code l'application exactement comme on le ferait en JavaScript, sauf qu'on utilise C++. Comme en JavaScript, on a toujours un gestionnaire d'évènement à implémenter, mais il sera implémenté en C++. Et tout le code de l’application est effectivement dans une bibliothèque externe.
Lorsque l'on code une application en JavaScript, on accède en fait à des composants écrits en C++ à travers leur interface JavaScript. L'idée c'est d’accéder à ces composants directement en C++, sans passer par JavaScript. On a donc, au contraire, une couche logicielle en moins...
Je connais cette documentation (XPCOM), et l'ai abondamment utilisée. Mais elle ne détaille pas comment manipuler un élément XUL en C++. Par exemple, je n'ai trouvé aucune documentation qui indique qu'un élément 'tree' en XUL correspond, en C++, à l'objet 'nsIDOMXULTreeElement', et que pour avoir l'index de l’élément sélectionné dans ce 'tree', il fallait d'abord faire un 'GetView(...)', sur le résultat duquel il faut ensuite faire un 'GetSelection(...)', sur le résultat duquel il faut faire 'GetCurrentIndex(...)'. Quand à 'js-ctypes', c'est apparemment essentiellement pour faire du C...
(Ça fait plus de 11 ans que j'utilise le CVS de savannah.gnu.org. Pourquoi changer quelque chose qui fonctionne ?)
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Intérêt
Posté par Guillaume Denry (site web personnel) . Évalué à 7.
Ça fait plus de 11 ans que je grave mes rapports de bugs sur des tablettes en marbre, pourquoi changer quelque chose qui fonctionne ?
[^] # Re: Intérêt
Posté par khivapia . Évalué à 8.
Parce que le marbre coûte cher évidemment. Je peux te proposer un service qui fait la même chose pour moins cher et te débarrasser de tes tablettes lourdes en encombrantes (ça tombe bien, j'ai ma salle de bains à refaire).
[^] # Re: Intérêt
Posté par François Chaix (site web personnel) . Évalué à 7.
Ça doit être hyper classe de carreler sa salle de bain avec des rapports de bugs !
La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.
[^] # Re: Intérêt
Posté par zebra3 . Évalué à 1.
Tu n'es pas au courant ? C'est ce qu'à fait Bill Gates avec ceux de Windows.
Faut dire qu'il a une très grande salle de bain.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Donc tu passes 10 fois plus de temps à implémenter un truc (des listeners et autres trucs d'interface), pour un résultat qui n'apporte au final rien en terme de perf (au niveau de l'UI).
disclamer : je fais du xpcom c++ depuis des années...
moui ok, je comprend mieux le principe de ton truc. Mais quand même, comme je dis, ça n'apporte rien en terme de perf, au niveau de l'interface utilisateur, sauf si tu manipules à tour de bras des centaines d’éléments XUL. En tout cas le rapport (productivité, facilité de dev, de maintenance etc)/performance est très très faible.
Pourtant, tout est indiqué sur la doc de la balise tree, https://developer.mozilla.org/en/XUL/tree , en particulier les interfaces qu'elle utilise, et donc ses propriétés dont la view etc. Etant donné que les objets DOM accessibles en JS sont simplement un accés XPCom aux objets C++ correspondant... Et par le passé, XulPlanet.org était encore mieux documenté au niveau des interfaces etc..
Pour être plus productif ? Pour faciliter les contributions ? Pour avoir un outil plus performant ? pour avoir une interface web agréable à utiliser ? (le browser CVS est juste horrible).
M'enfin chacun utilise ce qu'il veut :-)
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . Évalué à 3.
Sans entrer dans un débat JavaScript vs C++, il se trouve que je dispose d'outils, qui sont d'ailleurs utilisés dans l'application citée dans ce journal, grâce auxquels je mets nettement moins de temps à implémenter un 'truc' en C++ qu'en JavaScript, et que je ne suis probablement pas le seul, d'où ce journal.
Moi aussi. Et ?
Ça apporte peut-être peu, mais certainement pas rien en terme de performances, vu qu'on évite la surcouche JavaScript. Néanmoins, les performances ne sont pas, à mon avis, le critère déterminant. Il se trouve que, pour moi (et certainement pour d'autres, d'où ce journal), la productivité, la facilité de développement et de maintenance sont nettement plus élevés en C++ qu'en JavaScript.
Sauf que cette page est résolument orientée JavaScript, avec des exemples, alors que pour C++, il faut procéder par déduction en fouillant également dans les fichiers d'entête C++ fournis avec le SDK XULRunner.
(Je vais m'abstenir de répondre à ce propos, d'une part parce qu'il est hors-sujet, et, d'autre part, parce que ma précédente intervention sur le sujet ayant été prise au pied de la lettre).
On est bien d'accord, c'est pour cela que j'utilise C++ à la place de JavaScript, et si d'autres préfère JavaScript, grand bien leur fasse :-) !
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . Évalué à 3.
C++ n'est employé qu'en lieu et place de JavaScript. Toute la partie description de l'interface reste en XUL...
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Intérêt
Posté par nud . Évalué à 1.
Quel est l'avantage de XUL sur GtkBuilder ou QML si c'est pour faire une application en C++ à 100% ?
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . Évalué à 3.
Pour ma part, ne ne connaissant guère ces deux technologies, je ne saurais répondre. Je laisserais donc aux connaisseurs le soin de répondre à cette question, si tel est leur bon plaisir...
Soit dit en passant, mon intention, à travers ce journal, n'a jamais été de laisser entendre que XUL(Runner), avec ou sans C++, puisse, ou non, être supérieur à d'autres technologies similaires ...
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
le fait que tu n'utilises plus JS enlève une grande partie de l'intérêt de la plateforme selon moi (dev rapide, maintenance et evolution plus aisées etc..)
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . Évalué à 2.
Voir mon précédent commentaire.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Intérêt
Posté par totof2000 . Évalué à 3.
apâter le troll ?
# Pourquoi pas un autre toolkit ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Le but de XulRunner n'est pas un framework/une plateforme pour écrire une appli entièrement en C++.
Pourquoi ne pas utiliser QT ou autre toolkit graphique ?? Parce que si dans ton projet, l'utilisation du JS est à proscrire, tu t'es, à mon avis, trompé de framework.
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Quel intérêt d'utiliser QuickTime pour coder une application ? o_O
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à -5.
Je ne parles pas de QuickTime, mais de QT : http://en.wikipedia.org/wiki/Qt_%28framework%29
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par patrick_g (site web personnel) . Évalué à 10.
Il savait très bien de quoi tu parlais...mais il n'a pas pu résister à cette bonne vieille joke increvable :-)
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Je crois qu'il savait très bien que je savais très bien :)
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Aaah pardon, Qt n'étant pas un acronyme, je ne comprenais pas :)
[^] # Re: nazi
Posté par Octabrain . Évalué à 0.
Après les grammars nazis, les cases nazis, putain...
[^] # Re: nazi
Posté par zebra3 . Évalué à 10.
Attention, tu devrais faire le caractère « … » plutôt que trois points. Tu vas attirer les typography nazis…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: nazi
Posté par barmic . Évalué à -2.
Et ajouter une espace insécable avant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: nazi
Posté par 2PetitsVerres . Évalué à 3.
Euh tu es sûr de toi là ?
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: nazi
Posté par barmic . Évalué à 3.
Je l'étais. Je pensais que … était une double ponctuation ce qui n'est pas le cas. Je ne ferrais plus l'erreur :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: nazi
Posté par claudex . Évalué à 7.
Pourtant, c'est assez visible que c'est une triple ponctuation.
--> []
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: nazi
Posté par Octabrain . Évalué à 2. Dernière modification le 14 février 2012 à 15:31.
Non, ils sont bien trop occupés à couper les cheveux en 4 pour en faire des cheveux cadratins, cheveux semi-cadratins, gratins, ou de se battre pour savoir si on dit un espace ou une espace, et d'autres sujets "passionnants" :)
[^] # Re: nazi
Posté par BAud (site web personnel) . Évalué à 3.
il n'y a pas à se battre, vu qu'en typographie on dit « une espace » ;-)
[^] # Re: nazi
Posté par Octabrain . Évalué à 0.
C'est pas ce que dit wikipedia : Espace_(typographie)
[^] # Re: nazi
Posté par zebra3 . Évalué à 4.
Et si l'espace, c'était le luxe ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: nazi
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
"Octabrain VS. Nazis" ça pourrait faire un bon film de Série B.
[^] # Re: nazi
Posté par Larry Cow . Évalué à 2.
Sinon, bientôt, il y a Iron Sky.
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Zenitram (site web personnel) . Évalué à -3. Dernière modification le 14 février 2012 à 15:16.
Comme tu l'auras remarqué ;-) dans le lien cité, ce dont tu parles, c'est Qt, pas QT. Non, tu ne parles pas de QT, ou alors je me trompe pas mal dans la compréhension (différence nom et lien cité). Et regarde "juste" le logo...
Moi qui utilise les deux, c'est chiant quand les gens se trompent (c'est assez rapide de différencier, mais au début j'ai cru que tu voulais programmer en QuickTime, ça se fait certes, mais pas facile pour du web, c'est plus de la vidéo "managée").
Donc s'il vous plait, écrivez "Qt" correctement! Certes dans le contexte on peut comprendre, mais quand même (edit: ouais, ouais, je fais trop sérieux par rapport aux autres)
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Octabrain . Évalué à 0.
Merci zenitram :)
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Maclag . Évalué à 3.
C'est pas tout ça mais Claude SIMON n'a toujours pas répondu à la question.
...
C'était quoi déjà la question??
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . Évalué à 1.
Je ne vois en quoi le fait que ce ne soit pas le but devrait m'empêcher de le faire...
Comme dit dans un précédent commentaire, étant donné que l'API JavaScript de XULRunner n'est qu'une surcouche à des objets C++, cela ne me semble totalement dénué de sens de court-circuiter JavaScript pour accéder à ces objets directement en C++, d'autant plus si l'on n'a aucune affinité avec JavaScript...
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Tu ne nous dis pas en quoi XUL t'apporte quelque chose que ne pourrait pas t'apporter Qt avec Quick par exemple, qui permet de décrire de façon très puissante des interfaces dans un format de fichier.
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . Évalué à 5.
Parce que c'est hors sujet et que je ne saurais répondre à cette question, ne connaissant que très peu ces technologies !
Je ne veux, par ce journal, pousser personne à préférer XULRunner à d'autres technologies, mais s'il se trouve quelqu'un qui, quelles qu’en soient les raisons, décide d'utiliser XULRunner en combinaison avec C++, ce journal l'informe simplement de l'existence d'une source d'informations, que j'espère pertinentes, sur le sujet.
Accessoirement, pour ce que j'en ai lu, Qt Quick n'existait pas lorsque j'ai été amené à choisir XULRunner.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Certes. Mais tu t'embarques dans un truc pas adapté, donc qui te prend 10 fois plus de temps à réaliser que si tu utilisais des outils plus adaptés. C'est comme si tu utilisais un rateau pour faire un trou, alors que si tu utilisais une pelle, tu serais plus efficace.
En prenant un toolkit 100% C++ (puisqu'il semble que ce soit ton langage de prédilection), comme Qt, tu pourrais te concentrer plus sur les éléments de ton framework plutôt que sur des contournements de la plateforme...
Oui donc tu t'es trompé de plateforme à mon sens...
Si j'ai choisi XUL pour de nombreux développements (depuis des années), c'est bien pour le coté "web" de la plateforme (donc XML/XUL/CSS ET Javascript). Si je voulais faire une appli entièrement en C++, je ne choisirais certainement pas XULRunner...
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . Évalué à 4.
Cf. précédent commentaire.
XULRunner est écrit en C++. Son SDK fournit une API C++. Je crois que, de ce fait, on peut le qualifier de toolkit 100% C++. Il ne manque que la documentation adéquate pour l'utiliser en tant que tel, et ce sans un contournement d'aucune sorte.
C'est clair que, avec la démocratisation des technologies WEB, c'est effectivement ce coté WEB qui a été mis en avant, car susceptible de toucher le plus grand nombre de personnes. Il n'en demeure pas moins que XULRunner, de par sa conception, est parfaitement adapté pour une utilisation avec C++ en lieu et place de JavaScript, n'était ce manque de documentation.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par fredix . Évalué à -2.
Je crois que tu viens de succomber au lavage de cerveau du complot mondial des Illuminati, qui dit que le MOOoonde exige des apps web ...
Mais bon dans le monde réel les apps suivantes sont natives et cartonnent pour la plupart : skype, dropbox, spotify, opera, iTunes, ...
Sans dec test Qt ! tu découvrira un toolkit multiplateforme de malade et tu pourras même l'étendre si besoin avec la libqxt pour ajouter des modules super pratique.
Mais par pitié arrêtez de penser Web !! XulRunner c'est pour que le gogole qui va utiliser ton app soit content de le faire dans son browser des bois ?? Moi je paris sur les users qui voient les avantages d'un client natif et au vu du succès des produits cités plus haut alors qu'ils ont tous leur concurrent full web j'ai l'impression qu'il y a pas mal de users pas si débile que ça ...
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Frank-N-Furter . Évalué à 4.
Dude, T’es complètement à côté de la plaque.
Firefox, Thunderbird, Bluegriffon, Songbird, leur point commun, en dehors d’êtres des veaux (je déconne !!!), c’est d’êtres des applis web?
Depending on the time of day, the French go either way.
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par fredix . Évalué à -2.
Pour moi quand lis ceci je comprend que son app sera délivré dans le browser, pas comme une app externe parce que sinon je vois pas en quoi elle pourrait toucher plus de monde.
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Frank-N-Furter . Évalué à 2.
Camarade, cesse de jouer les Rosa Luxembourg des apps natives, et fait attention au contexte, il parlait des développeurs.
Depending on the time of day, the French go either way.
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par fredix . Évalué à 1.
Heu j'y crois pas une seconde, on saura s'il répond :)
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . Évalué à 2.
Me voici ! :-)
Il m'arrive de développer des applications WEB, et, bien que j'utilise également C++ dans ce cas (ça va encore me valoir des remarques des pro-JavaScript, ça), je n'utilise pas XULRunner pour ces dernières.
Pour faire des applications WEB, le couple XULRunner + C++ n'est peut-être pas pas le plus adapté, puisqu'il faudrait fournir le code C++ compilé pour chaque plate-forme cible, alors que si l'application n'utilise que JavaScript, elle tournera d'office sur tout les plate-formes sur lesquelles tourne XULRunner.
XULRunner, je ne l'utilise donc que pour des applications pour lesquelles je veux fournir une interface native. Et j'en n'utilise que les éléments relatifs à la gestion de l'interface graphique. Pour tout le reste (gestion des fichiers, du réseau, du multitâche...), j'ai mes propres outils. Donc, que XULRunner, Qt ou autres technologies aient de supers outils pour gérer ces éléments, ça m'importe peu...
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par fredix . Évalué à 1.
L'avantage de Qt c'est qu'il te fourni tout ça. Hormis le fait que Xulrunner t'intéresse, je vois pas bien son intérêt face à Qt.. J'essaye de comprendre le cheminement de l'esprit pour aboutir à ce choix :)
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Je pense qu'il est pas là pour discuter de cela, il l'a bien répété. Il a fait son choix, et/ou il a probablement un passif applicatif qui le contraint à rester avec xulrunner.
Maintenant, s'il fallait partir de 0, vu le spectre fonctionnel et technique titanesque qu'offre Qt, et compte tenu que c'est un framework nativement fait pour être utilisé en C++, c'est clair que je partirais vers ça sans la moindre hésitation.
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Frank-N-Furter . Évalué à 3.
Et pour les plus jeunes, XULRunner c’est comme Qt Quick, en plus vieux, et avec un éditeur (la MoFo) qui en a un peu honte, mais n’ose pas le laisser mourir, de peur de se prendre une soufflante du père Glazman, mais le jour où il change d’activité, le projet sera officiellement enterré.
Depending on the time of day, the French go either way.
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
pas du tout. Daniel n'a que peu d'influence sur les décisions de Mozilla depuis quelques années. Mozilla ne laisse pas mourrir XulRunner, pour la simple raison que Firefox est basé dessus. Mais Mozilla ne met plus en avant XulRunner, parce qu'ils ne veulent pas dépenser leur énergie sur ce projet en terme de dev, marketing et autre. S'occuper d'un produit de la nature de XulRunner, c'est s'occuper à essayer de résoudre toutes les problématiques des développeurs utilisant cette plateforme, problématiques qui ne rentreraient pas dans les objectifs actuels de Mozilla. Ils préfèrent se concentrer sur la plateforme purement web. Ils bossent ainsi sur la plateforme XUL, uniquement pour répondre à leurs besoins (à ceux de Firefox, TB et autres), et non aux besoins des autres.
Maintenant il y a pas mal de "cinglés" comme moi qui utilisent XulRunner et gecko pour leurs projets, parce qu'ils trouvent cette plateforme géniale malgré ses défauts.
De plus, vu que XulRunner n'est qu'un main() un poil différent de celui de firefox, et ne contient pas les fichiers XUL/JS/CSS de firefox (en gros), refaire un XulRunner ne serait pas compliqué. Le seul moyen pour Mozilla de tuer XulRunner, serait de tuer XUL et tout ce qui va avec (système d'overlay etc). Ce qui n'est pas près d'arriver...
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Frank-N-Furter . Évalué à 5.
C’était juste une boutade, mais si la MoFo venait à scalper XUL Runner, la réaction la plus intéressante viendrait très certainement de lui.
C’est ce que je voulais dire, quand je disais qu’ils le laissent mourir, je me souviens de l’époque ou ils en faisaient vaguement la promotion, et où l’on fantasmait sur l’idée de pouvoir taper faire xulrunner firefox.xpi & xulrunner thunderbird.xpi (me souviens plus de la syntaxe). Et j’imagine comprendre le pourquoi de certaines décisions (et parfois je pense qu’ils ont tords, mais c’est un autre débat).
De toute façon, je ne suis pas dev, juste utilisateur de longue date de netscape, et intéressé par tout ce qui gravite autour de la MoFo, mais je n’en pense pas moins qu’ils traitent comme de la merde les gens qui gravitent autour de l’ecosystem xulrunner.
Il n’y avait pas des discussions pour passer à autre chose dans un futur plus ou moins lointain ? Il me semblait avoir vu ça dans une roadmap, mais je peux confondre.
J’imagine que tu n’as pas forcément le temps, mais tu devrais rédiger un journal pour expliquer ce qu’est XUL Runner, je suis certain qu’il y a plein de gens qui ne connaissent pas chrome://browser/content/browser.xul
Depending on the time of day, the French go either way.
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par totof2000 . Évalué à 4. Dernière modification le 15 février 2012 à 18:20.
Bienvenu dans le monde de l'informatique dite "professionnelle", ou on te demande de faire entrer un cube de 10 cm de côté dans un trou rond de 8 cm de diamètre.
# bonne nouvelle
Posté par vida18 . Évalué à 3.
Bonne nouvelle. Il y a un an, des amis avaient comme projets de créer un "Mozilla Office" (en faite une version d'OOo avec une interface en XUL) sous licence MPL v2 qu'ils aurait donner à la Mozilla Foundation. Mais XULRunner les rebutait car ils avaient appris le C++ et C#/XAML à l'université.
[^] # Re: bonne nouvelle
Posté par Laurent Mouillart . Évalué à 4.
J'ai mieux : Apache OpenOffice by IBM = Eclipse + Gecko + Apache OpenOffice + Extension Lotus Symphony.
[^] # Re: bonne nouvelle
Posté par Ambroise . Évalué à 3.
Et quelles sont les prérequis matériel pour faire tourner ça ?
Rien que Eclipse + OpenOffice, ça mettrait ma machine au taf à genoux...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.