Jy[B]log

Theora, après Firefox et Chrome : Opera

Laurentj — Thu, 02 Jul 2009 17:30:00 +0200

Après Firefox et Chrome, Philip Jägenstedt, un développeur du navigateur Opera annonce que ce dernier embarquera en natif le support pour Ogg Vorbis/Theora. Un autre développeur d'Opera, Anne Van Kesteren, apporte des précisions sur ce choix en expliquant qu'embarquer H264 n'est pas très bon pour le web, et que le web a besoin de format ouvert, libre d'utilisation (sans avoir à payer des royalties), et libre de tout brevet logiciel. Theora est donc le format idéal pour diffuser de la vidéo sur le web.

Beaucoup de développeurs et d'utilisateurs préfèrent cependant H264, sous prétexte que les fichiers sont moins gros, et la qualité meilleure qu'avec Theora. Ils ne savent pas cependant (ou ne veulent pas savoir parfois) que Theora n'est pas si mauvais que ça, et que les encoders pour ce format s'améliorent !

Ainsi, la 1.1 alpha 2 de l'encoder 'Thusnelda' réalisé par la fondation Xiph vient de sortir. Sans changer le format Theora, il permet de produire des vidéos de meilleure qualité, et des fichiers moins gros. (voir ce comparatif sur ce blog). Bien entendu, la prochaine version de Firefox utilisera cette future version de la libtheora, si elle est prête à temps.

Ogg Theora vaincra ! :-)

Sorties majeures aujourd'hui

Laurentj — Tue, 30 Jun 2009 16:56:00 +0200

D'abord celle de Firefox 3.5. Et puis celle de PHP 5.3. Ils apportent chacun leur gros lot de nouveautés.

Notez les chiffres des versions de ces deux logiciels :-)

Sans oublier TwitFactory, la nouvelle appli de Daniel.

De la 3D dans Firefox

Laurentj — Sun, 28 Jun 2009 16:11:00 +0200

Énorme ! Le coeur du code de l'extension qui apporte un contexte 3D dans la balise <canvas> vient d'être intégré dans le trunk de Mozilla. Dans une version future de Firefox, on pourra donc faire de l'affichage 3D via cette balise, avec semble-t-il une API proche d'openGL.

Voir la news sur xulfr.

Chantiers: XBL2 et multi processes

Laurentj — Fri, 26 Jun 2009 17:51:00 +0200

Je l'avais déjà annoncé sur xulfr le mois dernier, le développement du support des multi-processeurs dans Gecko a démarré. Ce projet a même un nom maintenant : Electrolysis.

Benjamin Smedberg avait annoncé le projet "officiellement" il y a 10 jours, et peu de temps après, Chris Jones publiait une vidéo d'une première expérience, avec une simple fenêtre XUL dans lequel le contenu HTML était affiché via un processus différent.

Pour la petite anecdote, ils ont repris la bibliothèque de communication inter-processus de Chromium. Vive l'open source :-).

Autre bonne nouvelle, le développement de l'implémentation du langage XBL2 va bientôt démarrer, dixit Jonas Sicking, le développeur qui va s'en occuper. Pour en savoir plus sur XBL2, voir mon billet précédent sur ce sujet et les slides de la conférence sur XBL2 que j'avais donné à ParisWeb 2007.

J'aime bien ses périodes de release de Firefox, les développeurs n'ont plus trop de bugs à corriger pour la version qui sort, et du coup plus de temps pour développer des nouveaux trucs.

Pas de support DirectShow et Quicktime dans Firefox

Laurentj — Tue, 23 Jun 2009 12:49:00 +0200

À l'origine, dans le cadre de la balise video, il était prévu d'intégrer le support de DirectShow et de Quicktime dans Firefox, pour ses versions respectives sous windows et mac, en plus du support natif du format OGG/Theora. Finalement, cela ne se fera pas, comme l'explique Robert O'Callahan l'un des core-developer de Mozilla. Voici en gros les raisons :

Mozilla veut se concentrer sur la promotion des formats ouverts comme OGG/Theora
Apparemment, peu d'utilisateurs ont les codecs installés pour H264, par défaut, il n'y a que des codecs pour des "vieux" formats (sauf dans Windows 7 qui fournira un codec H264 en standard)
DirectShow est sous-spécifié, contient des bugs, et les codecs disponibles pour DirectShow sont de qualités très inégales, et ne fournissent pas tous tout ce qu'il faut pour que l'API de la balise video fonctionne correctement. C'est à dire, qu'avec certains codec, des scripts dans les pages web ne pourraient pas fonctionner, et l'auteur de la page web ne pourrait rien y faire. Déjà que la compatibilité cross-browser est un cauchemar, alors si il faut aussi se préoccuper des problèmes cross-codec...
Vu la qualité inégale des codecs, cela veut dire bugs potentiels, que les utilisateurs attribueraient à tord à Firefox. Les développeurs de Firefox ont assez de problèmes à régler comme ça
Il y a des codecs "malware"
Il y a des codecs avec des trous de sécurité, que Firefox ne pourrait pas "contrôler"
Deux backends en plus, c'est du boulot en plus, de la maintenance en plus etc.
Mozilla ne peut fournir des codecs par défauts avec le support Quicktime ou DirectShow (pour H264 notamment), à cause des royalties qu'il faudrait payer, et des problèmes de brevet.

