Mozillazine-Fr nous annonce qu'une société (Dynalivery) développerait une version du moteur de rendu Gecko en mode serveur.

L'objectif de la société est "d'étendre le champ d'application du XHTML" et c'est ainsi qu'il nous présente un première version de leur produit.

Cette version du moteur est vouée à être intégrée dans un serveur d'impression capable de transformer n'importe quelle ressource Web (au format XHTML) vers une sortie papier classique et/ou dans un autre format tels le PDF, le SVG pour n'en citer que deux.

Le produit est déjà parfaitement utilisable et preuve en est faite sur le site de démonstration de la société Dynalivery.

À tester d'urgence !

Ceux qui lisent les listes de la communauté Perl auront peut-être remarqué la mention d'un site venant d'ouvrir dans le style de CPAN : JSAN, JavaScript Archive Network. Ce site a pour objectif de rendre le même service à la communauté des développeurs Web que CPAN à celles des développeurs Perl.

CPAN est le Comprehensive Perl Archive Network, une grande collection de code source et de documentation dédiée au langage Perl.

JSAN est encore un peu dépeuplé, mais CPAN ne s'est pas construit en un jour. Gageons que le nombre de développeurs Javascript publiant leurs scripts ailleurs voudront ajouter à leur crédibilité en s'appuyant sur l'infrastructure de qualité mise en oeuvre pour JSAN.

Ça ajoutera aussi un peu plus de considération à ce langage mal aimé du Web (sauf depuis la sortie médiatique d'AJAX) qui a des choses à nous montrer.

La société Norvégienne Trolltech vient de sortir aujourd'hui la version finale de la bibliothèque graphique Qt4. Cette bibliothèque est notamment à la base de l'environnement de bureau KDE. Elle est disponible sous double licence GPL et QPL sous les environnements X11, MacOS et pour la première fois Windows

Les principales fonctionnalités de cette version sont :

• Tulip, un ensemble de conteneurs plus rapide
• Arthur, le moteur de dessin gérant le Postscript, OpenGL et SVG
• Scribe, une API de rendu de texte supportant l'unicode
• Interview, un nouveau contrôleur Modèle/Vue
• Mainwindow, un système moderne de création des fenêtres d'application.

De plus, le support des threads, des bases de données, du réseau ont été largement améliorés. Le nouveau QtDesigner supporte désormais les applications MDI et SDI (Multi/Single Document Interface).

NdM : Merci à oliv d'avoir également soumis cette dépêche.

Depuis quelques semaines, Ruby on Rails permet de développer des applications web avec Ajax.

Ruby est un langage de script (comme Perl ou Python), totalement orienté objet, avec une syntaxe très propre qui la programmation élégante et amusante.

Ruby on Rails est un framework de développement d'applications Web en Ruby, utilisant le modèle MVC. Oui, c'est vrai, il en existe déjà des dizaines. Mais grâce (entre autres) à son utilisation de Ruby, Rails permet de développer des applications Web jusqu'à 10 fois plus vite qu'avec d'autres frameworks (NdM. : ce type d'information est évidemment à prendre avec toutes la réserve nécessaire), avec un code bien plus concis. Ruby on Rails a provoqué ces derniers mois un petit ras de marée dans le monde des développeurs d'applications web, en remettant en cause le classique couple PHP/MySQL. D'autant plus que le support d'Ajax vient de lui être ajouté.

Ajax (Asynchronous Javascript and XML) est une vieille technologie : son composant de base, XMLHttpRequest, existe depuis 1998 et est utilisé un peu secrètement par de nombreux sites. Il permet de mettre à jour une page web sans avoir à recharger l'ensemble de la page (pour un petit exemple, postez un commentaire sur ce blog, c'est fait pour). Démocratisé par Google ces derniers temps (essayez par exemple de chercher quelque chose sur Google Suggest), son utilisation reste difficile, car il faut écrire du code compatible avec les différents navigateurs.

C'est là que Ruby on Rails montre tout son intérêt. Après avoir permis de développer des applications Web complexes sans écrire une ligne de SQL, Ruby on Rails permet de développer des applications Ajax en quelques minutes sans écrire une ligne de Javascript. Même si Ajax n'est pas la solution ultime, il permet de rendre des applications Web bien plus interactives et agréables pour les utilisateurs. Pas convaincu ? Essayez d'uploader un fichier sur cette page et admirez la barre de progression.

