Quelle disposition utiliser pour un clavier visuel ?

Le développement de CiviKey avançant il est temps de se poser la question de la disposition des touches. Historiquement l’interface a toujours suivi les dispositions des claviers physiques : un clavier Azerty et un clavier Qwerty comportant toutes les touches d’un clavier normal, avec pavé numérique et touches de fonctions.

Pourtant ce n’est pas forcément la solution la plus ergonomique, aussi bien pour un utilisateur valide que pour un utilisateur handicapé. Heureusement de nombreuses personnes se sont posés la question avant nous, comme Maxime Baas, Yohan Guerrier et Christophe Kolski qui ont publié deux articles traitant de la question, intitulés « Etude comparative entre clavier virtuel de type AZERTY et K-Hermès, destinés à des utilisateurs souffrant d’une Infirmité Motrice Cérébrale » et « Système de saisie de texte visant à réduire l’effort des utilisateurs à handicap moteur ». Le premier étant une comparaison entre deux claviers, un AZERTY (Clavicom NG) et le clavier K-Hermès dont les touches possèdent trois lettres et sont disposées en fonction des probabilités avec les lettres suivantes (par exemple dans la langue française le ‘q’ est souvent suivi du ‘u’, donc la touche contenant ‘u’ sera proche de la touche contenant ‘q’). Le second étant une recherche de disposition idéale visant à réduire l’effort aussi bien physique que psychique des utilisateurs du clavier.

Nous avons donc essayé de tirer de ces articles une définition du « clavier idéal », voici les points qu’il doit respecter :

  • Le nombre de touches du clavier doit être minimum.
  • Les touches retour et espaces étant les touches les plus utilisées sur un clavier, elles doivent être très facilement et rapidement accessibles, voire même multiples.
  • La prédiction de mot / de lettre, doit être intégré au clavier nativement et ne doit pas être une surcouche complexe à utiliser. Elle doit faire partie du comportement normal du clavier.
  • La disposition des touches ne doit pas forcement être calculée en fonction des touches les plus probables mais doit plutôt pouvoir être mémorisée très facilement. (Limiter le nombre de touches participe à ce point.)
  • Toujours dans l’optique de réduire le nombre de touches, il faut utiliser toutes les possibilités des périphériques d’entrée afin de supprimer les touches de changement de mode : le clic gauche peut envoyer une lettre en minuscule tandis que le clic droit envoi une majuscule, d’autre modes peuvent être activés par un clic long gauche et droit par exemple.
  • La grille n’est pas la meilleure solution : dans une grille, chaque touche est entourée au maximum de quatre autre touches… un placement en quinconce permet d’entourer chaque touche de six touches au maximum.

Voici donc la nouvelle disposition, disposée en tenant compte des points cités ci-dessus :

Cette disposition est évidemment amenée à évoluer mais elle représente le standard de ce que doit être un clavier visuel qui doit être plus facile à utiliser qu’une reproduction directe d’un clavier physique.

Les opérations sur les modes de clavier

Les Keyboard Modes ont chacun (cf. le post précédent), une liste des modes atomiques qui les composent : c’est un ensemble au sens mathématique du terme et les caractéristiques et opérations traditionnelles sur les ensembles sont utiles dans notre cas :

  • L’ensemble vide : Θ est notre mode vide (EmptyMode).
  • L’union : « Ctrl + Shift » U « Ctrl + Frigo » = « Ctrl + Shift + Frigo »
  • L’intersection : « Ctrl + Shift » ∩ « Ctrl + Frigo » = « Ctrl »
  • La soustraction : « Ctrl + Shift » - « Ctrl + Frigo » = « Shift »

Les prédicats suivants sont pratiques :

  • ContainsOne (teste que l’intersection de deux modes est non vide) : X.ContainsOne( Y ) <=> X ∩ Y != Θ
  • ContainsAll (teste qu’un mode est totalement contenu dans un autre) : X.ContainsAll( Y ) <=> X ∩ Y = Y

La liste des modes atomiques est ordonnée (selon la comparaison de chaîne ordinale évoquée précédemment) et cette propriété permet d’implémenter les différentes opérations efficacement. L’idée est d’avancer deux index dans les 2 listes (Gauche contient m éléments et Droite en contient n) à traiter en comparant les éléments : à chaque comparaison, on détecte un élément à gauche uniquement, à droite uniquement ou dans les deux.