Bref, dans Firefox, il n'y aura que le support natif de OGG/Theora (et OGG/Vorbis), ainsi que la backend GStreamer (au moins pour la version mobile, il n'est pas encore sûr qu'il le soit dans la version desktop).

Passage à Firefox 3.5RC

Laurentj — Mon, 22 Jun 2009 12:53:00 +0200

Ça y est, je viens de basculer définitivement de Firefox 3.0 à Firefox 3.5 (la release candidate). Malheureusement, j'ai encore la moitié des extensions qui ne sont pas compatibles, dont celle que je me sers pour lire mes flux RSS...

Vivement les extensions dans jetpack !

Jelix 1.0.9, Jelix 1.1.3 et WikiRenderer 3.1

Laurentj — Fri, 19 Jun 2009 13:43:00 +0200

Dans le courant de la semaine, j'ai publié des nouvelles versions correctives des deux branches actives de Jelix, le framework PHP. Vous pouvez mettre à jour vos installations Jelix sans risque. Il est même hautement recommandé de mettre à jour votre Jelix 1.1 si vous utilisez les modules d'interfaces de gestion de droits et de gestion d'utilisateur, à cause de problèmes critiques lorsque l'on change les droits (des droits peuvent être enlevés inopinément), et sur l'édition d'un profil d'un utilisateur.

Et puis aujourd'hui, je viens de sortir une nouvelle version de WikiRenderer, la 3.1, qui corrige quelques bugs, et qui apporte quelques facilités pour les développeurs de règles de transformations. Pour rappel, WikiRenderer est une classe qui permet de transformer un texte wiki dans une autre syntaxe wiki, ou en XHTML, ou tout autre langage de markup. Elle m'est très utile dans les petits modules de CMS, ou encore récemment, pour migrer le contenu wiki de XULFR d'un vieux wiki vers un nouveau wiki qui a une syntaxe différente. Et pour l'occasion de cette sortie, le site de WikiRenderer est maintenant disponible en Anglais, avec une documentation pour les développeurs.

De la com' débile chez Microsoft

Laurentj — Thu, 18 Jun 2009 11:53:00 +0200

Franchement, Microsoft tombe de plus en plus bas^[1]. Pour l'australie, ils font un espèce de jeux concours, où il faut trouver $10 000 quelque part sur le web, et on ne pourra le trouver qu'en utilisant IE8. Voir la page du concours sur le site de Microsoft^[2].

Bon déjà, limiter la navigation à un seul navigateur, alors que le web est supposé être universel, c'est vraiment un contre sens.

Mais ils font pire. Franchement, ce sont vraiment des boulets^[3].

Déjà pour le contenu du message, totalement affligeant. Se moquer ouvertement des autres navigateurs en utilisant des termes comme "Vieux Firefox", "Chrome ternis", c'est idiot. Parce que se moquer du navigateur, c'est se moquer de l'internaute qui utilise ledit navigateur et qui arrive sur le site. Et il me semble que d'un point de vue communication et commerciale, ce n'est pas en se foutant de la tête du client qu'on arrivera à lui faire acheter ce qu'on lui propose.

Mais il y a aussi la page web. C'est assez hallucinant d'utiliser quasiment une seule image pour afficher tout le contenu de la page web. Franchement, leur message ne tient plus la route, est totalement vidé de son sens. Messieurs de Microsoft, merci, mais tout les navigateurs savent afficher une image. Et faire une page web, ce n'est pas qu'avec des images.

Alors qu'ils auraient pu faire bien mieux, en profiter pour utiliser toute la technologie disponible dans IE8 en matière de CSS standard (même si leur implémentation est en deça des autres navigateurs), mais aussi en matière d'extensions propriétaires, leurs filtres et cie. Ils auraient même pu à la limite faire un truc qui s'affiche niquel dans leur browser, et qui est tout cassé dans les autres, pour essayer de prouver qu'ils peuvent faire mieux (le message passerait bien en tout cas envers des non technophiles).

