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.

Continuer la lecture de « Lequel est le plus rapide pour Javascript ? Webkit, Opera ou Gecko ? »

Un aperçu de Lightning sous Shredder pré-béta1

Shredder est le nom de code de Mozilla Thunderbird 3.0. Ce point étant éclairci, en suivant les informations de compilations, j’ai rajouté l’option ac_add_options –enable-calendar pour avoir le module lightning en plus du support du courrier et des forums.

Je n’ai pas encore explorer toutes les possibilités de cet agenda, m’étant contenté pour le moment d’un simple ajout de notes et de pense-bêtes. Cependant, l’intégration est agréable à voir. En tout cas, cela sent très bon pour le futur Mozilla Sunbird 0.9 qui sortira d’ici quelques temps.

Un aperçu général de l’interface avec Lightning activé :

L'interface générale avec Lightning

Une vue de l’agenda :

L'agenda géré sous Lightning

Bien entendu, c’est loin de pouvoir rivaliser avec un logiciel comme Evolution, mais cela fait plaisir d’avoir le choix de son logiciel d’agenda électronique 😉

Le retour d’un serpent de mer : QT avec Mozilla ;)

Sous linux et autres unix, Firefox utilise le toolkit GTK. Or à une époque reculée, un port pour QT pour la suite Mozilla avait été commencé, puis abandonné. cf le bogue 178987.

Or, en lisant OSNews, j’ai pu lire que le port était de nouveau en vie. Le wiki de Mozilla propose des infos pour compiler cette version. Cependant, j’ai préféré prendre une version déjà précompilée, en l’utilisant sous une Fedora 10 alpha 32 bits avec KDE 4.1. Gain de temps ? Une bonne heure 🙂

La version proposée semble être basée sur du code compilé le 4 août 2008.

Voici donc le résultat avec Acid3 et Google :

Acid3 sous Shiretoko en version QT

Google sous Shiretoko en version QT
Pour la petite histoire, peu après la libération du code source de mozilla fin mars 1998, le premier port fut effectué sous QT par Trolltech.

http://trolltech.com/company/newsroom/announcements/00000007

Le bogue qui permet de suivre l’évolution du port est le 448989. Donc si vous êtes intéressé par l’intégration de QT, c’est le bogue à suivre.

Vladimir Vukićević explique le pourquoi du comment de ce port.

Bref, c’est une bonne nouvelle pour les utilisateurs de KDE 4.x qui auront désormais un look natif pour les widgets, du moins quand Shiretoko sortira 🙂

Des nouvelles de Shiretoko pré-alpha2 ?

Après la sortie la semaine dernière de Shiretoko Alpha1 – et alors que le tronc est étiquetté 3.1a2pre, donc ce qui laisse supposer la sortie d’une version alpha 2, on peut faire un petit bilan rapide de ce qui attend la prochaine étape de développement, même si l’ajout des fonctionnalités est loin d’être terminé.

Un meilleur score encore au test acid3 : 85 / 100. Sûrement grace au bogue 199959

acid 3 : 85 / 100 avec Shiretoko pré-alpha2

2) Un support préliminaire croissant des balises <video> et <audio> au moins pour un premier temps pour la version linux du navigateur.

Cf l’ajout des bibliothèques ogg et theora, le bogue concerné étant 422538 – . Le support de l’ajout des balises <video> et <audio> étant le bogue 382267.

Cet ajout de fonctionnalités nécessite l’ajout de la bibliothèque libasound2-dev (libalsa) sous les distributions à la débian.

La « tuyauterie » en version gstreamer : bogue 422540 ; en version quicktime (MacOS-X) : et pour MS-Windows : 435339

Pour des exemples de vidéo utilisant l’élément HTML5 <video> : http://www.double.co.nz/video_test/

Balise <video> en action dans Shiretoko pré-alpha2

Vers un coeur commun entre Shiretoko, Shredder et SeaMonkey 2 ?

C’est une idée envisageable, étant donné que le dépot du code source de Shredder et de SeaMonkey pré-2.0 viennent de migrer, abandonnant le vieux dépot CVS vers un dépot mercurial.

Si l’on veut compiler soit-même le code source dit du « tronc » des logiciels de la Fondation Mozilla, que ce soit Shiretoko, Shredder ou SeaMonkey pré-2.0, il faut maintenant passer par des dépots mercurial.

Si le développement de Shiretoko est maintenant bien ancré sur un dépot mercurial, à savoir mozilla-central, c’est loin d’être le cas pour Shredder et SeaMonkey pré-2.0. Voici donc comment compiler Shredder ou SeaMonkey en utilisant le dépôt mercurial comm-central.

Déjà, il faut avoir autoconf 2.13 et mercurial pré-installé. Pour cela, il faut se conférer à la documentation de votre distribution pour savoir comment faire.

Ensuite, il faut récupérer le code source commun à Shredder et SeaMonkey pré-2.0 :

hg clone http://hg.mozilla.org/comm-central/ src

Une fois le code récupéré, il faut récupérer le complément à savoir le code en commun avec Shiretoko :

