Discussion :

[koala01]

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 [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)
• 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" ), 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
Pensez vous à des "widget" ou à des aspects auxquels je n'aurais pas pensé

Messieurs, faites chauffer les claviers et les neurones .

A vos marque... près... Partez!!

[minnesota]

Salut koala01,

Je suis passé sur le forum juste avant de me coucher, histoire de ne pas avoir trop de choses à lire une fois le dimanche arrivé. J'avais déjà commencé à faire une petite synthèse de la discussion principale. Y il a une chose importante, très importante, que j'ai retenu est que le terme de "widget" avait la fâcheuse tendance à échauffer les esprits des intervenants pour finir sur des discussions interminables. À mon sens, ce terme de design est vieillissant et n'est pas forcément en adéquation avec l'aspect moderne et avant-gardiste de Farfelue.


Donc, je pense qu'il ne faut pas utiliser ce nom et trouver un terme plus adapté.

[koala01]

Effectivement, le terme widget est relativement peu adapté, et je ne l'utilise ici que par réelle commodité (à défaut de trouver un autre terme)

C'est la raison pour laquelle je l'entoure volontiers de guillemets ou que je le fais suivre par un point d'interrogation.

Cependant, tu remarquera que je parle plus volontiers d' "élément(s) visuel(s)" car c'est bien sous cette forme que je souhaite que l'on y réfléchisse

Mais ta remarque est néanmoins tout à fait fondée

[Invité]

Je pense que se baser sur les widgets existant dans d'autres bibliothèques(Qt, Gtkmm, MFC...) pour obtenir des idées d'éléments visuels pourrait être interressant. Je pense donc qu'il manque :
-l'affichage sous forme d'arbre
-les fenêtre de dialogues
-les MDI

[ram-0000]

-l'affichage sous forme d'arbre

Je rajouterais aussi l'affichage sous forme de liste (qui pourrait peut être rejoindre les listes à sélection simple ou multiple).

Après tout l'affichage sous forme de liste n'est jamais qu'une liste à plusieurs colonnes (avec un header pour les titres des colonnes)

[minnesota]

Salut,

Je vous invite dans un premier temps à télécharger wxWidgets demo, la plupart des contrôles classiques (pour ne pas dire standards) y sont répertoriés. On peut agir directement sur ces derniers depuis l'application démo pour en faire ressortir des détails comportementaux ou des traits qu'ils auraient en commun.

Widgets Demo

This sample shows the basic controls available in wxWidgets.

• Windows
• Linux with GTK+
• Linux with X11
• Linux with Motif
• Mac

<edit>
J’ajoute encore un lien (http://www.smartclient.com/smartgwt/showcase/#main) comme source d'inspiration.
</edit>

[Invité]

Re-bonjour,
Je viens de penser à regarder une peu sur wikipédia(fr et en), et il y a un classement(basique) qui pourrait toujours aider pour faire les politiques.
Pour rajouter quelques élément à la liste :
-les boutons fléchés(spinbox)
-les barres d'avancement
-les "docks"
-les barres d'états
-les dials

[ram-0000]

Une petite réflexion sur tous ces objets.

Même si je reconnais leur bien fondé, ne risque t'on pas de repartir sur des sentiers déjà bien déblayés et balisés et se priver d'idées. De plus, ne risque t'on pas de repartir sur une hiérachie d'objets avec un super objet duquel dérive tous les autres objets graphique.

J'ai l'impression que tous ces objets graphiques (pourquoi pas des FarfObj d'ailleurs) ont 3 ou 4 caractéristiques différentes

• L'aspect Management : qui les a créé, qui peut les détruire, qui est leur parent de rattachement dans la hiérarchie d'objets représentés à l'écran
• L'aspect Représentation : la couleur, la forme, la taille, la dimension de tous ces objets graphiques. C'est cette partie qui va s'occuper du render.
• L'aspect Etat : l'objet est il visible ou caché, la liste à t'elle 1 ou plusieurs éléments sélectionés
• L'aspect Interaction : comment l'objet réagit il avec les autres objets ou le programme utilisateur, quelles sont les interactions possibles (lorsque la souris passe dessus par exemple). C'est dans cette partie que l'on va trouver toutes les callback.

[koala01]

Le risque est effectivement présent, il ne faut pas le nier.

Par contre, il est aussi vrai que, si on arrive à avoir un état des lieux correct (ce vers quoi tendent les différents liens donnés ) il est également possible de regrouper les différents éléments par "politique suivie".

Ainsi, la possibilité de redimensionner un élément visuel, de présenter un menu, d'avoir un état, de présenter un aspect différent quand le focus est sur l'élément, etc ... sont autant de politiques qui peuvent être regroupées et activées ou désactivée afin d'obtenir pour ainsi dire l'ensemble des éléments qui nous intéressent.

Maintenant, quelles sont les politiques qui, une fois regroupées, nous permettront de donner "ce qu'il faut" aux différents éléments visuels

Répondre à cette question, c'est faire une bonne moitié du travail nécessaire à la mise au point de la bibliothèque

[minnesota]

Sa...lut,

En fait, un TShape c'est plutôt un composant non ? Et ce composant on le positionne sur une fiche, un ou une TForm si je ne m'abuse, en somme une boite de dialogue. Si on veut une application fenêtrée, on utilise une TFrame je crois. Donc si TApplication devait avoir un rapport direct avec d'autres classes, ce serait plutôt avec TForm et TFrame, et non TShape ?

[koala01]

Sa...lut,

En fait, un TShape c'est plutôt un composant non ? Et ce composant on le positionne sur une fiche, un ou une TForm si je ne m'abuse, en somme une boite de dialogue. Si on veut une application fenêtrée, on utilise une TFrame je crois. Donc si TApplication devait avoir un rapport direct avec d'autres classes, ce serait plutôt avec TForm et TFrame, et non TShape ?

Tu semble te méprendre sur le sens du titre de la question.

Nous sommes bien consicent que ces deux éléments (TShape et TApplication) se trouvent aux extrémité du système à mettre en place, et qu'il n'y a pas de relation franche et directe entre ces deux types:
TShape représente le "minimum légal" requis par l'ensemble des éléments visuels que l'on va manipuler quand TApplication représente "l'objectif final" pouvant (ou non) contenir des éléments visuels.

La question est donc bien "on connait deux extrémités, que met on entre les deux? "
Les formulaires, les menus, les boutons, et tout le reste sont autant d'éléments qui viennent prendre place entre TShape et TApplication

[minnesota]

Tu semble te méprendre sur le sens du titre de la question.
...
La question est donc bien "on connait deux extrémités, que met on entre les deux? "

Autant pour moi, en effet, je ne voyais pas ça dans ce sens.