Mais non. Là, c'est juste de la COM' nullissime, d'une boite qui ne sait même pas mettre en avant son navigateur. Ou plutôt, peut être qu'elle saurait le faire, mais elle admet qu'ils ne peuvent pas faire mieux au niveau communication, parce qu'elle sait pertinemment que la concurrence promet bien plus de choses aux développeurs et aux utilisateurs.

Et le summum dans cette COM' nulle, c'est que sur la page il est indiqué le nom du site, http://www.tengrandisburiedhere.com/ et il est même utilisé sur certains liens dans le source de la page. Hélas, triple fois hélas, cette adresse ne mène nulle part. Elle est bien enregistrée, mais il n'y a pas de serveur derrière, elle ne redirige même pas sur la page du concours sur le site de Microsoft. Des boulets je vous dis.

En attendant, des petits malins ont réservé le nom de domaine http://www.tengrandisburiedthere.co... (notez le T avant "here" qui fait la différence), et il suffit de zoomer pour savoir qu'elle est le navigateur meilleur que IE8^[4] ;-).

On pourra aussi aller sur http://hacks.mozilla.org pour se délecter de ce que nous proposent ou proposeront nos "vieux Firefox", nos "chrome ternis" et autres navigateurs trop "exotiques", et en particulier ce que proposera Firefox 3.5 qui sortira d'ici 2-3 semaines.

Notes

[1] Toute ressemblance de ce billet avec un de mes commentaires sur linuxfr n'est pas du tout forfuite :-)

[2] Si par hasard la page n'etait pas disponible, et c'est arrivé hier, vous pouvez aller voir des captures d'écrans ici

[3] Que ce soit réalisé par Microsoft lui-même ou par un prestataire externe, le résultat est le même pour la boîte : catastrophique selon moi

[4] en tout cas, l'un des meilleurs ;-)

La technologie Zoomorama

Laurentj — Thu, 18 Jun 2009 11:17:00 +0200

Une fois n'est pas coutume, je vais vous parler de ce qu'on fait dans la boîte où je travaille, Zoomorama, ou plus exactement, de la technologie que l'on a crée ou utilisé.

Si vous vous baladez sur le site, vous comprendrez que nous avons créé un moyen de zoomer sur des photos dans des pages web. Et accessoirement, entre autres choses, nous proposons un espace d'hébergement de photos.

Les plus observateurs et techniciens d'entre vous, et surtout ceux qui prônent les standards comme moi et mes collègues chez Zoomorama, auront remarqué une "anomalie" (si on peut appeler ça une anomalie) sur le site : on utilise Flash. Pour se débarrasser au plus vite de ce problème "tendancieux", voici au moins deux bonnes raisons justifiant l'utilisation de Flash pour notre technologie de Zooming :

ça permet d'utiliser notre techno sur 99% des ordinateurs des internautes
pour nos besoins (et j'insiste là dessus), les standards tels qu'implémentés actuellement dans les navigateurs, ne sont pas encore assez robustes, matures, et surtout assez performants (et je répète: pour nos besoins). Et puis tant qu'il y aura cette bouse d'IE qui est majoritaire sur le web...

On utilise donc une techno qui n'est pas "web" (dans le sens noble du terme), mais... On se soigne !

En effet, déjà, d'une part, l'appli flash, c'est de l'ActionScript 3 à 99,9%. Pas de Flex ou autre truc d'Adobe. En fait, on utilise juste le compilateur AS3 d'Adobe. Et d'autre part, nous utilisons CSS, DOM, XML, Javascript etc. Mais attention, je ne parle pas dans notre site web. Je parle : dans notre application Flash.

Oui, vous avez bien compris : nous avons développé un... navigateur en Flash !

Un navigateur qui implémente donc les technologies suivantes :

XML, en particulier un sous ensemble de SVG, ainsi qu'une grammaire qui nous est propre, le ZML.
Bien sûr qui dit XML, dit DOM. Le document lu par notre browser est accessible à partir de la page web, et utilisable avec javascript comme n'importe quel autre document web. On peut donc le modifier dynamiquement, et ces modifications sont répercutées visuellement instantanément.
CSS. Nous implémentons globalement CSS 2.1, mais aussi des bouts de CSS3. Par exemple, nous sommes probablement la deuxième implémentation au monde après webkit, qui supporte les animations CSS. D'ailleurs nous avons l'intention de faire des retours au W3C. Dés qu'on aura un peu de temps (Oui Daniel, on n'a pas oublié :-)).

