Création de widget GTK+ en python sous Maemo5

En dépiThe new GTK+ logo.t de mon idée première de dériver de la classe gtk.Widget, ne maîtrisant pas toutes les subtilités de GTK+, je me suis rabattu sur la solution de spécialiser la classe gtk.DrawingArea.

La classe GenTree du projet Maegen illustre comment il est aisé de fabriquer ses propres widgets ! Dans cette exemple le widget n’est pas interactif et il se contente de se dessiner. C’est déjà un début.

L’interaction avec l’utilisateur se fera simplement en s’abonant aux événements et ne devrait pas poser de difficultés. Ma seule inquiètude se situe dans la capacité à s’interfacer avec les autres conteneurs GTK tels que les Aligment etc. Un widget bien élevé doit être capable d’adapter sa taille en fonction de son conteneur. Peut-on le faire avec un DrawingArea ?

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.

Retour de subversion sur le N900

The view of the front of a Nokia N900
Image via Wikipedia

L’évolution des distributions Linux consiste principalement à s’assurer que les divers logiciels puissent cohabiter entre eux, notamment en vérifiant les dépendances des logiciels vis-à-vis des librairies. Ainsi une simple incompatibilité d’un logiciel avec la version d’une librairie centrale ou d’un logiciel phare de la distribution suffit à écarter celui-ci.

Sous Maemo 5, il existe un paquet subversion qui a cessé de fonctionner depuis une récente mise à jour (PR1.3?). En effet subversion crash sur un segmentation fault. La raison en est la dépendance de subversion vis-à-vis de la librairie APR (Apache Portable Runtime) qui a changé de version mais est devenu incompatible avec le paquet subversion.

Malheureusement le paquet subversion pour N900 est devenu orphelin. Son mainteneur ne va pas repackager une version compatible avec la dernière version de la distribution du système (voir ce thread sur le forum maemo.org). Heureusement que le système de gestion de paquet permet de forcer la version des librairies … Au risque d’introduire de nouvelles incompatibilié.

Ainsi pour refaire fonctionner subversion il suffit de lancer la commande suivante en root

apt-get install libaprutil1=1.3.9-2 libapr1=1.4.2-1

Les versions sont celles qui fonctionnaient avec le paquet subversion pour Maemo 5 au moment où il a été créé.