QRezix

qRezix est le principale client xNet encore maintenu. Il doit sa survie à sa qualité d'être le seul client développé qui soit multiplateforme tout en restant graphiquement potable. Il doit ces deux qualités à la bibliothèque Qt.

Historique

BR2000

Le projet en lui-même est né avec un groupe de BRmen X2000 menés par Doudou qui était un fan de Qt (qui à l'époque n'était pas terrible-terrible...). Ils ont travailler à 3 ou 4 pour sortir la version 1.0 le 4 mars 2002, suivi de près par la version 1.1 le 6 avril qui suivait. L'équipe de développement comportait entre autres Doudou, MadCoder et Trasfract (Sylvain Joyeux, Pierre Habouzit et Benoït Casoetto).

Le projet s'est principalement inspiré des clients qui existaient déjà à l'époque (Rezix en particulier, duquel qRezix a tiré son nom, car en fait ce n'était qu'un implémentation en Qt de cet ancien client). Cette architecture simple est une fenêtre avec une liste de client chaque entrée indiquant le nom, la promo, les serveurs... Les favoris sont affichés en premier selon le choix de l'utilisateur.

BR2001

Le BR2001 n'a pas énormément travaillé sur qRezix. Il y a eu la version 1.2, mais on a aucune trace de ce que JiBee a bien pu faire sur le projet. Ce qui est certain, c'est qu'après la vesion 1.2, il a travaillé sur l'internationnalisation du projet. Le but d'origine n'était pas de rentre qRezix internationnal, mais simplement de résoudre les problèmes d'encodage des caractères accentués. Le code source a donc totalement été traduit en anglais et une traduction français a été créée.

JiBee a également porté qRezix de Qt2 à Qt3 ce qui a entraîné un blocage des release : Qt3 n'était en effet pas utilisable pour compiler qRezix légalement sous Windows...

JiBee a travaillé relativement seul sur le projet avec le support de Ey.

BR2002

Le projet était géré par Steak. La version 1.3 a été release le 1 mai 2004. Cette version n'était absolument par révolutionnaire mais apportait quelques améliorations dans la structure du code et des amélioration du comportement du programme.

Steak a ensuite travaillé sur la version 1.3.666 et en particulier sur l'authentification avec le serveur. Mais il a vite arrêter de travailler sur qRezix en raison du temps qu'il consacrait à l'étude du japonnais entre autre, et à différents problèmes occulaires. Cependant, le BR2002 a réalisé une prépassation très avancée ce qui fait que dès le mois de juin, la relève était en place...

BR2002/BR2003 : le temps d'une prépassation

Le BR2003 a commencé sont travail sur qRezix dès le mois de juin 2004. Et c'est moi qui m'en occupait déjà :).