Et c'est cela qui différencie Zoomorama des autres solutions de "zooming" que l'on peut trouver sur le web : on ne fait pas que zoomer simplement sur une photo, mais on zoom sur un document. Ce document n'est pas en HTML, mais en ZML, notre langage maison, très simple, et plus orienté contenu multimédia que contenu textuel comme HTML. Et nous nous basons donc sur des standards comme je l'ai indiqué.

Ce qui veut dire que notre technologie est à la portée de n'importe quel développeur web. Il y a finalement juste la surface de rendu qui change : ce n'est pas Gecko, Webkit, Trident, ou Prescot, mais Flash.

Cette utilisation des standards a aussi d'autres avantages :

on peut générer les documents dynamiquement coté serveur, tout comme n'importe quel page web. Entendre par là que le document est vraiment externe à notre appli Flash, et il n'y a pas besoin d'avoir des outils Adobe pour utiliser notre navigateur.
notre technologie est "browser-agnostic", c'est à dire que les documents produits par les utilisateurs seront réutilisables par n'importe quel autre navigateur qui implémenterait ZML et bien sûr, CSS et cie. Notre doux rêve serait par exemple d'avoir un browser basée sur Canvas. Mais les implémentations de Canvas dans les navigateurs d'aujourd'hui ne sont pas assez performantes (voir inexistante chez certains, hum, hum).

Si on avait du temps , et vu qu'on est au moins 3 dans l'équipe à connaître plus ou moins les méandres de Gecko, on essayerait bien une implémentation native dans Firefox, quitte à passer par XTF :-) Mais les journées de 48h, il parait que ça va pas se faire...

En tout cas, ce qui est sympa dans ce projet, c'est la volonté tenace de l'équipe d'utiliser et d'implémenter au plus juste les standards que l'on supporte. Sur ce point, je félicite David Marteau et Olivier Gambier pour le développement de ce browser. En ce qui me concerne, je développe (avec David), la nouvelle version de l'éditeur ZML wysiwyg, ZoomCreator, réécrite from scratch^[1], basé sur XulRunner et qui sera en quelque sorte un Kompozer-like ou BlueGriffon-like, mais pour ZML.

Nous travaillons aussi sur une documentation à l'intention des développeurs web qui voudraient zoomer dans tout les sens :-) Je vous tiendrais au courant.

Notes

[1] La version actuellement en ligne est basé sur XulRunner et une ancienne techno de Zoomorama basée sur un activeX

Des articles intéressants sur hacks.mozilla.org

Laurentj — Wed, 17 Jun 2009 17:53:00 +0200

Zut, j'ai oublié de vous signaler la publication de ma démo sur hacks.mozilla.org, que je vous avez promis. Je ne suis plus au point en matière de teasing, vous avez connu mieux sur ce blog, n'est-ce pas ? :-)

Donc voilà ma démo, à tester avec Firefox 3.5b99 au moins. Si des développeurs spécialisés sur Webkit (Riiiiik !), Opera ou Konqueror, pouvaient jeter un coup d'oeil voir si je peux améliorer ça pour leur navigateur préféré respectif... (Ouai, je m'y prend un peu tard, mais là, je n'ai plus la tête hors de l'eau, tellement ma todo list est lourde, et j'ai un tuba pour éviter de me noyer).

Bon sinon, sur hacks.mozilla.org, il y a des articles que j'ai vraiment aimé jusqu'ici, et finalement bien plus impressionnant que ma petite démo, et que je veux vous faire partager (pour ceux qui ne suivent pas hacks.m.o) :

Etonnant : faire de la 3D isométrique avec les css transforms.
Un bel audio player tout en HTML (vive la balise audio !)
Redimensionnement d'une image sans déformation (yeaa canvas baby)
De la géolocalisation avec open street map, par René Luc, un pote sur Xulfr.

Et puis il y a aussi ce débat (ici et là) sur la qualité de Theora par rapport à ce qu'on peut avoir dans YouTube par ex. Conclusion, Theora, c'est bon, mangez-en !

Et ce n'est pas fini, mon petit doigt me dit qu'il va y avoir encore de belle demo sur les nouvelles technologies web :-)

Les nouveautés de Firefox 3.5 en 35 jours

Laurentj — Tue, 09 Jun 2009 13:19:00 +0200

Mozilla vient d'ouvrir un site, hacks.mozilla.org. Pendant 35 jours, nous allons vous montrer les nouvelles possibilités du moteur de Firefox, tant en terme d'API javascript, qu'en terme de support de HTML5 et de CSS3. J'ai réalisé une démo qui sera publié sur ce site. Ce sera une démo sur CSS, qui utilisera des fontes téléchargeables (propriété font-face), les ombrages sur les textes (text-shadow) et les boites (box-shadow), accompagné d'une pincé de bords arrondis (border-radius).

Stay tuned !

Mise à jour: comme promis...

