Elgg 1.8 sur N900

English: The Nokia N900 showing system informa...
Image via Wikipedia

Je traînais une vieille installation de Elgg, le logiciel de réseau social libre, que je rechignais à mettre à jour par paresse et par peur de perdre le précieux contenu que j’y avais mis. Ce contenu était d’ailleurs pollué par les innombrables articles publiés par des internautes (mon serveur étant ouvert) et j’ai décidé de faire du ménage. Malheureusement la version 1.7 ne dispose pas de fonction de suppression en masse des utilisateurs et de leurs contenus. C’est donc en modifiant en base que se fait l’épuration des milliers d’utilisateurs incongrus. Un oubli du mot clé not dans une requête SQL et c’est le drame: je supprime les bons utilisateurs dont moi et mes contenus !

Comme dans tout malheur il y a une bonne chose, j’installe la dernière version de Elgg, là 1.8.3 qui dispose d’un plugin pour affichage mobile. C’est un élément qui me manquait vraiment avec la version 1.7 ! Sans application dédiée, l’utilisation la version normal du site sur le N900 n’est pas très ergonomique.

Si l’installation du plugin mobilize sur Elgg 1.8.3 se fait sans encombre, la détection du N900 en tant qu’appareil mobile nécessite un petit travail supplémentaire. Il faut modifier le fichier <eldd_dir>/mod/mobilize/start.php pour ajouter le user agent maemo dans la fonction detectmobile() vers la ligne 45.

Squelette de projet python pour Maemo5

Le projet Pyjama est aujourd’hui dans un état presque utilisable. Pyjama est un outil écrit en python pour générer un squelette de projet python pour Maemo5. Il s’agit d’un “bootstrapper” à la manière du plugin archetype de maven.

Le principal objectif de Pyjama est atteint puisque la version disponible sous forme de source permet de générer un embryon d’application exécutable. Les sources générés comprennent des outils afin de gérer le messages d’informations, la remontée de bug via googlecode et les tâches asynchrones.

Le prochaine étape est la création d’une interface de saisie des paramètres du projet ainsi que d’une IHM pour Maemo5. Ainsi on pourra créer le squelette sur PC ou bien directement sur le terminal.

Autorotation des applications Python sous Maemo 5

A screenshot of the Maemo interface on a Nokia...
Image via Wikipedia

La rotation de l’affichage suivant l’orientation du terminal est devenue depuis la PR1.3 une fonctionnalité intégrée au bureau Hildon, si bien que toutes les applications sont encouragées à proposer également la rotation de leur IHM suivant la position du mobile.

La gestion de l’orientation se fait par interception et appel à l’Hardware Abstract Layer (HAL) par le D-Bus. Cela peut en rebuter plus d’un, mais heureusement un hacker (comprendre développeur) australien, Thomas Perl, propose une classe python qui s’occupe de la gestion de l’orientation. Cette classe fait partie de la version maemo5 de gPodder et est disponible en GPL3. C’est donc avec bonheur que toutes les applications python sous Maemo 5 (évidement en GPL3) peuvent accéder à l’autorotation.

La classe en elle-même possède un dépendance sur gpodder et il faudra alors modifier 2 lignes de code relatives à l’internationalisation afin de la réutiliser dans sa propre application. C’est ce que j’ai fait pour ajouter l’autorotation à Gnatirac.

Le libre c’est bon !

Prototype d’application python pour Maemo 5

Often called "albino", this amelanis...
Image via Wikipedia

La mise en place d’un nouveau projet python pour Maemo5 est consitituée de plusieurs étapes:

  1. création du référentiel de sources: ex: subversion chez google code
  2. création du projet sous ESBox
  3. ajout des fichiers pour setuptool
  4. ajout de l’arborescence initiale du projet (architecture)
  5. import des sources dans le référentiel
  6. enregistrement du projet sur PYPI
  7. création du site du projet: ex: blog chez blogspot
  8. création du groupe de discussion: ex: google group

