Cerealizer 0.7 is out!

It now allows to dump() things repeatedly to a stream or file, and then load() things repeatedly out of it.

Many thanks to Peter Eckersley !

J'ai enfin trouvé comment traduire les applis de Cacko sur le Zaurus... en fait l'original est en anglais, des fichiers de traductions ont été ajouté pour le japonais, puis enlever pour retourner à l'anglais... il suffit donc d'en refaire pour la langue de Colin Marchika (écrivain français pas du tout connu mais très bon... pourquoi dirait-on toujours "la langue de Molière" ? il est pas le seul à la parler, cette langue !).

Du coup les traductions sont en cours et vont bientôt se retrouver en jolis petits paquets IPKG ici !

A new version of Soya, 0.14rc1, is out. This release includes many bugfixes and has been updated for latest release of Pyrex. It also includes a new GUI module called soya.gui (see the gui-* tutos for demo).

Here is the complete changelog:

• January 2008 : Soya3D 0.14rc1

• Allow the centre of mass of a Body to be anywhere in its local coordinate system (thanks Greg Ewing)

• Improve tutorial README (thanks Jacques Rebourcier)

• Update for Pyrex 0.9.6.2 (thanks Greg Ewing)

• Blender => Cal3D can now run with Python 2.3 (thanks Greg Ewing)

• New GUI module soya.gui

• Bugfixes:

• Fix the weird segfaulting bug in terrain (thanks Souvarine)

• Fix GL_INVALID_ENUM crash with the OSS ATI DRI driver (thanks Zoltan Dome)

• Fix data/worldS and data/blender in the yet-in

• Fix speed-1.py tuto

• Fog was activated by error on partial camera with no atmosphere

• Fix descender computation in font

• Fix ODE on terrain (tuto ode-collision-8-terrain.py)

Voici mon fond d'écran pour Zaurus. Quelques astuces :

• Avec Cacko, un fond d'écran en JEPG est beaucoup plus rapide qu'un fond d'écran en PNG ! Donc préférer ce format.

• L'écran du Zaurus n'affiche "que" 64 000 couleurs, ce qui provoque des "sautes" de teinte dans certains dégradés (lorsque le dégradé couvre plusieurs teintes). Pour éviter ça, on peut faire du tramage (dithering). Dans Gimp, je n'ai pas trouver d'autre moyen que de passer l'image en couleurs indexées (dans le menu image puis mode, en activant le tramage des couleurs) puis de la repasser en RGB (il doit sans dout y avoir un moyen mieux de faire du tramage, si quelqu'un a des idées je suis preneur !). Cette opération réduit le nombre de couleurs utilisées, et cache cela en "étalant" les pixels. Du coup il n'y a plus les sautes de couleurs dans les dégradés. Par contre, il y a un léger effet "granuleux", mais sur l'écran très fin du zaurus ça ne rend pas forcément mal !

La connection d'un Zaurus a un vidéo-projecteur, c'est un peu la quête du Graal ou la pierre philosophale dans le monde du Zaurus : tout le monde veut le faire mais personne n'y arrive... et je l'ai fait ! Petit Zaurus peut maintenant avoir un grand écran. Petit mais costaud ! Bien sûr il n'est pas question de projeter de la vidéo mais seulement des images fixes (diaporama).

Récapitulons les étapes :

1. Le CFXGA, accessoire officiel de connection Compactflash => VGA pour Zaurus, est épuisé et totalement introuvable.