Lorsque les deux éléments sont égaux, on peut avancer les deux index simultanément, sinon seul l’un des index avance : au pire des cas il y a donc m+n comparaisons et dans le meilleur des cas min(m,n).

L’implémentation repose sur une unique fonction qui applique l’algorithme ci-dessus sur les deux listes et qui est paramétrée par 3 prédicats (des fonctions booléenes prenant un élément en paramètre) :

static void Process( KeyboardMode left, 
                     IKeyboardMode right, 
                     Predicate<IKeyboardMode> onLeft, 
                     Predicate<IKeyboardMode> onRight,  
                     Predicate<IKeyboardMode> onBoth );

Ces prédicats sont appelés dans l’ordre d’apparition des modes atomiques dans les deux modes left et right selon que l’élément apparait à gauche uniquement, à droite uniquement ou dans les deux. Ces fonctions peuvent retourner false pour arrêter le processus. Process est utilisé pour toutes les opérations sur les modes.

Une seule fonction : pour combien d'opérations différentes ?

Voyons d'abord l'implémentation des deux prédicats.

Les prédicats ContainsOne/ContainsAll

ContainsOne est peut-être la plus simple : dès qu’un élément commun est trouvé, on peut conclure positivement et arrêter le processus. Il suffit donc de fournir une fonction qui arrête le processus et mémorise le succès dans le cas où un élément a été trouvé dans les deux listes.

bool IKeyboardMode.ContainsOne( IKeyboardMode mode )
{
  bool found = false;
  Process( this, mode, 
           null, 
           null,
           delegate( IKeyboardMode m ) { found = true; return false; } );
  return found;
}

ContainsAll est presque identique : c’est le cas « à droite seulement » qui est pisté et l’opposé qui est retourné car si on trouve un mode à droite seulement, c'est que c'est un "alien" qui ne devrait pas être là. (C'est une façon de parler, hein! Les étrangers ont bien le droit d'être là, sinon où serions nous ?)

bool IKeyboardMode.ContainsAll( IKeyboardMode mode )
{
  bool foundAlien = false;
  Process( this, mode,
           null,  // Use lambda syntax below instead of delegate keyword.
           m => { foundAlien = true; return false; }, 
           null );
  return !foundAlien;
}

Un Process, deux prédicats. Il est temps d'aborder les opérations plus complexes.

L’intersection

L’intersection est la plus simple des combinaisons : seuls les éléments qui apparaissent dans les deux listes doivent apparaitre dans le résultat final. On utilise donc une fonction (paramètre onBoth) qui ajoute l’élément à une liste (un collecteur) et continue le processus.

Problème : il nous faut donc appeler la méthode List.Add (qui ne retourne rien) alors que la méthode Process attend un prédicat (une fonction qui retourne un booléen).

Le code est le suivant :

IKeyboardMode IKeyboardMode.Intersect( IKeyboardMode mode )
{
  List m = new List<IKeyboardMode>();
  Process( this, mode, null, null, Adapter.AlwaysTrue<IKeyboardMode>( m.Add ) );
  return Context.ObtainMode( m );
}

L’adaptateur qui suit permet d’envelopper (wrapper) une action dans un prédicat toujours vrai :

public class Adapter 
{
  static public Predicate<T> AlwaysTrue<T>( Action<T> a )
  {
    return delegate( T o ) { a( o ); return true; };
  }
}

L’air de rien, ces quelques lignes mettent en œuvre simultanément les génériques, les fonctions anonymes et la clôture.

Personnellement je trouve ça superbe et c’est - à mon humble avis - un exemple de code qui démontre bien la puissance de ce drôle de langage que devient C#.

J’ai cependant essayé de trouvé plus élégant, l’appel devenant par exemple :

// Perfection (at least for me)… Sadly, it does not work.
var actionAlwaysTrue = m.Add.ToPredicate( true ); 

Malheureusement, cette solution (une méthode d’extension sur le delegate Action) ne permet que d’écrire :

