L’été s’est révélé très fructueux pour mes différents projets logiciels autour du format ODT. Voici un petit tour d’horizon des dernières nouveautés.

Dokuwiki

J’ai publié une nouvelle version de mon plugin d’export ODT pour Dokuwiki. Le changement principal est la prise en compte de la coloration syntaxique fournie par Dokuwiki. Vous pouvez voir un exemple de ce que ça donne sur cette page de mon wiki. Les couleurs du wiki et celles du document ODT ne sont pas exactement les mêmes, c’est normal :

C’est une fonctionnalité qu’on m’avait déjà demandé par le passé, et il s’est avéré que ce n’était pas si compliqué que ça à réaliser, principalement grâce au fait que la syntaxe CSS et la syntaxe des styles dans ODT XML sont très similaires. Ça c’est un format bien conçu, chapeau.

La nouvelle version du plugin est disponible en téléchargement depuis la page officielle du plugin ou directement chez moi. Vérifiez la signature GPG si vous le voulez/pouvez.

XHTML2ODT

Mon projet principal autour du format ODT est clairement XHTML2ODT, le convertisseur XHTML vers ODT (comme son nom l’indique ). Au début de la semaine, j’ai publié la version 1.0, ce qui est toujours une étape importante dans un projet logiciel. Le code qui la constitue a servi de fondation à deux plugins d’export depuis plusieurs mois maintenant, et est très largement couvert par plus d’une centaine de tests unitaires.

J’ai profité des jours suivants dans la semaine pour avancer le développement du projet sur certaines fonctionnalités qui semblaient intéressantes. Dans la même veine que pour le plugin Dokuwiki, j’ai ajouté la prise en compte de la coloration syntaxique fournie par deux moteurs : Pygments (en Python) et GeSHi (en PHP). Tout n’est pas encore parfaitement géré, mais le fonctionnement de la coloration syntaxique pour GeSHi ouvre peut-être la voie à une gestion plus large des styles CSS inclus directement dans le code HTML, par le biais de la balise <style> (c’est ainsi que GeSHi procède).

Enfin, GeSHi a aussi une fonctionnalité amusante : il peut numéroter les lignes du code. Cette fonctionnalité est aussi prise en compte et conservée lors de la conversion en ODT.

Tout ce nouveau code a été publié dans la version 1.1 de XHTML2ODT, que vous pourrez trouver sur la page de téléchargement. Au passage, j’en ai profité pour corriger un petit bug dans la conversion des espaces en mode préformaté, et pour ajouter un petit script de conversion en bash. Le but n’est pas de l’amener au même niveau de fonctionnalités que ses cousins Python et PHP, mais de montrer simplement comment mettre en œuvre les feuilles XSL.

Enfin, autre changement non technique mais non moins important : la licence s’est assouplie. J’ai passé le code de GPL v2 ou plus à LGPL v2 ou plus. Concrètement, cela signifie que si vous insérer le code dans une autre application, et que vous la distribuez, vous n’avez plus besoin de mettre votre application sous GPL. La seule contrainte restante est de publier les changements que vous avez fait sur le code XHTML2ODT lui-même, si vous en avez fait. C’est tout, rien d’autre.

Dernière petite nouvelle, j’ai écrit un article de quatre pages pour le magazine (papier !) Programmez! au sujet d’XHTML2ODT, il devrait sortir à la rentrée. Je vous tiendrai au courant, ça va de soi

Export ODT pour Trac

J’ai publié une nouvelle version du plugin d’export Trac, pour profiter des évolutions de la bibliothèque principale en ce qui concerne la coloration syntaxique. Vous pouvez voir le résultat en vous rendant sur la page WikiProcessing (fournie par défaut dans Trac) et en cliquant tout en bas sur le lien “OpenDocument”. Ou plus directement, en cliquant ici. Tada ! Le petit bout de code en C au milieu de la page est colorisé.

Dans cette nouvelle version, j’ai aussi tiré parti du système d’ajout de styles proposé maintenant directement dans XHTML2ODT, ce qui simplifie grandement le plugin. Si vous voulez faire un plugin d’export ODT pour une appli en Python, le plugin Trac peut être une bonne source d’inspiration.

Export ODT pour Dotclear

Là aussi, j’ai publié une nouvelle version du plugin d’export Dotclear pour profiter des avancées de la bibliothèque. Dotclear ne fait pas de coloration syntaxique par défaut, mais il existe un plugin pour cela, qui s’appelle syntaxehl, et qui utilise GeSHi en dessous. Le plugin peut fonctionner avec ou sans numérotation des lignes, les deux modes sont traduits en ODT.

Pour que ce soit plus parlant, voici un exemple de ce qui est produit par le plugin SyntaxeHL :

/* Commentaire */
class syntaxeHl
{   
 
    public static function registerFunc($wiki2xhtml)

    {   
        $dir = dirname(__FILE__).'/geshi/geshi/';
        $od = opendir($dir);

        while($f = readdir($od))
        {   
            if(is_file($dir.$f) && substr($f,-4,4)=='.php')

            {   
                $lang = str_replace('.php','',$f);
                $wiki2xhtml->registerFunction('macro:['.$lang.']',array('syntaxeHl','parse'));

            }
        }
    }
 
    public static function parse($text,$args)