2. Sur un forum russe (j'avoue, je ne parle pas un mot de russe, mais google sait traduire !), j'apprends que tous les accessoires de type Compactflash => VGA ont le même chipset, et fonctionne donc de la même manière... et donc avec les Zaurus ! Il y a une demi-douzaines de modèles : Prolink PK201 et PK203, Pretec CompactPresenter, Margi Presenter-to- go, Colorgraphics voyager VGA, LifeView FlyPresenter CF.

3. Bien sûr, tous sont épuisés. Manifestement, les interfaces Compactflash ne sont plus à la mode...

4. EBay, Amazon,..., c'est nul : impossible de trouver un de ces accessoires d'occasion.

5. Par contre, les petits revendeurs, c'est bien ! En fouillant bien je trouve (là encore, traduisez avec google) :

   • Une boutique au Danemark qui vend des Prolink PK203

   • Une boutique en Grèce qui vend des Pretec

   • Une autre boutique en Grèce qui vend des Pretec

   • Une boutique en Israel qui vend des Prolink

   • HP aux états-unis qui vend des Colorgraphics Voyager

   • Un site de matériel spécifique pour personnes handicapées, en France qui propose un appareil ressemblant furieusement à un Colorgraphics Voyager

6. Je contact la boutique au Danemark, pas de réponse... la première boutique grec refuse de livrer en France... mais la seconde accepte pour la "modique" somme de 150€ ! Donc je saute sur l'occasion.

7. Je reçois l'engin 3 semaines plus tard

8. Il existe un driver pour le Pretec dans la ROM Cacko que j'utilise. Manque de bol, le driver est pour un noyau Linux 2.4.18 alors que les Zaurus récents ont un noyau 2.4.20. Donc pas compatible... Il suffirait de recompiler les sources, mais seuls les sources du driver originel pour le CFXGA sont disponibles, et pas celles pour le Pretec !

9. C'est l'occasion de s'essayer à l'ingénierie inverse. XDelta m'apprend qu'il n'y a que deux octets de différences entre les driver compilé pour noyau 2.4.18 pour le CFXGA et pour le Pretec ! Ensuite, objdump -D m'apprends que ces différences se situent dans des segments de données appelés "crt_800x600x60x16" et "crt_640x480x72x16" que je retrouve dans les sources. Et ça compile !

10. Vient le moment d'essayer... alors je branche mon Zaurus à un moniteur via le Pretec ; j'obtiens quelques images puis tout se met à planter. C'est l'hécatombe : les processus meurent sans raison apparente !

11. En supprimant une à une les fonctions dans le driver et dans le programme "mirroir" (cfxgamirror) qui lit l'écran du Zaurus (FrameBuffer) et écrit dans la carte Pretec, j'obtiens la conviction que le problème ne vient pas de l'écriture dans la carte, mais bien de la lecture du FrameBuffer ! Cela colle avec des messages de forum indiquant le même type d'erreur avec des CFXGA sur les Zaurus récents.

12. La lecture du FrameBuffer est faite via une série d'appel à mmap auquel je ne comprends pas grand chose... je vire tout ça et je le remplace par une simple lecture du fichier /dev/fb0

13. Et là... ça marche :-)

Plus d'info sur le forum Zaurus FR.

Et voilà, petit Zaurus a terminé son apprentissage de Python. J'ai cross-compilé Python 2.5.1 depuis quelques semaines déjà, et maintenant je viens d'achever la compilation de PyQt sur le Zaurus lui-même (le module utilisant trop de référence à des chemins diverses pour que la cross-compilation soit aisée).Ce PyQt est lié à l'interface Qt embarqué qui est l'interface "native" avec la ROM d'origine de Sharp comme dans la ROM dérivé Cacko. Il est donc possible de développer des applis Zaurus graphiques entièrement en Python ! (Astuce : utiliser le module qtpe de PyQt pour avoir un rendu qui prenne en compte les paramètres de Cacko ; sinon on a un rendu Qt "de base" avec des polices minuscules qui ne tiennent pas compte de la taille de l'écran du Zaurus).

Comme d'habitude, les paquets sont ici.

Petit à petit, petit Zaurus deviendra grand !

Et voilà, petit Zaurus à commencer à apprendre le français. Désormais son bureau est dans la langue de Molière !

J'ai tout bien empaqueté dans des IPKG. Pour passer le bureau de la ROM Cacko en français, il suffit désormais d'installer les 4 paquets suivants (disponibles ici) :

• fr-locales

• fr-libqpe

• fr-config

• fr-translation-desktop

Et c'est tout ! Les paquets se chargent d'installer et de modifier les fichiers de configuration nécessaires.

Un seul détail : les icônes du bureau sont traduites lors de l'installation du paquet fr-desktop-translation. Donc les icônes des logiciels installés APRÈS ce paquet ne sont pas traduites. Dans ce cas, il faut désinstaller fr-desktop-translation et le réinstaller.

Pour repasser le Zaurus en anglais, il suffit de désinstaller les 4 paquets.

Pas de vacances pour les petits Zaurus indisciplinés ! Aujourd'hui petit Zaurus à commencer à apprendre le français ; pas grand choses pour l'instant. Juste les "locales", qui permettent d'avoir les paramètres linguistiques du français (par exemple 0,1 au lieu de 0.1), ainsi que les traductions... si elles existent (ce qui n'est évidemment pas le cas pour l'instant).

Voilà la recette magique pour passer la ROM Cacko en locales françaises :

1. installer les locales françaises proprement dites qui sont ici.

2. éditer le fichier /home/zaurus/Settings/locale.conf, et remplacer "Language = en" par "Language = fr"

3. éditer /home/zaurus/.profile et /opt/QtPalmtop/qpe.sh, et ajouter dans ces deux fichiers :

export LANG=fr
export LANGUAGE=fr
export LC_ALL=fr

1. créer le répertoire /opt/QtPalmtop/i18n/fr, copier dedans le fichier /opt/QtPalmtop/i18n/en/libsl.qmid, et créer dedans un fichier .directory avec ceci :

[Desktop Entry]
Name=French

