Archives du mot-clé shiretoko

Shiretoko : le « bling bling » arrive.

Dans un billet de juillet 2008, j’avais proposé une vidéo pour montrer la fonction d’aperçu des onglets. Depuis quelques jours, les versions de développements de Shiretoko propose un bouton « List all tabs » à droite du bouton « nouvel onglet », qui permet d’avoir un aperçu visuel des onglets déjà ouverts.

Fonctionnalité également disponible avec le raccourci ctrl + touche de tabulation. Et voici un aperçu du résultat :

Nouvelle version de l'aperçu d'onglets dans Shiretoko

Et de 93 / 100 à Acid3 pour la pré-bêta 2 de Shiretoko…

Décidement, le test Acid3 est de plus en plus supporté par Shiretoko. Avec la fermeture du bogue 302775, il ne reste plus que 7 petits points à récolter…

93 / 100 au test Acid3 pour Shiretoko pré-bêta2

Le test sera-t-il complètement passé avec la version finale de Shiretoko ? Cela serait étonnant, au moins, on ne pourra pas dire qu’entre Mozilla Firefox 3.0 et son successeur Shiretoko, les modifications se seront limitées à la façade…

Et dire qu’il y a moins de 72 heures, j’annonçais 90 / 100 comme niveau de passage du test Acid3

Sortie de Shiretoko Beta 1 et de Shredder Alpha3

En clair ? Deux versions de développement de logiciels libre majeurs issus ou dérivés de la Fondation Mozilla viennent de pointer le bout de leur octets.

Pour Shiretoko bêta 1, les notes de publications nous annoncent que :

  • Le support des propriétés CSS 2 & 3 sont améliorés.
  • La barre d’adresse intelligente peut être utilisé avec des caractères spéciaux pour modifier la recherche, et non une bête liste comme auparavant.
  • Le raccourci ctrl + tab sur une série d’onglets propose un aperçu visuel.
  • Ajout des balises <audio> et <video>, de la géolocalisation selon les normes W3C, des améliorations au niveau du support SVG, du javascript.
  • Le moteur Javascript amélioré « TraceMonkey » est ajouté, mais non activé par défaut.

Un billet en anglais montre les nouveautés visuelles difficile à expliquer autrement :/

Pour Shredder Alpha 3, les notes de publications nous apprennent :

  • Amélioration de l’interface de lecture des messages.
  • Ajout / édition des contacts directement dans la section d’en-tête des messages.
  • Intégration dans la fonction de recherche de Windows Vista.
  • Ajout d’un champ « anniversaire » dans la fiche des contacts

En plus de cela, il ne faut pas oublier le travail d’intégration de l’agenda qui a commencé, comme abordé dans un précédent message.

Prochaines étapes : une version bêta 2 pour Shiretoko d’ici la fin du mois prochain, la première version bêta pour Shredder étant prévue pour un peu plus tard, étant donné qu’il dépend du travail effectué sur le moteur de rendu Gecko 1.9.1, coeur de Shiretoko.

Et de 90 pour le test Acid3 pour le futur Mozilla Firefox 3.1

Avec la fermeture du bogue 454325, le score atteint par une version de développement de la bêta2 de Shiretoko (qui est prévue pour novembre prochain) est de 90 points. Soit 19 points de plus que la dernière version stable en date, Mozilla Firefox 3.0.3.

Acid3 à 90/100 pour Minefield

Maintenant, reste à savoir si le score obtenu sans l’activation de la technologie SMIL, à savoir 94 / 100 sera disponible pour Mozilla Firefox 3.1 dont on peut estimer la sortie pour début 2009.

Seul l’avenir nous le dira ;)

Le retour (?) du bouton « nouvel onglet » dans la barre d’onglets de Mozilla Firefox ?

Avec le bogue 455756, le bouton « nouvel onglet fait son arrivée (ou son retour, car j’avoue avoir un léger doute) à droite de la fenêtre principale.

Une image valant 1000 mots :

Le bouton "nouvel onglet" dans Shiretoko pre-beta1

Maintenant, reste à savoir si le bouton sera conservé ou pas dans la version finale de Shiretoko.

