jan 09

Lors du premier article de la série BehindCVK, nous vous avions brièvement parlé du noyau ou Kernel du CVK. Nous allons maintenant approfondir cette partie de notre architecture.

Le Kernel peut être considéré comme le chef d’orchestre des plugins. Lorsqu’il est seul, rien ne se passe, mais il est pourtant indispensable au fonctionnement du CVK car il effectue différents rôles majeurs :

  • Il possède et propose le contexte (état) courant du CVK, c’est-à-dire les claviers disponibles, avec chacune de leurs touches, les commandes associées, ….
  • Il découvre dynamiquement les plugins installés sur la machine
  • Il gère les dépendances entres ces plugins
  • Il gère la persistance de chaque plugin

1) Le contexte

Le contexte est l’état du CVK à un instant donné. C’est la représentation des claviers et tous les éléments qui les composent. Voici les éléments qui composent le contexte :

Le contexte CVK

  • Keyboards : Liste des claviers disponibles
  • Modes : Liste des modes disponibles pour un clavier (Maj, Alt, Ctrl …)
  • Zones : Liste des zones qui composent le clavier. Ce sont des zones fonctionnelles qui servent à regrouper des touches (Zone du pavé numérique, zone de flèches …)
  • Keys : Liste des touches contenues dans la zone. Elles contiennent des ActualKeys
  • ActualKeys : Liste des actions pour une touche dans un mode donné. Chaque touche ayant un comportement différent selon le mode, ce sont les ActualKeys qui possèdent le label et l’action à effectuer.
  • Layouts : Ils représentent la disposition des touches. Pour un même clavier, il est possible d’avoir plusieurs dispositions. Par exemple, Il est possible de changer la position de certaines touches pour obtenir des claviers AZERTY et QWERTY
  • LayoutZones : Groupement de KeyLayouts correspondant aux Zones du clavier
  • KeyLayouts : Contient les informations relatives au positionnement de chaque touche.
  • CurrentMode : Mode actuellement utilisé
  • CurrentLayout : Layout actuellement utilisé
  • CurrentKeyboard : Clavier actuellement utilisé

Le contexte est sauvé dans un fichier XML, il est donc possible de publier ce fichier afin de le partager avec d’autres utilisateurs. Ainsi un ergothérapeute ayant configuré un contexte spécifique à un handicape peut diffuser ce contexte aux personnes concernées.

2) Découverte des plugins

Les plugins CVK sont en réalité des assembly (Fichier .dll). Pour les installer, il suffit d’ajouter des fichiers dans le dossier « Plugins » du répertoire d’installation. C’est donc le rôle du Kernel de parcourir ces fichiers, de les identifier comme plugins puis de les charger dans l’application.

3) Gestion des dépendances

Chaque plugin à la possibilité d’utiliser d’autres plugins. CVK gère différents niveaux de dépendances entre ces plugins :

  • Optional : Le plugin utilisé peut ne pas être présent
  • OptionalTryStart : Le plugin utilisé peut ne pas être présent. Dans le cas où il est présent et arrêté, le Kernel essaiera de le démarrer.
  • MustExist : Le plugin utilisé doit être présent même arrêté
  • MustExistTryStart : Le plugin utilisé doit être présent . Dans le cas où il est présent et arrêté, le Kernel essaiera de le démarrer.
  • MustExistAndRun : Le plugin utilisé doit être présent et démarré.

En fonction des dépendances, le Kernel démarre ou non chacun des plugins. Par exemple si un Plugin-A déclare avoir besoin d’un Plugin-B en MustExistAndRun et que ce Plugin-B n’est pas présent, le Plugin-A sera désactivé. Cela implique que si un autre plugin à besoin du Plugin-A il sera désactivé à son tour et ainsi de suite.

4) Gestion de la persistance

Afin de centraliser l’ensemble des données à persister, le Kernel propose à chaque plugin un dictionnaire permettant de stocker des données ce qui facilite le travail des développeurs de plugins.