1. à ce moment là, le Zaurus est paramétré en français... mais la police par défaut devient minuscule. C'est ici que tout le monde bloque... Après de longues recherches infructueuses, voici la recette pour les remettre normalement (ça vient d'un forum russe, encore un ! vous allez finir par croire que je parle russe mais pas du tout !) : il "suffit" de prendre le fichier /opt/QtPalmtop/lib/libqpe.so.1.5.0, de l'éditer avec un éditeur hexadécimal (genre khexedit) et de recherche "helvetica". Il y a un occurrence vers la fin du fichier, précédée de "en". On remplace "en" par "fr", on enregistre, et sur le zaurus, on supprime /opt/QtPalmtop/lib/libqpe.so.1.5.0 (qui est un lien vers un truc inamovible) et on le remplace par la version modifiée.

Et on a enfin le Zaurus en mode français. Bien sûr, si on le repasse en anglais, on aura les polices minuscules... mais quel intérêt de le remettre en anglais ?

Maintenant il reste à faire les traductions... vu que apparemment rien n'existe en matière de traduction en français... bref petit Zaurus a encore du boulot pour apprendre le français !

Lorsque j'ai adopté ce petit Zaurus (un PDA / mini ordi portable sous Linux), je m'attendais à avoir des problèmes avec le matériel : écran ou clavier trop petits, cartes mémoires ou cartes d'extension mal supportés,... éh bien non : on se fait vite à la taille de l'engin, même en étant très myope (la forte résolution de l'écran n'y est sans doute pas pour rien), et les problèmes de compatibilité matérielle ont été vite réglé par un reflashage de ma carte wifi.

En revanche, c'est le logiciel qui pose problème : le Zaurus est une petite machine têtue et indisciplinée ! Sharp a arrêté la production de Zaurus début 2007, depuis la moitié des sites oueb en relation avec le Zaurus sont morts (non seulement inanimés mais souvent "erreur 404"). Pour le logiciel, on a le choix entre plusieurs ROM (équivalent des distributions Linux). Il y a donc Cacko, une ROM stable et fonctionnelle mais pas remis à jour depuis 3 ans, et une demi-douzaine de ROM toutes plus instables les unes que les autres, mais avec la dernière version du noyau Linux... bref je me retrouve donc évidemment avec la première ROM, puisque je veux quelque chose qui marche !

Mais comme elle date de 3 ans, je suis obligé de compiler quelques logiciels récents. C'est là que l'enfer de la "cross-compilation" commence... Le Zaurus n'est pas assez puissant pour compiler ses propres logiciels, et il n'a pas les fichiers de développements nécessaires. C'est donc à "maman" de faire les compilations... dans un langage machine qui n'est pas le sien (le Zaurus ayant un processeur ARM). Ce qui est particulièrement délicat...

Du coup j'ai sorti l'artillerie lourde : une batterie de script Python ! Petit Zaurus indiscipliné, tu me feras tourner ton LyX et ton Python !

Pour Noël mon ordinateur a mis bas. Voici des photos de la maman et du bébé !

I'm currently working on a new widget system for Soya.

It will feature advanced widgets such as scroll panes or flying windows, as well as a nice automatic dimensioning system, even better than GTK and Tk ones !

For now, I'm focusing on the widget's logic, and not on their graphical aspect.

The final goal being to add Soya's support to EditObj 2, in order to be able to generate dialog boxes in Soya for editing various game objects. Can be usefull for game editor but also for many complex games (roleplaying games, strategy games,...). I'm precisely thinking about new game projects in that area.

Here are some screenshots using various styles :

Songwrite 2 0.1.2 fixes a few bugs that were remaining in 0.1 and 0.1.1, namely :

• Guitar pro importer was missing

• Fix copy / paste of notes with alterations on staffs

• Fix view name translation

• Fix "AttributeError: 'ObjectPack' object has no attribute 'song'" when selecting notes

• Fix copy-paste between different windows

You can get it there.

Here is a first stable release of Songwrite 2!

Songwrite 2 is a tablature editor for Linux, written in Python with GTK and Cairo. A tablature is a guitar partition ; Songwrite 2 supports many string instruments in addition to traditional staffs.

With Songwrite 2 you can...

• ... edit tablatures (guitar, bass, banjo,...) and staff, and add lyrics to write your own songs !

• ...create your own songbook

• ... play your partitions

• ... print your partitions and your songs

• ...convert automatically staffs to tablatures and tablatures to staffs

• ...export your songs into many formats (PDF, Midi, ASCII tablatures, GNU Lilypond, LaTeX, PostScript,...)

• ... import Guitar Pro 3 / 4 file (experimental)

Songwrite 2 is a complete rewrite of Songwrite 1 with :

• A new interface based on Gtk 2 and Cairo, with anti-aliasing

• A new staff rendering engine, now handling tonality and alteration correctly

• A new plugin system

• A new documentation

• Printing support updated for recent version of Lilypond (2.11.20 and above)

This is the very first release of EditObj 2.

It is a full rewrite of EditObj 1, and it now supports both Tk and Gtk 2.