Discussion :

[Invité]

L'aspect "composite" passe donc, non pas par une base classe commune, mais un "Boost.Any".

C'est marrant, je réfléchissais à cela, tout à l'heure, et je me disais que l'alternative à l'héritage était peut être l'utilisation de conteneurs "non typés" (à la boost any).

Un des avantages de cette approche, c'est qu'un même widget peut appartenir à plusieurs hiérarchies de conteneurs, ce qui revient à avoir plusieurs composites différents (ownership, pointage, dessin...)

Du coup, je me demande si on ne pourrait pas généraliser cela... Par exemple en se disant que les "primitives de bases" au lieu d'être des traits ou des fonctions membres, pourraient être des fonctions génériques, qui s'appliquent à des conteneurs de "widgets concernés". Peut être qu'on pourrait, comme cela, séparer des caractéristiques "internes et obligatoires" du widget (rendues par des membres à la compilation), de certaines caractéristiques "externes et facultatives", implémentées via des conteneurs à l'exécution...

Francois

[Goten]

Pas si on arrive a établir des bons paramètres par défaut... (pour la plus part des widgets ça doit être bien faisable).

Sa plus les templates typedef, la syntaxe est pas si lourde que ça.

Mais oui, 40 000 policies, c'est pas non plus ce qu'il y'a de mieux. (et y'a des comportements qui sont gérable autrement que par des policies).

[metagoto]

C'est marrant, je réfléchissais à cela, tout à l'heure, et je me disais que l'alternative à l'héritage était peut être l'utilisation de conteneurs "non typés" (à la boost any).

J'aurai plutôt tendance à privilégier une base class "widget" juste pour du type erasure. Je ne vois pas ça comme un "super objet", juste une base classe pour les seuls widgets. Puis tout le reste dans des policies. Mais des policies, pas besoins d'en avoir 50 à mon avis. Une policies pour la gestion des events, une pour l'affichage et une pour les data.

En fait, proche de ça: (lien que j'avais déjà posté précédemment)
http://notus.sourceforge.net/notusguide.html

Les problèmes d'interfaces non uniformes entre les widgets est, me semble-t-il, moins important dans un cadre GUI, car c'est l'OS qui trig et entraine les changements d'état plus que ne le fait le "programmeur". Dire à un widget de faire ceci ou cela passe par un message "d'invalidation" puis de "redraw" plutot que a_widget.draw(). Je ne sais pas si je me fais comprendre. Les fonctions membres devraient être réduites au minimum.

[ElPedro]

Ok, je comptais déblatérer sur les concepts après mon post de ce midi... mais apparemment j'ai été beaucoup plus lent à la détente que vous tous .


metagogo, ton lien est super! Peut-on par conséquent considérer qu'une librairie graphique orientee programmation generique, sans superobject existe deja ?


Bon courage à tous!

[Invité]

J'aurai plutôt tendance à privilégier une base class "widget" juste pour du type erasure. Je ne vois pas ça comme un "super objet", juste une base classe pour les seuls widgets. Puis tout le reste dans des policies. Mais des policies, pas besoins d'en avoir 50 à mon avis. Une policies pour la gestion des events, une pour l'affichage et une pour les data.

Assez d'accord avec ca... En fait, je me dis qu'on peut probablement imaginer une hierarchie assez courte de widgets (je pense qu'on se rendra compte qu'elle sert un peu). Le seul risque de la classe widget, c'est que l'utilisateur peut en dériver s'il le souhaite (il n'y a pas de classe finale).

Pour les policies, faut voir. A mon avis, les data ca se gère avec des itérateurs ou quelque chose du genre... L'affichage, comme ca risque d'être spécifique à chaque widget (et customisable), je ne suis pas certain que la policy soit la meilleure solution. Il n'y a pas grand chose à partager d'un widget à l'autre.

Pour les messages, oui, il faut voir si une policy suffit, ou s'il faut catégoriser... Quelque part, c'est là qu'on va parler de focus clavier, de composants scrollables... Il faudra aussi réfléchir au statut des messages... Quelque part, je me dis qu'il s'agit d'un composant de base, transversal aux widgets (pas des policies)...