var actionAlwaysTrue = ((Action<IKeyboardMode>)m.Add).ToPredicate( true );

Car la méthode Add doit être explicitement considérée comme un delegate afin que les méthodes d’extension puissent s’appliquer. De même, la forme suivante n’est pas syntaxiquement correcte :

// Not perfect… And does not work.
var actionAlwaysTrue = Adapter.ToPredicate( m.Add, true ); 

Le compilateur exige la définition explicite du type, celui-ci ne pouvant être inférée par le type de l’action, ce qui nous ramène à :

var actionAlwaysTrue = Adapter.ToPredicate<IKeyboardMode>( m.Add, true ); 

Alors, en désespoir de cause, je préfère conserver mes deux petits helpers AlwaysTrue (et AlwaysFalse) :

var actionAlwaysTrue = Adapter.AlwaysTrue<IKeyboardMode>( m.Add );

L’union, la soustraction et le toggle

L’union se définit ainsi : que l’élément apparaisse à droite, à gauche ou dans les deux, il doit apparaitre dans le résultat final. C’est donc la même fonction qui est fournie aux 3 cas et qui ajoute l’élément à la liste (le collecteur).

IKeyboardMode IKeyboardMode.Add( IKeyboardMode mode )
{
  List<IKeyboardMode> m = new List<IKeyboardMode>();
  var add = Adapter.AlwaysTrue<IKeyboardMode>( m.Add );
  Process( this, mode, add, add, add );
  return Context.ObtainMode( m );
}

Ici, j’ai utilisé var pour définir la variable car le contexte est suffisamment explicite et l’algorithme suffisamment simple. En règle générale, je type explicitement mes variables : d’expérience le code est nettement plus lisible et maintenable ainsi.

La soustraction consiste à ne conserver que les modes qui apparaissent à gauche :

IKeyboardMode IKeyboardMode.Remove( IKeyboardMode mode )
{
  List<IKeyboardMode> m = new List<IKeyboardMode>();
  Process( this, mode, Adapter.AlwaysTrue<IKeyboardMode>( m.Add ), null, null );
  return Context.ObtainMode( m );
}

Le petit dernier est le « Toggle ». Intuitivement, il s’agit de l’opération qui « inverse » l’état d’un mode particulier, par exemple :

  • Toggle( « Ctrl + Shift », « Ctrl » ) => « Shift »
  • Toggle( « Shift », « Ctrl » ) => « Ctrl + Shift »

En quelques mots: si le mode est présent je le retire, sinon je l’ajoute. Evidemment, cela doit fonctionner avec plusieurs modes :

  • Toggle( « Ctrl + Shift », « Ctrl + Frigo » ) => « Shift + Frigo »
  • Toggle( « Shift + Frigo », « Ctrl + Frigo » ) => « Ctrl + Shift »

Ce toggle est trivial à implémenter grâce à la fonction Process car il suffit simplement de collecter ceux qui sont à gauche, ceux qui sont à droite, mais pas les éléments communs.

IKeyboardMode IKeyboardMode.Toggle( IKeyboardMode mode )
{
  List<IKeyboardMode> m = new List<IKeyboardMode>();
  var add = Adapter.AlwaysTrue( m.Add );
  Process( this, mode, add, add, null );
  return Context.ObtainMode( m );
}

This is the end. Mais j’ai pourtant eu envie de continuer…

Toutes les opérations possibles ?

Intrigante cette fonction Process qui permet de tout implémenter. A-t-on oublié des opérations intéressantes ?

Mon idée est de me servir de Process pour vérifier que je n’ai rien oublié : le tableau suivant recense toutes les utilisations possibles de la méthode d’ajout à un collecteur (il y a 3 slots, chacun pouvant être null ou add, il y a donc 23 = 8 possibilités).

onLeft    onRight    onBoth    Name & description    Comments
null null null “Empty” Useless.
null null add Intersect (keep commons) Implemented. Kind of symmetric of ‘Toggle’.
null add null “Cleanup” (keep theirs only) Useless since it is the symmetric of ‘Remove’
null add add “Other” (keep theirs and commons, reject mine) Useless. Opposite of ‘This’.
add null null Remove (keep mine only) Implemented. Opposite of ‘Cleanup’
add null add “This” (keep mine and commons and reject theirs) Useless. Opposite of ‘Other’.
add add null Toggle (keep mine, theirs, but reject commons) Implemented.
add add add Add Implemented.