Pourra-t'on encore lire et écrire sur un support physique soit des données en format XML soit des pages web (quand il y a des scripts) sans enfreindre de brevet logiciel ? Telle est la question que l'on peut se poser en lisant que Microsoft a déposé deux brevets amusants :
1) le premier concerne la «sérialisation» de plusieurs scripts dans un format unifié (ce qui ressemblerait furieusement à la description d'un format générique XML)
2) le deuxième concerne la sérialisation de données en format XML

Pour les profanes, sauver un document openOffice revient à sérialiser une structure de donnée en mémoire dans un fichier XML :), et inclure des macros dans le même documents ainsi que sauver sur un disque une page web qui inclut des appels à plusieurs scripts en javascript et/ou perlscript, et/ou vbscript ou autre revient à faire ce qui est couvert par le premier brevet.

Le début de l'affaire du pilote pwc remonte à août 2004. Jusqu'à cette époque, la partie libre de ce pilote pour webcams basés sur des chipsets Philips était disponible dans la version officielle du noyau Linux. Toutefois, ce pilote ne permettait de gérer que les modes de basse qualité des webcams, un module supplémentaire propriétaire, pwcx, étant nécessaire pour accéder aux modes évolués qui nécessitaient des routines de décompression.

En août 2004, un différent opposa les développeurs du noyau Linux au développeur du pilote. En effet, le module libre mettait en place un hook spécifique dans le noyau permettant au module non-libre de mettre à disposition ses fonctionnalités avancées de décompression. Or, les développeurs noyau, et en particulier Linus Torvalds, ne souhaitaient pas mettre à disposition un hook particulier pour les besoins d'un module propriétaire : "if a change is needed to be made to the kernel in order to get a closed source module to work, that module must be made opensource".

L'auteur du pilote a alors fait savoir que ce hook existait depuis longtemps et qu'il ne comprenait pas cette décision. Au final, la discussion a amené l'auteur à demander le retrait du pilote.

Le noyau Linux ne disposait alors plus de pilote pour les webcams à base de composants Philips, pourtant très répandues. Heureusement, un français, Luc Saillard, a repris le développement de ce dernier. À la mi-septembre 2004, il envoie un patch contenant une nouvelle version du pilote, entièrement libre, et permettant d'utiliser certains modes de décompression qui n'étaient auparavant utilisables qu'avec le module propriétaire, grâce à de l'ingénierie inverse. Tout semblait donc s'arranger.

Mais, tout récemment, nouveau coup de théâtre : le développeur originel du pilote demande de nouveau le retrait de ce dernier, arguant du fait que le pilote de Luc Saillard aurait été réalisé plus par décompilation du pilote propriétaire que par ingénierie inverse. Après une investigation plus poussée, Alan Cox a trouvé que les remarques de l'auteur originel étaient recevables. Il a par ailleurs eu une discussion amicale avec Philips qui a abouti au retrait du code litigieux des décompresseurs.

À ce jour, le noyau Linux supporte donc toujours les webcams à base de composants Philips, mais uniquement dans les modes basiques. Toutefois, ce rebondissement n'est certainement pas le dernier dans cette saga, et l'espoir de disposer un jour d'un pilote complètement libre et dégagé de tout problème reste présent.

Après plus de 6 mois de développement, une nouvelle version de Qemu est sortie fin avril. Qemu est un émulateur fonctionnant dans deux modes différents. Le premier mode permet d'émuler une architecture matérielle complète : le processeur ainsi que les périphériques matériels comme les disques, les cartes réseau, les ports séries, etc. Ce mode permet d'exécuter un système d'exploitation complet, et se rapproche de ce que permet l'émulateur Bochs. Le second mode, fonctionnant sous GNU/Linux uniquement permet d'exécuter des binaires prévus pour une architecture donnée sur une autre architecture : l'émulation n'a lieu que pour un processus particulier.

Le premier mode permettant d'exécuter un système d'exploitation complet, il est parfait pour tester de nouveaux systèmes, réaliser le débogage de modules noyau ou simuler des réseaux composés de machines virtuelles. Le second mode permet par exemple aux possesseurs d'architectures non-x86 d'exécuter des applications propriétaires compilés pour x86 lorsque cela est nécessaire.