Un autre endroit où il va falloir des policies, en revanche, c'est l'alignement...

Francois

[Yakuzan]

Et vous autres, là, qui avez lu la discussion sans intervenir... Qu'en pensez vous

Allez, que diable, exprimez vous...

Je pense avoir passé plus d'une heure à comprendre tous les acronymes utilisées jusqu'a maintenant(STL, IHM, U++, (SG)BDR, RAD...etc).

[metagoto]

Pour les policies, faut voir. A mon avis, les data ca se gère avec des itérateurs ou quelque chose du genre... L'affichage, comme ca risque d'être spécifique à chaque widget (et customisable), je ne suis pas certain que la policy soit la meilleure solution. Il n'y a pas grand chose à partager d'un widget à l'autre.

A voir. Oui pour les itérateurs. Une "policy" pour le model serait juste une manière d'injecter les data de manière générique. Ce sont des paroles en l'air. J'imagine juste que le model fait son job de son coté. Le widget va juste manipuler le "value_type", "iterator_type" (etc) du Model.

Pour les messages, oui, il faut voir si une policy suffit, ou s'il faut catégoriser... Quelque part, c'est là qu'on va parler de focus clavier, de composants scrollables... Il faudra aussi réfléchir au statut des messages... Quelque part, je me dis qu'il s'agit d'un composant de base, transversal aux widgets (pas des policies)...

Ce qui peut être "transversal" serait, je pense, le mécanisme de dispatching qui reçoit les events et qui les forward dans un format compatible avec les policies du widget concret qui lui agit en fonction de ces events. Ensuite, tout comme le fait Notus (voir le lien plus haut) ou SmartWin, la policy des events peut être un type composite (disons un agrégat de "functoids" qui captent tel ou tel event). Les valeurs de retour de ces messages doivent être retournés à l'OS. Les procédures par défaut doivent prendre le relais si les messages ne sont pas traités... un sacré chantier

[epsilon68]

Notus a l'air de d'être la lib que vous aimeriez definir,
pourquoi ne reprenez-vous pas Notus pour joindre vos efforts,
vous ne partiriez pas de 0 et ce projet grossirait plus vite non?

[poukill]

Notus a l'air de d'être la lib que vous aimeriez definir,
pourquoi ne reprenez-vous pas Notus pour joindre vos efforts,
vous ne partiriez pas de 0 et ce projet grossirait plus vite non?

J'ai regardé rapidement Notus, c'est vrai que c'est dans l'esprit de la discussion ici... Du coup, + 1.

[Lavock]

Idem. Apparemment, l'auteur est un gros fan de prog fonctionnel (haskell principalement). En tout cas, je suis plus pour contribuer à ce projet qu'à adobe.asl.

[Invité]

Notus, ca n'a plus trop l'air de bouger depuis 2004, non?

Francois

[Invité]

Ce qui peut être "transversal" serait, je pense, le mécanisme de dispatching qui reçoit les events et qui les forward dans un format compatible avec les policies du widget concret qui lui agit en fonction de ces events. Ensuite, tout comme le fait Notus (voir le lien plus haut) ou SmartWin, la policy des events peut être un type composite (disons un agrégat de "functoids" qui captent tel ou tel event). Les valeurs de retour de ces messages doivent être retournés à l'OS. Les procédures par défaut doivent prendre le relais si les messages ne sont pas traités... un sacré chantier

Je me demande dans quelle mesure tous les messages doivent être passés et traités par les widgets. En fait, les évènements pointage classique (clavier, souris, etc...) pourraient être interprétés indépendemment, et traduits en des appels à des policies "commande" appartenant aux widgets, ou pas d'ailleurs.

Ce que j'essaye de dire, c'est qu'il n'est pas nécessaire que les widgets s'occupent des messages, ils pourraient juste avoir des fonctions membres (oh pardon, des policies fonctionnelles) que le système d'interprétation des messages appelle quand il décode des évènements...