Les options d’optimisation agressives sont-elles inutiles ?

Dans une page de leur wiki les développeurs de Mozilla Firefox et des outils associés déclarent, je cite :

For Firefox 3 builds, please use –enable-optimize without flags.

Our testing has shown that different parts of Mozilla run faster at different optimization levels. For example, cairo, pixman and sqlite are compiled at -O2 because they are fastest at that level while the JS engine is fastest at -Os. [3] Don’t use –enable-optimize as a place to pass in random compile flags. That’s a global setting that sets optimization levels throughout the source tree and is different depending on the module being compiled.

If you still need to pass in other non-optimization flags to the compile, please use CFLAGS and CXXFLAGS instead of passing them to –enable-optimize.

Ce qui donne traduit :

Pour la compilation de Firefox 3, veuillez utiliser –enable-optimize sans options.

Nos tests nous ont montrés que les différentes parties de Mozilla sont plus rapides à différents niveaux d’optimisation. Par exemple, cairo, pixman et sqlite sont compilé en -O2 car ils sont plus rapide à ce niveau tandis que le moteur JS est plus rapide avec -Os. N’utilisez pas –enable-optimize comme un endroit pour insérer des options de compilations divers. C’est un réglage global qui définit les niveaux d’optimisation tout au long du code source et il diffère en fonction du module qui est compilé.

Si vous avez toujours besoin de passer des options de non optimisation au moment de la compilation, veuillez utiliser CFLAGS et CXXFLAGS au lieu d’utiliser la ligne –enable-optimize.

Lire la suite

Concours de vitesse en javascript…

Dans un précédent billet, je parlais de l’impact de TraceMonkey sur les tests concernant la vitesse d’exécution de Javascript. J’ai donc voulu tester les performances de Firefox 3.0.1, Shiretoko pré-bêta1, Opera 9.60 bêta et du dernier Webkit en date sur les tests proposés par Google pour le moteur de javascript V8 qui équipe Google Chrome.

La lecture du résultat est simple. Avoir 100 comme score est la base. Plus le score est important, mieux c’est.

Lire la suite

Et SeaMonkey 2.0 dans tout cela ?

Alors que Shiretoko alpha2 vient juste de sortir (), j’ai envie de parler d’un certain SeaMonkey 2.0, qui se basera sur un Gecko 1.9.1 final (base de Firefox 3.1 alias Shiretoko).

Un bogue intéressant, c’est le bogue 394522 : « Migrate SeaMonkey preferences panes to use <preferences> »

En clair, c’est une volonté d’utiliser les outils du toolkit de Mozilla Firefox et de laisser tomber lentement mais surement le vieux code XPFE qui commence à prendre la poussière.

En effet, si on ouvre les préférences d’un SeaMonkey (version de développement) récente, on s’aperçoit d’un message, qui annonce que la migration est en route.

Le panneau des préférences en cours de migration

En ce qui concerne l’abandon du code XPFE dans SeaMonkey, le code a connu une purge dans ce domaine depuis quelques temps. Cf les bogues 380786 et 386906.

D’ailleurs l’alpha1 de SeaMonkey 2 ne saurait tarder, le code devant être gelé aux alentours du 9 septembre.

Ce sera une bonne nouvelle pour les fans du successeur de la suite Mozilla dont les buts sont précisés sur cette page.

Vrac’ons rapidement.

Un petit vrac rapide, sur le pouce.

C’est tout pour aujourd’hui.

Au moins, sauf contre ordre, pas de Shiretoko Alpha 3 ;)

Selon ce compte rendu de la Fondation Mozilla, le code de la version béta1 de Firefox 3.1 (connu sous le nom de code Shiretoko) est prévu pour être gelé le 9 septembre prochain. En ce qui concerne la version alpha2, selon ce billet du Firefox Extension Guru’s Blog, la sortie de la version alpha2 est prévue pour le 11 septembre.

En tout cas, il est certain d’une chose : il n’y aura pas d’alpha3. J’utilise une version de développement officielle pour rédiger ce billet, comme le prouve la capture d’écran :

Une préversion béta1 de Shiretoko sous Ubuntu Linux

Voir le bogue 452778 pour suivre la sortie de la version alpha2.