Ces 4 fonctions couvrent bien l’ensemble des opérations sensées. Vous certainement pas, mais moi, ce constat me rassure Smile.

 

PS: Pourquoi le tableau ci-dessus est-il en anglais ? Parceque qand je code, je "suis" en anglais. Et que ce tableau, je l'ai fais dans le code.

Keyboard Modes version 2.5

Ce billet est le premier d’une série consacré aux Modes d’un clavier. Il explique la modélisation et l’implémentation des Modes dans CiviKey. D’autres billets traiteront notamment des points suivants :

  • Les Modes se combinent, s’intersectent, se contiennent : quelles sont les opérations de base que doivent supporter les modes et surtout comment les implémenter efficacement ?
  • Le « Fallback d’un Mode », où comment calculer de la meilleure à la pire les combinaisons de modes qui découlent d’un mode combiné. Ci-dessous un exemple :
    1. « Ctrl » + « Frigo » + « Shift »
    2. « Ctrl » + « Frigo »
    3. « Ctrl » + « Shift »
    4. « Frigo » + « Shift »
    5. « Ctrl »
    6. « Frigo »
    7. « Shift »
    8. «»
    Combien y-a-t-il de fallbacks en fonction de du nombre de modes atomiques ? Comment les générer ?
  • La gestion de « AvailableMode » et « CurrentMode »
    Le fait est que sur un clavier, il y a deux collections de modes très différents : les modes possibles et les modes courants. Exemple de modes possibles « Alt+Ctrl+ Frigo+Word » et de modes courants « » (aucun) ou « Ctrl+ Frigo ». Le fait de supprimer un mode possible entraîne nécessairement la suppression de celui-ci des modes courants, ce qui entraîne la suppression des KeyMode et LayoutKeyMode qui étaient définis par ce mode…
  • Le « Fallback » des KeyMode et des LayoutKeyMode : le Mode courant d’un clavier pilote le comportement (KeyMode) et l’affichage (LayoutKey) d’une touche (Key). Quelle implémentation efficace pour la gestion des touches peut-on envisager ?

 

Un cache centrale : un objet, un mode.

Les Modes sont totalement « objectivés ». Les objets IKeyBoardMode ne peuvent être obtenus que via l’objet Context : sa méthode ObtainMode( string m ) se charge de la normalisation et de trouver l’objet-mode correspondant dans un cache interne (de le créer et de l’y ajouter si besoin). Grâce à ce cache, les « objets-modes » sont uniques (dans le cadre d’un Contexte) : il n’y a qu’un et un seul objet « Ctrl + Shift » (il y a également un unique EmptyMode – le mode vide qui correspond à la chaîne vide).

L’empreinte mémoire est diminuée et on peut se servir de ces « objets-modes » pour porter de la donnée potentiellement plus lourde (ce que l’on va exploiter pour stocker la liste des fall backs de chaque mode) et comme clef efficace de hash (l’identité de l’objet garantit celle du mode).

IKeyboardMode m = Context.ObtainMode( "Alpha+Beta" );
Assert.That( Context.ObtainMode( "\r++\t Beta ++ Alpha ++" ) == m, 
                                        "Canonical ordering and trimming." );

Combined & Atomic Modes : les débuts de l’implémentation

Ces deux types de modes doivent rentrer dans un moule commun : le design pattern du Composite s’impose. Tout mode expose donc les modes atomiques qui le composent.

public interface IKeyboardMode : IComparable<IKeyboardMode>
{
    /// <summary>
    /// Gets the <see cref="IContext"/>. 
    /// </summary>
    IContext Context { get; }

    /// <summary>
    /// Gets the atomic modes that this mode contains.
    /// </summary>
    IReadOnlyList<IKeyboardMode> AtomicModes { get; }

    /// <summary>
    /// Gets a value indicating whether this mode contains zero 
    /// (the empty mode is considered as an atomic mode) or only one atomic mode.
    /// </summary>
    bool IsAtomic { get; }

}

