Je code donc je suis

Suite à cette news annonçant l’exclusion du binding Gstreamer de la nouvelle version de Ruby-GNOME2 je me pose des questions.
En effet j’utilise RG2 dans Geekast et le binding GStreamer m’est utile pour afficher des vidéos et lire des flux audios.

J’envisage de réécrire Geekast en gtkmm, de manière à bénéficier d’un meilleur binding et surtout des avantages d’un langage compilé : réactivité, ressources moindres et capacité à monter en charge. Cependant cette tâche nécessite de réellement maîtriser le C++ et gtkmm. Un effort certain mais qui le vaut si l’on souhaite faire évoluer son logiciel sans être limité par un langage script.

Cependant pour de nombreux petits logiciels sans prétention que tout un chacun peut vouloir développer, le C++ est sans aucun doute “overkill”. Il n’y a qu’à voir le succès de PyGTK pour comprendre qu’un binding de qualité est nécessaire à Ruby. En tant qu’ancien développeur sur Windows j’ai développé en Windev(arg) et VisualBasic(re-arg) et même si ces technologies sont repoussantes, le principe de pouvoir produire un logiciel en quelques clics et lignes de codes est important en entreprise.
Sur ce secteur, Ruby tout autant que Python ont cette capacité contrairement aux C/C++/Java/C#/... . Il nous manque surtout un framework desktop façon Ruby on Rails ou Django.

Aussi je ne peux me résoudre à abandonner le binding Ruby-GNOME2. Grâce à Rails, Ruby a pu faire connaître sa valeur de langage objet exceptionnel. Il serait profitable aux entreprises de ne pouvoir utiliser en interne que ce langage, au lieu de disperser ses forces sur une multitude de langages et technologies différentes.

Microsoft via sa plateforme .NET propose justement aux entreprises de pouvoir n’utiliser qu’un seul langage que ce soit pour faire du web ou du desktop. Par exemple ASP.NET qui n’a plus rien à voir avec l’ancien ASP permet de développer une application web en C# ou VB.NET. En choisissant C# ou VB.NET une entreprise peut aussi bien développer la même application en web et desktop.

En OpenSource rien de tout cela. Certes nous avons l’ovni Mono qui est une implémentation libre de .NET, mais il est par définition toujours en retard sur son modèle et de plus est sous l’épée Damocles des nombreux brevets déposés par Microsoft sur l’API .NET.

Ruby on Rails de part son succès foudroyant a permis de faire comprendre l’intérêt d’un framework. Toutes personnes ayant repris le code PHP d’une autre personne est à même de comprendre cela.

Il en sera de même avec les applications desktop. Le problème est que contrairement au web celui-ci n’est pas universel. Autant pour le web on a réussi à faire comprendre l’intérêt des standards grâce essentiellement à firefox et la fondation Mozilla, autant le standard du desktop se résume aux 97% du monopole de Windows. Ceci explique les différentes tentatives de desktop web pour le rendre universel. Je doute toujours de l’intérêt que ce soit pour les développeurs que pour les utilisateurs.
En effet même avec AJAX et des bibliothèques JS, cela reste une vraie souffrance à simuler des fenêtres et une barre de tâche quand on a déjà utilisé une bibliothèque desktop comme GTK+ ou Qt. De plus l’accès au matériel est impossible en web, AJAX ou pas, et un lecteur multimédia ne pourra pas exister sans l’aide de Flash.
Pour ce type d’application avancée souhaitant ménager la chèvre et le choux, la plateforme de Mozilla est rêvé, voir par exemple le lecteur songbird et le futur gros hit Joost qui utilisent entre autres XUL.

Cependant XUL est spécifique au moteur de Firefox, et Firefox est encore très loin d’être le navigateur web majoritaire. Via XUL et xul-runner, on en revient finalement aux bonnes vieilles applications desktop…

XUL n’est qu’un HTML doppé permettant d’obtenir des objets graphiques modernes sur une page web et le développement d’une application desktop complexe nécessite l’utilisation du C++ ou du binding Python PyXPCOM.

On en revient donc aux mêmes contraintes qu’une application GNOME ou KDE, si ce n’est que ces dernières sont capables de communiquer avec leur desktop. Une application Mozilla ne s’intégre bien qu’avec … Firefox. Viser l’architecture Mozilla c’est viser le multi-plateforme en effet mais c’est se limiter énormément des capacités du desktop et de la communication entre les applications. Or cet aspect est très important pour les utilisateurs.

XUL et la plateforme Mozilla a bien sûr un intérêt énorme. Cependant quand on fait le pari du desktop Linux en entreprise, pari de plus en plus crédible, les capacités de communication entre les applications et l’intégration au desktop sont essentiels dans un environnement professionnel. Or ni le web AJAXé ni XUL ne peuvent y répondre. A moins de faire le pari des terminaux ne lançant que Firefox, pourquoi pas, mais à court/moyen terme en milieu professionnel non.

Pour finir ces digressions, le premier qui proposera un framework desktop à la Rails arrivera certainement a pousser son architecture, et Ruby y a sans aucun doute sa place.

Certains le savent peut être, j’utilise les signaux de la Glib dans Geekast.

Il ne s’agit pas ici des signaux de GTK+, comme “clicked” déclenché sur le clic d’un bouton. Il s’agit de créer ses propres signaux pour ses besoins personnels. Des signaux applicatifs donc.

Ces signaux m’ont servi de base comme outil me permettant d’architecturer mon logiciel sur un modèle MVC. On peut voir ma documentation à ce sujet sur l’ancien wiki : Implémentation d’un motif de conception (pattern) MVC par signaux.

Même si cette approche est intéressante, elle était contraignante car il était nécessaire de définir tous les signaux dans la classe Signal ; créer son signal et la méthode associée, même si elle n’est pas utilisée.

J’ai finalement réussi à générer les signaux à la volée en utilisant plusieurs fonctionnalitées de Ruby, tel que le method_missing et le define_method qui permet d’ajouter une méthode à la classe d’un objet.

On peut voir ce que ça donne en comparant l’ancienne version de la classe, signal_old.org avec la nouvelle : signal.rb, ou via le diff.

Au niveau de l’usage, le code est peu impacté, mais il est nécessaire maintenant de donner en paramètre de la méthode connect, les types envoyés dans le block, exemple :

   def jabberBuffer
     @sig.connect("CjabberBuffer",['Integer','String','Time'])
         {|channel, buffer, time|
           puts "toto"
         }
   end

Ici on se connecte au signal CjabberBuffer. Ce signal reçoit 3 paramètres de type entier, chaîne et heure.

La méthode connect de la classe Sig n’existant pas, la méthode method_missing est appelée automatiquement. Celle-ci récupère les divers paramètres et le block de code envoyé. Elle créée la méthode du signal puis le signal lui même. Ensuite elle appelle la méthode lconnect qui connecte le block de code au signal créé.

Simple à utiliser. Même si le code de la classe Sig n’est peut être pas dans l’absolue très propre, il exploite certaines capacités excellentes de Ruby.

De plus il permet d’apporter au plus grand nombre l’usage des signaux. Cela pourra peut-être devenir une brique de base à un futur “framework”.