Tracemonkey has landed.

Derrière ce détournement d’une phrase célèbre prononcée en 1969 – wikipedia est votre ami – le compilateur JIT pour le module javascript que j’évoquais hier vient d’arriver sur le code de développement du tronc de Shiretoko, dont la version alpha2 est prévue pour bientôt.

En effet, ce matin, réveillé à 4 h 30 par mon chiot labrador de 9 mois, j’ai allumé l’ordinateur tout en sirotant mon thé. Et après le duo habituel hg --verbose pull ; hg --verbose update pour mettre à jour le code source, j’ai pu lire ceci :


pulling from http://hg.mozilla.org/mozilla-central/
searching for changes
adding changesets
adding manifests
adding file changes
added 1167 changesets with 2340 changes to 146 files

Quoique l’arrivée du code n’est pas encore super bonne. Après une tentative de compilation avortée, j’ai viré le répertoire de compilation, et relancé la dite compilation. Mais il semble y avoir un léger problème au niveau du fichier libxul.so… :(


../../staticlib/components/libgklayout.a(nsCanvasRenderingContext2D.o): In function `nsCanvasRenderingContext2D::PutImageData()':
nsCanvasRenderingContext2D.cpp:(.text+0x4165): undefined reference to `js_ArrayToJSUint8Buffer'
/usr/bin/ld: ../../staticlib/components/libgklayout.a(nsCanvasRenderingContext2D.o): relocation R_X86_64_PC32 against `js_ArrayToJSUint8Buffer' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld a retourné 1 code d'état d'exécution
make[4]: *** [libxul.so] Erreur 1
make[4]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx/toolkit/library »
make[3]: *** [libs_tier_toolkit] Erreur 2
make[3]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx »
make[2]: *** [tier_toolkit] Erreur 2
make[2]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx »
make[1]: *** [default] Erreur 2
make[1]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx »
make: *** [build] Erreur 2

Bref, c’est pas encore cela… Je sens que je vais ouvrir un petit bogue malgré la tentative pour que la compilation se fasse en code 64 bits, si j’en crois cette révision rajoutée récemment


author David Anderson
Thu Aug 21 18:07:26 2008 -0700 (at Thu Aug 21 18:07:26 2008 -0700)
changeset 18331 7098e0020929
parent 18330 91fe6b5784bd
Fixed x86_64 build issue (accidentally trying to build 32-bit nanojit).

J’ai rapporté le bogue 451669. On verra bien ;)

Euh, après une petite recherche, il semblerait que le bogue 451242 soit responsable ici… Oups ;)

Quoi de neuf dans le petit monde des navigateurs internet ?

Un petit bilan en ce mois d’août sur les navigateurs internet.

Voila, c’est tout pour aujourd’hui ;)

Shiretoko : le port pour QT est fusionné.

Il y a une dizaine de jours, je vous parlais du retour du support du toolkit QT pour le code de développement de Shiretoko.

C’est maintenant officiel. Le bogue 448989 vient d’être fermé comme corrigé. Le titre est assez clair :

Merge mozilla-qt branch into mozilla-central ce qui donne traduit : « Fusionner la branche mozilla-qt dans mozilla-central ».

Désormais, il sera possible – même si le port est assez brut de décoffrage de compiler le code source en utilisant le toolkit Qt à la place du toolkit GTK.

Une bonne nouvelle pour les personnes qui ne jurent que par KDE et qui trouve konqueror un peu trop limité par rapport à Gecko ou Webkit.

Lequel est le plus rapide pour Javascript ? Webkit, Opera ou Gecko ?

Pour le savoir, il faut utiliser deux tests complémentaires : le test du site CelticKane et le test « SunSpider« .

Les versions testées sont :

  • une compilation nocturne de Shiretoko pré-alpha2 de ce 13 août matin => Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1a2pre) Gecko/20080813050659 Minefield/3.1a2pre
  • Une préversion d’Opera 9.52, cf ce billet du blog des développeurs d’Opera.
  • Webkit révision 35706, compilée ce matin, pour contourner le bogue 20370 qui rendait impossible la compilation de la version gtk.

Lire la suite