Qemu étant indépendant du processeur émulé, il supporte l'émulation de différentes plateformes. L'émulation des processeurs x86 et PPC est complète, et l'émulation des processeurs x86_64, ARM ou SPARC sont à des états plus ou moins avancés. D'autre part, Qemu utilise une technique de traduction dynamique, qui consiste à transformer le code binaire de l'architecture cible en code binaire pour l'architecture hôte. Cette traduction étant effectuée une fois pour toutes pour chaque partie de code, la vitesse d'émulation est grandement améliorée par rapport à un émulateur classique comme Bochs.

Par ailleurs, la version 0.7.0 permet d'utiliser un module noyau, kqemu qui permet d'accélérer encore plus l'émulation, en permettant l'exécution de parties du code directement sur le processeur. Ce module ne fonctionne que si l'on émule un PC sur un PC et est livré sous licence propriétaire. Son auteur, Fabrice Bellard, qui est aussi le développeur principal de Qemu, recherche en effet un sponsor pour le développement de Qemu et kqemu. L'utilisation de cette licence propriétaire a provoqué de vives discussions sur la liste, certains défendant le bien-fondé de la démarche du développeur, d'autres la rejetant. Parallèlement, Paul Brooks a créé un projet expérimental pour développer un module aux fonctionnalités similaires à kqemu, mais distribué sous licence GPL: qvm86.

En dehors de ce support de kqemu, la version 0.7.0 apporte quelques nouveautés ou améliorations comme le support initial de l'architecture x86_64, une amélioration du support SPARC qui permet maintenant de démarrer Linux, le support de l'émulation du port parallèle, des instructions MMX, SSE, SSE2 et PNI, l'amélioration du support ARM, et l'intégration d'un code émulant une unité de calcul en virgule flottante.

Libpoppler est une bibliothèque qui a une API GObject, le modèle objet C de la Glib utilisé dans GNOME. Un binding Python pour cette bibliothèque vient d'être réalisé.

La particularité de ce binding est qu'il a été généré automatiquement en introspectant le code C. C'est une étape importante dans le travail d'introspection de Glib, et qui devrait permettre de donner à de nombreux langages l'accès complet aux API GNOME.

NdM : Un binding permet de programmer dans un langage en se servant d'une bibliothèque écrite dans un autre langage.

Le NILS (National Information and Library Service) a développé un outil d'analyse des contrastes de couleurs [Colour Contrast Analyser (CCA)]. Ce logiciel sert à éprouver l'accessibilité de son site du point de vue de l'acuité visuelle. C'est un outil très simple d'utilisation et qui permet d'apporter un plus en terme d'accessibilité, non seulement pour un projet web, mais également pour tout projet graphique.

Actuellement, seul une version pour Windows de ce logiciel existe. Le NILS recherche des développeurs pour porter ce logiciel sous GNU/Linux.

Anjuta est un environnement de développement intégré (IDE) C/C++ pour GNOME, disposant de nombreuses fonctionnalités: gestion de projet, assistants, outils de debogage, support cvs, exploration de symboles...
Son éditeur de code source, reposant sur Scintilla, comprend coloration syntaxique, autocompletion, etc.

La version 2.0 est la première de la série 2.0.x, nouvelle branche dont l'architecture a été totalement revue pour séparer le code en librairies (libanjuta, GDL, Gnome-build) et offrir aux développeurs de plugins de nouvelles possibilités.

La dernière version stable de anjuta était la 1.2.2, sortie en avril 2004. Cette version est pour le moment considérée comme non stable, mais les développeurs insistent sur la nécessité de la tester et de reporter les bugs. Par ailleurs, elle peut fonctionner en parallèle de la version 1.x, à condition d'utiliser un préfixe différent pour l'installation.

Enfin, on peut noter la sortie simultanée de la version 1.2.3, qui contient uniquement des corrections de bogues pour la "vieille" branche 1.x.

Dans un e-mail au mainteneur de moteur de rendu KHTML, le développeur principal du service navigateur d'Apple suggère l'abandon du code de KHTML ou la branche KHTML au bénéfice de la branche d'Apple appelée WebCore. Cette proposition a provoqué de vives réactions de la part des développeurs de KDE (KHTML fait partie du projet KDE) et s'est trouvée être l'occasion d'un bilan des deux ans de collaboration entre KHTML et Apple.

L'affaire fait suite au passage de l'Acid2 Standards-Compliant Test (test de compatibilité avec les standard Web extrêmement exigeant) par Safari.

