Sortie de java-gnome 4.0.16 et le futur

Il y a quelques jours, le 17 juin 2010 pour être précis, une nouvelle version de java-gnome est sortie. Cette dernière, numérotée 4.0.16, apporte comme toujours son lot d’amélioration. Il y a eu tout de même moins de modifications par rapport à ce que l’on a pu voir précédemment mais quand même. Une nouvelle version apporte toujours un peu de neuf (ou de vieux remis à neuf) et ça fait plaisir.

1. Nouvelle version : 4.0.16

Ainsi, java-gnome comporte maintenant le support complet pour l’utilisation des “accelerators” (on peut peut-être traduire par “raccourcis”), qui sont des combinaisons de touches permettant d’activer des actions et des entrées dans les menus. Je pense que bon nombre d’entre nous connaissent le très classique CTRL + Q pour quitter un programme. Le coeur de l’API se situe dans la classe AcceleratorGroup mais il faudra aussi utiliser les méthodes setAccelerator() des classes MenuItem et Action. L’API native étant presque incompréhensible, le travail pour porter tout ça en Java a été assez conséquent.


De manière plus rapide, le support des opérateurs utilisables avec Cairo a été ajouter avec la classe Operator. Une bonne quantité d’exemple en image en montre le principe (images bien entendu générées avec java-gnome lors de la construction de la documentation. Le style CENTER a été ajouté dans la classe ButtonBoxStyle. Les fichiers .defs on été mis à jour pour prendre en compte les modifications apportées par GTK 2.18 et et le widget InfoBar a été ajouté (effectués par votre serviteur). Les interfaces Activatable et Editable ont reçu quelques changements tout comme la classe Glib qui comporte une nouvelle méthode formatSizeForDisplay() permettant de formater un taille d’octets en une chaîne de caractères plus lisibles pour nous humains. Enfin, une dernière méthode ensureNative() a été ajoutée à la classe Window de GDK.

2. Le futur

En tant que contributeur et avec les autres personnes travaillant sur java-gnome, nous nous sommes aperçu que maintenir un jeu de fichiers .defs pour générer la partie non publique de l’API commençait à être compliqué. Nous avons alors changer un peu le plan prévu. C’est pourquoi, en ce moment, certains travaillent sur l’utilisation du projet GObject Introspection pour générer une partie de l’API. C’est probablement le meilleur moyen d’avoir une source donnée la plus complète et la plus à jour afin de garder les bindings les plus proches des dernières versions des bibliothèques natives. Cependant, la migration vers GObject Introspection demande un travail long et délicat puisqu’il faut réécrire une partie du générateur de code que l’on sait stable puisqu’il commence à prendre de l’âge. J’espère tout de même que l’on aura quelque chose de fonctionnel assez vite afin de tester et stabiliser le code le plus rapidement possible.

Le futur de java-gnome prévoit de bonnes surprises, c’est certain. Tout ça dans le but d’améliorer encore l’API telle qu’on la connaît et de toucher un public toujours plus grand.