Les outils existants (Contacts et Identifiants) utilisent les dossiers comme des containers de données, de l'exacte même façon que les répertoires sont des containers de fichiers dans un Explorateur.
Les dossiers de l'Agenda doivent fonctionner différemment, car il doit absolument être possible de voir la totalité des évènements et rendez-vous d'une journée, sans avoir à se construire mentalement cette image globale en "additionnant" les rendez-vous stockés dans les différents dossiers.
Les premières discussions sur le sujet avaient abouties a l'idée que les dossiers de l'Agenda devaient fonctionner soit en mode normal (container) soit en mode filtre.
Le mode filtre correspondrait en fait à une sorte d'héritage mais inversé, le patriarche héritant de ses descendants. (Ce type de vue avait également été évoqué pour la recherche de Contacts.) Illustrons cette notion avec un exemple basé sur un arbre de dossier comprenant :
Code : Tout sélectionner
[-] Agenda
[-] Perso
[-] Pro
[-] Projet A
[-] Projet B
- Sélectionner Agenda afficherait la totalité des données (et non seulement celles de la racine)
- Sélectionner Perso n'afficherait que les données Perso.
- Sélectionner Pro afficherait les données du dossier Pro et de ses sous-dossiers Projet A et Projet B.
Malheureusement, permettre à un arbre de dossiers de fonctionner selon deux modes opposés n'est pas standard et risque de perturber voire bloquer certains utilisateurs (partant désormais sur l'hypothèse que l'aide n'est jamais déclenchée).
Tout utilisateur Windows étant par contre habitué à filtrer ses données avec des CheckBoxes, c'est cette solution qui a été retenue. Le résultat sera différent, mais les capacités de filtrages seront supérieures. Ainsi, il sera possible de cocher les dossiers Perso et Projet A et d'obtenir un filtre que l'arbre en mode filtre ne permet pas.
Le besoin de filtrer des dossiers a déjà été rencontré dans le Gestionnaire de données. L'impossibilité d'associer des CheckBoxes à un TreeView a forcé l'utilisation d'un ListView, l'impression de hiérarchie des dossiers étant recréée grâce à l'indentation des dossiers : Cette liste à plat ne permettant pas de réduire (et cacher) une branche, c'est bien la solution du TreeView qui est visée. La première idée a été d'utiliser huit icônes de 32x16 qui combineraient les deux états (Checked / Unchecked) et les quatre types de dossier (outil / utilisateur x ouvert / fermé).
Mais un paragraphe de l'aide parle d'une liste d'images secondaire, ce qui correspond exactement au besoin :