KDE est un des projets majeurs du monde du logiciel libre. Ce bureau complet est développé à un rythme rapide par des codeurs du monde entier et il requiert donc l'utilisation intensive d'un outil de gestion de code performant. Jusqu'à présent c'était le vénérable CVS (Concurrent Versions System) qui était utilisé mais dès octobre 2004 les leaders du projet KDE avaient décidé de changer et de basculer vers le plus moderne Subversion.

Cette transition délicate est maintenant terminée (depuis le 5 mai) et le travail a repris de plus belle sur les serveurs KDE pour pouvoir nous proposer un bureau encore plus performant et complet.

Après un an et demi d'attente (depuis la 2.4.2), une nouvelle version stable de wxWidgets vient de sortir. C'est la première version stable à prendre le nom de wxWidgets. En effet, le précédent nom de wxWindows semblait ne pas plaire à Microsoft.
Pour rappel, wxWidgets est une bibliothèque graphique portable "native" pour GTK (NdM : 1.2.x, mais aussi 2.x avec cette nouvelle version), Motif, X11, OS/2, Mac OS 9, Mac OS X, Win16, Win32, WinCE, Nano-X, MGL et Palm OS.

Dans cette nouvelle version majeure, un important travail sur le support de la STL a été fait. De nouvelles fonctionnalités ont fait leur apparition comme, par exemple, wxGridBagSizer qui permet de décrire l'organisation d'une fenêtre comme un tableau dont les cases peuvent fusionner. Espérons que cette nouvelle version permette à encore plus de développeurs de découvrir ce fabuleux framework très bien documenté.

Suite à l'annonce de l'arrêt de la version gratuite de BitKeeper, Linus Torvalds et quelques autres développeurs ont travaillé sur un nouveau système pour gérer le développement du noyau, appelé Git.

Ce week-end, deux développeurs du noyau ont réussi chacun de leur côté à importer la totalité de l'historique du noyau dans Git, l'un à partir de CVS, l'autre à partir de BitKeeper. Ces trois ans d'historique représentaient 3.2 Go de données une fois importées dans Git, ce qui pour Linus Torvalds est tout à fait raisonnable et conforme à ses prédictions.

Toutefois, Linus a proposé de ne pas importer tout l'historique dans Git, mais de repartir de zéro. Cette proposition n'a pas rencontré d'opposition et le développement du noyau a donc repris en utilisant Git. Depuis, plusieurs dizaines de patches ont été intégrés, aboutissant à la sortie de la version 2.6.12-rc3 du noyau. Cette version est la première utilisant le nouveau système de gestion des sources Git.

Par ailleurs, Tony Luck a annoncé qu'il avait rédigé un guide pour les débutants de Git et des développeurs ont annoncé l'existence de deux interfaces Web pour Git : gitweb et wit.

Face au changement de politique de la société BitMover, il est intéressant de constater la vitesse à laquelle l'équipe de développement du noyau a créé un nouvel outil et l'a rendu utilisable pour continuer le travail et sortir de nouvelles versions.

Un article de Computer World, repris par Linux Weekly News, rapporte quelques unes des discussions ayant eu lieu à la mini-conférence annuelle OpenOffice à Canberra. D'après Ken Foskey, un développeur d'OpenOffice, le principal problème est le manque de développeur, et une base de code qui est trop importante. OpenOffice.org contiendrait en effet 10 millions de lignes de code, et serait assez délicat à compiler.

En dehors des 50 développeurs de Sun travaillant sur OpenOffice.org en Allemagne, et des 10 développeurs de Novell, seuls 4 contributeurs de la communauté sont réellement actifs.

La responsable marketing a indiqué que la sortie d'OpenOffice.org 2.0 n'aurait lieu qu'en juin ou juillet et qu'ils songeaient à un cycle de release plus court, avec moins de fonctionnalités apportées à chaque fois, pour stimuler le développement communautaire.

L'«évangéliste technique en chef » pense que le principal problème vient de la taille du code, pas du pouvoir de Sun dans le développement d'OpenOffice et précise que toutes les contributions sont les bienvenues. Toutefois, comme le soulignent les commentaires sur Linux Weekly News, tout contributeur à OpenOffice.org doit signer un accord qui prévoit que les contributions deviennent la propriété commune de Sun et du contributeur. Sun peut donc les utiliser à loisir dans son produit propriétaire StarOffice.