Des problèmes XML dans webkit

Laurentj — Tue, 02 Jun 2009 12:11:00 +0200

Ici à Zoomorama, on hallucine sur les implémentations de XML dans les navigateurs. En effet, dans un de nos projets, on doit manipuler en javascript un document XML, créé à partir d'un DOMParser, et on a besoin de pouvoir propager un événement DOM sur des éléments XML. Et c'est loin d'être facile...

Avec Gecko, absolument aucun problème. Le DOMParser renvoi bien un XMLDocument, avec des beaux nœuds DOMElement, et on peut attacher des event listeners sur les éléments, créer des événements, les propager etc.. Bref, ça fait ce que ça doit faire. Le bonheur.

Avec Opera, on arrive à s'en sortir, il a une implémentation native correcte comme dans Gecko. Il y a juste des bizarreries, comme sur getElementByTagName. Par contre, il est le seul à implémenter xml:id, ce dont on a besoin.

Avec IE, il n'y a pas d'objet DOMParser. On se dit, c'est un peu normal, dans la mesure où on sait que IE et XML, ça fait deux. Mais il y a quand même un activeX similaire. Qui fonctionne... En fait, non, je n'appelle pas ça fonctionner. Le problème est que ce parser est complètement à la ramasse. Déjà il ne tient pas compte des DTD, ne connait même pas le namespace "xml", et j'en passe. Le pire est qu'il retourne des objets ActiveX, et non des objets Javascript. Ainsi il est impossible de toucher au prototype, de redéfinir des méthodes, ce qui serait utile pour compléter ou corriger l'implémentation. Parce que bien sûr, l'implémentation du DOM dans ce truc est complètement "fucké" comme dirait mon collègue. Par exemple, il n'y a même pas de localName sur les éléments, getElementsByTagName est buggé, et d'une manière général, le support des namespaces sur cette implémentation est archi buggé et incomplète. Un comble pour un parser XML. (Pu***, mais faites disparaître ce navigateur de merde !!! Et que ses développeurs soient maudis sur 15 générations ! )

Conclusion : le parser XML de IE est juste inutilisable. Mon collègue Olivier (Maître es-javascript) a donc réimplémenté un DOMParser XML et un pseudo DOM pour IE, avec juste ce dont on a besoin. Super lourd. Mais on n'a pas trop le choix.

Avec webkit, c'est un peu mieux. Ou pas. Il a un DOMParser, qui nous ressort bien un arbre DOM à peu prés correct. Mais là où ça coince : pas de stack d'événements sur l'implémentation. On ne peut pas propager des événements. Et là on se dit, sur webkit, ils ont fumé la moquette. Parce que Webkit est censé supporter XHTML, et donc les événements dans XHTML. Or, XHTML, c'est du XML. Mais si en XML, il n'y a pas de support d'événements, ça veut dire que l'implémentation de XHTML ne repose pas sur celle de XML, ou que l'implémentation des événements n'est pas faite sur les classes de base XML, mais sur les classes XHTML qui en hérite. Enfin bref, une raison dans le genre. Je ne suis pas allé voir le code de webkit. Mais c'est en tout cas pas logique du tout.

Toujours est-il qu'on ne peut pas propager d'événement. On s'est dit, on va modifier le prototype des objets DOM retournés par le DOMParser de webkit, et on va implémenter une stack d'events. Las, les constructeurs XMLDocument et Node ne sont apparemment pas appelés lorsque le document est construit , et du coup, on ne peut pas appliquer la stack sur les prototypes parce qu'on ne peut pas avoir de variables privées "instance".

Conclusion : avec webkit, c'est aussi le cauchemar. L'unique solution que l'on voit, c'est de refaire là aussi un parser XML et implémentation DOM (celle qu'on a fait pour IE n'est pas totalement réutilisable, n'est pas complète, et repose en partie sur l'active X parser de IE). Mais ce serait d'une connerie sans nom. Du très grand n'importe quoi. C'est totalement désespérant.

Si il y a un spécialiste webkit dans le coin qui aurait un tuyau à nous filer pour nous éviter de réinventer la roue...

La balise

Laurentj — Thu, 28 May 2009 12:13:00 +0200

L'adoption du format Ogg Theora fait son chemin : DailyMotion viennent d'annoncer sur leur blog (et via un communiqué de presse) qu'ils vont prendre en charge la balise <video> de HTML5, en particulier avec Firefox 3.5 qui sortira dans quelques jours en RC.

Ils ont ouvert un site en test diffusant les vidéos au format Ogg Theora, openvideo.dailymotion.com à visiter avec Firefox 3.5. Ils ont également fait une page de démonstration montrant les possibilités de l'utilisation de la balise <video>, conjointement avec les autres technologies web comme javascript, css, svg etc...

