Sortie de XulRunner 1.8.0.1

Posté par  (site web personnel, Mastodon) . Modéré par Mouns.
Étiquettes :
0
4
fév.
2006
Mozilla
Mozilla vient de sortir aujourd'hui une première version stable "preview" de XulRunner.

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

  • # Stabilité de l'API

    Posté par  . Évalué à 6.

    J'ai cru comprendre que l'api avait une facheuse tendance à beaucoup bouger et à multiplier les incompatibilités de version à version.
    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  . Évalué à 5.

      Pour l'instant oui... (peut-être seulement 3 moteurs xul néanmoins : les xulrunners se partageant la plus grosse partie de leur code) :(
      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  (site web personnel, Mastodon) . Évalué à 4.

      J'ai cru comprendre que l'api avait une facheuse tendance à beaucoup bouger et à multiplier les incompatibilités de version à version.


      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).

      je fais tourner un thunderbird, un firefox, un truc et un machin xul : est-ce que cela va utiliser 4 moteurs xul différents?


      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  (site web personnel) . Évalué à 8.

        > 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).

        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  (site web personnel) . Évalué à 5.

          >Dommage qu'il ne semble pas y avoir de binding connus vers les
          >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  . Évalué à 1.

          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.

          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  (site web personnel) . Évalué à 3.

            Justement, linux est un mauvais exemple. Les noyaux 2.6 sont vraiment "chiant" au niveau des serveurs. D'ailleurs, j'ai certains serveurs encore en 2.4 car avec lui, pas de surprise ni de reboot du serveur tous les mois. Lors d'une mise à jour du noyau pour cause de trous de sécurité, tu es sur qu'il reboote bien.

            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  (site web personnel) . Évalué à 8.

        cite moi une seule plateforme, un seul framework dont l'api ne bouge pas dans le temps
        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  . Évalué à 1.

          C'est un peu ce que je voulais dire :-)
          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  (site web personnel, Mastodon) . Évalué à 5.

          > L'API doit évoluer, certe, mais en gardant une certaine compatibilité.

          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  (site web personnel) . Évalué à 4.

            Les règles qui ont été adoptées dans le domaine aéronautique et spatial sont bâties sur la notion d'interchangeabilité. Quand elle est rompue, c'est un changement de version majeure. J'ai l'impression que dans le monde du logiciel, il serait bon d'utiliser les même règles.
          • [^] # Re: Stabilité de l'API

            Posté par  . Évalué à 7.

            Je pense qu'il faut distinguer 3 types d'API.


            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  . Évalué à 4.

        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.


        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  . Évalué à 7.

          ni l'un ni l'autre.
          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  (site web personnel) . Évalué à 10.

        << cite moi une seule plateforme, un seul framework dont l'api ne bouge pas dans le temps >>

        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  (site web personnel, Mastodon) . Évalué à 6.

          bonne nouvelle : ça fait 7 ans que la plateforme mozilla existe ;-)

          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  (site web personnel) . Évalué à 2.

    On parle déjà de la version 3 alors qu'ici bas c'est la lutte avec la 1.5, décidement ces développeurs, toujours en avance sur leur temps ;)
    • [^] # Re: Firefox 3 ?

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      oui :-)

      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  (Mastodon) . Évalué à 10.

        Gecko 1.9 utilisera Cairo pour le backend graphique

        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  (site web personnel, Mastodon) . Évalué à 3.

          je sens comme une odeur de Troll, pas vous ? :-)

          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  (Mastodon) . Évalué à 5.

            je sens comme une odeur de Troll, pas vous

            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.

            Au dernière nouvelle, les developpeurs de Cairo n'ont pas l'intention d'arreter tout developpement et optimisation.

            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  . Évalué à 7.

              > Cairo a un rendu très joli, mais va à peu près aussi vite qu'une
              > 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  (Mastodon) . Évalué à 3.

                Comparé à quoi, dans quel contexte ?

                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é.

                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 ?

                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  (site web personnel, Mastodon) . Évalué à 6.

                  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é.


                  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  (Mastodon) . Évalué à 2.

                    Ouhh là ! comment tu y va vite à déscendre Cairo avec l'experience malheureuse que tu as !

                    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  . Évalué à 3.

      décidement ces développeurs, toujours en avance sur leur temps


      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  (site web personnel) . Évalué à 7.

    Bonjour,

    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  . Évalué à 2.

      Quelqu'un a des retours d'expérience sur cet outil ? Je pense regarder ça dès lundi mais si il était possible d'avoir une idée du niveau d'avancement.

      Merci d'avance.
    • [^] # Re: Le projet FANI utilise déjà XUL Runner

      Posté par  . Évalué à 7.

      la console est fourni dans le toolkit:

      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  . Évalué à 7.

        Pour la documentation, je suis entièrement d'accord. Lorsque j'ai voulu écrire une petite extension pour Firefox, je n'imaginais pas devoir tâtonner sur le Web pendant des heures pour comprendre le fonctionnement de certains XPCOM. J'ai même fini par aller voir directement le code source, parfois mieux commenté que la doc sur xulplanet !
  • # Fin des abbérrations

    Posté par  . Évalué à 4.

    Et surtout cela permettra au navigateurs gecko (type epiphany) de ne plus avoir de dépendances sur firefox ou mozilla.
    • [^] # Re: Fin des abbérrations

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Ça ils pourraient le faire depuis longtemps. Le SDK de gecko est disponible depuis nombre d'année. C'est un choix des développeurs d'Epiphany que de lier épiphany à Mozilla/Firefox.

      http://www.mozilla.org/projects/embedding/
    • [^] # Re: Fin des abbérrations

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      je voulais rajouter aussi que Epiphany a une interface qui n'est pas faite en XUL je crois. Utiliser XulRunner ne leur servirait donc à rien du tout, puisque XulRunner est fait pour lancer des applications faites en XUL, et non des applications tierces, développée autrement. Epiphany ne fait qu'utiliser Gecko pour la partie visualisation de page web.
      • [^] # Re: Fin des abbérrations

        Posté par  (site web personnel) . Évalué à 3.

        Personellement, si j'ai choisi galeon (proche d'epiphany) c'est principalement pour ne pas avoir d'interface XUL ... et je dois dire que cela améliore de beaucoup les performances ...

        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  . Évalué à 4.

    Comme le dis guido, c'est tres chiant d'ecrire du XML a la main, personne a envie de le faire!

    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  (site web personnel, Mastodon) . Évalué à 2.

      c'est tres chiant d'ecrire du XML a la main, personne a envie de le faire!


      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  (site web personnel) . Évalué à 3.

      YAML ?

      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  (site web personnel) . Évalué à 3.

      Sans aller jusqu'à un outil de RAD spécifique, utiliser un éditeur XML qui fait de la complétion en fonction du schéma utilisé permet de taper très vite "à la main".

      Au boulot pour ça on utilise le plugin OxygenXML pour Eclipse. Mais c'est pô libre...
    • [^] # Re: outil de rad?

      Posté par  . Évalué à 4.

      Le plugin qui monte pour le dev Xul
      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.