Laurent J a écrit 2933 commentaires

et pouquoi ne pas s'être baser sur XUL et l'enrichir de balises spécifiques et étendre Gecko et FF avec des spécificités au lieu de réécrire l'interface complètement

Parce que l'utilisation de XUL impose bien entendu à Gecko de parser non seulement la page web, mais aussi le XUL de l'interface. Bref, si pas interface en XUL, moins besoin de ressources.

Et puis ajouter des balises spécifiques dans une langage XML dont l'objectif est de justement faire abstraction d'un toolkit, c'est un peu crade hein ;-)

En outre, il ne faut pas oublier un autre avantage de la techno XUL Mozilla, le support des client riches. Avec Camino ca n'est pas possible.

Totalement faux. J'affiche trés bien mes pages XUL dans Camino ;-) Donc il peut trés bien servir de client "leger" riche ;-)

l'UltraSPARC T1 , une puce ultra innovante puisqu'elle propose 8 coeurs simples (in-order) avec 4 threads dans chaque coeur. On obtient ainsi une puce à 1.2 GHz faisant tourner 32 threads simultanément en ne consommant que 72 watts !

Je veux la même dans ma machine pour mes compilations de moz !

mk_add_options MOZ_MAKE_FLAGS=-j32, ça le fait moi je dit :-) Parce que bon, du -j2, c'est bien beau, mais attendre 30 minutes pour avoir un binaire Gecko, c'est embétant à la longue :-)

Y a ceux aussi qui compilent à longueur de journée du KDE ou du gentoo qui pourraient être interressé :-)

la roue n'est pas réinventé, puisque camino réutilise le composant le plus compliqué à réaliser : le moteur d'affichage de page web, Gecko.

c'est juste l'interface qui change. Et elle est ici spécifique à MacOsX, pour que le navigateur soit bien intégré dans l'environnement, et qu'il respecte mieux les conventions en matière d'interface utilisateur Mac. (ce que Firefox a du mal à faire, du fait du choix technologique qui est fait pour la réalisation de son interface)

C'est donc pas du gachi comme tu dis. Ça permet de proposer une autre approche en matière d'interface et de fonctionnalité.

À t'entendre, il y aurait des dizaines de navigateurs existants. Or sur mac, on a quoi ? 3 navigateurs seulement : Safari, Firefox, et maintenant Camino (IE étant abandonné). Dont deux utilisant le même moteur Gecko.

Franchement , je vois pas où est le gachi d'energie.

Pour faire court, et pour les anglophobes, la différence avec Camino est que l'interface est native macosx aqua. Tandis qu'avec Firefox, l'interface est faite en XUL. Parce que XUL est un langage faisant abstraction des spécificités des plateformes, on ne peut faire une appli vraiment intégré dans le système. (même si le moteur gecko traduit les balises XUL en élement natifs de l'environnement).

En contre-partie, on peut faire avec XUL une interface qui fonctionnera sur toutes les plateformes, pas besoin de faire x version, et on n'a pas à apprendre les apis des toolkits.

De plus Camino fait appel à d'autres API/services spécifiques à MacOSx, lui permetttant une trés bonne intégration dans l'environnement.

Si on y repense bien : linus a fait la même chose pour Linux. Il n'a commencé à parler de son projet qu'une fois que son truc commençait à fonctionner.

Si il en avait parler dés le début, il aurait peut être subit des critiques, voir des moqueries "bouarf, c'est trop dur, ça fonctionnera jamais, c'est pas comme ci comme ça qu'il faut faire" etc.. Cela l'aurait peut etre découragé et on ne serait pas là à discuter de logiciels libres :-)

C'est une attitude que j'ai tendance aussi à avoir.

C'est le cas par exemple pour mon editeur XML wysiwyg basé sur Gecko, et diffusé sous licence libre. C'est quelque chose de complexe (validation temps réèl, hack de Gecko toussa) et donc, je n'ai pas de temps à perdre avec l'exterieur pour justifier mes choix techniques, pour justifier mes hacks sur Gecko, à répondre aux multiples questions qui ne manquerait pas d'y avoir sur un produit non utilisable. (inutilisable = questions pourquoi ça marche pas, forcement).

Bref, j'ai commencé à communiquer sur le logiciel qu'à partir du moment où on pouvait commencer à voir quelque chose d'utilisable, qui fonctionne "à peu prés". Mais je n'ai pas encore fait "la grosse pub" (cependant cela ne va pas trop tarder), car il y a encore pas mal de bug connu. Et j'ai pas envie d'avoir mon bugzilla pourri par des dizaines de doublons de déclarations de bugs.

J'ai fait la même chose aussi pour mon projet perso de framework PHP : j'ai bossé dessus tout seul, sans en parler à personne, histoire de bien reflechir sur les concepts que je voulais développer. Une fois que les bases étaient jétées, j'ai commencé à publier les sources. Et puis j'ai un peu plus de temps puisque le plus dur est fait, et du coup je suis plus receptif aux commentaires d'utilisateurs.

Bref, je pense que la façon de bosser de Novell est trés bien car elle permet effectivement une meilleur productivité.