Qu'un site majeur dans la diffusion de vidéos sur Internet utilise ces technologies, promet un bel avenir à Theora. Bien que les encodeurs actuels pour Theora soient de moins bonne qualité que pour le H264 par exemple, un travail est en cours (sponsorisé notamment par Mozilla), pour les améliorer, tant au niveau de la qualité de l'image, que la taille des fichiers. Voir par exemple une de ces améliorations faite au début du mois.

Pour rappel, Ogg Theora est un format libre et ouvert pour stocker de la vidéo. Pour en savoir plus sur la balise <video>, vous pouvez lire un de mes billets précédents sur le sujet.

Go Theora ! Go !

Commit access on Mozilla repositories

Laurentj — Thu, 28 May 2009 11:33:00 +0200

After 5 years of Mozilla hacking, and some patches accepted and landed into the Mozilla trunk, I finally asked yesterday an access to commit on Mercurial repositories of Mozilla. And this request has been granted ! Youhouuu !

For me, it's a sort of gratefulness from the other contributors :-) Thank you Mozilla !

Un peu d'actu sur jelix et cie

Laurentj — Mon, 25 May 2009 12:44:00 +0200

Depuis quelques mois, je n'ai plus autant de temps pour bosser sur plusieurs projets perso en même temps. Ils avancent donc tous moins vite. Je ne peux me concentrer maintenant que sur un seul projet à la fois. Ou presque. Aussi depuis quelques semaines j'ai décidé (et un peu contraint à cause du changement de serveur) de bosser sur mon site xulfr.org. Depuis trois ans, je n'y avais pas trop touché, car j'étais plus absorbé par le développement d'un certain framework Jelix. Framework dont l'objectif à l'origine, c'était justement de motoriser Xulfr :-)

Donc voilà, après trois ans de développement de Jelix, je me remet enfin sur xulfr.org. En le migrant vers Jelix. Et ce n'est pas un mal, car ça permet finalement de toucher à plusieurs de mes projets.

L'objectif premier de cette migration : virer le vieux phpwiki (version datant de 2003 !) qui est incompatible avec PHP5 et n'était donc plus utilisable sur notre nouveau serveur. Il a donc fallu que je choisisse un nouveau système Wiki. La tentation a été trop grande de développer un wiki avec Jelix (après tout, j'ai développé Jelix un peu pour ça). C'est donc en cours avec le projet jCms. Cette migration est à moitié faite : les pages du wiki de Xulfr sont maintenant motorisées par mon cms. Mais il n'est pas possible d'éditer les pages parce que le système d'authentification n'est pas encore "branché" sur le cms.

Pour ce nouveau wiki, j'ai adopté une syntaxe proche de celle de DokuWiki. Il a donc fallu faire un script qui d'une part, migre les données des anciennes tables de phpwiki vers celles de jCms, et au passage qui converti l'ancienne syntaxe vers la nouvelle. Pour cette conversion, j'ai utilisé bien entendu mon parser de syntaxe Wiki, WikiRenderer, pour lequel j'ai donc développé des règles de conversion "phpwiki vers dokuwiki". Et cela ma permis de débusquer quelques bugs dans WikiRenderer. Je vais pouvoir alors sortir une version 3.1 dès que j'aurais le temps.

Après l'intégration de Jelix sur xulfr.org, l'installation de jCms, et la migration du contenu, place à l'intégration d'un système d'authentification. Je me repose bien sûr sur celui de Jelix, mais aussi du module jCommunity, qui permet à un utilisateur de s'inscrire sur un site, d'éditer son profil etc. Ça a été l'occasion de fixer quelques bugs dans ce module et de faire quelques améliorations pour la prochaine version 0.2 de jCommunity. Cette intégration de jCommunity n'est pas encore en ligne, parce qu'il me reste encore à faire une chose : "relier" jCommunity avec la base des utilisateurs du forum que l'on utilise sur XulFr.org. Et c'est en cours de développement. L'idée est qu'au final on ne passe plus que par jCommunity pour gérer son compte sur XulFr, et qu'on ait donc pas à s'enregistrer deux fois comme c'était le cas lorsqu'on avait phpwiki. Histoire aussi que l'on ait qu'une seule base d'utilisateur.

Une fois le système d'inscription/authentification installé, je pourrais faire les améliorations nécessaires sur jCms pour le "brancher" sur jCommunity. Ce sera peut-être l'occasion de sortir une version 0.1 de jCms... Je verrais, parce que pour le moment, l'installation de jCms n'est pas très "friendly", et faut mettre un peu les mains dans le camboui. Faudrait peut être alors me remettre sur Jelix, pour développer enfin le futur système d'installation/mise à jour pour les applications Jelix, qui est normalement prévu pour Jelix 1.2.

Voilà voilà. Je ne cause pas beaucoup sur mon blog en ce moment, mais j'avance quand même sur xulfr.org, Jelix, jCommunity, jCms, WikiRenderer...

Xulfr.org indisponible

Laurentj — Mon, 11 May 2009 12:22:00 +0200

Cher développeurs XUL, depuis hier soir le serveur de xulfr.org est mort. Paix à son âme. Nous allons le remplacer le plus tôt possible, mais le site ne sera pas revenu avant 2-3 jours je pense. Je vous tiens au courant...

Mise à jour: le site est de nouveau operationnel depuis Mercredi dans la journée :-)

Améliorations du serializer de Mozilla

Laurentj — Mon, 27 Apr 2009 11:42:00 +0200

Enfin ! Ça y est ! C'est arrivé dans le trunk samedi ! Mon super gros patch sur le serializer ! Il y a 10 mois j'avais commencé son développement. Je vous rassure, je n'ai pas travaillé pendant ces 10 mois régulièrement sur cette amélioration. Il y a eu beaucoup de temps morts (la faute à pas le temps), et beaucoup d'attente pour les reviews et super-review.

Qu'est ce que cela apporte ? Le support des mêmes flags de l'interface nsIDocumentEncoder pour XHTML/XML que pour HTML. Donc principalement, la possibilité d'avoir enfin du "pretty printing" (indentation, passage à la ligne au bout de X caractères etc..) lors de la serialisation d'un DOM XHTML et XML. Seul un document HTML profitait de cette possibilité. Bien sur, pour XHTML, le pretty printing tient compte de la spécificité de XHTML. Par exemple, pas de pretty printing dans les balises <pre> ou <script>.

Au passage, puisque maintenant le code du pretty printing est commun à HTML/XHTML/XML, j'ai amélioré le pretty printing du HTML. L'indentation n'est plus boguée, les sauts à la ligne se font au bon endroit etc... Ce patch corrige donc d'emblée deux bugs de longues dates, et va en permettre de fermer quelques autres assez rapidement, en espérant ne pas avoir introduit de régression (mais bien sûr j'ai ajouté plein de tests unitaires pour limiter les régressions potentielles).

Et concrètement, ce patch va permettre d'avoir un meilleur enregistrement des pages web éditée dans BlueGriffon, Kompozer, ou tout autre application qui sera basée sur XulRunner 1.9.2 minimum (dont Firefox 4)..

Quand une nouveauté CSS en chasse une autre...

Laurentj — Fri, 24 Apr 2009 13:55:00 +0200

Les nouvelles propriétés CSS qui arrivent dans nos navigateurs permettent de faire des choses plus sophistiquées mais de façon plus simple qu'avant.

J'avais déjà montré cette facilité en appliquant des styles d'ombrages et de rotation sur la page d'accueil de jelix.org. Mais il n'y a pas que les sites web qui vont pouvoir profiter de ces avancées, il y a aussi Firefox.

Comme vous le savez certainement déjà, Firefox utilise un langage XML, le XUL, pour son interface graphique et CSS pour le design de cette interface. Je vais prendre un exemple de l'utilisation des nouvelles propriétés CSS dans Firefox : la barre de boutons de la boite de dialogue des extensions, sous MacOSX.

Dans Firefox 3.0, ça donne ça :

C'est assez sobre. Pour les arrondis sur les boutons droite et gauche, border-radius^[1] est utilisée, et sur tout les boutons, il y a une simple image de fond avec un léger dégradé.

Durant le développement de Firefox 3.5, est arrivé la propriété border-image (Voir un de mes billets sur ce sujet). Un contributeur s'est dit, "utilisons là", pour rendre ces boutons plus jolis. Et les boutons sont devenus ceci, comme on peut le voir dans Firefox 3.1 beta3:

Comme vous le voyez, avec border-image, on peut faire des bordure plus sympa et assez facilement en CSS. D'ailleurs l'auteur en a profité pour ajouter des "effets" selon l'état du bouton (voir par exemple le bouton "extension" sur lequel j'ai le bouton de la souris enfoncé). Le seul souci de cette approche est que ça utilise pas mal d'images. Déjà, il y a trois types de boutons (gauche, milieu, centre), mais en plus il y a plusieurs états du boutons : relâché, sélectionné, enfoncé, actif etc... Voici par exemple trois de ces images pour le bouton de droite :

Pour réaliser des bordures complexes, on n'a toutefois pas le choix.

Mais que remarque-t-on sur ces images ? En fait elles ne font que reproduire des effets d'ombres.

Des ombres ? Ça tombe bien, il y a une autre nouvelle propriété dans Firefox 3.5 pour faire des ombres : box-shadow. Et si on l'utilisait ? C'est ce que s'est dit un contributeur. Hop, quelques lignes de css à modifier, suppression de toutes ces images (70ko en moins) et le résultat que vous pourrez admirer dans Firefox 4^[2] :

On obtient quasiment la même chose qu'avec la technique du border-image précédente, mais sans images donc plus léger, avec une manière plus simple de créer et modifier le design.

Notes

[1] ou plutôt -moz-border-radius, cette propriété n'étant pas encore un standard dans CSS3, Mozilla l'a préfixé avec -moz- comme le permet la spécification CSS, tout comme box-shadow

[2] pas sûr que le patch sera intégré dans Firefox 3.5

Interface de la balise video dans Firefox

Laurentj — Thu, 23 Apr 2009 15:30:00 +0200

Depuis quelques heures, des améliorations sur l'interface utilisateur de la balise video ont été incluses dans le trunk et pour la prochaine beta de Firefox (cliquez sur l'image pour la voir en taille réèlle)

Les améliorations en questions :

réglette pour choisir le volume sonore (tout à droite)
affichage du temps total de la vidéo
affichage du temps écoulé, dans la petite bulle au dessus de la barre de progression, petite bulle qui sert également à aller directement à l'endroit voulu dans le film en la déplaçant.
affichage de la progression du téléchargement dans la barre de progression de lecture (je ne sais plus si ça n'y était pas déjà dans la beta précédente)

Bref, on commence à avoir une interface par défaut plutôt complète. Notez que cette interface n'apparaît que si la souris est au dessus de l'élément <video>, et seulement si l'attribut controls est présent.

Ce qui est interressant à savoir, c'est la façon dont cette barre de contrôle est implémentée dans Firefox. En fait, ce n'est pas le code de la balise vidéo qui effectue directement cet affichage, mais un simple composant XBL qui est attaché à cet élément.

Pour rappel, XBL est un langage XML (en cours de normalisation au W3C) qui permet de définir le contenu d'un élément en indiquant les éléments fils (anonymes) à ajouter, ainsi que son comportement, c'est à dire un ensemble de méthodes javascript pour son API, et également des fonctions appelées sur des événements DOM (sur le click etc). Dans un fichier XBL, on peut ainsi définir plusieurs éléments.

Comme on peut le voir dans ce fichier XBL de l'élément video, les contrôles sont en fait des éléments XUL. Et sur les click et autre de ces élements XUL, le code javascript appel l'API native de l'élément video.

Le design est déclaré via une feuille CSS. Dans la feuille de style dédiée, on peut voir que tout est quasiment fait en CSS, que ce soit les arrondis, les couleurs, les opacités etc. Les seules images utilisées concernent juste les symboles play/pause, le dessin du haut parleur, et la bulle du temps écoulé.

Bref, on utilise des technos du web pour implémenter en partie... des technos du web :-)

Mais ce n'est pas tout !

Cette interface par défaut ne vous plaît pas ? Faites une extension qui propose un nouveau XBL en remplacement de l'original ! Ou une autre feuille de style CSS ! Où les deux !

Aaah, c'est beau les technos Mozilla, n'est-ce pas ? :-)

Flemme

Laurentj — Fri, 10 Apr 2009 18:12:00 +0200

J'ai une de ces flemmes de bloguer en ce moment... Pourtant y a pas mal de choses que je voudrais écrire...

PS: arf, faire un billet de moins de 140 caractères... je file un mauvais coton... je vais finir sur twitter si ça continue... Bon ben voilà, ça fait plus de 140 caractères, l'honneur est sauf.

Jy[B]log

Theora, après Firefox et Chrome : Opera

Sorties majeures aujourd'hui

De la 3D dans Firefox

Chantiers: XBL2 et multi processes

Pas de support DirectShow et Quicktime dans Firefox

Passage à Firefox 3.5RC

Jelix 1.0.9, Jelix 1.1.3 et WikiRenderer 3.1

De la com' débile chez Microsoft

Notes

La technologie Zoomorama

Notes

Des articles intéressants sur hacks.mozilla.org

Les nouveautés de Firefox 3.5 en 35 jours

Des problèmes XML dans webkit

La balise chez Dailymotion

Commit access on Mozilla repositories

Un peu d'actu sur jelix et cie

Xulfr.org indisponible

Améliorations du serializer de Mozilla

Quand une nouveauté CSS en chasse une autre...

Notes

Interface de la balise video dans Firefox

Flemme

La balise