Stabilité de l'API

• [^]Re: Stabilité de l'API

  Posté par Chaddaï Fouché () le 04/02/2006 à 01:22. (lien). É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 Laurent J (page perso, ) le 04/02/2006 à 09:26. (lien). É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 Sytoka Modon (page perso, ) le 04/02/2006 à 09:48. (lien). É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 oops (page perso, ) le 04/02/2006 à 11:07. (lien). É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 djano () le 13/02/2006 à 10:44. (lien). É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 Sytoka Modon (page perso, ) le 13/02/2006 à 13:49. (lien). É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 TImaniac (page perso, ) le 04/02/2006 à 11:24. (lien). É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 :)

    --
    MonoFrance

    • [^]Re: Stabilité de l'API

      Posté par Gabriel () le 04/02/2006 à 12:54. (lien). É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.

      --
      Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying

    • [^]Re: Stabilité de l'API

      Posté par Laurent J (page perso, ) le 04/02/2006 à 15:52. (lien). É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 Pierre Jarillon (page perso, ) le 04/02/2006 à 21:52. (lien). É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 Paul Rouget (page perso, ) le 06/02/2006 à 04:34. (lien). É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 Vincent Danjean () le 04/02/2006 à 16:52. (lien). É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 luna () le 04/02/2006 à 19:46. (lien). É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 Philippe Fremy (page perso, ) le 05/02/2006 à 19:50. (lien). É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.

    --
    phil.freehackers.org

    • [^]Re: Stabilité de l'API

      Posté par Laurent J (page perso, ) le 05/02/2006 à 22:22. (lien). É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 ?

• [^]Re: Firefox 3 ?

  Posté par Laurent J (page perso, ) le 04/02/2006 à 09:42. (lien). É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 Yusei (page perso, ) le 04/02/2006 à 13:19. (lien). É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 Laurent J (page perso, ) le 04/02/2006 à 15:55. (lien). É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 Yusei (page perso, ) le 05/02/2006 à 15:47. (lien). É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 tgl () le 05/02/2006 à 16:18. (lien). É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 Yusei (page perso, ) le 05/02/2006 à 17:21. (lien). É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 Laurent J (page perso, ) le 05/02/2006 à 22:32. (lien). É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 Yusei (page perso, ) le 06/02/2006 à 21:35. (lien). É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 chaperon () le 04/02/2006 à 12:54. (lien). É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.

  --
  man man, man !

Le projet FANI utilise déjà XUL Runner

• [^]Re: Le projet FANI utilise déjà XUL Runner

  Posté par SF () le 04/02/2006 à 09:44. (lien). É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 lekma () le 04/02/2006 à 11:47. (lien). É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 Kalex (page perso, ) le 05/02/2006 à 13:19. (lien). É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 !

    --
    Captures de pages Web sous Linux

Fin des abbérrations

• [^]Re: Fin des abbérrations

  Posté par Laurent J (page perso, ) le 04/02/2006 à 15:57. (lien). É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 Laurent J (page perso, ) le 04/02/2006 à 16:00. (lien). É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 Mildred (Jabber id, page perso, ) le 05/02/2006 à 19:53. (lien). É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 ?

    --
    La Roue du Temps

outil de rad?

• [^]Re: outil de rad?

  Posté par Laurent J (page perso, ) le 06/02/2006 à 07:45. (lien). É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 Sytoka Modon (page perso, ) le 06/02/2006 à 14:01. (lien). É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 Wawet76 (page perso, ) le 07/02/2006 à 11:04. (lien). É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 golum () le 07/02/2006 à 12:09. (lien). Évalué à 4.

  Le plugin qui monte pour le dev Xul
  http://eclipsexul.sourceforge.net/