Par exemple : si tu as un bouton qui exécute une commande, laquelle peut etre déclenchée par un clic sur le bouton, un evenement clavier, un double click ou la sélection d'un élément de menu (voire être un message adhoc envoyé dans certains cas par une fonction du programme métier), dans un monde "pur widgets", on définit tous ces évènements au niveau du bouton, du menu, etc... et on fait tout pointer vers la même commande.

On pourrait aussi bien sortir cela du widget, et tout passer à la "machine à messages", qui aurait pour charge de transformer des messages en commandes.

Dans ce dispositif, les widgets ne serviraient (pour les outils de pointage) qu'à dire à leur hierarchie "j'occupe cet espace", (pour la souris) et j'"ai le focus" (pour le clavier).

(Je ne dis pas que c'est ce qu'il faut faire, j'essaye juste d'imaginer comment on peut bâtir un framework avec "moins" de widgets)

Francois

[metagoto]

Ce que j'essaye de dire, c'est qu'il n'est pas nécessaire que les widgets s'occupent des messages, ils pourraient juste avoir des fonctions membres (oh pardon, des policies fonctionnelles) que le système d'interprétation des messages appelle quand il décode des évènements...

[...]

On pourrait aussi bien sortir cela du widget, et tout passer à la "machine à messages", qui aurait pour charge de transformer des messages en commandes.

En fait, c'est le but. Le but c'est que tous les messages qui ne nous intéressent pas soient traités correctement et de manière transparente ailleurs que dans le widget. Là je parle de messages spécifiques à l'OS, des trucs low level. Mais dans ces messages, ceux qui nous intéressent doivent "trigger" les "policies fonctionnelles" qui ont été associées au widget. Pour bien faire, ces messages doivent être transformés en amont pour être indépendants de la plateforme (si on le souhaite) mais surtout pour que la policy reçoive des données qui ont du sens. Genre ne pas recevoir un WPARAM et un LPARAM, mais directement un "Point".

[Invité]

Bon, y'a comme un temps mort, là...

Koala, t'es toujours intéressé? Qui d'autre?

Personnellement, cette discussion m'a donné envie, je participerai à un tel projet s'il est lancé (j'ai de toutes façons des besoins en terme d'IHM)

Francois

[koala01]

Oui, je suis toujours intéressé...

Désolé, mais je n'avais pas grand chose à dire sur les dernières interventions (si quelqu'un préfère participer à notus, qui pourrait d'ailleurs nous apporter quelques idées intéressantes à marier avec celles de ASL), c'est son choix

En plus, j'ai été assez pris ces deux derniers jours

[Invité]

Notus, ca m'a l'air un rien mort, tant la version, que la mailing list... Il faut regarder ce qu'ils ont fait peut être aussi essayer de comprendre pourquoi ca s'est arrêté (en dehors du classique... j'avais pas le temps)

Pour le reste, j'essaie de résumer vite fait ce qu'on s'est dit à ce jour

On voudrait bâtir une librairie d'interface

- qui ne repose pas sur une hiérarchie de classes géante, mais plutôt sur des classes templatisées avec des policies
- qui découple rendu, gestions des évènements,
- qui utilise encore des widgets, mais nettement plus maigres que leur version classique (ne contenant plus leurs données, déléguant leur rendu, et le traitement des messages)
- qui s'appuie autant que possible sur la STL et les parties stables de boost

Voici quelques ajouts de mon cru (mais qui reflètent quand même la discussion)

1- le but est que tout cela reste simple côté utilisateur, même si on veut utiliser des fonctions avancées, la librairie s'adresse à des programmeurs de base (voire, idéalement, permettrait de "dédramatiser l'IHM"
2- pour cela, on aura probablement un "langage" simple de définition de l'interface, utilisable soit directement, soit via une IDE de type RAD
3- à l'autre bout de la chaine, on veut demeurer portable, mais aussi proche que possible du système (pour rester rapide et conserver une faible empreinte mémoire, le but d'une IHM, c'est de rester discret), on va donc probablement avoir un "langage bas niveau" qui décrit les actions de dessin et les interactions avec les périphériques, et qui peut ensuite être "réalisé" par différents moteurs de rendu
4- dans l'esprit, la librairie est un traducteur (compilateur? interpréteur?), qui passe de la représentation "utilisateur" à la représentation "machine portable"

A mon avis, la première étape serait de se fabriquer une espece de "micro prototype" disons quelque chose qui permet de définir une fenetre contenant des listes, des boutons, et des labels, de l'afficher, et de définir quelques évènements... Ca permettrait probablement d'avoir une première idée des choses à faire, des pb rencontrés, sans prendre trop de temps...

Metagoto, tu jouerais avec nous?
Les autres? Comptons nous...

Francois

[Goten]

Pour le langage de définition, faudra le parser je suppose. (en général... c'est mieux :') ). Si le langage est de votre cru alors ça veut dire boost.spirit?