La première chose a été de recompiler une version pour Windows, ce qui n'avait plus été fait depuis près d'un an. Ceci permettait donc d'envisager de futures release du programme pas uniquement sous Linux. Le travail s'est finalement concentré pendant les vacances d'été avec une amélioration importante de l'interface et de la structure interne (début de séparation de la gestion des connexions de l'affichage), la création d'une structure (pas terrible) de chargement de plug-ins, l'ajout d'icône pour rendre l'interface plus conviviale... La version a été tagguée tour à tour 1.3.666 puis 1.5.

Une autre innovation importante à été le passage du chat qui reposait un protocole en UDP vers un protocole TCP. Le but déclaré du BR2002 étant de rendre les communication fiables et sécurisées (on veut savoir si l'autre ne reçoit pas nos messages).

Toutes ces modifications associées au travail de Steak sur l'authentification et le travail de JiBee pour recoder un nouveau serveur xNet , on conduit à la version 1.6 de qRezix qui est sorti le 14 octobre 2004 à la fois pour Windows, Linux et Mac OS X.

Face à qRezix 1.6.0 est apparu Rezix.NET qui se voulait innovant. Conséquence de ceci, on a travaillé à 2 avec Steak pour implémenter dans qRezix toutes les fonctionnalité des Rezix.NET. Ce qui a rapidement conduit à la sortie de qRezix 1.6.1 le 22 novembre 2004. C'était la dernière version sur laquelle ait travailler Steak.

BR2003

La suite a été plus calme. La préparation de qRezix 1.6.2 s'est faite tranquillement, l'objectif principal était de supprimer un maximum de bugs de cette future version. Les innovations n'ont pas été nombreuses, mais on pourra noter la completion du nick dans le chat avec tab et la recherche intelligente via clavier. Cette version a vu le retour de Ey parmi les développeurs. Elle a aussi été la seule version à bénéficier d'une sortie ayant été précédée de 2 release-candidates qui ont aidées à corriger plusieurs bugs supplémentaires. La version a finalement été sortie le 22 mars 2005.

Le problème de cette version est qu'elle a introduit un bug... enfin plutôt révélé un bug. Jusqu'à présent qRezix plantait en l'absence de réseau ce qui a été corrigé avec la 1.6.2. Mais ce que je n'avais pas remarqué à l'époque c'était qu'en l'absence de réseau qRezix raffraichissait la fenêtre toutes les secondes et en même temps changeait le thême d'icône. Conséquence directe de ce défaut, qRezix prenait 100% du processeur en l'absence de réseau, ce que j'ai eu la chance de constater lors de ma soutenance de modex... Il fallait donc sortir un version avant l'arrivée des 2004 pour éviter que ce bug ne pose trop de problème aux 2004 qui allaient passer leur soutenance de stage. C'est pour ça qu'est sortie la verson 1.6.3 le 1 mai 2005. Cette version innovait au passage une nouvelle organisation plus agréable des propriétés et peut-être globalement considérée comme stable.

Ceci n'a pas empêcher de continuer de développer cette branche avec la préparation de qRezix 1.6.4 qui devrait sortir dans les prochains jours. A part 2-3 bugs corrigés, cette version n'innove pas vraiment si ce n'est pas son intrégration améliorée à Mac OS et sa cache des propriétés.

Mais après un an de travail sur qRezix, j'étais enfin prêt pour le grand ménage. Même si pendant toute l'année je me suis efforcer d'améliorer la structure du code de qRezix pour le rendre plus modulaire et surtout plus maintenable, je n'avais jamais vraiment révolutionner le projet. Avec la sortie de Qt4 en juin, j'ai commencé à porter le code, et je n'ai pas pu m'empêcher de quasiment tout réécrire. Conséquence : le programme sera désormais modulaire, l'interface est repensée, le programme est plus léger en mémoire... Pour l'instant il a le numéro de code 1.7.0, mais il est fortement probable que cette version deviendra qRezix II vu l'importance des modifications du programme.

Pour écrire cette partie, j'ai utilisé mes connaissances personnelles issue de mon année et des brouettes d'expérience au BR ainsi que les informations contenues dans le ChangeLog.

Développement

Cette partie a pour but de présenter brièvement l'état du projet à travers l'organisation du développement.

Outils nécessaires

• Le développement de qRezix se fait comme tous les projets du BR via un système de partage de projet : SVN. Il est donc nécessaire d'installer un client SVN pour travailler. Sous Linux et Mac OS, il y a des packages de SVN qui sont distribuer. Sous Windows, il est fortement conseillé d'utiliser TortoiseSVN. Pour plus d'information sur SubVersion, merci de vous référer à la page correspondante.

* Il faut également installer Qt, la version dépend de la branche de travail. Pour qRezix 1.6, il faut utiliser Qt3 (3.3.3 ou ultérieure) alors que pour qRezix 1.7, Qt4 (4.0.1 ou ultérieure). Pour obtenir Qt3 pour Windows, merci de demander à Fruneau. Pour Qt4, il faut faire attention sur certaine distribution de bien installer tous les modules nécessaires (au moins Core, GUI et Network) et les outils qui vont avec (designer, linguist, assistant).

• Pour générer la documentation il peut être intéressant d'installer également Doxygen. La plupart du temps l'utilisation de Doxygen est très simple : il suffit de l'appliquer au fichier Doxyfile qui se trouve à la racine du projet.

doxygen Doxyfile

Structure de la SVN

Pour ce qui est de l'utilisation de SVN, je vous laisse vous référer à la page correspondante. Cette partie à plutôt pour but d'expliquer comment utiliser la SVN pour travailler sur qRezix.

Tout d'abord, il est important de noter que qRezix utilise une structure tout ce qu'il y a de plus classique (avec trunk, branches et tags). Le trunk étant la branche principale du projet.

Travailler sur la branche principale

La branche principale du projet correspond à la version qui évolue actuellement. A l'heure actuelle c'est la 1.6.x. Cette branche change régulièrement et on peut y trouver les dernières innovations réalisée sur cette branche. Lorsqu'on s'approche d'une release de qRezix, il faut freezer la branche principale. Pour ceci, on sépare le développement de la version qui va sortir de celui de la branche principale.

Par exemple pour release qRezix 1.6.4, j'ai freezé la branche environ 1 semaine et demi avant la sortie via :

svn copy trunk branches/qrezix--release--1.6.4

Une fois les branches séparées, la branche de release ne doit plus subir que des corrections de bugs. En cas de besoin, on pourra sortir des pre-release (rc). Une fois qu'une version est considérée stable, on la tag, c'est à dire qu'on fait une photographie instantannée du projet :

svn copy branches/qrezix--release--1.6.4 tags/qrezix--1.6.4-rc1 # pour une préversion
svn copy branches/qrezix--release--1.6.4 tags/qrezix--1.6.4 # pour la version définitive

On peut même envisager alors des révisions sur la version actuelle qui serait des bugfixes de la branche de release intervenu après la sortie. Dans ce cas, on aurait

svn copy branches/qrezix--release--1.6.4 tags/qrezix--1.6.4-r1 # pour une révision de la version

Ceci peut paraître contraignant, mais c'est la base d'un projet mené correctement. Ca permet d'avoir un historique des branches et des versions, de pouvoir envisager de sortir des révisions de toutes les branches de release en cas de découverte d'une faille importante du programme et ça évite surtout d'avoir une version qui s'éternise... lorsqu'on décide de freezer une version, ceux qui veulent continuer à innover travaillent sur le trunk pendant que d'autres stabilise la version de release.

Branches de devel

A côté de la branche principale, il peut y avoir des branches de devel. Alors que la différence entre 2 releases issues d'une même branche sont le plus souvent mineures voire de la simple maintenance, la différence entre le trunk et la branches de devel est quelque chose de beaucoup plus important. La branche de devel apporte des innonvations importantes et devrait conduire à une nouvelle version majeure du programme.

Actuellement, on a une branche de devel : branches/qrezix--qt4 qui est pour l'instant nommée qRezix 1.7 mais devrait être renommée qRezix 2 à terme. La branche de devel peut évoluer dans l'ombre un certain temps avant de sortir. Avant de sortir, on pourra tagguer plusieurs versions en alpha ou beta.

svn copy branches/qrezix--qt4 tags/qrezix--2.0.0-beta1

Lorsque la branche de devel est prête à être sortie, elle vient remplacer le trunk. Pour ceci il faut opérer dans l'ordre :

• Sauvergarder l'ancien trunk

svn move trunk branches/qrezix--1.6 # ceci n'étant plus une branche de release, on ne met pas le release

• Déplacer la branche de devel vers le trunk

svn move branches/qrezix--qt4 trunk

• Créer la branche de release de la version initiale de la nouvelle version majeure du programme

svn move trunk branches/qrezix--release--2.0.0

• Et puis là on est revenu au point précédent :)

Numérotation des versions

Comme pour tout programme, qRezix a des versions numérotées de la forme X.Y.Z-T

• X est la version majeure, il ne change que lors de modification très importantes de la structure du programme.
• Y est la version mineure, il change lorsque le programme a subit des évolution plus importante qu'une simple maintenance.
• Z est la version de maintenance, il change lorsque le programme subit des bugfixes et l'implémentation de fonctionnalités mineures.
• T est le tag

L'utilisation du tag est particulières :

• alpha pour une pré-version non encore formalisée d'une nouvelle version majeure ou mineure du programme (2.0.0-alpha1 ou 1.7.0-alpha2 mais pas 1.6.5-alpha1)
• beta pour une pré-version formalisée d'une nouvelle version majeure ou mineure du programme (2.0.0-beta1 ou 1.7.0-beta2 mais pas 1.6.5-beta1)
• rc pour une version candidate à la release. Elle sert uniquement à la recherche de derniers bugs (1.6.2-rc1)
• r pour une révision d'une version déjà sortie. Elle sert uniquement à corriger de graves anomalies de la version (1.6.4-r1)

Documentation

La documentation de qRezix est composée de cette page, de la doc de l'API qu'il est possible de générer grâce à Doxygen, ainsi que de tout ce que vous pourrez trouver sur cette page. Dans tous les cas, la meilleure doc restera toujours une personne qui connait bien le projet :)...

