Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 9 sur 17 PremièrePremière ... 5678910111213 ... DernièreDernière
Affichage des résultats 161 à 180 sur 324
  1. #161
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par metagoto Voir le message
    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

  2. #162
    Membre Expert
    Avatar de Goten
    Inscrit en
    juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 24

    Informations forums :
    Inscription : juillet 2008
    Messages : 1 580
    Points : 2 170
    Points
    2 170

    Par défaut

    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).
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

  3. #163
    Membre chevronné Avatar de metagoto
    Hobbyist programmateur
    Inscrit en
    juin 2009
    Messages
    646
    Détails du profil
    Informations professionnelles :
    Activité : Hobbyist programmateur

    Informations forums :
    Inscription : juin 2009
    Messages : 646
    Points : 785
    Points
    785

    Par défaut

    Citation Envoyé par fcharton Voir le message
    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.

  4. #164
    Nouveau Membre du Club
    Inscrit en
    novembre 2009
    Messages
    65
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 65
    Points : 38
    Points
    38

    Par défaut

    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!

  5. #165
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par metagoto Voir le message
    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

  6. #166
    Nouveau Membre du Club
    Inscrit en
    septembre 2008
    Messages
    84
    Détails du profil
    Informations forums :
    Inscription : septembre 2008
    Messages : 84
    Points : 37
    Points
    37

    Par défaut

    Citation Envoyé par koala01 Voir le message
    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).

  7. #167
    Membre chevronné Avatar de metagoto
    Hobbyist programmateur
    Inscrit en
    juin 2009
    Messages
    646
    Détails du profil
    Informations professionnelles :
    Activité : Hobbyist programmateur

    Informations forums :
    Inscription : juin 2009
    Messages : 646
    Points : 785
    Points
    785

    Par défaut

    Citation Envoyé par fcharton Voir le message
    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.

    Citation Envoyé par fcharton Voir le message
    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

  8. #168
    Membre Expert
    Inscrit en
    juin 2006
    Messages
    1 214
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : juin 2006
    Messages : 1 214
    Points : 1 015
    Points
    1 015

    Par défaut

    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?

  9. #169
    Rédacteur/Modérateur
    Avatar de poukill
    Inscrit en
    février 2006
    Messages
    2 152
    Détails du profil
    Informations personnelles :
    Âge : 31

    Informations forums :
    Inscription : février 2006
    Messages : 2 152
    Points : 2 053
    Points
    2 053

    Par défaut

    Citation Envoyé par epsilon68 Voir le message
    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.

  10. #170
    Membre expérimenté Avatar de Lavock
    Inscrit en
    octobre 2009
    Messages
    560
    Détails du profil
    Informations forums :
    Inscription : octobre 2009
    Messages : 560
    Points : 595
    Points
    595

    Par défaut

    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.
    The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.
    --Wilhelm Stekel

  11. #171
    Invité
    Invité(e)

    Par défaut

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

    Francois

  12. #172
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par metagoto Voir le message
    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

  13. #173
    Membre chevronné Avatar de metagoto
    Hobbyist programmateur
    Inscrit en
    juin 2009
    Messages
    646
    Détails du profil
    Informations professionnelles :
    Activité : Hobbyist programmateur

    Informations forums :
    Inscription : juin 2009
    Messages : 646
    Points : 785
    Points
    785

    Par défaut

    Citation Envoyé par fcharton Voir le message
    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".

  14. #174
    Invité
    Invité(e)

    Par défaut

    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

  15. #175
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 733
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 733
    Points : 17 209
    Points
    17 209

    Par défaut

    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  16. #176
    Invité
    Invité(e)

    Par défaut

    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
    Dernière modification par Invité ; 11/04/2010 à 11h49.

  17. #177
    Membre Expert
    Avatar de Goten
    Inscrit en
    juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 24

    Informations forums :
    Inscription : juillet 2008
    Messages : 1 580
    Points : 2 170
    Points
    2 170

    Par défaut

    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à)
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

  18. #178
    Nouveau Membre du Club
    Inscrit en
    novembre 2009
    Messages
    65
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 65
    Points : 38
    Points
    38

    Par défaut

    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 .

  19. #179
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 733
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 733
    Points : 17 209
    Points
    17 209

    Par défaut

    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  20. #180
    Membre Expert
    Avatar de Goten
    Inscrit en
    juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 24

    Informations forums :
    Inscription : juillet 2008
    Messages : 1 580
    Points : 2 170
    Points
    2 170

    Par défaut

    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.
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •