Aller au contenu | Aller au menu | Aller à la recherche

vendredi, octobre 16 2009

Transitions CSS

La version de développement du futur Firefox 3.7 implémente depuis quelques jours les transitions CSS. Vous avez peut être pu le voir, en lisant Paul qui a parlé discrètement sur son blog, en même temps que la nouvelle implémentation de l'API de l'accéléromètre. Vous pouvez voir une démo de Paul avec les transitions CSS.

Le principe est assez simple:

  • avec la propriété transition-property, vous indiquez les propriétés CSS qui seront concernées par la transition, c'est à dire, quand leur valeur changera, il y aura une transition entre l'ancienne valeur vers la nouvelle valeur, le changement ne sera donc pas immédiat.
  • transition-duration permet d'indiquer la durée de la transition, pour chacune des propriétés
  • transition-timing-function, indique la fonction de transition, c'est à dire la manière dont la transition sera faite. Par exemple la fonction ease-in-out fait une transition rapide au début, lente au "milieu", et rapide à la fin. On a ainsi des fonctions pour faire des effets élastiques, smooth etc..
  • transition-delay pour indiquer à partir de combien de temps la transition doit être faite, à partir du moment où la valeur est changée.
  • transition pour indiquer tout ça en une seule instruction.

Voir la spécification complète sur le site du W3C (spécification qui est encore un brouillon).

Un exemple :

  .mydiv {
     width: 100px;
     transition: width 1s linear;
  }

 .mydiv:hover {
    width:200px;
 }

Quand on passera la souris au dessus de l'élément, sa largeur changera à 200px. Avec la propriété transition, ce changement ne sera pas immédiat. La largeur passera de 100px à 200px en 1 seconde, de manière linéaire. Bien sûr, ce changement de valeur peut être fait via javascript plutôt que sur un :hover, par exemple: document.querySelector(".mydiv").style.width="200px";.

Le gros intérêt de ces propriétés CSS, c'est que ça va rendre obsolète beaucoup de fonctions d'animations que l'on retrouve dans beaucoup de frameworks javascript (jquery, mootools...). Ça permettra des pages plus légères (les frameworks seront moins lourds à terme) et plus rapide.

C'est donc implémenté dans webkit (donc dans Safari, et Chrome je crois), et dans une future version de Firefox, en utilisant bien entendu les prefixes -webkit- et -moz- sur les propriétés pour que ça fonctionne.

Et, comme je l'avais déjà dis il y a quelques mois dans un billet sur notre technologie à Zoomorama, c'est aussi implémenté dans notre browser (développé en actionscript 3). J'ai mis en ligne deux démos faites par David Marteau, et c'est utilisable dés maintenant dans vos fichiers ZML :-)

mercredi, octobre 14 2009

TI: interdiction de bidouiller sa machine ??

Mékilsoncon ! Texas Instrument interdit d'installer un firmware sur ses calculatrices, pour des histoires de droits !

D'un coté, ça ne m'étonne pas, j'ai toujours trouvé que Texas Instrument faisaient des calculatrices de mer.. pas assez bidouillables. Au début des années 90 déjà, faire un programme qui utilisait au maximum les possibilités de la machine (comprendre, en assembleur), c'était presque mission impossible. Fallait faire des hacks de malade, peu pratiques. Peu interressant.

Contrairement à HP. Dans les HP48 par exemple, en programmation RPL, il y avait des objets pour les nombres, pour les chaines, pour les sources en RPN, pour les bibliothèques etc. Et il y en avait aussi... pour les programmes binaires ! On pouvait donc installer un assembleur (merci à Phong "hpninja" Nguyen pour avoir crée le premier assembleur sur hp48 :-)), et coder comme des malades en assembleur, créé des binaires super optimisé, torturant au maximum cette petite machine, arrivant à en faire une véritable console de jeu digne des gameboys de l'époque ! (qui plus est, autorisées officiellement en cours et au BAC :-) ). On pouvait aussi appeler en RPL, des routines de la ROM, offrant encore plus de possibilité à celui qui programmait simplement en RPL (non officiellement documentés, mais heureusement, il y avait des livres pour ça, merci Paul Courbis et Sebastion Lalande !).

Bref, je me suis éclaté avec cette machine (en réalisant entre autre ces programmes là). Et d'autres développeurs aussi, au point de justement refaire un OS (le metakernel !). La mémoire ROM à l'époque n'était pas flashable (encore chère à l'époque), mais il y avait de quoi changer le boot, pour faire démarrer la machine sur un autre endroit que la ROM.

HP n'a jamais d'ailleurs interdit ces pratiques ou limiter cette "bidouillabilité", bien au contraire. Ils ont même fini par embaucher des auteurs du metakernel, qui servira de base plus tard à l'OS de la HP49.

Les gusses de Texas Instrument devraient y réfléchir...

L'utilité de l'API de l'accéléromètre dans les navigateurs

Paul Rouget nous a fait de jolies demos (que vous pouvez voir en vidéo sur hacks.mozilla.org), pour montrer ce qu'on peut faire avec la nouvelle API qui permet de profiter de l'accéléromètre embarqué dans votre laptop ou tablette.

Les réactions n'ont pas tardé un peu partout sur le web, et en gros, j'en ai retiré 3 différentes :

  • "vous feriez mieux de travailler sur autre chose"
  • "c'est inutile, ça sert à rien"
  • "c'est génial !"

Pour le "vous feriez mieux de travailler sur autre chose", on va passer vite fait, c'est du pur troll. Il y a plusieurs dizaines de développeurs qui bossent à temps plein sur Firefox, et il est évident que chacun bosse sur des sujets différents. Le support de l'accéléromètre a été fait par un seul gars, pas 250. Bref, ce n'est pas une perte de temps.

Les deux autres remarques sont plus intéressantes. Et en analysant (à l'arrache) les réactions, j'ai remarqué qu'en fait la première semblait être faite principalement par des non-développeurs, et la deuxième par des développeurs.

En fait, beaucoup de gens, en voyant une des démos qui montre une page web s'orienter ou se tordre en fonction de l'orientation du laptop, n'ont pas vu l'intérêt technique de la chose. Ils ont regardé la démo "au premier degré" pourrait-on dire. Il y en a qui ont cru comprendre que dans les prochaines versions de Firefox, les pages web s'orienteront en fonction de l'orientation du laptop. Du coup, ils disent que ça ne sert à rien, qu'ils ne bougent de toute façon pas leur laptop, ou encore que c'est une horreur, parce que quand une image s'affichera dans le mauvais sens, ils ne pourront plus basculer leur laptop pour voir l'image dans le bon sens, etc...

Et en fait, ce n'est pas du tout ça, et effectivement, la démo est peut être mal choisie au final. Car en fait, l'intérêt de la démo se trouve sous le capot, dans le code source de la page, pour montrer avec quelle facilité on peut utiliser l'accéléromètre. C'est pourquoi la plupart qui ont trouvé cette démo géniale sont je pense des développeurs, ils ont regardé le source de la page.

Il faut donc juste comprendre que Mozilla a mis à disposition un outil, pour les développeurs web. Et il est tellement nouveau que des usages concrets de cet outils restent à inventer. On sait que l'une des premières utilités est pour les jeux, sur Fennec, la version mobile de Firefox, ou pour la version desktop sur les tablettes, comme on peut voir dans les jeux pour IPhone. Pour d'autres utilités, surtout sur le desktop, nul doute que des développeurs vont en trouver ! C'était pareil pour <canvas>, <video>, l'api de géolocalisation etc.. On ne voit pas toujours l'intérêt d'une nouvelle techno quand elle débarque. Mais au final, des usages sont inventés, créés.

Ça me rappelle d'ailleurs la conférence de Paul et Tristan à Paris Web, durant laquelle Paul fait plein de démos sur des nouvelles technos présentes ou à venir dans Firefox, et ajoutant à un moment donné, "j'ai pas dit que ça servait à quelque chose", suivi d'un grand rire dans la salle. Oui, au visionnage des démos (genre une vidéo de Tristan Nitot tournant en rond), un utilisateur lambda, voire un développeur web, peut effectivement se demander l'intérêt de tel ou tel truc. Mais en y réfléchissant, ou quand il sera confronté à un besoin précis, peut être bien qu'il en trouvera.

Si d'ailleurs vous avez des idées de l'utilité de l'accéléromètre dans une appli web, signalez les à Paul ou ici dans les commentaires, cela lui permettra de faire des démos "plus utiles" du point de vue de l'utilisateur :-)

jeudi, octobre 8 2009

PHP n'est pas un bon langage de template

Ça me fait plaisir de lire ce genre de billet, surtout venant de la part d'une figure du monde PHP, à savoir Fabien Potencier (monsieur Symfony). Ça fait des années que je pense comme Fabien : PHP est un mauvais langage de template. Pas assez sécure (que fait-t-on des templates uploadés par des utilisateurs par exemple ?), trop verbeux, parfois trop complexe pour les intégrateurs web qui ne savent pas programmer, et n'impose pas une séparation entre logique métier et "vue" (vu que dans un template en PHP, on peut appeler tout et n'importe quoi).

C'est pourquoi j'ai toujours préfèré utiliser un langage qui soit conçu pour les templates, pour faciliter leurs écritures d'une part, et de bien faire une séparation entre la logique métier et la "vue". Et c'est pourquoi dans Jelix, j'ai crée mon propre moteur de template, ultra léger et performant, jTpl, qui est disponible en version standalone, dont je devrais sortir la version 1.0 dés que j'ai un peu de temps.

lundi, octobre 5 2009

De retour de Prague

Encore une fois, l'équipe de Mozilla Europe s'est démenée pour nous offrir un MozCamp de qualité. Organisation impeccable, lieu impeccable. Merci beaucoup William, Irina, et Paul (j'en n'oublie pas ?), j'ai vraiment apprécié ces trois jours !

J'ai trouvé les conférences intéressantes, et plus encore, la joie de retrouver d'autres contributeurs (plus de 140 !). C'est l'occasion de se voir "en vrai", de pouvoir discuter sur les projets actuels et futurs, et au passage de pratiquer un peu son anglais. Et bien sûr de passer de bons moment autour d'une de plusieurs bières Tchèques, que ce soit à 20-30 ou en petit comité tard le soir, pour discuter de Mozilla, de la life, 42. Quelques bons petits moments de distractions dans cette vie de fou :-). Ça recharge les batteries !

vendredi, septembre 25 2009

Fortune

Je ne peux m'empêcher de publier un extrait d'un message interne, véritable fortune d'auto-satisfaction de mon collègue Olivier[1], core-developer du browser de zoomorama, à propos donc de ce browser et d'une demo pour un client :

Mais quand même, je peux pas m'empêcher d'avoir une demi-molle :-): un putain de *browser* avec une putain d'implem DOM *from the ground-up*, du scripting hystéro-maniaque comme si les anglais avaient débarqués, de la stylesheet de motard poilu, du content delivering fondant sous la langue comme un clitoris de parturiente

Mais c'est vrai que c'est assez impressionnant ce qu'on arrive à faire. David et Olivier, vous déchirez :-)

Notes

[1] il est bien entendu d'accord pour la publication

Agenda d'octobre chargé

Que d'évènements en ce mois d'octobre à venir !

  • Du 2 au 4, je serais à Pragues, pour le MozCamp 2009
  • Le 8 et le 9, je serais aux conférences Paris Web. je crois qu'il reste encore des places, allez-y ! C'est un évènement à ne pas manquer pour les développeurs web, chefs de projets etc. Tous les ans, ce sont des conférences d'excellentes qualités, faites par des vrais professionnels du métier, et organisées par une équipe au top ! Le prix est ridicule (surtout pour une boîte), en regard des connaissances enrichies qui vous seront transmises.
  • Enfin, du 19 au 23, Fabien Cazenave (monsieur Kompozer) et moi allons dispenser des cours sur les technologies Mozilla, à l'université d'Evry. C'est le projet Comete. Une première en France :-)

mardi, septembre 22 2009

De la 3D dans Firefox

L'extension canvas 3D permet depuis 2 ans, d'utiliser l'element <canvas> pour faire de la 3D, en profitant de l'accélération matériel apportée par openGL.

S'en est suivi la naissance d'un groupe de travail en mars dernier, au Khronos Group, pour normaliser une API, appelée communément WebGL, dérivée d'OpenGL ES 2.0, qui sera adaptée aux application web. Mozilla et d'autres éditeurs participent à ce groupe.

En juin dernier, le code de l'extension Canvas 3D a été intégré dans le trunk de Mozilla, et ce n'est que depuis quelques jours que ce code a été activé par défaut dans les compilations nocturnes de Firefox (en l'occurence, cela sera disponible pour Firefox 3.7, il est trop tard pour Firefox 3.6 qui sortira d'ici la fin de l'année). Il y a eu aussi des changements dans l'API du contexte 3D de l'élement <canvas>, afin de coller au plus près aux derniers brouillons de WebGL.

Nous voilà donc avec des nightlies de Firefox permettant de faire de la 3D. Le développeur de canvas 3D, Vlad Vukićević, vient de publier une démo, qui permet de visualiser une creature en 3D.

J'ai fait un screencast de la demo executée avec une nightly de Firefox (fichier Ogg/Theora, et désolé, pas d'utilisation de la balise video dans ce billet, impossible de l'utiliser avec dotclear ! grrrrrr)

Mise à jour : deux nouvelles démos ! À voir ici et .

vendredi, septembre 11 2009

XRX, un doux rêve ?

Tangi vient de publier un billet très intéressant sur une nouvelle façon de faire une application web, une architecture XRX, qui utilise XForms, Rest, et XQuery. Vu de loin, ce triplet à l'air sexy, et fait renaître l'idée de faire du XML de bout en bout, sans avoir à taper une ligne de code "fonctionnelles". Et pour Tangui, cela apporte beaucoup de simplicité par rapport au triptique Javascript/PHP/MYSQL. Sur ce point, je ne suis pas d'accord avec lui.

Lire la suite...

mercredi, août 19 2009

Khromaxul 0.4 on the road

Dans la nouvelle version de ZoomCreator que nous sommes en train de réécrire, nous voulions ajouter de beaux colors pickers. Pour cela, j'ai trouvé Khromaxul, un ensemble de color pickers sous forme de composants XBL (avec du SVG), crée par Joliclic. La demo et les tests m'ont fait bonne impression, ainsi que le code en général.

Mais un souci s'est posé à l'intégration. Pour synchroniser les color pickers (mise à jour des pickers quand vous changez la couleur dans un), il faut se taper des tonnes de lignes de code javascript, avec des event listeners sur chacun des pickers. À cela il faut ajouter que chaque composant a sa propre API. Ainsi il y a des pickers pour les couleurs RGB, d'autres pour HSV etc. Et donc lors de cette synchronisation "à la main", il faut aussi se taper les conversions d'un format de couleur à un autre.

Bref, d'un point de vue du développeur, ce n'était pas très sexy à utiliser. J'ai donc décidé d'améliorer tout ça (vive les licences libres !). J'ai d'abord harcelé Joliclic pour qu'il crée un dépôt des sources quelque part, en lui proposant BitBucket. Vous pouvez ainsi accéder aux dernières modifications. Et voilà les améliorations principales que j'ai apporté :

  • uniformisation de l'API des pickers : ils héritent tous du même XBL de base que j'ai dévelopé, avec une propriété "color" contenant une chaine avec le code couleur en CSS (rgb, hsl, hexa...), et une propriété colorObject qui est un objet permettant de manipuler la couleur en question.
  • cet XBL de base intégre la communication avec un dispatcher. En fait, Joliclic a crée un broadcaster similaire au broadcaster XUL, mais spécialisé pour nos besoins. Ainsi, pour synchroniser les pickers, il suffit juste de créer une balise kh-colordispatcher, et d'indiquer son id dans un attribut "dispatcher" sur chacun des pickers. Plus une seule de code JS à écrire !
  • j'ai aussi ajouter support de la transparence dans les couleurs: rgba, hsla, hsva.
  • J'ai développé également un picker pour choisir la transparence, une colorbox affichant la transparence, un textbox pour saisir un code couleur etc....

Bref, la version 0.4 n'apportera pas de grande nouveauté pour l'utilisateur, mais un grand bouleversement pour le développeur désirant intégrer un ou plusieurs color pickers dans son application XUL.

vendredi, août 14 2009

De la bonne redaction des messages d'avertissements

J'ai eu un truc que je ne comprenais pas avec Mercurial. J'avais créé une branche nommée sur mon dépôt local, et fait des commits. Du coup, tout logiquement, j'avais deux "heads", une pour la branche nommée, et une autre pour la branche "default". Au moment de faire mon push, Mercurial a ralé, comme quoi ça allait créer des nouvelles têtes sur le dépôt distant, et me disait qu'il faudrait faire un merge avant de faire le push. Le problème, c'est que je ne veux pas fusionner les deux branches !

Du coup, j'ai eu un gros doute sur ma compréhension de ce qu'était un head, une branche nommée et à quoi ça servait. Mais j'avais beau lire la doc, il me semblait bien avoir compris tout ceci. Et ça ne m'avançait pas sur le pourquoi de l'erreur de Mercurial. Pourquoi fallait-il absolument faire un merge ? Pourquoi avoir un système de branches si c'est pour les fusionner systématiquement ?

Et puis j'ai expliqué mon problème sur le channel irc de Mercurial, et je fus plutôt rassuré. Ou presque. Parce qu'en fait, c'est moi qui n'ait pas tout à fait compris le sens du message d'erreur. Je l'ai trop pris au pied de la lettre. Ce n'est pas une erreur, mais un avertissement, et l'ordre qu'il faille fusionner, n'est pas un ordre, mais une simple proposition pour résoudre le problème (parmis d'autres non explicitées). Et on m'a expliqué qu'en fait, je devais forcer[1] le push avec l'option -f , et que dans les prochaines versions, le message sera plus explicite (pas seulement indiquer qu'il faut merger) ou n'apparaitra plus tout simplement (j'imagine, seulement dans les cas où il s'agit que de têtes de branches, et pas plusieurs têtes sur une même branche).

Bref, voilà mes doutes levés. Je peux continuer à travailler :-)

Notes

[1] ce qu'en fait j'hésitais à faire avant, parce que quand on force les choses, bien souvent ça apporte des ennuis

mardi, août 11 2009

Moment de faiblesse

J'ai ouvert un compte twitter. Pour rigoler. Ou pas.

Mise à jour: j'ai aussi ouvert un compte sur identi.ca

mercredi, août 5 2009

Jelix.org down

Bon, il suffit que je me déconnecte quelques jours pour que le serveur du projet Jelix décide de ne plus répondre. Malheureusement, je n'en sais pas plus pour le moment. J'ai contacté son propriétaire pour qu'il le redémarre, mais j'ai bien peur que lui aussi soit parti quelque part sous le soleil.

Désolé donc pour les utilisateurs de Jelix, il va falloir patienter quelques jours. Je retourne sur la plage.

C'est bête, j'avais quelques nouveautés intéressantes à "pusher" sur le dépôt Mercurial pendant ce brêve temps de connectivité :-)

jeudi, juillet 23 2009

Code Rush sous CC

Le documentaire qui raconte la naissance du projet Mozilla, Code Rush, est maintenant disponible sous licence CC, donc librement visualisable et redistribuable. Il est disponible sous différents formats. Une version numérique (certainement haute qualité) reproduite à partir des rushs originaux est en cours de montage.

Même si je n'ai pas vécu ces débuts (je n'ai commencé à m'intéresser au projet Mozilla qu'en 2002), ça me fait quelque chose de revoir[1] ce documentaire sur ce projet dans lequel je m'investis depuis 2003. Je considère cette naissance comme un grand moment historique en informatique (Netscape Navigator fut tout de même le premier logiciel propriétaire d'envergure à être libéré..).

via Tristan.

Notes

[1] je l'avais déjà vu

lundi, juillet 20 2009

En plein dans le Mercure

En ce moment, je m'amuse pas mal avec Mercurial.

Chez Zoomorama, parce que Subversion devenait limitant pour nous, nous avons décidé de migrer vers Mercurial. On a pas mal recherché et discuté des différents avantages et inconvénients entre git et mercurial, et hg nous semble plus approprié pour nos besoins.

  1. Mercurial nous semble plus propre d'un point de vue des commandes (Il n'y a pas 144 scripts différents avec des dépendances dans tout les sens comme dans Git) et il est presque aussi simple à utiliser que subversion. Cela nous fera gagner du temps pour s'approprier l'outil.
  2. Il y a une très bonne documentation (bien que celle de Git semble s'améliorer), entre autre ce guide
  3. Et surtout il a un bon support sur toutes les plateformes, ce qui est important pour nous puisqu'on fait, entre autres choses, des applis multi plateformes basées sur Mozilla.
  4. On utilise Gecko, en le modifiant, et Gecko étant sous Mercurial, ça ne nous fait pas apprendre un nième outils.

Au niveau fonctionnalités, Git et Mercurial se valent je trouve, surtout dans les fonctionnalités de base. Mercurial a beaucoup progressé et comblé son relatif retard ces derniers temps. Et vu qu'on ne va pas forcément utiliser les fonctionnalités super avancées de ces outils ce n'est pas sur ce point qu'on a pu les départager (quoique, j'apprecie beaucoup l'extension mq de Mercurial)... D'un point de vue performance, on n'a pas des projets de plusieurs dizaines de millions de lignes de code, aussi je ne pense pas que Mercurial va nous pénaliser (bien qu'il parait qu'il est plus lent que Git sur certaines opérations).

Le seul inconvénient qu'on lui trouve : le site officiel est moche par rapport à celui de git :-), mais heureusement, il y a un nouveau site plus propre : http://hg-scm.org/.

Un bon comparatif (sans troll et assez objectif je trouve) qui a fini par nous convaincre : Git vs Mercurial.

Et puis, du coté de mes projets perso, je suis en train aussi de passer aussi à Mercurial. Pour Jelix, je viens de monter http://hg.jelix.org. Je dois encore configurer les droits d'accés pour le push via ssh (c'est moins classe à configurer que pour subversion [1]) et quelques autres broutilles (comme modifier les cron des builders de nightlies). Je vais enfin pouvoir commiter dans le train !

À propos de gestionnaire de sources, le projet PHP vient de changer lui aussi de système. Ils ont enfin délaissé CVS pour utiliser Subversion. Je m'étonne toutefois qu'ils ne se soient pas orienté vers Git, Mercurial ou un autre système décentralisé. Surtout que je n'arrive pas à mettre la main sur leurs arguments en faveur de Subversion par rapport à Git/Mercurial.

Notes

[1] en fait non, une fois compris le truc, c'est bien plus puissant, en utilisant http://hg.opensource.lshift.net/mercurial-server/ et je viens de terminer sa configuration :-)

vendredi, juillet 17 2009

Transformations 2D et 3D en CSS

Ainsi donc, webkit supporte maintenant les transformations 3D en CSS. Je trouve ça génial. J'apprécie déjà les transformations 2D (que j'utilise sur la page d'accueil de jelix.org). Mais là, ça ouvre encore plus de perspectives (c'est le cas de le dire ;-)).

Seulement, à travers les demos que j'ai ouvert dans mon Firefox (qui ne supporte pas les propriétés transform3D), j'ai remarqué que l'utilisation de ces transformations avaient un écueil : ça se dégrade très mal dans les navigateurs ne supportant pas ces propriétés. Du genre, les éléments s'affichent les uns sur les autres. Il y a certainement des améliorations possibles dans ces démos pour que ça se dégrade un peu mieux. Mais c'est certain qu'il va falloir faire attention...

Pour les plus curieux d'entre vous, les brouillons des spécifications sont disponibles sur le site du W3C : CSS3 3D transforms, CSS3 3D transforms.

jeudi, juillet 2 2009

Theora, après Firefox et Chrome : Opera

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

mardi, juin 30 2009

Sorties majeures aujourd'hui

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.

dimanche, juin 28 2009

De la 3D dans Firefox

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

vendredi, juin 26 2009

Chantiers: XBL2 et multi processes

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.

- page 2 de 44 -