Laurent J a écrit 2945 commentaires

De la théorie sur le papier.

Quelle mauvaise foi. Il existe plein d'éditeurs MathML, Firefox affiche le MathML. Y a plein de plugins pour afficher du MathML pour IE. Ce n'est pas parce que tu es totalement ignorant de ce langage que c'est forcément mauvais.

Ormis l'échange de formule entre logicielle. Je ne vois pas trop son interêt.

Inclure des formules mathématiques dans n'importe quel fichier XML. Afficher une formule mathématique dans une page web.. etc...

Au niveau du rendu, je ne vois pas pourquoi l'affichage d'une formule mathematique avec mathml serait moins bonne qu'avec tex. Si le navigateur est bien codé et que les bonnes fontes sont installées, y a pas de problème.

De plus, ton image png a de forte chance d'être plus lourde que le même contenu en MathML.

C'est en partie vrai. Mais un pda requiert un site dédié.

Pour les sites mal foutu oui. Mais si tu organise ton contenu comme il faut, que tu propose une feuille de style spécifique pour les pda (media="handeld"), y a pas de raison de fournir un "contenu spécifique".

Les écrans du futur auront sûrement un format A3 ou supérieur et une résolution proche des imprimantes (300/600 dpi)

A3 ! Ouai \o/ ! super pour mettre dans ma poche !

Les formules mathématiques par exemple: TeX -> DVI -> PNG.

Et MathML, c'est fait pour quoi à ton avis ?
http://www.w3.org/Math/


C'est pas de la faute des utilisateurs de wikipedia si les auteurs de mediawiki ne permettent pas l'insertion de formules mathématiques stockées en mathml.

Je pense que tu devrais faire un tour sur http://www.w3.org/ , tu verrais que bon nombre de techno repondre à beaucoup de besoins.

Pourquoi faire compliqué quand on peut faire simple?

Parce qu'on ne sait pas faire plus simple en ayant la même flexibilité ? Les mêmes propriétés (universalité, indépendance du média, tout ça...) ?

Plus sérieusement, un web basé sur du dvi/pdf/... ne serait il pas plus beau, plus stable, et surtout rendu de la même façon quelque soit le logiciel utilisé.

J'aime bien le "plus serieusement", qui précède ce troll des cavernes :-)

tu oublie que les technos du web se veulent universelles, sont conçues pour que les documents puissent être lu dans n'importe quel condition, avec n'importe quel type de browser. Elles sont conçus pour que le document s'adapte au media utilisé, et non l'inverse !

Va donc lire sur un pda un site dont le contenu est entièrement dans un pdf formaté en A4. Bon courage !

PDF est juste fait pour l'impression. Il ne peut s'adapter au media. C'est au media de s'adapter à PDF, et ça, c'est terriblement difficile.

Wikipedia est obligé d'utiliser des images pour combler les insuffisances de cette merveilleuse technologie.

Quelles insuffisances ? des images sur quoi ?

non, sous windows, gecko utilise l'api windows...

Quand je pense, qu'en php, je dois gérer le fait qu'à chaque fois qu'on clique sur un bouton, faut recharger la page, c'est vrai qu'il serait peut être temps de se demander s'il n'y a pas un problème...

C'est pas un problème de php. C'est un problème d'architecture de ton appli. Les services web n'ont pas été inventé pour rien. Les templates XUL non plus. xmlHttpRequest non plus, XForms non plus....

ça se regle l'occupation mémoire. Voir http://www.chevrel.org/fr/carnet/index.php?2006/01/05/545-pa(...) et http://weblogs.mozillazine.org/ben/archives/009749.html

Aucun problème à signaler.. En tout cas aucun que tu site.

À noter que j'utilise une version officielle, et non celle livrée par ma distrib.

Certains ne vont pas manquer d'évoquer des problèmes de fuites de mémoires, qui n'en sont pas vraiment pour la plupart. L'occupation mémoire importante étant surtout dû au bfcache (back/forward cache). Voir les explications de Ben Goodger http://weblogs.mozillazine.org/ben/archives/009749.html et aussi ceux de Pascal Chevrel http://www.chevrel.org/fr/carnet/index.php?2006/01/05/545-pa(...)

>J'espère qu'il en restera quelque chose dans quelques années.

Sur http://www.archive.org trés certainement...

--->[]

elle arrive, elle arrive ;-)

tu lag :-)

sinon, pour parler de tes problèmes sur wengo, je pense que le mieux est d'aller sur le forum de wengo http://www.wengo.fr/assistance/forum/viewforum.php?f=84

...J'ai piscine

Et puis c'est loin Montain view...

à mon avis "qui n'est pas encore assez complet"

Konqueror évoluant rapidement, peut être n'a t il pas la dernière version.

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)