La création des fichiers initiaux est une tâche rébarbative mais nécessaire pour d’une part industrialiser la production (build, déploiement et d’autre part assurer la qualité du code (architecture en couche, réutilisation…). D’un projet à l’autre ces étapes ne diffèrent que par les caractéristiques du projet:

  • Nom du projet
  • Nom de l’auteur
  • Licence du projet
  • Date de création
  • Nom de certaines classes etc.

En somme la phase d’initialisation du projet doit pouvoir s’automatiser. Un peu à la manière des archétypes maven, il serait intéressant de pouvoir générer à l’aide d’une commande (et d’un assistant) le squelette d’un nouveau projet qui compile et s’exécute !

Le projet Pyjama est sans doute le dernier que je crée par copier/coller d’un projet précédent. Pyjama doit en effet permettre la création de projet via une simple commande.

Client Picasa pour N900

English: Nokia N900 smartphone (display shows ...
Image via Wikipedia

Le N900 dispose d’une grande capacité de stockage (27 Go) mais cela n’élude pas le besoin de sauvegarde externe qui peut se faire par un script utilisant rsync automatisé par alarmed ou bien par l’utilitaire Caritang qui permet de transférer les médias (photo et vidéo) sur Picasa.

Nous nous intéressons au cas où les médias sont archivés sur Picasa. La consultation des médias ne peut pas se faire aisément sur le terminal. En effet, la version complète utilise un style d’affichage prévu pour les écrans d’ordinateur et non pas pour le petit écran du N900. De plus l’utilisation des javascript mettent déjà à mal la puissance faiblarde du N900 dont le CPU plafonne à 600 Mhz (voire 800 Mhz par overclocking) et l’avènement de nouvelles technologies telles que HTML5 vont rendre le navigateur du N900 inopérant sur les nouveaux sites. Finalement l’utilisation de la version web de picasa n’est donc pas une solution viable.

Un client spécific permettrait d’utiliser correctement les possibilités du terminal (écran, cpu) afin de rendre accessible les média archivés. Mais il semble que ce besoin n’ait pas eu d’écho dans la communauté des développeurs Maemo5: il n’y a pas d’application cliente Picasa pour le N900 ! Alors j’en ai développé une: Gnatirac. Gnatirac utilise le binding python de l’API Gdata pour Picasa Web et permet de naviguer dans les albums et les photos d’un compte picasa. Voilà, le N900 dispose de son client Picasa.

Créer un widget GTK en python sous Maemo5

GTK Widgets
Image by crafterm via Flickr

Dans le développement de Maegen j’ai eu envie de créer une vue affichant l’arbe généalogique de manière arborescente. Pour cela j’ai utilisé un gtk.DrawingArea dans lequel je dessine l’arbre. Les méthodes de dessin et les diverses variables sont portées par la fenêtre qui contient le gtk.DrawingArea.

L’envie de réutiliser cette arbre ailleur qu’en pleine fenêtre m’invite à en faire un widget à part entière que je pourrai mettre dans une fenêtre ou tout autre widget conteneur.

Le site learningpython montre un exemple de création de widget personnalisé et l’exemple fonctionne quasiment parfaitement sur Ubuntu 11.04. Quasiment car le widget ne s’affiche que si on redimensionne la fenêtre. Je me lance alors dans un refatoring pour extraire le code de dessin et le mettre dans une classe dérivant de gtk.Widget. Voir le code ici.

Le premier problème vient d’une inattention fébrile à l’idée de créer mon premier widget… L’oublie de la ligne suivante:

# register the class as a Gtk widget
gobject.type_register(MyOwnWidgetClass)

qui est obligatoire sinon la méthode __init__() de la classe gtk.Widget refuse de s’éxécuter sur la classe dérivée.

Malheueusement une fois cette ligne ajoutée, le widget reste définivement vide sans le moindre petit arbre dedans. En y regardant de plus près, la méthode do_expose_event() n’est pas appelée. Cela est encore pour moi un mystère…

Quoiqu’il en soit il y a un contournement qui consiste à dériver de gtk.DrawingArea pour créer mon widget. Cette solution est sans doute la plus simple compte tenu du fait que mon code de départ manipule un DrawingArea ! Le site suivant montre une telle réalisation : zetcode.com

Google Data API 2.0.15 et Maemo5 en python

.AVI en el N900Maegen, une application de généalogie pour Maemo5/N900 utilise le service googlecode de google pour la soumission de bug. Pour cela Maegen se base sur la librairie gdata fournie par google. Le code de rapport de bug a été écrit il y a plus d’un an et suppose que la version de gdata soit la 2.0.9 alors que la version courante est la 2.0.15

Ayant testé Maegen sur des machines différentes sur lesquelles des versions récentes de gdata étaient installées, je pensais qu’une dépendance de type au moins la 2.0.9 était une solution valable. Cela donne dans le fichier setup.py

setup(... install_requires=["gdata>=2.0.9"], ...)

Tout semblait marcher correctement puisque à la fois sur le terminal et les machines de développement (Virtual Appliance Maemo SDK), Maegen s’executait correctement, jusqu’à ce que je décide de passer sur une machine vierge (Virtual Appliance Maemo SDK) où jamais gdata n’avait été installé. Et là ce fut le drame, Maegen ne fonctionnait plus. La faute à gdata introuvable.

Une première solution est provoquer l’installation des dépendances. Pour cela se mettre sous l’environnement de compilation croisée

scratchbox

puis se placer dans le répertoire du projet

cd workspace/maegen

et enfin lancer une installation

python2.5 setup.py install

Lorsque les lignes cabalistiques ont fini de défiler, on remarque que gdata 2.0.15 a été installé. Le lancement de Maegen echoue cette fois sur l’absence du paquet json !

D’où vient le problème ? En regardant la version de gdata sur les machine où Maegen fonctionne, je remarque alors une différence: c’est la 2.0.14. Je désinstalle donc gdata 2.0.15 et installe la 2.0.14 à partir des sources dans scratchbox et là le miracle se produit: Maegen reprend vie !

En comparant le module gdata.gauth.py entre la 2.0.14 et la 2.0.15, on constate que des tentatives d’imports de json sont effectués à partir de la ligne 64 et finalement suppose que python 2.6 est utlisé en essyant un ultime import json, ce qui malheureusement échouera lamentablement sur le N900 qui ne dispose que de python 2.5 !

Voilà, le mystère est résolu, à moins de rajouter une dépendance vers json, je doit me résoudre à ne pas utliser la dernière version de gdata. Pour cela la directive de dépendance dans le fichier setup.py devient:

install_requires=["gdata>=2.0.9, <=2.0.14"]

En conclusion, les dépendances externes doivent être utiliser avec parcimonie et on doit éviter les dépendances ouvertes en leur préférant une dépendance exacte si possible. En effet moins il y a de dépendance, plus l’application est autonome et légère avec des risque de conflit de version en moins. De plus les dépendances ouvertes ouvrent la porte à une régression apportée par une nouvelle version.

Application généalogique sous Maemo 5/N900

Le N900 est un vieux smartphone qui ne bénéficie plus de l’attention de la communauté Maemo comme à ses débuts fin 2009. Il n’en reste pas moins à mon sens la machine improbable que tous les développeurs du libre et de l’open-source n’avaient osé espérer même si les puristes bouderont leur plaisir en arguant que certains composants du N900 sont propriétaires. Les alternatives comme openmoko ne sont pas au niveau technique ni d’ergonomie du N900.

Même si il s’agit d’une plateforme appelée à mourir, il y a encore des utilisateurs qui comme moi n’hésitent pas à se retrousser la chemise pour développer l’application manquante répondant à leur besoin. En l’occurrence il s’agit d’une application de saisie de relevés généalogique que j’ai appelé sans grande originalité Maegen.

Maegen permet la saisie des informations en mobilité puis de faire leur exportation au format GEDCOM pour les integrer dans tout autre logiciel final. L’interface de Maegen est spécifique au N900 ce qui lui permet d’être plus pratique qu’une application pure GTK de PC que le N900 peut exécuter. La contrepartie est que Maegen se concentre sur les données essentielles permettant de crééer des individus et leur relations.

L’application est disponible sur l’index des paquet python Pypi et dispose d’un Blog. L’installation se fait facilement pourvu que l’on dipose de easy_install sur le terminal. Il suffit alors de faire en temps que root

easy_install maegen

Actuellement l’application est utilisable pour des saisies basiques, l’export GEDCOM fonctionne, le tracé de l’arbre également. Une évolution possible serait l’utilisation du cœur de GRAMPS afin de bénéficier de l’expérience de ce projet et de mutualiser les efforts.

Multithreading avec GTK en python sur N900

Une application sous linux en python telle que Caritang doit résoudre le problème de réactivité de l’interface utilisateur en prenant en compte les spécificités suivantes:

  1. la thread principale qui execute GTK
  2. l’interpréteur python
  3. le serveur X

Une IHM se doit d’être réactive. Toute action de l’utilisateur doit provoquer une réponse immédiate de l’IHM. Or la mise à jour de l’IHM se fait quand la thread principal qui execute la boocle gtk sort du code appelé par l’évènement de l’interface graphique. Autrement dit ce n’est que lorsque le code créeé par le programmeur pour effectuer l’action est terminé qu’on est sûr que l’IHM sera mis à jour. Donc si le code de l’action n’est pas trés rapide alors on va monopoliser la thread principale de gtk à faire de l’applicatif au lieu de faire de l’IHM.
Quand on veut effectuer un traitement long, il faut lancer une thread dédiée à ce traitement afin de libérer la thread principale. Plusieurs techniques existent: on peut utiliser les fonctions utilitaires de gobject comme timeout_add ou bien une classe Timer ou alors créer soit même une Thread.
Quelque soit la technique il faut néanmoins indiquer à gtk qu’il va s,exécuter en multithreading en invoquant gtk.gdk.threads_init()

Libérer la thread principal permet à GTK de mettre à jour l’IHM. Ainsi si la thread du traitement modifie le texte d’un gtk.Label, la thread de GTK pourra mettre à jour l’IHM. Inversement l’IHM étant disponible, l’utilisateur peut demander la fermeture de l’application. Dans ce cas que se passe-t-il pour la thread de traitement? Soit elle continue en empêchant la fermeture du programme soit elle est brûtalement arrétée si elle est marquée comme deamon. Ce dernier cas n’est pas la meilleur solution car il entraine des erreurs dans la thread de traitement. Ainsi durant l’arrêt de l’interpréteur python, la thread de traitement se retrouve dépourvu des variables locales ou d’instances.
L’idéal est d’envoyer un signal à la tread de traitement pour qu’elle se termine proprement.

Enfin le serveur X (peut?) n’est pas “thread safe”. Malgrès tout ce qui précède il se peut que le thread principale de GTK accède à l’IHM en même temps que la thread de traitement. Une simple modification du texte d’un gtk.Label provoquera de manière aléatoire une erreur dans XLib. La solution est de protéger (synchroniser) les accès aux composants graphiques en encadrant toute modification de l’IHM dans la thread de traitement par gtk.gdk.threads_enter() et gtk.gdk.threads_leave()

Ajout d’un programme dans Hildon

Hildon est le nom de l’interface graphique du N900. Toute application qui veut s’intégrer à l’interface doit avoir une entrée dans la liste des programmes. Pour cela il n’est pas nécessaire de fabriquer une application “packagée” sous forme de paquet debian. Une simple installation de module python fait l’affaire.

La principale chose à faire est del créer un fichier du nom de l’application. Supposons que l’application s’appelle zourite. Il faut alors créer un fichier
/usr/share/applications/hildon/zourite.desktop
dont le contenu minimal sera:
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Name=Zourite
Exec=/usr/bin/zourite

La ligne Exec peut contenir une ligne de commande complète avec argument telle que /usr/bin/caritang -g

Ce fichier suffit pour que Hildon ajoute une entrée dans la liste des programmes.
Liste des applications dans Hildon

Maintenant si on veut que Hildon affiche une jolie icone, il faut la lui fournir. Avec le fichier .desktop minimaliste, hildon va rechercher les icones à l’emplcement par défaut sous le nom par défaut, à savoir:

/usr/share/icons/hicolor/48x48/hildon/zourite.png
/usr/share/icons/hicolor/64x64/hildon/zourite.png

Avec un minimum d’effort il est maintenant possible d’ajouter un raccourci sur le bureau.

Ajout d'un raccourci sur le bureau Hildon