Je pense que si le projet était lancé, finalement, y'a moyen que j'apporte ma pierre à l'édifice, car ça me plait.



@metagoto : Rory for the win :p. (j'avais pas fait gaffe jusque là)

[ElPedro]

Plutôt non pour moi : j'ai plein de trucs à faire à côté, et que ce qui est proposé ici ne va pas forcément dans le même sens que ce que j'envisagerai (cf mon post sur le système idéal). Les goûts et les couleurs!
Cependant, je suis ok pour donner le coup de main sur des macros (je suis un utilisateur regulier de boost.pp).

Qques remarques :
1> Je ne vois pas l'intérêt des signaux. J'ai quand même écrit plus d'une quinzaine d'IHM jusqu'à présent (avec un framework dédié simple), et je n'en vois pas toujours l'utilite. Les signaux forment une technique de programmation certes intéressante, mais qui ne me semble nullement requise pour faire de l'IHM.

2> model-vue-controller me semble une évidence... mais peut être est-ce parce que c'est le premier pattern qu'on m'a présenté, ça laisse des traces.

3> Si on regarde une IHM à la CEGUI, on a des inject(controles) et un rendu en image, qui peut ensuite être affiché. Bref, y'a pas de creation de fenetre, ni de gestion d'evenement windows du tout.

4> Je pense qu'il faut pas se leurrer, je vois bien dans les moteurs 3D, les plus belles IHM sont réalisées en Flash/equivalent par des graphistes expérimentés (tous les graphistes 2D pros que je connais, connaissent flash). Elles sont ensuite jouée dans des textures à destination du moteur 3D. Il ne me semble pas possible de faire aussi et mignon et cohérent avec une simple API (à part peut être en procédural comme 'theprodukkt').

C'est pourquoi, tant qu'à avoir une interface belle-mais-pas-transcendante, autant qu'elle soit hyper simple à mettre en place pour les développeurs.

5>

A mon avis, la première étape serait de se fabriquer une espece de "micro prototype"

Oui. A ce moment là, je saurai peut être plus facilement dire si je peux aider ou pas. Mais pour l'instant c'est plutôt non pour moi .

[koala01]

Je pense qu'il serait effectivement temps de commencer à sortir un peu du domaine de la "pure hypothèse" et d'essayer de mettre un système minimum de base au point.

Je vais donc me charger de demander la création d'un hébergement svn pour le projet, de manière à pouvoir rapidement partager les fichiers, mais avez vous une idée du nom que l'on devrait donner au projet

C'est idiot, mais, quitte à choisir un nom, autant qu'il plaise à "un maxium" de gens

[EDIT]Il faudra aussi choisir la licence que je souhaite mettre en open source (ce qui est d'ailleurs une des conditions pour obtenir l'accord sur les principaux sites fournissant le support SVN, developpez ne faisant pas exception).

Concrètement, je me tournerais bien volontiers vers la LGPL version 3, mais nous pouvons choisir n'importe quelle autre licence, allant de BSD à BSL... Quelqu'un a-t-il un avis tranché sur la question

[Goten]

Je suis assez fan de la BSD (la BSL est du même ressort) , (question de choix et de philosophie). Mais de là à l'imposer :p.