python client.py checkout

Pour cette partie, l’outil CVS configuré correctement est indispensable. En clair, il faut que la variable CVSROOT soit définie ainsi :

export CVSROOT= »:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot »

Vient le moment stratégique, préparer le .mozconfig pour les options de compilation. Il faut ajouter les deux lignes suivantes :

ac_add_options --enable-application=mail
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb

Et virer un . $topsrcdir/mail/config/mozconfig qui aurait pu s’y trouver si on récupère un vieux fichier .mozconfig

Voici pour information mon .mozconfig pour Shredder :

#
# See http://www.mozilla.org/build/ for build instructions.
#

ac_add_options –enable-application=mail
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb

# Options for ‘configure’ (same as command-line options).
ac_add_options –enable-optimize= »-Os -march=native -w -pipe »
ac_add_options –disable-debug
ac_add_options –disable-tests
ac_add_options –enable-default-toolkit=cairo-gtk2
ac_add_options –enable-static
ac_add_options –disable-shared

Ensuite, il suffit de lancer la compilation et d’attendre.

Et voici ce que donne une boite « about » d’un Shredder compilé avec le code source du dépôt mercurial comm-central.

Shredder pré-alpha2 ?

Les pages qui m’ont aidé pour rédiger cet article :

http://wiki.mozilla.org/SeaMonkey:hg-based_build
http://developer.mozilla.org/en/docs/Mozilla_Source_Code_(Mercurial)
http://developer.mozilla.org/en/docs/Comm-central_source_code_(Mercurial)
http://developer.mozilla.org/en/docs/comm-central

Quoi de neuf avec Shiretoko Alpha 1 ?

Si on en croit ce bilan hebdomadaire de la Fondation Mozilla reproduit sur le blog « Firefox Extension Guru’s Blog« , Shiretoko alpha 1 devrait sortir le 25 juillet prochain, le code ayant été gelé à 23 h 59, heure du Pacifique, soit Paris – 9 heures.

Qu’y aura-t-il dedans, sauf changement de dernière minute ?

84 / 100 pour le test Acid3 sous Shiretoko alpha1

Bref, que du bon, et encore du meilleur à venir. Enfin, on verra bien ce que cela donnera lors de la sortie de la version finale, prévue pour fin 2008, début 2009.

Sortie de Firefox 3.0.1

Lu sur le blog Mozilla Developper News, la première mise à jour de Firefox 3, la version 3.0.1 vient de sortir, un mois jour pour jour après la sortie de la version 3.0.

Au menu des nouveautés ?

Pour les mises à jour : si vous utilisez Windows ou MacOS-X, suffit de demander la recherche de mises à jour. Pour Linux, il suffit d’attendre que votre distribution vous propose la mise à jour.

Firefox se « bling-bling »iserait-il ?

On peut le penser, surtout avec l’arrivée d’un correctif pour le bogue 395980, qui introduit via le raccourci touche control + tabulation l’aperçu des onglets sans avoir besoin de changer de page.

Ce correctif ne concerne que la version de développement de Firefox 3.1, alias Shiretoko qui est prévu pour fin 2008, début 2009.

Une petite vidéo faite sur mon PC il y a quelques minutes explique mieux le principe.

Utile ? Peut-être pas outre mesure au premier abord. Bling bling ? Sûrement 😉

Les aléas du dépot « proposed ».

Si utiliser le dépot « proposed » d’une distribution Ubuntu Linux est souvent intéressant, il y a parfois quelques effets de bords qui sont plus ou moins génants.

Si, en gros, 99% du temps, une mise à jour ne pose quasiment aucun problème, le dernier pourcent restant peut être ennuyeux, pour ne pas dire qu’il facilite franchement le transit intestinal.

Ce matin, les dépots proposed ont installés une mise à jour 3.0.1 pour un certain Firefox 3, ce qui :

  1. Laisse penser que Firefox 3.0.1 ne va pas tarder
  2. Que les équipes de veille d’Ubuntu Linux ont vraiment l’oeil à tout

Voici ce que l’on pouvait voir :

Firefox 3.0.1 dans Hardy Proposed

Bref, une mise à jour classique. Classique, pas franchement. Car désormais, les extensions sont vérifiées à chaque démarrage – en mode silencieux. Et manque de pot, les traductions ne sont pas « compatibles ». Voici le message d’erreur qu’on peut avoir :

Extensions incompatibles ?!

Moralité ? Le firefox disponible démarre alors en anglais. Voir le bogue 247494 en ce qui concerne le problème. Cela ne me dérange pas outre mesure, n’utilisant pas la version 3.0, et encore moins la traduction française qui souffre – selon moi – d’une mauvaise traduction du terme « bookmarks » en marque-pages alors que le terme de signets était utilisé auparavant.

Bref, il faudra attendre une mise à jour du paquet language-pack-gnome-fr-base qui contient les fichiers de traduction de Firefox et du xulrunner désactivé par sécurité. Quelques jours d’attente, donc, pas de quoi casser 3 pattes à un canard 😉