Comme le montre le support de l’interface correspondante, les modes sont comparables (en mathématique, on dit que l’on peut définir une relation d’ordre – strict ou total, au choix – sur l’ensemble des modes) ce qui permet de les ordonner (donc de les trier) en s’appuyant sur la chaîne de caractères normalisée, mais avec une astuce :

 public int CompareTo( IKeyboardMode other )
 {
    if( _modes == other ) return 0;
    int cmp = _modes.Count - other.AtomicModes.Count;
    if( cmp == 0 ) cmp = StringComparer.Ordinal.Compare( other.ToString(), _mode );
    return cmp;
}

Tout mode contenant plus de mode atomique qu’un autre est plus grand. Si les deux modes ont autant de modes atomiques l’un que l’autre, alors la chaîne est utilisée. Cela est rendu possible grâce à la normalisation des chaînes de modes (ordonnancement des modes atomiques du plus fort au plus petit séparés par des +), et il faut inverser la comparaison : « Ctrl » est meilleur que « Shift » (alors qu’il est « plus petit » dans l’ordre lexicographique).

Toutes les opérations liées aux modes utilisent la comparaison ordinale : elle est plus rapide et tout aussi solide que celle indépendante de la culture (sous réserve de normaliser les chaînes, au niveau de la représentation interne de l’Unicode, ce qui est fait dans ObtainMode).

Dans l’implémentation, on retrouve les 3 types de modes (vide, atomiques, combinés) via les 3 constructeurs :

class KeyboardMode : IKeyboardMode
{
  Context _context;
  string _mode;
  IReadOnlyList<IKeyboardMode> _modes;

  /// <summary>
  /// Initializes the new empty mode of a Context.
  /// </summary>
  internal KeyboardMode( Context ctx )
  {
    Debug.Assert( ctx.EmptyMode == null, 
                                "There is only one empty mode per context." );
    _context = ctx;
    _mode = String.Empty;
    _modes = ReadOnlyListEmpty<IKeyboardMode>.Empty;
    _fallbacks = new ReadOnlyListMono<IKeyboardMode>( this );
  }

  /// <summary>
  /// Initializes a new atomic mode.
  /// </summary>
  internal KeyboardMode( Context ctx, string atomicMode )
  {
    _context = ctx;
    _mode = atomicMode;
    _modes = new ReadOnlyListMono<IKeyboardMode>( this );
    _fallbacks = ctx.EmptyMode.Fallbacks;
  }

  /// <summary>
  /// Initializes a new combined mode.
  /// </summary>
  internal KeyboardMode( Context ctx, string combinedMode, IReadOnlyList<IKeyboardMode> modes )
  {
     Debug.Assert( combinedMode.IndexOf( '+' ) > 0 && modes.Count > 1, 
                            "There is more than one mode in a Combined Mode." );
     Debug.Assert( modes.All( m => m.IsAtomic ), "Provided modes are all atomic." );
     Debug.Assert( modes.GroupBy( m => m ).Where( g => g.Count() != 1 ).Count() == 0, 
                            "No duplicate in atomic in modes." );
     _context = ctx;
     _mode = combinedMode;
     _modes = modes;
  }
}

Notez l’utilisation des helpers ReadOnlyListEmpty et ReadOnlyListMono. Le premier implémente la liste des modes du mode vide : le mode vide ne contient aucun mode. Le deuxième implémente les modes d’un mode atomique : un mode atomique contient un seul mode atomique : lui-même.

Attention ! Note importante !

Un mode est immuable (immutable in English), exactement comme une chaîne de caractère en C# ou en Java. Ce qui veut dire qu’ajouter un mode à un mode existant en faisant (en utilisant une des opérations qui feront l'ob jet d'un prochain billet) :

m.Add( m2 );

aboutit à… rien de rien de nada. Comme pour les chaînes de caractères, il faut faire

m = m.Add( m2 )