Le seul problème peut être la review de code quand il s'agit d'intégrer des gros morceaux de code qu'on a développé ainsi en privé, dans un produit existant. Soit les responsables du projet font confiance. Soit il va leur falloir du temps pour valider le code produit et l'intégrer alors dans le tronc. (Par exemple, dans Mozilla, tout patch est revu au moins par deux personnes différentes : mes patchs pour l'editeur XML étant gros et complexes, une fois que je les aurais proposé, vont mettre quelques mois avant d'être intégrés dans le tronc, processus qualité oblige).

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

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

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.

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.

Ç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/

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

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

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.

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.

http://www.chezmoicamarche.org

Il l'a mise à jour. (essaye d'aller dans le panneau des extensions et tente de faire une mise à jour)

>Dans l'esprit, c'est quand même une fonctionnalité pour utilisateurs de windows.

non, aussi pour des utilisateurs linux comme moi.

Je n'installe pas la version de la distrib, car dans la majorité d'entre elles, c'est une vieille version de FF (1.0.x). (sauf si on installe une version instable de la distrib comme cooker ou snapsht d'ubuntu, mais bon).

Bref, j'installe les binaires fournis par Mozilla. Ça fonctionne trés bien, et j'ai un navigateur dernier cri toujours à jour.

1) pourquoi ce lien, alors que la mise à jour est automatique ? ;-)
2) http://www.mozilla-europe.org/fr/ c'est mieux, c'est en français :-p.


À noter que ceux qui avaient téléchargé une RC de FF 1.5, ont normalement déjà eu la mise à jour depuis quelques jours (car ils ont une version FF déclarée comme "version test", donc reçoivent les mises à jours avant les autres).

A part le challenge technique, c'est quoi l'interêt ?

Alors, je vais parler un peu de ma vie, parce que ce genre de chose m'interresse aussi.

Donc voilà, je développe un logiciel, basé sur Gecko. Lors du dev, je suis sous linux, je teste sous linux une version pour linux. Mais quand je sors une nouvelle version, je fourni non seulement un binaire linux, mais aussi un binaire windows. (Ba oui, y a des gens, ils veulent pouvoir utiliser ce que je fais sous windows ;-) )

Bon, bref, il faut que je compile sous windows. Pour cela, il faut que je boote sous windows, où il n'y a d'installer que le minimum pour la compilation (VC++, cygwin ...). et je compile. Ce qui me prend au moins 35 min. C'est bien beau de regarder passer pendant au moins 35 min plein de lignes de commande gcc, mais bon, y a mieux à faire. Comme par exemple continuer à coder, en profiter pour lire ses mails, faire autre chose de productif quoi. Le problème, c'est que tout mon environnement de travail est sous linux, configuré sous linux.

Donc voilà, si je pouvais compiler une version windows sous linux, je pourrais pendant la compil faire autre chose que surfer ou rester à regarder défiler des lignes de compil...

voilà voilà...

pas d'accés public : moins de "surface" visible pour les éventuels pirates, pas besoin de divulguer le serveur subversion, donc moins de tentatives potentielles pour tenter de profiter de failles, de corrompre les sources etc..

Enfin j'imagine.. Et puis bon, vu la nature du logiciel, je suppose que les développeurs de nmap sont un tantinet parano ;-)

Le mieux est encore de leur demander, pourquoi.

Tu peux télécharger les sources. Mais tu n'a pas accés au dépot subversion. La GPL n'oblige pas de donner accés au dépot des sources hein ;-), la GPL donne juste l'obligation de livrer les sources à ceux qu'ils le demandent, des versions sorties. Note bien la différence entre "livrer" et "acceder" ;-)



Bien sûr, si tu deviens un contributeur régulier, je suppose qu'ils te donneront accés au dépot. Mais faut montrer "patte" blanche à mon avis, vu le caractère sensible de ce logiciel.

Tu ne manipules plus des enregistrements, mais des objets. Qui peuvent avoir aussi leurs propres méthodes etc.

En résumé, avec un SGBDOO, plus besoin de ces couches logiciels qui font du mapping relationnel objet. Adieux donc activerecord en ruby et autre truc java super lourd. (bien sûr, il faut le binding langage_de_ton_choix pour le sgbdoo)

non c'était un exemple, une comparaison. Inclure des algos de DRM dans un logiciel libre est une situation tout aussi folle que donner sa clé privée à tout le monde.

>Lorsque tu installe une mdv, tu te retrouve avec un nombre incalculable de logiciel. Et pour faire la moindre chose, il te faut déjà passé un grand moment a lancé plein de logiciel et comparer.

Rassure moi, ce que tu décris ce sont des souvenirs d'une mandrake 9.x ou 8.x hein ? (et encore)


Parce que moi, en installant tout par défaut, je me retrouve avec menu K ne me proposant pas 15 navigateurs ou client mail ou ce que tu veux différent. (et que ce soit une Mdk 10.1 ou une mandriva 2006), J'ai un menu K simple, propre.

Merci donc d'arréter avec cette légende du passé.

La technologie du moteur d'affichage utilisée actuellement n'est pas portable facilement sous Linux.

Dommage. La concurrence a une longueur d'avance sur ce point, puisque hachette utilise mozilla comme plateforme pour leur soft : http://linuxfr.org/2004/08/12/17025.html