[conception]De TShape à TApplication
Salut,
Pour l'instant, nous avons, à peu près, les deux extrémités du problème:
Nous disposons en effet de formes d'un coté, et d'au moins un aperçu *relativement* précis de ce que nous souhaitons comme classe permettant de gérer l'application (si vous vous demandez de quoi je parle, n'hésitez pas à voir cette discussion).
[mode aparté="on"] En fait, il manque, selon le SVN, deux choses pour pouvoir réellement profiter des formes: Le pinceau et la gestion des polices de caractères (avec tout ce que cela peut comprendre de mise en gras, de souligné, d'italique, ...)
Je lance donc un appel du pied à qui se sent motivé pour essayer de donner une implémentation de base sur ces deux points particuliers pour qu'il se fasse connaitre :D[mode aparté="off"]
Nous disposons en plus un "fil conducteur" en ce qui concerne la transmission de message entre les différentes parties et autres callbacks sous la forme de boost.signals2.
Cependant, il nous reste encore à définir tout ce qui peut faire qu'une "forme" soit utilisable par l'application en la transformant en élément visuel ("widget").
Pour cela, je souhaiterais que l'on essaye de déterminer ce qui manque parmi la liste (non exhaustive et non triée) qui pourrait être composée de:
- forumlaires (la fenêtre principale pouvant être considérée comme tel:D)
- menus et éléments de menu
- bouton
- boutons radio
- label
- liste déroulante
- liste à sélection multiple
- champs texte
- affichage "en tableau" (des lignes et des colonnes)
- barre de défilement (horizontale et verticales)
- case à cocher
- les zones de textes, de mémo, de texte enrichi
- tous les éléments que j'ai éventuellement oubliés.
Je souhaiterais donc en priorité arriver à compléter cette liste, afin de pouvoir déterminer les aspects "transversaux" et les points de variation qui existe entre ces différents éléments
Par exemple:
- certains de ces éléments peuvent être "actifs" ou non
- certains ne peuvent être composés que de texte (comprenez : non reliés à une donnée particulière), alors que le texte d'autre peut être dépendant d'une donnée d'un type particulier (éventuellement défini par l'utilisateur de la bibliothèque) et, parmi cette deuxième sorte certains autorisent la mise à jour de la donnée, d'autres non.
- Certains réagissent au survol de la souris, d'autres non
- Certains réagissent au clique de la souris, d'autres non
- Certains réagissent aux événement du clavier, d'autres non
- Certains peuvent prendre le "focus", d'autres non, et certains pourraient transmettre le focus à un élément qui leur est relié
- Certains peuvent réagir à un raccourci clavier
- Certains peuvent devenir visibles dans certaines conditions (les barres de défilement, par exemple), d'autres non
- Certains peuvent être redimensionnés, éventuellement en respectant des contraintes de tailles, d'autre (ex: le marqueur de sélection des boutons radio ou des case à cocher) ne doivent pas l'être
- Certains doivent assurer un aspect "thread safety", en cas d'application multi threadée, mais ce n'est pas nécessaire pour d'autre
- Certains peuvent contenir des éléments "enfants", d'autres non
Tous ces points, et tous ceux que je peux avoir oublié, sont susceptible de représenter une politique particulière, s'adaptant selon plusieurs traits.
L'idée que j'ai en tête est de créer toutes ces politiques différentes, et celles que je peux avoir oublié, de manière à n'avoir plus qu'à "faire mon marcher" parmi ces différentes politiques et les utiliser comme autant de briques atomiques pour créer les éléments visuels intéressants.
Ici aussi, la liste n'est très certainement pas complète, mais la première liste que j'ai donné devrait nous permettre de la compléter ;)
Au delà, la liste des différents éléments visuels et des politiques que l'on peut leur associer nous permettra de déterminer... quels signaux (et les arguments qui leurs sont nécessaires) sont susceptibles d'être émis et reçus, et par qui.
Une fois que nous disposerons de la liste des signaux, de qui est susceptible de les émettre et de qui est susceptible de les recevoir, nous pourrons réfléchir à la manière de les regrouper qui sera la plus efficace, pour enfin les "distribuer" aux différents éléments visuels.
Si nous arrivons jusqu'ici, nous pourrons dire que nous sommes aux portes de ce que la façade de mise en relation avec le système, et donc, que nous serons tout proche d'atteindre notre but.
Le but de cette discussion est donc de vous permettre de compléter les listes ci-dessus afin d'être sur de ne rien oublier, ni en terme d'élément visuel ("widget" :question:), ni en terme de politique et de traits de politiques, ni en terme de signaux émis
Chaque fois que nous aurons une idée à peu près précise et estimée complète d'une politique à implémenter, nous ouvrirons une discussion afin de:
- discuter de la meilleure manière de la mettre en pratique (en terme de conception et / ou d'algorithme et / ou de structure de données), en veillant à être le moins intrusif possible
- discuter des tests unitaires à mettre en place
- choisir celui qui écrira les tests unitaires
- choisir celui qui donnera la première implémentation de la politique
- choisir celui ou ceux qui feront la revue de code et la validation
- ...
Cette manière de faire devrait nous permettre de profiter des idées de l'ensemble de l'équipe en évitant (autant que faire se peut) de surcharger un membre ou l'autre en lui laissant tout "le sale boulot", et évitant, je l'espère, une certaine forme de découragement du au fait de faire toujours la même chose.
Que pensez-vous de cette proposition :question:
Pensez vous à des "widget" ou à des aspects auxquels je n'aurais pas pensé :question:
Messieurs, faites chauffer les claviers et les neurones :D.
A vos marque... près... Partez!!