car toutes les opérations sont des fonctions (qui seraient décorées par des const - http://www.parashift.com/c++-faq-lite/const-correctness.html - en C++ mais ce modificateur n’existe malheureusement pas en C#).

ObtainMode : le cœur

La méthode ObtainMode est centrale à la gestion de ces objets. Elle gère le cache qui est un dictionnaire dont la clef est la version normalisée de la chaîne de caractère d’un mode. Sans être complexe, son implémentation effectue le moins possible d’opérations et elle est un peu longue à commenter de façon détaillée ici. Le code source est disponible ici : https://svn.invenietis.com/svn/CK/Core/trunk/CK.Context/Context/KeyboardMode.cs (anonymous/anonymous)

Le billet suivant traite des opérations possibles sur les modes (et de la façon dont elles sont implémentés).

 

Composition des solutions

Les solutions de CiviKey sont des solutions dites « composées » : chaque solution tire parti d’une ou plusieurs solutions pour ne faire qu’ajouter des fonctionnalités, sans devoir recopier des projets essentiels. La solution Core est la solution de base, elle regroupe les projets du noyau permettant par exemple de lire et sauvegarder les données de CiviKey. Ensuite la solution Certified apporte un host d’exécution du Core, ainsi que des plugins essentiels, elle est donc composée du résultat de la solution Core. Enfin Contrib est une solution « bac à sable » où tout le monde peut venir tester son plugin. Elle est composée par la solution Certified et contient donc tous ses plugins, et en y ajoutant les plugins développés par les développeurs de la communauté Open Source ou par les étudiants d’In’Tech INFO.

Création d’un « Runtime »

Pour que ces solutions puissent être composées par d’autres il a fallu réfléchir à un système assez souple pour ne lier trop fortement deux solutions entre elles. Il faut par exemple que le développement de Core puisse continuer en parallèle sans impacter Certified.

Pour cela nous avons ajouté un dossier « Runtime » à chaque solution (sauf Core car c’est la solution élémentaire) contenant les résultats de la (ou des) Solutions qui la compose : Certified/Runtime contient donc les binaires de Core. Les projets de la Solution composée n’ont qu’à faire référence aux binaires du dossier Runtime pour les utiliser et les développeurs de la Solution composée gèrent leur répertoire Runtime : ce sont eux qui choisissent de prendre en compte on non les nouvelles versions des composants sur lesquels ils s’appuient.

Ce dossier Runtime peut être mis sous contrôle de SubVersion (ou autre gestionnaire de code source), c’est d’ailleurs ce que nous faisons à Invenietis. De cette façon, les Solutions sont autonomes et il est aisé de « remonter dans le temps » du projet : les sources sont en phase avec les versions exactes des composants sur lesquels la Solution est fondée.

Les « Saveurs »

Lorsqu’on compile une solution dans Visual Studio il est possible de choisir dans quel mode se déroulera la compilation. En mode Debug, pour que les « #If Debug », « Debug.* », etc. soient pris en compte, cela permet de résoudre les bugs plus facilement (via des outils de diagnostic). En mode Release, pour que les performances soient optimales.

Mais il n’y a pas que Debug et Release : si ces « modes de compilation » sont les plus courants, il peut s’avérer nécessaire de gérer d’autres « saveurs » : processeur, optimisations plus ou moins agressive, versions gratuites vs. payantes, signé ou non, etc. La notion de « Saveur » généralise le « mode de compilation » : un même composant logiciel est disponible pour le développeur en plusieurs « saveurs » et celui-ci doit pouvoir les choisir.

Le Runtime de chaque Solution contient un sous dossier par « saveur », typiquement Debug et Release, qui contiennent les résultats des compilations correspondantes. Il est donc possible de choisir quelle « saveur » utiliser simplement en changeant les chemins des références.

Notons qu’il est même possible d’intégrer la version dans la « saveur » : rien n’empêche de travailler en même temps sur des composants « ReleaseOld » et « ReleaseNew » (afin de vérifier que le plugin que l’on écrit marche aussi bien avec deux versions différentes du même composant.

Malheureusement, changer toutes les références à chaque changement de configuration est très fastidieux (une solution comme Certified possède, à date, 14 projets, chaque projet possède au moins 3 références au Core, il faut donc changer 42 chemins à chaque fois que l’on veut passer en Debug/Release).

Pour éviter cette opération, le dossier Runtime contient un répertoire Current. Ce dossier est une copie exacte d’une des saveurs disponible dans Runtime. La solution n’a plus qu’à faire référence systématiquement aux binaires de Current : pour changer de configuration, il suffit de remplacer ces binaires par les binaires de la saveur que vous voulez utiliser. Il est ainsi très facile par exemple d’utiliser le Core en Release dans la solution Certified en mode Debug (ou le contraire).

Pour le moment ce dossier Current est à gérer manuellement, il faut le créer, le mettre en « ignore list » dans SubVersion, et faire un export des binaires de Debug / Release dedans afin de pouvoir les utiliser. Nous spécifions actuellement un petit utilitaire pour automatiser et sécuriser cette opération, il devrait permettre aussi de faire un update automatique des « saveurs » disponibles.

Finissons sur une remarque générale : nous proposons ici un moyen simple de gérer un très classique problème du développement logiciel. Dans le bon vieux temps des compilateurs C, des fichiers make permettaient de se lier à des librairies différentes en fonction de valeur de macro (la « saveur » à produire). Visual Studio n’intègre pas cette possibilité (subordonner ses références au « mode de compilation ») car elle a souvent été mal utilisée et source de problème.

Pour notre part, nous estimons avoir besoin de ce petit jeu : compiler facilement ma Solution avec tous les checks intégrés dans la saveur « Debug » du Core pour faciliter la traque des bugs… alors que ma Solution, elle-même, est compilée en « Release ».

Ou le contraire : j’ai confiance dans le Core, je travaille en Debug et utilise le Core en Release. Bref, les différentes combinaisons sont possibles… Mais nous imposons néanmoins UNE contrainte forte : les « saveurs » doivent être interchangeables au sens où elles doivent toutes contenir les mêmes composants.

Exemple pratique : Faire fonctionner Contrib après un checkout

Voici toutes les étapes pour mettre en œuvre la solution Contrib directement après un checkout. Pour information le dépôt de Contrib est à l’adresse suivante : https://civikey.svn.codeplex.com/svn/trunk/Contrib Voici la marche à suivre :

  1. 1 - Aller dans Runtime/, créer le dossier Current/ et l’ajouter en « ignore list » dans votre client SubVersion.
  2. 2 - Exporter les dll d’un des deux dossiers de Runtime/ vers Current/.
  3. 3 - Lancer la solution Contrib.VS2008.sln.
  4. 4 - Compiler une première fois la solution.
  5. 5 - Dans les propriétés du projet Artefact aller dans la section « Déboguer » puis choisir « Output/Debug (ou Release selon votre mode de compilation)/CiviKey.exe » comme programme de démarrage. Attention cette configuration s’enregistre dans un fichier .user, qui ne doit pas être commit car cette configuration est liée à chaque poste.

Une fois cette configuration faite vous n’aurez plus qu’à changer le mode de compilation de Contrib ou de changer les dll de Runtime/Current/ pour compiler avec les saveurs qu’il vous faut.

Liens entre structure et layout

Les travaux sur la version 2.5.0 du Core, et plus précisément le développement de la nouvelle interface graphique de CiviKey nous ont permis de soulever une nouvelle problématique qui a entrainé l’évolution de la structure même de ce que sont un clavier et son affichage (ou layout).

Un petit rappel ne fait pas de mal

Les classes qui définissent la structure des objets d’un contexte CiviKey sont organisées en deux sections parallèles :

  • la structure de « ce qu’est un clavier », au sens des données liées au comportement et à la nature des objets (propriété Enabled et commandes associées à l’appui d’une touche par exemple)
  • et la façon dont ces claviers doivent être affichés : les Layouts (propriété Visible et positionnement à l’écran par exemple).

 

D’abord, de nouveaux noms

Lors de l’évolution décrite ci-après, on s’est rapidement rendu compte que les noms des classes n’étaient pas suffisamment explicites : ils avaient déjà évolué une première fois pour perdre le préfixe CVK (ICVKContext est devenu IContext), et l’ajout des interfaces « Current » (voir ci-dessous) a fait déborder le vase (avec un horrible ICurrentActualKeyLayoutCurrent…). Olivier a donc décidé de renommer certaines interfaces pour plus de clarté : IKeyboardZone devient IZone (parce qu’après tout, lorsqu’on travaille dans CiviKey on sait bien qu’une zone est une zone de clavier) ; IActualKey devient IKeyMode (car « actual » étant un faux-ami en anglais, certains ne comprenait pas le sens « Réel » de ce nom, IKeyMode est plus clair car cet objet représente simplement une touche - ou Key - dans un Mode donné). Du côté des layouts certains noms ont changé aussi en respectant une parfaite cohérence avec la section structurelle. L’intérêt de ce re-nommage est double :

  • les noms des objets sont « alignés » sur leur « structure » et il est beaucoup plus facile de s’y retrouver.
  • cela permet aussi de séparer les objets Layout des objets Structure dans la liste des classes dans Visual Studio : les Layouts, commençant tous par « ILayout » sont regroupés et non plus éparpillés parmi les autre classes/interfaces.

 

Voici donc la nouvelle organisation des interfaces du modèle :

Avant Maintenant
  • IContext
    • IKeyboard
      • IKeyboardZone
        • IKey
          • IActualKey
      • IKeyboardLayout
        • IKeyboardZoneLayout
          • IKeyLayout
            • IActualKeyLayout
  • IContext
    • IKeyboard
      • IZone
        • IKey
          • IKeyMode
      • ILayout
        • ILayoutZone
          • ILayoutKey
            • ILayoutKeyMode

Mais où est le problème ?

Avant tout, si cela n’est pas déjà fait, il vous faut commencer par lire l’article d’Olivier sur les modes et les fallbacks calculés lorsqu’un IActualKey n’existe pas dans le mode courant.

Désormais armés pour comprendre les modes ainsi que les fallbacks, voici le souci lié à l’ancienne conception de ces classes:

Les relations qui lient les IXXX aux ILayoutXXX sont de type 1:1, et cela est très bien … sauf pour les IKeyMode vs. IKeyModeLayout. En effet cela oblige chaque IKeyMode à « posséder » son ILayoutKeyMode, donc pour deux IKeyMode il faut deux ILayoutKeyMode distincts, ce qui impose donc redéfinir les valeurs des propriétés de ces ILayoutKeyMode, or dans la plupart des cas (99% je pense) les propriétés de layout (largeur, hauteur, position) ne changent pas entre deux IKeyMode différents (ce qui change, ce sont le comportement ou le label). Cela entraine une copie des données, et du coup une surcharge, aussi bien pour le système que pour l’utilisateur lors de la modification de l’affichage d’un clavier (pour déplacer une touche, il faudrait modifier la position de chacun de ses IKeyMode via chaque ILayoutKeyMode).

La solution trouvée à ce problème est assez simple, il suffit d’appliquer le même principe de fallback (la façon dont on retrouve le « meilleur » IKeyMode pour un mode donné) aux ILayoutKeyMode que celui applicable aux IKeyMode. L’impact est qu’il n’y a plus de lien direct entre un IKeyMode et un ILayoutKeyMode. Par contre il est toujours possible via tout IKey de retrouver le ILayoutKey courant, et sur cet ILayoutKey de trouver le « meilleur » ILayoutKeyMode calculé en fonction du mode courant (et non en fonction de l’IKeyMode courant).

Afin de faciliter la programmation, deux nouvelles interfaces ont étés introduites dans le modèle : un IKeyModeCurrent étend IKeyMode, et un ILayoutKeyModeCurrent étend ILayoutKeyMode. Ces deux interfaces ne peuvent être obtenues que via les différentes propriétés « Current » et ne font qu’ajouter une propriété « IsFallBack » qui est vrai si l’objet ne correspond pas exactement au mode courant (mais est juste le « meilleur » objet calculé pour le mode courant).

Pour plus de détails vous trouverez ici le diagramme de classes des objets du Contexte (aussi disponible dans le dossier Context/Model du projet CK.Context de la solution CK.Core).

Le fallback est plus simple à comprendre car il s’applique de façon indépendante aux touches et à leurs layouts. L’implémentation bénéficie également de cette simplification : les objets (internes au CK.Context) qui implémentent IKeyMode et ILayoutKeyMode utilisent exactement le même mécanisme de gestion des fallbacks (qui, à l’occasion, a été optimisé).