XulRunner est un framework d'application multi-plateforme, basé sur les technologies Mozilla. Il contient donc le moteur Gecko 1.8 et une multitude d'APIs. XulRunner permet donc un développement rapide et le lancement d'applications réalisées avec les technologies XUL, XHTML, SVG, CSS, Javascript, XBL et bien d'autres encore.
Cette version est basée sur le même code que celui de Firefox 1.5.0.1. C'est en quelque sorte un Firefox amélioré livré sans son interface. À terme les produits Mozilla utiliseront XulRunner (Firefox 3, en 2007, motorisé par Gecko 1.9). Ils partageront donc les mêmes bibliothèques, facilitant les installations, les mises à jour et permettant d'économiser des ressources systèmes.
XulRunner est surtout destiné aux développeurs pour le moment, vu le peu d'application qui existent. La version finale 1.9 en 2007 fournira un système d'installation et de déploiement pour les applications XUL et une API plus complète. Diverses applications utilisant XulRunner existent déjà, comme le lecteur multimédia Songbird, le logiciel de traitement d'images Xul DAIM, ou encore GencatRss, un agrégateur RSS.
D'autres logiciels basés sur Mozilla comme l'éditeur HTML Nvu, l'éditeur XML Etna, ou encore la version XUL du client SIP OpenWengo, utiliseront eux aussi XulRunner. Des entreprises utilisent déjà XulRunner pour leurs projets internes.
XulRunner inclus une multitude de technologies, permettant de réaliser des applications très diverses : XUL pour l'interface utilisateur, XBL pour les composants d'interface réutilisable et puis bien sûr XHTML, CSS, SVG, MathML, XSLT, Xforms (via une extension), DOM, Javascript, E4X, etc..
Il propose également quelques centaines d'objets XPCOM, fournissant une API bien fournie. Vous pouvez vous aussi développer des composants XPCOM dans divers langages.
- nativement en C++ et Javascript
- perl et ruby via des bindings externes
- Python et Java pour la version finale (que vous pouvez d'hors et déjà activer en recompilant XulRunner)
- Mono (experimental)
XPCom permet donc de s'ouvrir à d'autres technologies et de réutiliser des bibliothèques développées dans d'autres langages.
On retrouve comme dans Firefox un système de profil et de préférences, un toolkit XUL, un gestionnaire de thèmes et d'extensions, un système de localisation etc.
Note : la numérotation de version de XulRunner suit celle du moteur Gecko. C'est pour cela que cette première version stable ne commence pas par 0.1 ou 1.0.
Aller plus loin
- News sur Devnews (4 clics)
- XulRunner sur Xulfr (7 clics)
- XulRunner sur DevMo (4 clics)
- Tutoriel XUL (5 clics)
- Les technologies de XulRunner (6 clics)
- XUL sur Wikipédia (3 clics)
# Stabilité de l'API
Posté par Gabriel . Évalué à 6.
Qu'est-ce qu'il en est en ce moment?
Deuxio: je fais tourner un thunderbird, un firefox, un truc et un machin xul : est-ce que cela va utiliser 4 moteurs xul différents?
[^] # Re: Stabilité de l'API
Posté par Chaddaï Fouché . Évalué à 5.
Mais l'objectif est à terme de tout passer sur XulRunner et ainsi de faire de sacrés économie de ressource.
--
Jedaï
[^] # Re: Stabilité de l'API
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Oui, d'une version de gecko à l'autre, l'api évolue. C'est normal (cite moi une seule plateforme, un seul framework dont l'api ne bouge pas dans le temps).
C'est le cas à l'heure actuelle, puisque chaque executable a son propre gecko. Avec Xulrunner ce n'est en principe pas le cas : chaque appli utilisant le même executable (xulrunner), donc les bibliothèques de xulrunner ne sont chargés qu'une fois en mêmoire.
[^] # Re: Stabilité de l'API
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
> moi une seule plateforme, un seul framework dont l'api ne bouge
> pas dans le temps).
OpenStep ?
Il y a bouger et bouger...
Si l'on regarde les gros projets, il casse la compatibilité ascendante de temps en temps mais essayes de l'éviter tous les quatres matins.
Pour en revenir a OpenStep, on ne peux pas dire que ce soit dépassé et moche (cf MacOSX), et ca contine aussi d'évoluer. Dommage qu'il ne semble pas y avoir de binding connus vers les langages de scripts car je suis sur qu'il y gagnerais (j'ai bien vu une libcamelbones0 sur ma debian mais je ne sais ce que ca vaut). Je pense notament à ruby que je connais très peu mais qui semble proche d'ObjectiveC dans sa philosophie.
[^] # Re: Stabilité de l'API
Posté par oops (site web personnel) . Évalué à 5.
>langages de scripts car je suis sur qu'il y gagnerais
Perl : Camelbones http://camelbones.sourceforge.net/
Python : PyObjc http://pyobjc.sourceforge.net/
Ruby : RIGS http://www.gnustep.org/experience/RIGS.html
Scheme doit trainer aussi quelque part
Non interprété :
C : naturel ( ObjC est une surcouche de C )
C++ : ObjC++ dans gcc-4.X ?
JIGS : java
Il faut savoir que CamelBones / PyObjC ne fontionne pas très bien avec GNUstep actuellement et que RIGS ne passe probablement pas sur Cocoa...
[^] # Re: Stabilité de l'API
Posté par djano . Évalué à 1.
Pense a Linux qui modifie regulierement les interfaces d'acces pour une partie du materiel (et qui a pose des problemes dans le cas du support des webcams philips il me semble).
Et dans le cas qui nous interesse, XULRunner est une version en developpement, donc il est normal que ca evolue sans cesse.
[^] # Re: Stabilité de l'API
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Le problème avec les noyaux 2.6, c'est que pour un non spécialiste de la programmation du noyau, on avance un peu trop à l'aveuglette et parfois sans filet...
[^] # Re: Stabilité de l'API
Posté par TImaniac (site web personnel) . Évalué à 8.
L'API doit évoluer, certe, mais en gardant une certaine compatibilité. Imagine un peu le problème si Java 1.5 n'était pas compatible avec java 1.4 qui n'était pas compatible avec Java 1.3, etc. Ou pire imagine si la libc changeait tous les ans :)
[^] # Re: Stabilité de l'API
Posté par Gabriel . Évalué à 1.
Ceci dit tant qu'il y a pas des cent et des mille d'applications en xul on peut toujours évoluer bien sûr, et d'une certaine manière c'est un choix, entre la compatibilité et l'évolution.
[^] # Re: Stabilité de l'API
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
C'est ce qui se passe dans Gecko quand même. Ça évolue, mais les corrections pour adapter à chaque nouvelle version de gecko sont mineures tout de même. Et puis bon, comparer Gecko à Java, c'est tout de même un peu oser : Java est quand même plus mature que les technologies incluses dans Gecko. Il est donc normal que l'API de Java soit un minimum stable ;-)
Et à l'avenir, ce sera pareil pour Gecko, une fois que tout sera suffisement mature (et ça commence à l'être, d'où XulRunner), l'API sera stable. Nombre d'interfaces IDL sont marquées "FROZEN" dans Mozilla, et ce nombre va augmenter pour la version public stable de XulRunner (1.9)
[^] # Re: Stabilité de l'API
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
[^] # Re: Stabilité de l'API
Posté par Paul Rouget . Évalué à 7.
L'API coté XPFE (XUL & co)
L'API XpCom
L'API interne à Gecko
Suite à mes différentes expériences, je peux dire que:
L'API XPFE reste bien évidement stable pour tout ce qui est standardisé (XHTML, CSS, SVG, ...). Pour ce qui ne l'est pas (XUL) c'est vrai qu'il y a des améliorations (richbox par exemple) et des modifications (les colonnes des arbres). Ce ne sont pas des évolutions violentes de l'API. Cela n'a pas demandé énormément de travail de faire évoluer une application basée sur Gecko 1.7 à Gecko 1.8 (coté XPFE). Pour ce qui est de l'enregistrement chrome (disons rapidement la manière de packager) c'est vrai quelle a beaucoup changée, mais la méthode actuelle risque bien du durer un bout de temps :)
Au niveau de l'API XpCom, rien de bien nouveau entre Gecko 1.7 et 1.8, à part peut être l'API des strings, simplement parce que l'on a switché d'API par défaut (il y l'API frozen et internal). Avant on utilisait l'internal par défaut, maintenant la frozen (je n'ai pas du tout suivi le pourquoi de la chose), on peut facilement faire remonter l'internal (avec un #define en plus), et on est compatible. Mais bon, tant qu'à faire, on préfère passer son code en Frozen, et dans ce cas, c'est 2/3 noms de types qui ont changés.
L'API interne (le code du moteur), là il y a débat à savoir si elle doit être clairement considérée comme une véritable API claire et stable. Je ne la connais pas bien, mais ce ne doit pas être très strict. Pour plus dinfos, voyez les questions que se posent les gens qui connaissent:
http://glazman.org/weblog/dotclear/index.php?2005/11/16/1383(...)
http://benjamin.smedbergs.us/blog/2005-11-17/the-internals-o(...)
Pour conclure, il faut voir que Gecko est une plateforme jeune et que l'on peut dire que sa version 1.8 est une version ayant pour ambition d'être exploitée par bien d'autres softs que simplement Firefox et Thunderbird, ce qui anonce un réel effort de s'orienter vers les développeurs (après le grand public, les développeurs).
[^] # Re: Stabilité de l'API
Posté par Vincent Danjean . Évalué à 4.
Je ne comprends pas très bien ce paragraphe (ou plutôt j'en vois plusieurs interprétations). Si quelqu'un pouvait m'éclairer...
Est-ce que Xulrunner sera :
-(1) une bibliothèque partagée liées aux diverses application (firefox, ...)
-(2) un "demon" lancé par l'utilisateur utilisé par firefox, ... (communication par socket, mémoire partagée, ...)
-(3) une application qui charge dynamiquement les "modules" souhaités (firefox, ...)
Les trois formes permettent de partager le code en mémoire. Par contre, (2) nécessite d'avoir un logiciel vraiment déboggué (je n'ai pas envie que le plantage de "firefox" plante le demon et par suite les autres appli xul). (3) est encore pire puisqu'il faut que toutes les applis xul soient sans bug.
[^] # Re: Stabilité de l'API
Posté par luna . Évalué à 7.
si j'ai tout bien compris
xulrunner est une application qui charge le module souhaité
xulrunner est exécuté indépendamment pour chaque exécution avec un truc du type "xulrunner monapplication"
un peu comme java si tu veux
l'intérêt c'est que toutes les bibliothèques peuvent être partagées, mais chaque application a sa propre instance de xulrunner
[^] # Re: Stabilité de l'API
Posté par Philippe F (site web personnel) . Évalué à 10.
win32: tu peux encore compiler tes programmes windows 3.1 aujourd'hui, ils fonctionnent toujours. Ca doit faire dans les 15 ans de plate-forme stable. C'est d'ailleurs une des forces de windows.
Sinon, on peut citer gtk, Gnome, KDE et Qt, dont les versions sont entierement compatibles entre elles si on ne change pas le premier chiffre. On tape dans les 3-4 ans de stabilite. Et deja avec 3-4 ans, ce n'est pas suffisant, il y a pas mal d'applications qui ne sont jamais portees et sont en quelque sorte perdues. Sous windows, ca m'arrive d'utiliser des applis qui clairement ont ete ecrites pour windows 3.1 et qui fonctionnent tres bien.
Tout ca pour dire que la stabilite des APIs, ce n'est pas un truc a prendre a la legere et que les faire varier meme de facon mineures tous les 6 mois, c'est le meilleur moyen de tuer un projet.
[^] # Re: Stabilité de l'API
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Plus serieusement, la plateforme était jusqu'à il y a 2-3 ans utilisé exclusivement par Mozilla pour la suite, Firefox &co. C'est pour cela qu'il ne se souciait pas de la stabilité au niveau API. Maintenant que la technologie est mature et utilisée par de plus en plus de monde, il est certain qu'ils vont tout stabiliser.
# Firefox 3 ?
Posté par Ludovic F (site web personnel) . Évalué à 2.
[^] # Re: Firefox 3 ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
d'ailleurs, pour les developpeurs XUL et web, cette version est trés, trés trés attendue. En effet, elle contiendra Gecko 1.9, qui apporte de *grosses* améliorations.
Gecko 1.9 utilisera Cairo pour le backend graphique (avec toutes les possibilités d'affichage que ça apporte : export PDF, postcript etc...)
De plus, des grosses partie du layout engine (le moteur qui s'occupe d'agencer l'affichage des elements xml en fonction des css) sera entierement refondu (refonte qui a déjà commencée) : plus rapide, et un meilleur support CSS. L'architecture du layout engine dans le Gecko 1.8 actuel (utilisé dans ff1.5 et qui sera utilisé aussi dans FF 2.0) ne permet pas de corriger facilement certains bugs CSS (d'où l'echec du test acid2 et une non evolution de ce coté là). La nouvelle architecture dans Gecko 1.9 le permettra.
bref, autant pour les developpeurs, Firefox 2.0 ne va pas apporter grand chose (mais pour les utilisateurs oui bien sûr, au niveau de l'interface etc..), autant Firefox 3.0, donc XulRunner 1.9 apportera enormement.
[^] # Re: Firefox 3 ?
Posté par Yusei (Mastodon) . Évalué à 10.
Et bien mes ailleux, j'espère que d'ici là Cairo sera plus optimisé que maintenant, ou j'espère que j'aurai une nouvelle machine.
[^] # Re: Firefox 3 ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Tu fais bien d'éspérer. Au dernière nouvelle, les developpeurs de Cairo n'ont pas l'intention d'arreter tout developpement et optimisation.
Et puis honnetement, je doute, vu les enjeux, que Mozilla ce soit "trompé" de Backend ;-)
[^] # Re: Firefox 3 ?
Posté par Yusei (Mastodon) . Évalué à 5.
En même temps, n'importe quoi qui n'est pas de l'adoration pour un logiciel libre est qualifié de Troll... en l'occurence, Cairo a un rendu très joli, mais va à peu près aussi vite qu'une tortue unijambiste dans la mélasse.
Ce qui m'inquiète, ce n'est pas l'intention d'utiliser Cairo un jour, c'est plutôt la date annoncée. 2007 c'est bientôt.
[^] # Re: Firefox 3 ?
Posté par tgl . Évalué à 7.
> tortue unijambiste dans la mélasse.
Comparé à quoi, dans quel contexte ? Bref, qu'est ce qui te fait dire ça ?
Je suis curieux, parceque bon, du Cairo y'en a qui s'est immicé un peu partout sur mon desktop depuis gtk+-2.8, sans que j'ai pour autant l'impression d'une quelconque régression.
Et puis aussi, j'avais il y a qlqs temps comparé au niveau de Poppler (le moteur de rendu PDF utilisé par Evince et d'autres) le backend Cairo et le backend Splash (celui hérité de XPDF), et j'avais trouvé que Cairo s'en sortait plutôt mieux (les pages un peu compliquées apparaissaient, à vue de nez, plus rapidement).
Bon, y'a rien de bien scientifique là dedans, mais comme ça là j'ai pas vraiment l'impression que Cairo soit la grosse bouse que tu décris. Ou bien est-ce que c'est ma machine (Pentium M 1,5MHz avec une Radeon r200) qui est trop rapide pour que je m'en rende compte ?
[^] # Re: Firefox 3 ?
Posté par Yusei (Mastodon) . Évalué à 3.
Le contexte: quand j'essaye de faire du rendu de SVG (produit par inkscape ou sodipodi), par exemple dans Firefox. Ces SVG sont principalement constitués de courbes de bézier.
Par contre, je n'ai pas fait de comparaison entre différents moteurs de rendu, je me suis contenté de remarquer que pour l'instant Cairo était lent, sur ma machine. Par exemple, lorsque je change une propriété d'une des courbes, il y a un délai sensible avant que le changement soit rendu et affiché.
Si ça se trouve, tu as une accélération matérielle et moi j'ai un rendu logiciel, je ne sais pas. En tout cas, mon Athlon 1,6 GHz, en rendu logiciel, pédale dans la choucroute.
[^] # Re: Firefox 3 ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Ouhh là ! comment tu y va vite à déscendre Cairo avec l'experience malheureuse que tu as !
Tu oublie que dans le cas de l'affichage d'un svg (ou autre XML d'ailleurs) dans Gecko, Cairo n'est que le dernier maillon d'une longue chaine de traitement avant l'affichage sur le péripherique proprement dit.
Pour l'affichage d'un SVG, il y a d'abord l'interpretation/execution de ton bout de javascript qui change la propriété en question, puis le traitement dans le DOM conséquent à ce bout de code, puis le moteur du layout, qui détermine ce qui a changé, puis quoi et comment afficher en fonction des éléments DOM et des styles CSS impliqués, le calcul de toutes les "frames" (en gros une frame = le moindre rectangle affiché ayant sa couleur, effet graphique etc.., ou le moindre caractère), leurs dimensions, caractéristiques (y en a des centaines, voir des milliers pour une page). Puis viens ensuite l'appel de la couche Cairo pour la partie "dessiner".
Bref, si lenteur il y a, Cairo n'est pas à mettre en cause à 100%. Il y a toute une chaîne. un moteur de rendu XML est trés complexe.
Mais j'ai une bonne nouvelle pour toi : dans gecko 1.9, le moteur du layout va connaître de nombreux changement et optimisation. En comptant également sur une amélioration des perfs dans Cairo même. On peut parier sur de nettes améliorations. ;-)
[^] # Re: Firefox 3 ?
Posté par Yusei (Mastodon) . Évalué à 2.
J'ai dit que c'était un exemple. Autre exemple: quand j'ouvre un PDF généré par lilypond [1] avec xpdf, c'est instantané (et moche). Quand j'ouvre le même PDF avec evince avec le backend cairo, la page met plus d'une minute à être rendue (mais c'est très joli). Là encore, il n'y a pas que Cairo qui entre en jeu, je sais, mais disons que j'ai l'impression, au vu de nombreux exemples, qu'il y est pour quelque chose.
[1]: http://www.mutopiaproject.org/ftp/BachJS/BWVAnh114/anna-magd(...)
[^] # Re: Firefox 3 ?
Posté par chaperon . Évalué à 3.
Histoire d'enfoncer un peu les portes ouvertes ...
Le plus difficile dans des projets de cette envergure, c'est la conception d'architecture. Or, comme les changements d'architecture doivent se faire en douceur, sous peine d'incompatibilités majeures, Firefox 2.0 ne peut pas apporter de gros changements.
De même pour le développement de Linux : il ne se passe "rien" entre 2 versions majeures (c'est moins vrai actuellement), juste des ajouts mineurs, quelques évolutions. Mais en période "instable", le noyau subit des changements complets d'architecture.
Donc cette avance sur les versions est nécessaire, puisque la version 2.0 sera une sorte de suite logique, déjà figée, et la 3.0 doit se concevoir maintenant, avant que la 2.0 ne conditionne les évolutions de la 3.0.
# Le projet FANI utilise déjà XUL Runner
Posté par Christophe Nowicki (site web personnel) . Évalué à 7.
Cela fait près de 3 mois que nous avons migré, notre projet FANI ( http://www.fani-project.org) sous XulRunner :
http://www.fani-project.org/index.php?page=screenshots
Cette migration, c'est très bien passée, il y a peu de diffèrence entre cet environnement d'execution et Mozilla-Firefox.
Parcontre, il faut signaler un gros point noir : La non disponibilité des outils de développement / debug tel que le DOM Inspector ( http://www.mozilla.org/projects/inspector/ ) et la console Javascript ( http://www.mozilla.org/projects/xpcom/consoleservice.html ).
Voilà
[^] # Re: Le projet FANI utilise déjà XUL Runner
Posté par SF . Évalué à 2.
Merci d'avance.
[^] # Re: Le projet FANI utilise déjà XUL Runner
Posté par lekma . Évalué à 7.
function showConsole() {
window.open("chrome://global/content/console.xul", "_blank", "chrome,extrachrome,menubar,resizable,scrollbars,status,toolbar");
}
pour le DOMi il te faut activer le gestionnaire d'extension, dans ton application.ini:
[XRE]
EnableExtensionManager=true
et il te faut bricoler un peu un DOMi provenant de firefox (ou compiler le tient).
l'enorme point noir de xul en general et de xulrunner en particulier (selon moi), c'est l'absence d'une documentation claire (et qques autres petits trucs, mais bon...).
[^] # Re: Le projet FANI utilise déjà XUL Runner
Posté par Kalex . Évalué à 7.
# Fin des abbérrations
Posté par olosta . Évalué à 4.
[^] # Re: Fin des abbérrations
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
http://www.mozilla.org/projects/embedding/
[^] # Re: Fin des abbérrations
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
[^] # Re: Fin des abbérrations
Posté par Mildred (site web personnel) . Évalué à 3.
Sinon, ca ne doit pas être impossible de faire un binding de gtk et des lib gnome pour les langages utiliss par Gecko/XulRunner ... non ?
# outil de rad?
Posté par Pierre . Évalué à 4.
J'ai lu un peu rapidement les tutoriel xml, je ne vois nulle part de référence a un outil qui pourrait permettre d'écrire rapidement tout ce xml.
[^] # Re: outil de rad?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Faut pas prendre ton appreciation pour une généralité :-)
Moi ça ne me gène pas d'écrire du XML. Et en tout cas, c'est beaucoup moins chiant d'écrire du XUL pour décrire une interface utilisateur que de le faire programmativement avec une API genre qt/gtk/autre toolkit. D'où le succés de tout ces langages XUL like, que ce soit pour Java (y a plein de library java qui interpretent du XUL-like et transforment en ordres swing), pour .NET (futur XAML) ou encore pour flash (techno Flex).
Avec une interface décrite en XML, on a une meilleure vue d'ensemble du code de l'interface utilisateur, on voit mieux l'imbrication et le positionnement relatif entre widget etc..
Ceci dit, il est vrai qu'il serait bien d'avoir un éditeur wysiwyg qui permettrait de dessiner à la main l'interface. Cependant si il n'y en a pas, c'est parce qu'il y a aussi une certaine barrière technologique. XUL possède des mécanismes, comme les overlays, les templates, les XBL etc, qui sont trés dur à rendre éditable en "wysiwyg". C'est le genre de chose que l'on ne peut écrire qu'à la main quasiement. Une solution intermédiaire, serait de réaliser un éditeur wysiwyg "basique", mais alors on ne profiterait que trés peu du potentiel de XUL. D'où l'abondon du tout premier projet sur ce sujet, XulMaker (y a aussi d'autres raisons, mais si il n'a pas été repris...). Et il n'y a pas eu d'autres réèlles tentatives depuis.
En attendant, on peut toujours utiliser un des plugins eclipse pour XUL, qui facilite l'écriture du XUL (c'est en quelque sorte un éditeur XML amélioré présentant l'arbo XML).
[^] # Re: outil de rad?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Pour décrire une configuration qui s'écrit sous forme d'arbre, le YAML est vraiment très bien. Bien moins lourd que le xml.
[^] # Re: outil de rad?
Posté par Wawet76 . Évalué à 3.
Au boulot pour ça on utilise le plugin OxygenXML pour Eclipse. Mais c'est pô libre...
[^] # Re: outil de rad?
Posté par golum . Évalué à 4.
http://eclipsexul.sourceforge.net/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.