Par exemple un plugin peut stocker un paramètre comme ceci :
dictionnaire[‘monParametre’] = true ;

Il peut ensuite l’utiliser comme cela :
if( (bool)dictionnaire[‘monParametre’])

De manière automatique, le paramètre « monParametre » sera persisté et rechargé par le Kernel sans aucune action du plugin.

En réalité il est possible de sauver des données sur différent éléments :

  • Configuration «User», si la machine possède plusieurs comptes utilisateurs. Les plugins peuvent sauver des paramètres spécifiques à chaque utilisateur.
  • Configuration « Machine», les paramètres sont communs à tous les utilisateurs d’une même machine.
  • Configuration «Context», les paramètres sont sauvés dans le fichier du contexte. Si ce fichier est diffusé et utilisé sur une autre machine, les paramètres seront rechargés.
  • Il est ensuite possible d’affecter des paramètres sur chaque élément du contexte. Cela permet, par exemple, d’affecter une couleur de touche à tout le clavier et d’affecter une autre couleur à une touche en particulier. Ainsi toutes les touches du clavier auront une couleur sauf celle qui a reçu le paramètre spécifique.

Episode 3 : La gestion des plugins.
Episode 4 : Les editeurs.
Episode 5 : La configuration des plugins.

mai 29

Voici le premier article d’une petite série qui consiste à vous présenter le fonctionnement sous-jacent du CVK (et pourquoi il est promis à un grand avenir).

 

Au premier coup d’œil à part plusieurs graphismes attrayants les concurrents du CVK n’ont rien à lui envier, mais regardant de plus près… le terme « Custom » prend tout son sens.

 

En creusant un peu, on observe plusieurs grandes parties dans notre architecture :

 

  • Un noyau (que nous appelleront Kernel) qui contient l’intelligence utile pour générer le comportement des claviers en termes de logique.
  • Un système de gestion de plugins (extensions) permettant de faire évoluer le clavier très simplement sans remettre en cause ce qui à déjà été fait.

 

Cela constitue la base « solide » du CVK.. Voir la suite »

mai 19

L”équipe est composée de huit élèves et est suivie par deux enseignants. Parmi ces élèves, deux ont été désigné comme chef de projet. L’un devant gérer le développement du noyau de l’application, l’autre de l’interface utilisateur.

Afin de travailler dans de bonnes conditions, l’équipe CVK utilise différentes méthodes et outils (Ide, intégration continue, …) nous vous en reparlerons dans un article à venir.

Toute l’équipe se réunit une fois par semaine afin de rendre compte de l’avancement du projet mais aussi pour définir les tâches à venir. Suite à ces réunions, les chefs de projets doivent synthétiser et répartir ces tâches sur les deux outils utilisés : un wiki type wikipedia et Microsoft Project.

Exemple de msProject

L’ensemble de l’équipe consulte ensuite régulièrement ces tâches afin de les réaliser au mieux. Nous faisons un bilan hebdomadaire avec nos suiveur le Mercredi après-midi

mai 06

Nous sommes heureux de vous présenter ce nouveau canal de communication autour de l’équipe CVK In’ Tech INFO 2008.

Le projet :

Le Custom Virtual Keyboard (CVK) est un clavier virtuel, personnalisable et gratuit. Il permet aux personnes atteintes d’un handicap de pouvoir utiliser un clavier au même titre que n’importe qui. Le logiciel se présente sous la forme d’un clavier qui apparaît sur votre écran d’ordinateur et, par le biais d’une souris et/ou de contacteurs (boutons d’interruption), de cliquer sur le caractère voulu pour simuler l’appui d’une touche au clavier.

Cette année le projet est divisé en deux équipes:

  • Une equipe technique qui développe la V2 du logiciel CVK en .Net.
  • Une partie communication qui monte une structure Open Source autour du projet et qui organise un évènement pour la Release.

Gràce à ce Blog vous allez pouvoir nous suivre en direct.

A très Bientot.

qsdqsdqsd