Dans l'état actuel des choses, la meilleure doc de qRezix, c'est moi.

Branche 1.6

Structure du programme

La structure interne du programme peut-être résumée au schéma suivant :

Ce schéma n'est pas exhaustif, mais met en évidence les différentes imbrications des éléments. Toutes les cadres qui se chevauchent (et le cas échéant se contiennet) représente des classes qui sont imbriquées l'une à l'autre. Ansi la classe QRezix qui gère la totalité du programme est totalement dépendante de la quasitotalité des autres classes, la classe RzxConnectionLister dont le but est de lister les personnes est complètement dépendante de RzxRezal et vice-versa (il y a même des redondances de stockage)... idem, pour le chat qui est géré partiellement par RzxConnectionLister et partiellement par RzxRezal.

La classe RzxComputer a une importance réduite et la quasitotalité de ses données sont redondantes avec RzxItem. De plus certaines informations de RzxComputer sont stockées directement par RzxConfig, qui est elle-même à moitié implémentée par RzxProperty.

En résumé, la structure (déjà modularisée comparée à la version 1.2 dans laquelle RzxConnectionLister n'existait pas et était partie intégrante de RzxRezal) n'est pas facilement maintenable.

Interface de plug-ins

qRezix 1.6 est la première version à bénéficier d'une structure d'accueil de plug-in. Cette structure est rudimentaire et souffre du fait que qRezix n'est pas modulaire. En effet la classe RzxPlugIn est compilée à la fois dans le plug-in et dans qRezix, ce qui crée des problèmes dès que les deux versions diffèrent.

Pour éviter les problèmes, la version de la strucutre de plug-in est numéroté de façon très stricte, et le filtrage est fait au chargement du plug-in.

Ce défaut entraîne un grand nombre de complication. Les plug-ins n'ont absolument aucun accès direct aux données stockées par qRezix. Toutes les informations transitent donc par des fonction standardisées du plug-in, mais cette méthode de travail limite le nombre d'information pouvant être échangé. Il n'en reste pas moins que cette structure est tout à fait suffisante pour réaliser des plug-ins comme l'Xplo ou SmiliX (qui sont disponible sur la SVN dans le reposoire qrezix-plugins).

Pour pouvoir faire un plug-in pour qRezix, il faut récupérer la dernière version de rzxplugin.h et rzxplugin.cpp dans la branche de release de qRezix correspondante à la version pour laquelle vous voulez faire le plugin. Il suffit alors de créer un projet dérivant de RzxPlugIn. La documentation de RzxPlugIn peut-être générée automatique à l'aide de Doxygen et peut-être trouvée ici, de même pour la documentation du plug-in Xplo qui permet d'avoir un bon exemple de plug-in complet.

Cette structure a totalement disparue avec qRezix 1.7 pour être remplacer par des modules plus souple et mieux conçus.

Branche 1.7

Objectif

Cette version de qRezix repose sur un double objectif :

• porter le code en Qt4.
• modulariser le programme.

Qt4

Le premier point ne présente pas une difficulté énorme, mais a conduit à pas mal de réorganisation du code. En particulier, qRezix 1.7 bénéficie de la puissance du nouveau système Model/View de Qt4, ce qui a nécessiter de redévelopper la quasitotalité de l'interface principale.

La toute dernière version SVN de qRezix utilise Qt version 4.0.1 minimum, la version 4.0.0 comportant un certain nombre de bugs (en particulieurs dans certaines templates) qui empêchent la compilation du programme.

Modularité

La modularisation du programme est un point essentiel. Elle apporte un certain nombre d'évolution nécessaire à la survie de qRezix :

• restructuration du programme qui permet une meilleure maintenance
• possibilité de limiter qRezix à certaines fonctionnalités (utile pour l'utilisation chez des personnes qui n'ont pas besoin d'avoir le logiciel complet si par exemple ils n'utilisent jamais le chat).
• possibilité de travailler avec un plus grand nombre de personne sur le projet. Chacun pouvant en effet travailler sur un module
• possibilité de gérer plusieurs protocoles pour se connecter à plusieurs serveurs

Structure du programme

Le schéma suivant représente de manière simplifié la structure interne de qRezix 1.7.x :

Bien que le nombre d'élément soit impressionnant, cette structure est beaucoup plus propre que celle de qRezix 1.6. Le schéma montre en effet en particulier que les éléments sont proprement séparé, les seuls dépendances entre les modules qu'il peut y avoir sont gérées par la bibliothèque principale.

Le RzxComputer a acquis un rôle beaucoup plus important, il gère désormais la totalité des informations concernant une machine et inclus les actions qu'il est envisageable d'effectuer (propriétés, chat, http, ftp...). Le chat est géré par les modules qui se déclarent comme supportant cette fonctionnalité, de même pour les propriétés.

La fenêtre de préférences (RzxProperty) génère dynamiquement la page de propriétés en fonction de ce que les modules installés désirent. Et tout est mis en oeuvre (au travers de classe abstraites regroupant tous les outils nécessaires) pour que chaque module puisse créer simplement ses propres classes de configuration.

Les modules peuvent être construit soit en built-in soit en plug-in. Aucun n'est nécessaire au fonctionnement du programme (enfin si on retire tous les protos réseau, programme perd beaucoup de son intérêt).