    {   
        global $core;
        $settings = $core->blog->settings->syntaxehl;

 
        $text = trim($text);
        $args = preg_replace("/^(\[(.*)\]$)/","$2",$args);

        $geshi = new GeSHi($text,$args);
 
        if(!$settings->get('syntaxehl_enable_klink'))  $geshi->enable_keyword_links(false);

        if($settings->get('syntaxehl_enable_linenum')) $geshi->enable_line_numbers(GESHI_NORMAL_LINE_NUMBERS);
        //if($settings->get('syntaxehl_enable_css_classes')) $geshi->enable_classes();

        $geshi->enable_classes();

Et maintenant, avec la numérotation des lignes :

/* Commentaire */
class syntaxeHl
{   
 
    public static function registerFunc($wiki2xhtml)
    {   
        $dir = dirname(__FILE__).'/geshi/geshi/';
        $od = opendir($dir);
        while($f = readdir($od))
        {   
            if(is_file($dir.$f) && substr($f,-4,4)=='.php')
            {   
                $lang = str_replace('.php','',$f);
                $wiki2xhtml->registerFunction('macro:['.$lang.']',array('syntaxeHl','parse'));
            }
        }
    }
 
    public static function parse($text,$args)
    {   
        global $core;
        $settings = $core->blog->settings->syntaxehl;
 
        $text = trim($text);
        $args = preg_replace("/^(\[(.*)\]$)/","$2",$args);
        $geshi = new GeSHi($text,$args);
 
        if(!$settings->get('syntaxehl_enable_klink'))  $geshi->enable_keyword_links(false);
        if($settings->get('syntaxehl_enable_linenum')) $geshi->enable_line_numbers(GESHI_NORMAL_LINE_NUMBERS);
        //if($settings->get('syntaxehl_enable_css_classes')) $geshi->enable_classes();
        $geshi->enable_classes();

Pour voir ce que cela donne en ODT, il vous suffit d’exporter ce billet de blog (le bouton est en haut à droite). Sympathique, non ?

Enfin, comme pour le plugin Trac, j’en ai profité pour déléguer l’ajout des styles à XHTML2ODT lui-même, ce qui simplifie grandement le code. Si vous cherchez à faire un plugin d’export ODT en PHP, le plugin d’export Dotclear est un bon candidat pour chercher l’inspiration.

Vous pouvez télécharger et installer le plugin depuis sa page sur DotAddict.

Flattr

Ça fait plusieurs semaines que j’entends parler de Flattr, ce nouveau service qui veut révolutionner le micro-paiement. Tuxicoman y a même consacré un article assez élogieux. En deux mots, la différence par rapport à PayPal, c’est qu’on affecte avant toute chose un “budget”, c’est à dire une somme fixe d’argent, qui sera distribuée entre les différentes choses pour lesquelles vous aurez cliqué sur le bouton “Flattr”. Son concernés bien évidemment les logiciels (libres ou pas), mais aussi la musique, les vidéos, les écrits, et autres.

À la fin du mois, votre budget mensuel est donc réparti, et si vous n’avez cliqué sur rien il est distribué à des organisation caritatives. Le budget minimum est de deux euros, c’est donc pas la mort. Si vous ne remplissez plus votre compte, il est désactivé temporairement bien sûr.

Le fait d’affecter un budget mensuel fixe, qui partira de toute façon, est à mon avis ce qui fait toute la différence. J’ai décider de me créer un compte pour voir ce que ça donne à l’usage, et pour soutenir les projets qui me plaisent. Bien sûr, j’en ai profité pour enregistrer les projets dont je suis l’auteur, mais que ce soit clair : je ne m’attends pas à rouler sur l’or du jour au lendemain Toutefois, si mes quelques bouts de code vous plaisent et que vous avez un compte sur Flattr, vous trouverez tous les liens sur mon profil. Les projets de conversion ODT ci-dessus sont normalement tous enregistrés.

À vous les studios

Bon, OK, certaines personnes pourraient objecter qu’il y aurait de meilleures façons de passer ses vacances.

Un bon gros weekend de geek. Mais il fallait le faire, ça commençait à trop tarder, avec les petits plugins que j’éparpille un peu partout, et les quelques développements que je réalise, il était temps que je mette en place une plate-forme pour assurer la maintenance de tout cela. Mon choix s’est porté sur Trac, voici pourquoi.

Mais pourquoi, au fait ?

J’avais installé un wiki sur mon site il y a quelques mois, pour noter tout ce qui n’a pas la même durée de vie qu’un article de blog. Et j’ai pris aussi l’habitude de développer avec Git, en hébergeant le code source chez Gitorious.

Gitorious est un très bon hébergeur de code source, basé sur Git donc, avec une interface assez jolie et ergonomique. Il est sous licence AGPL contrairement à son concurrent le plus direct, GitHub, qui est propriétaire. Vu mon penchant pour le logiciel libre, je me suis naturellement orienté vers Gitorious. Il a toutefois un défaut important : il n’y a pas de gestionnaire de tickets. C’est prévu, mais pour l’instant ils en sont à la conception, puisqu’ils voudraient mettre en place un système vraiment décentralisé et communiquant. On pourrait ainsi référencer et suivre les tickets ouverts sur d’autres instances de Gitorious.

C’est bien beau, mais pour l’instant ça veut dire que je dois trouver un autre moyen pour gérer les tickets des logiciels que je développe et auxquels je contribue. Ce n’est pas bien grave, il y a de nombreuses options en logiciel libre, donc j’ai cherché celle qui me conviendrait le mieux. Parmi mes contraintes, il y a :

1. être en développement actif
2. être relativement simple et facile à manipuler, je n’ai pas envie de noyer des rapporteurs de bugs potentiels
3. la possibilité d’utiliser OpenID. Je n’ai pas envie de forcer les rapporteurs de bugs à ouvrir un n^ième compte à usage unique. En plus, grâce à OpenID, je déporte la problématique de gestion du spam sur le fournisseur OpenID, ce qui m’arrange pas mal.
4. la possibilité de personnaliser sommairement l’interface, pour l’adapter au thème du reste du site.

Voici le résultat des courses (à mettre bien entendu en regard de mon besoin, qui n’est pas forcément celui de tout le monde).

La gestion de ticket en logiciel libre

Tout d’abord, j’ai cherché ce qui m’imposerait un minimum de dépendances. Sachant que mon espace web fonctionne très majoritairement en PHP/PostgreSQL, j’ai cherché des gestionnaires de tickets sur les mêmes technos.

Flyspray

Flyspray est un gestionnaire de tickets léger en PHP. Il a l’air pas mal du tout, mais son activité de développement semble relativement faible, et il n’a pas encore OpenID, donc j’ai laissé tomber.

Mantis

Attention, gros poids lourd. Mantis est un gestionnaire de tickets très puissant, mais qui échoue sans réserves au point n°2. Peut-être que ce sera un outils parfait pour quelqu’un dont c’est le métier, qui va rester toute la journée devant et apprendre à le maîtriser, mais pour moi et le quidam moyen qui ouvrira des tickets chez moi, c’est trop compliqué.

InDefero

Ça c’est très intéressant. InDefero est un petit dernier qui se veut être un clone de Google Code en PHP. Il a l’air vraiment très bien, mais pour l’instant il ne gère pas OpenID. Dommage, tout le reste avait l’air très bien.

Bon, ne voyant rien sortir en PHP/PostgreSQL, j’ai décidé de relâcher la contrainte PHP, et d’aller regarder ce qui se fait dans les autres langages.

Bugzilla

Je connais pas mal, vu que c’est ce qui est installé chez Fedora. Trop complexe à utiliser, trop complexe à installer, et trop gourmand en ressources.

Redmine

Là, on a du très lourd. Redmine est un gestionnaire de projets écrit en Ruby, qui fait exactement tout ce que je veux, et même plus. Le mec cool qui m’héberge a en plus déjà installé un Redmine sur le serveur, mais vu que mes réglages sont assez différents (accès à tout le monde), il faudra que je m’installe une autre instance. A priori pas un problème.

Trac

Trac, je connais déjà. C’est un très bon gestionnaire de projets, simple et efficace, écrit en Python (donc un plus pour moi), et pour lequel j’ai déjà écrit plusieurs plugins. Lui aussi, il fait tout ce que je veux.

Redmine ou Trac

Les deux finalistes sont donc Redmine et Trac. Je me suis dit que c’était l’occasion d’essayer Redmine, donc j’ai essayé de comprendre comment c’était installé sur la machine. Et bien, je dois dire que je n’ai pas compris. C’est manifestement installé dans Apache avec Passenger, mais à part ça je n’ai rien réussi à recoller. En plus j’ai essayé de ne pas toucher aux fichiers pour éviter de casser quoi que ce soit, ce qui fait qu’au bout d’une demi-heure de farfouillages et de recherches sur le net, j’ai perdu la motivation. Ça marche, mais je ne comprends pas pourquoi, et ça j’aime pas tellement.

Donc bon, je me suis rabattu sur le bon vieux Trac que je connais bien maintenant. Finalement, le fait qu’il soit écrit en Python fait que je peux mieux le maîtriser, et écrire des plugins si nécessaire, plugins qui pourront peut-être servir à d’autres.

Comme j’ai plusieurs projets indépendants, je vais faire gérer plusieurs “environnements” à la même instance de Trac, ce qui économisera la mémoire. Cela se fait assez facilement grâce à la fonctionnalité correspondante de Trac, c’est à dire --env-parent-dir pour tracd ou la variable d’environnement TRAC_ENV_PARENT_DIR dans mod_wsgi (que j’utilise). Toutes les instructions sont sur le site de Trac.

Adaptations

Alors, reprenons le besoin : mon code est hébergé chez Gitorious, il ne me faut donc qu’un gestionnaire de tickets. Comme Trac fournit un wiki, je vais m’en servir à la place de celui de Gitorious, pour pouvoir référencer les tickets d’incidents, et profiter des possibilités d’adaptation graphique de Trac. Par contre, Trac fournit aussi un gestionnaire de code source, et ça je n’en ai pas besoin.

Le navigateur de sources

Et oui, si mon code est hébergé chez Gitorious, ça serait bizarre de se servir de l’explorateur de code de Trac. J’ai donc cherché plusieurs solutions pour remplacer le navigateur de Trac par un lien vers Gitorious, mais rien ne s’est révélé très satisfaisant. En plus de ça, la syntaxe wiki de Trac permet de référencer un fichier dans l’arborescence des sources, avec un lien du type [source:monfichier.ext]. Dans le meilleur des mondes, ces liens arriveraient directement dans Gitorious, sur le bon fichier, et même à la bonne ligne.

J’allais quand même pas rater une occasion d’améliorer le monde, non ? Donc j’ai fait un plugin Gitorious pour Trac qui fait exactement ça : il remplace le lien du navigateur de sources par un lien vers Gitorious (il faut configurer le nom du projet cible), et intercepte tous les liens vers les sources en les réécrivant pour pointer vers le navigateur de Gitorious. Si vous êtes dans le même cas que moi, n’hésitez pas à vous servir de mon plugin.

Il y a des fonctionnalités de Trac qui n’existent pas chez Gitorious, je n’ai donc pas tout remplacé, mais c’est déjà assez sympa.

Autres plugins

Trac dispose d’un plugin pour l’authentification par OpenID, donc y’a qu’à installer. Il me fallait aussi évidemment le plugin Git, histoire que mes modifications apparaissent dans la timeline. Et j’en ai bien sûr profité pour installer mon plugin d’export ODT. Enfin, j’ai installé le plugin TranslatedPages pour faciliter la traduction des pages du wiki.

La quantité de plugins disponible pour Trac est vraiment phénoménale, on trouve tout ce qu’on veut !

Graphisme

Je n’allais pas quand même laisser les visiteurs et les rapporteurs de bugs avec une rétine intacte, c’est pas le genre de la maison. J’ai donc modifié le template de Trac par défaut pour que mon espace de développement soit aussi moche que le reste de mon site. La cohérence, c’est important. Les instructions se trouvent sur le site de Trac, avec quelques exemples pour les cas classiques (ajouter une CSS, etc.).

Le langage de templates utilisé par Trac est Genshi, c’est très proche du XML/XSL, ça me rappelle le langage TAL de Zope, donc c’est marrant. En plus je commence à bien le connaître puisque je l’utilise au boulot.

J’ai aussi modifié la page qui sert d’index aux projets. Là aussi, les instructions sont déjà toutes prêtes sur le site de Trac. Je vous laisse souffrir admirer.

Téléchargements

Il existe plusieurs moyens de proposer un espace de téléchargement de fichiers dans Trac. On peut tout simplement faire un lien vers un répertoire d’Apache. On peut ajouter un lien dans la barre de navigation principale pour pointer vers ce répertoire. On peut aussi attacher les fichiers à une page du wiki, mais ce n’est pas ce qu’il y a de plus pratique. Et évidemment, il y a trois plugins différents pour gérer un véritable espace de téléchargement (Trac : there’s a plugin for it).

Mais moi je voulais quelque chose d’un peu différent : je voulais pouvoir générer automatiquement des archives de la branche de développement toutes les nuits, je voulais pouvoir signer les publications, etc. J’ai donc opté pour un dossier dans Apache, qui est rempli par un script externe. Ce script tourne toutes les nuits et créée deux archives (tar.gz et zip) pour chaque tag de chaque projet, ainsi que deux archives de la branche de développement. Il en profite pour générer un bel index, et un flux Atom. C’est pas très compliqué, il y a peut-être 50 lignes de shell, donc pour l’instant je ne le publie pas sauf si quelqu’un se déclare intéressé. La génération du flux Atom est laissée à un autre script que j’ai écrit.

Conclusion

Je dispose maintenant d’une bonne plateforme d’hébergement de code, simple, bien intégrée avec Gitorious, extensible, automatisée, et surtout que je connaît bien.

Si jamais je décide de pousser l’auto-hébergement plus loin et de me passer de Gitorious, Trac est tout à fait à même de répondre au besoin. Je ne tire pas un trait sur Redmine pour autant, peut-être qu’un jour j’aurais l’occasion de l’utiliser activement. En attendant, le fait que je sois capable d’écrire des plugins pour Trac est quand même un facteur de poids dans la balance.

Si vous voulez plus de détails sur l’implémentation de tout ça, n’hésitez pas à me contacter (mais c’est pas très sorcier au final).

J’ai (enfin) fait une page pour décrire les quelques scripts que j’ai fait et qui pourraient servir à d’autres. Pour faciliter la lecture des utilisateurs de flux RSS et pour éviter un clic aux autres, je vais tout recopier dans ce billet, mais la page de référence est sur mon wiki.

J’ai écrit un certain nombre de scripts pour me faciliter la vie de tous les jours. Et oui, comme tout bon informaticien, je suis prêt à passer 8 heures à peaufiner un script qui me fera gagner 30 secondes tous les mois… Mais bon, là n’est pas la question.

Mes scripts

Il se trouve que je pense que certains de ces scripts pourraient être utiles à d’autres, donc dans le plus pur esprit du Logiciel Libre, je les met à disposition sur cet espace de développement. Tous ces scripts sont sous licence GPL v3. Voici une petite présentation.

backup-delicious.py

Un simple script pour sauvegarder ses signets stockés sur delicious.com dans un fichier XML, au cas où Delicious aurait un problème (site cassé, perte de données, politique commerciale à la con, revente de Yahoo, etc.).

birthdaysfromvcard.py

Le script créé un fichier iCalendar avec les anniversaires des gens trouvés dans un fichier vCard (vcf).

Très pratique pour ne plus oublier les anniversaires des ses connaissances (voire de sa famille…)

files2feed.py

Le script créé un ficher Atom XML (équivalent RSS) à partir des derniers fichiers modifiés ou ajoutés dans un répertoire et ses sous-répertoires.

Cas d’utilisation : je partage mes fichiers par le web, et j’aimerais bien proposer un flux RSS pour les mises à jour et les nouveaux fichiers partagés (ici c’est un flux Atom, mais c’est le même principe).

make-songs-list.py

Le script créé un PDF à partir des chansons disponibles pour Performous, un excellent jeu de karaoké.

Il utilise la pochette de l’album si elle est dispo, et essaye d’en mettre un maximum sur le minimum de pages, pour qu’il n’y ait plus qu’à imprimer et à distribuer aux joueurs.

podcast-transcode.py

Cas d’utilisation : je dispose d’un lecteur de vidéos portable que j’utilise dans les transports en commun, mais il n’est pas assez puissant pour décoder les vidéos d’aujourd’hui (résolutions assez élevées, codecs gourmands, etc.) Il faut donc que je convertisse et que je redimensionne les vidéos des podcasts auxquels je suis abonné.

Fonctionnement : le script prend en entrée un flux RSS, et convertit toutes les vidéos incluses en attachement au format AVI/DivX/MP3, en les redimensionnant à la taille demandée. Une fois la conversion effectuée, la balise d’attachement est mise à jour pour pointer sur l’adresse de la vidéo convertie.

Pour les vidéos de TED, le script peut même ajouter les sous-titres s’ils sont dispo, et si le script tedtalksubs.py est installé (c’est à dire dans le PATH). C’est un autre de mes scripts, téléchargeable au même endroit (enfin, dans ce cas-là, dire “de mes scripts” est un peu fort, puisque j’ai quasiment tout pompé sur un autre).

Le script tedtalksubs.py est indépendant, il permet de lister, télécharger et convertir au format SRT les sous-titres des vidéos de TED.

rss-mirror.py

Cas d’utilisation : quand je tombe sur une page web intéressante mais que je n’ai pas le temps de lire là tout de suite, je la sauvegarde dans Instapaper. Le service me fournit ensuite un flux RSS des pages en attente de lecture. Pour utiliser au mieux le temps que je passe dans les transports en commun, j’aimerais y lire ces pages, mais je n’ai pas d’abonnement internet mobile. Par contre, j’ai un lecteur portable qui dispose d’un navigateur web.

Fonctionnement : le script prend un ou plusieurs flux RSS en entrée, et fait un miroir local de toutes les entrées en utilisant wget ou httrack. Le niveau de profondeur des liens récupérés est configurable, mais par défaut il ne prend que la page indiquée, pas les liens trouvés sur cette page. Il créé ensuite un index des pages téléchargées en utilisant le fabuleux iUI.

Le répertoire de téléchargement peut ensuite être synchronisé sur un lecteur portable, qui n’a alors besoin que d’un navigateur web. Dans mon cas, je l’utilise avec Instapaper, mais n’importe quel flux RSS peut être utilisé. Par exemple, des signets sur Delicious, les favoris de Tiny Tiny RSS ou Google Reader, etc.).

C’est en quelque sorte le lecteur de flux hors-ligne du pauvre

Conclusion

Voilà, si vous avez des commentaires, des remarques, ou des propositions d’amélioration à faire sur ces scripts, n’hésitez pas. Une petite description est disponible en en-tête de chacun d’eux, et vous pouvez les lancer avec --help pour connaître les options disponibles. Ils nécessitent tous au moins python 2.5, les autres dépendances étant spécifiques à chacun des scripts.

Pour essayer de faire connaître XHTML2ODT, j’ai écrit un article sur LinuxFR qui en fait la promotion, ou du moins qui annonce à tout le monde que ça existe. Oui oui, écrire un article sur LinuxFR, c’est parler au monde. Rien que ça

Je rappelle brièvement de quoi il s’agit : XHTML2ODT a pour objectif de convertir une page web (HTML) en document ODT, éditable ensuite par tous les traitements de texte qui utilisent ce format, notamment OpenOffice. Pour ce faire, il s’appuie sur un document OpenOffice “modèle”, dans lequel on peut définir les styles que l’on veut.

Comme il n’y a pas de gestionnaire de bugs pour l’instant, vous pouvez éventuellement utiliser les commentaires de cet article pour ça. Mais bon, il faudrait que j’en installe un quand même, ce serait plus propre. Je pencherais bien pour un Trac, mais maintenant faut voir si mon gentil hébergeur sera d’accord…

Mise à jour : Finalement j’ai fait un site dédié pour XHTML2ODT, avec Trac. Le code reste hébergé par Gitorious pour l’instant.

Quand on écrit un billet avec Dotclear, on dispose de deux modes : le mode “wiki” ou le mode “xhtml”.

En mode wiki, on dispose d’une syntaxe codifiée et simplifiée, mais il faut apprendre cette syntaxe, et ce qui est affiché à l’écran est très différent de ce qui sera affiché sur le site ensuite. Il y a quelques temps, je préférais ce mode de rédaction (c’est plus rigolo ), mais c’est moins facile d’accès pour les débutants, et après tout, on ne fait pas des programmes que pour les informaticiens.

Le second mode affiche le texte dans la zone d’édition avec le formatage qu’il aura à l’affichage final, un peu comme votre traitement de texte préféré^[1]. En plus, et c’est important pour moi, il y a un onglet “source” qui permet de voir le XHTML généré, et éventuellement de faire des retouches, ou d’ajouter des blocs de code.

Mais voilà, le mode wiki a beaucoup plus de fonctionnalités que ce qui est repris dans la barre de formatage du mode xhtml. Notamment, il y en a une que j’aime bien utiliser : les notes de bas de page^[2]. En mode wiki, on entoure la note par des symboles “$$”, et Dotclear génère automatiquement l’appel de note, la note de bas de page, et les liens entre les deux. C’est très pratique, je voulais retrouver cette possibilité en mode xhtml.

J’ai donc fait un plugin pour Dotclear qui ajoute un bouton à la barre de formatage, et qui génère les appels de note, la zone de notes de bas de page, les liens entre les notes, tout en s’occupant d’incrémenter le numéro de note à chaque fois. Le plugin s’appelle footnotesToolbar, et il est disponible sur le lab Dotclear. Si vous pensez qu’il peut vous être utile, n’hésitez pas à le télécharger et à me donner votre avis !

Bonne rédaction

Mise à jour : j’ai aussi ajouté un bout de code pour lui faire afficher les notes de bas de page au survol de l’appel de notes. C’est une très bonne idée que j’ai piquée à Dokuwiki, sur conseil d’antistress (voir commentaires ci-dessous).

Il est un peu tard pour faire un compte-rendu de la conférence de Copenhague sur l’évolution du climat, mais bon, il faut le temps que les articles soient lus, que les idées se décantent, etc, etc. Voilà ce que j’en retire.

“Stop the Politics Climate Treaty Now - Greenpeace” par Takver

« De la démocratie dans le monde »

Je n’ai pas de remarque particulièrement plus pertinente que qui que ce soit d’autre sur le sujet, ni de point de vue d’insider (je n’y étais pas), mais j’aimerais tout de même porter à votre attention un article que je trouve à la fois pertinent, bien argumenté, et surtout doté d’une bonne prise de recul sur cette question. Il s’agit de l’article de Sylvestre Huet, journaliste scientifique à Libération, intitulé « Climat : qui est responsable du Flopenhague ? ».

Je vous encourage évidemment à courir le lire en entier, mais pour faire un résumé rapide je pense qu’il pose une très bonne question : les ONG écolo se sont-elles trompées de cible ?

En effet, en orientant leur actions et leurs communications vers les responsables politiques, n’ont-elles pas choisi la solution de facilité (toute relative qu’elle est bien sûr ) ? Les politiques sont peu nombreux, semblent avoir le pouvoir de décision et d’action, sont en général très instruits, etc. Ils ressemblent à s’y méprendre à la parfaite cible à viser.

Sauf que voilà, comme l’écrivait déjà Alexis de Tocqueville au début du 19^ème siècle dans De la Démocratie en Amérique, et comme le rappelle Jean-Marc Jancovici sur son site, la démocratie est un régime politique dans lequel les dirigeants sont des représentants du peuple. C’est le peuple qui décide, pas les politiques, et il ne peut pas se reposer sur eux pour être une sorte de grand frère bienveillant qui prend tout seul les bonnes décisions. La démocratie responsabilise le peuple, il se doit donc d’être responsable. Au passage, je vous encourage à aller lire les deux articles de J.M. Jancovici sur le sujet, c’est particulièrement intéressant. Avec du très très bon dedans, notamment la façon dont on pourrait mettre en place de la démocratie directe, le fait que les sondages actuels en sont un ersatz puant, etc. Mais je ne vais pas me lancer dans la paraphrase de J.M.J., j’ai mis ça dans mes bonnes résolutions pour 2010.

“COP15 - Klimademo” par gruenenrw

Pour en revenir au sujet, je pense donc que Sylvestre Huet met le doigt sur le fond du problème : pour faire changer les choses, il ne faut pas essayer de convaincre les politiques, il faut convaincre les citoyens. Et c’est beaucoup plus difficile. Les citoyens :

• sont beaucoup plus nombreux
• sont principalement préoccupés par le quotidien, bien moins par les moyens et longs termes
• ne sont pas forcément intéressés par le sujet
• ont des niveaux d’instruction très variés
• sont déjà abondamment bombardés de messages de communication (la pub) tentant de les convaincre

Bref, c’est une toute autre paire de manches. Sauf que voilà, le jour où un politique lira dans les derniers sondages : « Pensez-vous qu’il faut mettre en place une taxe carbone ? Oui 70% / Non 30% », vous pouvez être sûr qu’il le fera sans hésiter une seconde. Après tout, c’est bien ça son boulot.

“Bring Home a Climate Treaty” par Takver

Un pacte avec le diable ?

Alors ça tombe bien, il y a des gens qui bossent depuis des années sur la façon de diffuser un message pour convaincre le public. Ce sont les gens du marketing et de la communication. Principalement employés par les publicitaires, ils le sont aussi parfois par les lobbies, les politiques, etc. Je sais qu’on touche là à un tabou, parce que la consommation de masse et tout ce qui peut l’inciter est aux antipodes de l’écologie, mais je pense qu’il faudra inévitablement utiliser ou acquérir les compétences qui sont actuellement celles des agences de communication.

Ça me rappelle une situation relativement similaire que nous avons vécu dans le monde du logiciel libre. Mes premiers contacts avec le logiciel libre l’ont été par résistance à une société en situation de monopole (il s’agit bien sûr de Microsoft) et dont les pratiques commerciales étaient… comment dire… très éloignées de ma conception de l’éthique. Autant dire qu’à l’époque, toute société qui se montait dans le domaine du logiciel libre recevait illico un a priori négatif, d’autant plus si elle gagnait en popularité (« Mandrake c’est du Microsoft à la sauce Linux »).

Et au cours des années, les associations du logiciel libre se sont rendu compte que ce qui les empêchait de toucher le grand public, ce n’était plus les raisons techniques (logiciels moins faciles d’utilisation) mais tout simplement la méconnaissance des gens, le manque de communication, et finalement de marketing.

Je pense que la première association à avoir lancé une opération marketing d’envergure a été la Fondation Mozilla. Une fois l’horreur et le rejet viscéral passés, beaucoup d’autres lui ont emboîté le pas.

“Copenhagen during COP15” par UN Climate Change

Y’a du boulot…

Dans le cadre de l’écologie, je pense qu’il y a là un exemple à prendre. Les associations du logiciel libre ne sont pas spécialement plus fortunées que celles qui défendent l’environnement, il y a donc très probablement des méthodes à réutiliser. Je pense par exemple au concours de vidéo que Mozilla a lancé pour la sortie de Firefox 3.0. Pourquoi pas un concours de vidéo pour sensibiliser le public à sa dépendance aux énergies fossiles ? À l’impact du réchauffement planétaire sur les activités humaines futures ? Je suis sûr qu’il y a des idées à échanger.

La communauté du logiciel libre étant déjà plutôt politisée (la liberté dans le logiciel est un problème éminemment politique), je suis sûr qu’il y a déjà beaucoup de membres communs aux deux causes. J’espère que le besoin de mutualisation des compétences et des expériences va se faire plus clair au cours des mois qui viennent, et que nous pourrons nous entre-aider sur ce sujet commun. Il est grand temps, plus nous attendons et plus la note climatique sera salée.

“COP15 Climate March” par america.gov

Et voilà, je viens de boucler une première version utilisable d’un plugin d’export ODT pour Trac.

Parce que une fois c’est bien, deux fois c’est mieux, et trois fois bonjour les dég… euh, non en fait ça devrait marcher pareil que le reste. Il faut excuser mon humour pourri, mais je cauchemarde rêve de l’XML en ce moment.

Après avoir bien cherché, je suis obligé de me rendre à l’évidence : il n’y a toujours personne d’autre que moi qui ait écrit de feuille de style XSLT pour convertir de l’HTML en ODT. Dans l’autre sens, il y en a pléthore, mais dans ce sens, rien. Comme j’ai réutilisé pour le plugin Trac les feuilles que j’avais écrites pour le plugin Dotclear, je me suis dit qu’il n’était pas forcément complètement stupide d’en faire un projet séparé. C’est donc ce que j’ai fait, j’ai ouvert un projet sur Gitorious appelé xhtml2odt (oui, très original, je sais). J’en ai profité pour écrire tout un tas de tests unitaires, pour m’éviter les régressions et aussi parce que ça se prête quand même bien aux conversions .

Je vais maintenant adapter le plugin Dotclear pour qu’il utilise ces feuilles, qui ont été légèrement améliorées lors de la réalisation du plugin Trac.

Si vous décidez de les utiliser pour un autre plugin d’export ODT dans une autre appli, ce serait cool de m’envoyer un petit mail, ça m’intéresse

Voilà, si vous utilisez Trac et que vous êtes intéressé par l’export ODT des les pages du wiki, n’hésitez pas à tester ! Ce n’est pas encore parfait mais c’est déjà suffisamment avancé pour que vos retours soient utiles.

Mise à jour : le projet XHTML2ODT a maintenant son propre site web. Le code reste hébergé par Gitorious pour l’instant.

Je m’intéresse, comme beaucoup en ce moment, à ce qui se passe dans le monde des smartphones, ces téléphones / PDA dont tout le monde parle. Malheureusement, pour quelqu’un attaché à ses libertés électroniques (et plus généralement, n’ayant pas envie de se faire prendre pour un porte-feuille sur pattes), j’ai la forte impression qu’il n’y a pas de Graal en vue… Voilà un petit passage en revue des différentes options.

Le plus célèbre : l’iPhone

Je vais commencer par celui que tout le monde connaît, l’iPhone d’Apple. Très joli couple appareil / système d’exploitation, qui cache quand même des limitations comme on en avait rarement vu dans le monde de l’informatique. Je n’en ai pas, donc ce qui suit est basé sur les infos que j’ai pu glaner sur le web. Si je me suis trompé, n’hésitez pas à corriger.

• Déjà, il faut iTunes pour l’activer, sans ça il ne sert à rien. Non seulement je trouve qu’il est abusif de lier l’utilisation d’un appareil mobile à un logiciel sur un PC classique, mais en plus pour moi qui suis sous Linux, c’est raté.
• On ne peut installer des applications dessus qu’en passant par le site web d’Apple, où l’entreprise contrôle sévèrement ce qui a le droit d’exister sur l’iPhone. Il est déjà arrivé à plusieurs reprises que des logiciels soient censurés, soit parce qu’ils entraient en concurrence avec la stratégie commerciale d’Apple (Google Voice par exemple), soit parce qu’ils n’étaient pas politiquement corrects (iBoobs par exemple). Imaginez si seul Microsoft pouvait dicter ce que vous installez sur votre PC Windows ? Pas de Firefox, pas d’OpenOffice, pas de Thunderbird, pas de VLC, etc… Avec l’iPhone, c’est une réalité.
• Jusqu’à très récemment (juin 2009), pour pouvoir faire fonctionner son iPhone, il fallait obligatoirement donner son numéro de carte bleue à Apple, qui le stockait sur ses serveurs pour vous débiter automatiquement lors d’achat d’applications ! Rien que ça…
• C’est un peu plus geek, mais pour pouvoir développer des applications qui tourneront sur iPhone, il faut absolument avoir un Mac. Cette manière de faire de la quasi vente liée commence à sentir très fortement l’arnaque.
• La batterie n’est pas remplaçable, elle est soudée. Quand on sait que c’est ce qui s’use le plus, c’est quand même vraiment n’importe quoi.

Il paraît qu’il est possible de “pirater” un iPhone pour contourner certaines de ces limitations, mais je ne vois pas pourquoi j’achèterais un téléphone qui a été conçu dans le but de limiter ses utilisateurs. Bref, c’est clair que l’iPhone ne passera pas par moi.

Le plus ancien : Windows Mobile

Cela fait plusieurs années que j’ai des contacts avec les smartphones sous Windows Mobile. Le premier contact, dans un cadre professionnel, a été avec un Qtek 2020i (HTC Alpine), sous Windows CE 3 (je crois). Il m’est apparu tout de suite que ce sont en fait des mini-ordinateurs dans lesquels on a essayé de faire rentrer un Windows au chausse-pied, et sur lesquels on a greffé une application de téléphonie. C’est assez pratique comme PDA, mais difficilement utilisable comme téléphone. Parfois les SMS n’étaient pas annoncés, les options de sonneries étaient plus que minimales, le lien entre les contacts et le reste des applis était rarement fait, etc.

Or depuis quelques mois, mon frère m’a donné son ancien téléphone sous Windows Mobile 6. La situation technique s’est beaucoup améliorée, c’est nettement plus utilisable en tant que téléphone, notamment grâce aux interfaces d’HTC. Cependant, la synchronisation avec un PC sous linux est encore assez sensible, c’est toujours du propriétaire, et sous Windows il n’est toujours pas possible de le synchroniser avec quelque chose de standard (un fichier VCard ou iCalendar par exemple), seul Outlook est accepté. A tel point que, par exemple, ma boîte n’utilise pas Outlook comme client de messagerie, mais est obligée de l’accpeter quand même sur les postes parce que certaines personnes haut placé ont des téléphones/PDA sous Windows Mobile… Là aussi, la quasi vente liée qu’on connaît bien chez Microsoft.

Au passage, depuis que j’ai ce téléphone, j’ai pu participer à SynCE, le projet qui permet de synchroniser un téléphone sous Windows Mobile et un ordinateur sous Linux. J’ai corrigé quelques bugs de conversion, j’ai ajouté des tests unitaires, quelques fonctionnalités de partage de connexion, et finalement les responsables du projet m’ont donné les accès en écriture au SVN Très sympa de leur part.

En tout cas, grâce à SynCE et OpenSync, je peux synchroniser mon Windows Mobile avec mon PC Linux, et ça c’est bien cool. L’installation d’applications n’est pas restreinte, donc la plate-forme est assez ouverte, bien que fondamentalement propriétaire.

Le challenger : Android

Android est un système d’exploitation libre pour téléphone portable, fait par Google. Certains gourous de chez XDA-developers ont porté Android sur mon téléphone originellement sous Windows Mobile, donc j’ai pu l’essayer. J’ai un avis très mitigé : techniquement, c’est très joli et très intuitif, mais ça semble tout de même très fermé (un comble pour un OS libre). Les applications de contacts et de calendrier ne sont pas libres, elles sont propriété de Google et non redistribuables. De plus, on peut démarrer le téléphone sans compte Google, mais il le demande aussitôt. On peut ignorer l’inscription, mais dans ce cas il est impossible d’utiliser :

• La gestion des contacts
• Le calendrier
• L’application d’installation de nouveaux programmes

On est donc coincé avec un joli téléphone, sans les applications les plus utiles, et sans la possibilité d’en installer d’autres.

Ah, et au passage : il n’est pas prévu qu’Android puisse se synchroniser avec un PC ou un Mac, quelque soit le système d’exploitation de ce dernier : le principe est de tout synchroniser avec son compte Google, justement…

On sait que l’objectif d’Android est de concurrencer Apple avec l’iPhone, mais ce serait bien qu’il ne le concurrence pas sur le terrain des restrictions et de la vente liée. Pour l’instant on est loin du niveau de restrictions de l’iPhone, mais c’est quand même inquiétant. L’omniprésence de Google est elle-aussi inquiétante. Si Microsoft se fait remplacer par Google, on y aura perdu au change : on sera toujours dans une situation de monopole, mais elle sera plus difficile à déloger : à la différence de Microsoft, chez Google, ils sont bons.

Le petit nouveau : Maemo

Maemo est un système d’exploitation libre développé par Nokia à destination de ses “tablettes internet” : des PDA communicants très évolués à qui il ne manque que la téléphonie GSM. L’OS est basé sur Linux, et utilise massivement GTK/GNOME. Très récemment est sorti le N900 qui ajoute un puce GSM. Le tableau semble complet, mais voilà : il y a quelques mois Nokia a racheté TrollTech, la société à l’origine de QT (concurrent de GTK). Maemo 5, l’OS du N900, est encore basé sur GTK, mais Nokia a annoncé que les prochaines versions seront basées sur QT. En achetant un N900 aujourd’hui, on se retrouve finalement à investir dans une plate-forme logicielle en fin de vie.

Le plus geek : OpenMoko

OpenMoko est une plate-forme 100% libre et 100% ouverte, mais encore en développement. Elle n’est pour l’instant pas vraiment utilisable en tant que téléphone de tous les jours pour le quidam moyen, et son évolution est assez lente par manque de ressources.

Conclusion

Personne ne sort de mes tests avec un sans faute, et c’est bien dommage. Le salut viendra-t-il de LiMo ? Ce qui est certain, c’est que le secteur est en pleine ébullition en ce moment. Vos avis sont évidemment les bienvenus.

Trouvaille musicale de la semaine, complètement par chance, sur Jamendo.

Pour ceux qui ne connaissent pas encore, Jamendo est un site de diffusion de musique sous licence Creative Commons. J’ai écrit un petit billet sur le sujet il y a quelques années. Toute la musique que vous trouverez là-bas est au minimum librement téléchargeable et distribuable, et même parfois plus (remixable, utilisable commercialement, etc…). Alors bien sûr, vous n’y trouverez pas Britney Spears et autres Star Academy, les artistes y sont généralement auto-produits. Mais attention, ça ne veut pas dire qu’il n’y a que de la musique ressemblant à celle du cousin Kevin dans sa cave, ou à celle de 5 gus dans un garage. J’en veux pour preuve l’énorme découverte de cette semaine : Diablo Swing Orchestra.

Dès les tags, le groupe annonce la couleur : Jazz-Métal. Oulà ! Mais quelle est donc cette chose ? Je vous laisse vous faire une idée avec le lecteur ci-dessous.

Alors ? C’est-y pas gigantesque ? Lisez-aussi la description du groupe sur Jamendo, c’est bien fun

Mes préférées :

• Balrog Boogie (comment elle déchire celle-là…)
• Heroines
• Poetic Pitbull Revolutions
• Rag Doll Physics
• Infralove

Certes, tout n’est pas parfait sur Jamendo, il faut chercher un peu pour trouver ce qui vous plaît. Mais quand on tombe sur un groupe comme ça, on accepte facilement les quelques écoutes ratées. Au passage, j’en profite pour lister les albums que j’ai bien aimé.

Je souhaite le plus grand succès possible au Diablo Swing Orchestra, en espérant qu’ils continuent à placer leur musique sous licence Creative Commons. Merci pour la musique, vous êtes très très forts !

Mon afficheur web de photos, que j’avais présenté précédemment, a maintenant un nouveau nom : Photo Imp !

J’en ai profité pour ouvrir un espace sur Gitorious, pour que le développement soit plus accessible et plus visible.

En ce moment, je suis en train de porter la bibliothèque javascript type “Lightbox” qui permettait d’afficher les photos depuis ShadowBox vers PrettyPhoto, puisque ShadowBox n’est plus libre dans les versions récentes (utilisation commerciale interdite). C’est un peu plus long que prévu, mais je vois le bout.

Pour en revenir au nom, il a été trouvé par Peuf, et c’est une référence à une créature du monde de Terry Pratchett : le “photo imp” est un petit démon dans une boîte noire avec une petite fenêtre, appelée Iconographe. Quand on ouvre la fenêtre, le “photo imp” peint très rapidement ce qu’il voit sur une toile. L’appareil dispose aussi d’une salamandre pour éclairer rapidement l’objet à dessiner. C’est évidemment une transposition de l’appareil photo, très très bien vu de la part de Peuf, merci beaucoup. Pour les détails : voyez la page Wikipedia.

Je publierai une nouvelle version quand j’aurais porté le code sur PrettyPhoto. Si vous utilisez Photo Imp, dites-le moi, ça m’intéresse !