GUI, gestion des évènements - Page 2

Zephyr (./30) :
50 heures de calcul ? j'ai juste dit (./19) que c'était trop couteux pour être une solution acceptable dans mon cas, puisque je compte accéder très souvent aux propriétés, et que donc rééxécuter sans cesse le même calcul était inadapté.

Mauvaise nouvelle: tu peux pas trouver mieux que O(1).

Zephyr (./30) :
pour le [] c'est pas con, mais je risque d'avoir besoin de cet opérateur pour des cas bien plus adaptées à cette syntaxe (accéder aux éléments d'une ListBox, par exemple), donc je préfère le laisser libre.

Ok.

Alors toi quand t'as décidé de pas comprendre un truc... bref, fin du HS.

t0: "C'est trop pas performant."
après: "Au mieux c'est linéaire."
après: "C'est pas linéaire mais de tte façon, la syntaxe deviendra trop complexe"
après: "Ouais mais [] je vais utiliser ailleurs".
Fin du HS mais fin de la mauvaise foi aussi j'espère :-/

Pour finir sur les propriétés, je suis tombé sur une proposition assez sympa d'un type qui n'utilise pas de conteneur, juste des templates et un pointeur intelligent (de LA STL)
http://bytes.com/groups/cpp/559912-designing-property-system
A voir

onur > la problématique du départ n'a jamais été un problème de performance, relis le topic. J'ai dit dès le début que je voulais une syntaxe légère, et tu me proposes un truc à la fois plus lent qu'un accès direct (O(1) ou autre je m'en tape, ça reste plus lent qu'un accesseur simple) et plus lourd au niveau de la syntaxe, je suis censé répondre quoi à part que ça ne m'intéresse pas ?

noisette > l'astuce est sympa, mais au final il faut quand même mettre un attribut public dans la classe :/

C'est exactement ce que j'ai proposé dans le ./17, hein...

On peut éviter l'attribut public en faisant prendre un pointeur au constructeur de la classe Property, qui peut être passé par le constructeur de la classe qui contient la propriété. Ça fait qu'on a juste un attribut privé dans cette classe et un pointeur privé dans Property.

Et pour faire plus intéressant, on peut aussi passer des pointeurs vers des méthodes de la classe conteneur à la propriété. Comme ça s'il y a du code d'accès à rajouter, ce n'est plus à Property qu'il faut le rajouter (beurk!), mais la propriété appellera automatiquement la fonction voulue de la classe conteneur.

Ah désolé, j'avais mal compris ton post. Par contre je n'ai pas toujours pas compris comment on évitait l'attribut public ? (pour avoir un accès au final qui se fasse via une syntaxe aussi simple et lisible que "myObject.Property = value;")

Ah, c'est l'attribut public Property<X> x qui te dérange? Et ben, ce n'est pas un vrai attribut public, les opérations d'assignation et de récupération sont surchargées, l'objet de type X est parfaitement encapsulé.

C'est pas faux, je vais partir sur cette solution. Merci

Gros retour au sujet avec une nouvelle question : jusqu'à maintenant, je n'avais pas envisagé faire de transmission d'évènements autrement que de père en fils. Par exemple, quand on appuie sur une touche du clavier, la fenêtre active transmet à l'onglet du TabControl actif, qui transmet à la TextBox active, qui traite l'évènement.

D'emblée, ça pose un petit problème qui n'est pas bien compliqué à résoudre mais que je ne trouve quand même pas très naturel : on connait le contrôle actif mais pas le parent du contrôle actif, et encore moins le parent du parent du contrôle actif, etc. Il faut donc en permanence conserver non pas le contrôle actif, mais toute la chaine qui permet d'y arriver en partant du contrôle racine ("Desktop", dans mon cas).

Autre soucis : quand on clique sur un bouton dans une fenêtre inactive, ça doit activer la fenêtre (pour la faire passer au premier plan, entre autres). Mais même s'il est possible de gérer ça avec une transmission de père en fils (la fenêtre va intercepter l'évènement "au passage", s'activer, et transmettre à ses fils), une transmission inverse m'aurait semblé plus logique (la fenêtre s'active parceque l'un de ses fils a reçu un évènement, et non l'inverse).

Bref, est-ce vraiment la bonne technique ?

Hmmm, je dirais qu'il faut distinguer le focus de fenetre et celui de composant.
D'autre part, je pense qu'une solution pour le focus de composant est que la fenetre garde une liste de tous les éléments qui ont le focus (en gros la chaine entre la fenetre et le bouton pour un cas classique) et leur envoie un onblur lorsqu'un des composants dans la fenetre lui envoie une notification de focus.
Pour obtenir la liste, je dirais que tu as deux solution : soit chaque composant connait son père et l'orsqu'un décide lors d'un clic de prendre le focus il transmet l'info de proche en proche jusqu'à la fenetre lui meme, soit ton dispatch du click renvoie une fonction (enfin un objet avec un callback je suppose en C++), ce qui est un moyen assez générique de remonter dans l'arbre sans stocker directement son parent.

Edit : relu vite fait, je pense que c'est clair comme du mazout

Je suis pas sûr d'avoir compris ce que tu voulais dire en effet

Hmm si tes contrôles ne connaissent pas leur parent ça peut effectivement être problématique ^^
Sinon pour ce qui est de la propagation en sens inverse je te rappelle que les fonctions ont une valeur de retour (et que tu peux utiliser des paramètres de sortie, etc...) donc il n'y a pas forcément besoin de te casser la tête.
Après pour l'activation des forms je serais plutôt d'avis d'intercepter l'évènement avant de le transmettre au contrôle fils (En fait ça revient à faire une séparation entre deux types de propagation de message) car de toutes façons cela doit fonctionner pareil, qu'il y ait ou non un contrôle fils, et que le contrôle fils choisisse de répondre ou non.
Enfin ce que je veux dire c'est que l'activation du parent ne dois, dans ce cas au moins, pas dépendre de l'activation du fils ^^

je me suis démerdé comme ça pour le moment, reste à voir si ça tiendra la route au fur et à mesure que les fonctions vont se multiplier ^^

Au fait, sans indiscrétion, tu fais ça pourquoi?

juste pour voir comment ça marche ^^

Zephyr (./40) :
Gros retour au sujet avec une nouvelle question : jusqu'à maintenant, je n'avais pas envisagé faire de transmission d'évènements autrement que de père en fils. Par exemple, quand on appuie sur une touche du clavier, la fenêtre active transmet à l'onglet du TabControl actif, qui transmet à la TextBox active, qui traite l'évènement.
D'emblée, ça pose un petit problème qui n'est pas bien compliqué à résoudre mais que je ne trouve quand même pas très naturel : on connait le contrôle actif mais pas le parent du contrôle actif, et encore moins le parent du parent du contrôle actif, etc. Il faut donc en permanence conserver non pas le contrôle actif, mais toute la chaine qui permet d'y arriver en partant du contrôle racine ("Desktop", dans mon cas).

En fait, je dirais que le problème est même plus en amont : pourquoi passer par toute une chaîne de composants (le chemin racine -> fils actif) alors que tu connais déjà le composant actif ? Autant directement soumettre l’évènement au composant actif.

Par contre, si celui-ci ne traite pas l’évènement il peut être intéressant de faire remonter ce dernier vers ses parents, qui seraient plus susceptibles de le traiter.

Autre soucis : quand on clique sur un bouton dans une fenêtre inactive, ça doit activer la fenêtre (pour la faire passer au premier plan, entre autres). Mais même s'il est possible de gérer ça avec une transmission de père en fils (la fenêtre va intercepter l'évènement "au passage", s'activer, et transmettre à ses fils), une transmission inverse m'aurait semblé plus logique (la fenêtre s'active parceque l'un de ses fils a reçu un évènement, et non l'inverse).

Ah bah voilà ^^

oui, ça me semble bien plus simple en théorie, mais je demande si ça ne va pas bloquer à un moment où à un autre ?

Pourquoi ?

Je sais pas, j'avais l'impression que les "vraies" GUI fonctionnaient avec une propagation de père en fils donc je suis spontanément parti dans cette direction (et puis c'est ce que semblent suggérer certaines propositions sur ce topic aussi), mais j'avoue que pour l'instant je vois pas d'exemple qui ne puisse pas être géré avec un système inverse.

Pour la souris tu es obligé de traverser toute la chaine (faut bien tester toutes les hitbox, et du coup ça force le sens parent -> fils ), et pour le clavier, tu pourrais le faire directement, mais à ce moment là tu n'auras aucun moyen de filtrer les évènements clavier si tu en éprouves le besoin. (Et pour des trucs simples comme le changement de contrôle avec tab ça pourra passer mais pour des trucs plus complexe ce n'est pas garanti)

[nosmile]Ben, la manière de laquelle c'est résolu dans Qt, c'est que tout objet a un parent (c'est géré par QObject, la classe de base de tous les objets touchant aux évènements) consultable par la méthode QObject:arent(). Le parent peut être NULL, mais pour les contrôles (QWidget), c'est forcément le contrôle conteneur, avoir NULL comme parent voulant dire qu'il s'agit d'une fenêtre (qui n'a évidemment pas de conteneur). Il y a également différentes méthodes pour avoir accès aux fils (on peut avoir la liste de tous les objets fils ou faire des recherches selon des critères précis).

GoldenCrystal (./51) :
Pour la souris tu es obligé de traverser toute la chaine (faut bien tester toutes les hitbox, et du coup ça force le sens parent -> fils ),

Pour la souris, c’est juste le moment où tu cherches le composant qui est sous la souris que tu es obligé de parcourir les composants du père vers le fils, mais une fois que tu as trouvé ce composant, c’est uniquement à lui que tu transmets l’évènement souris, et ce composant traite l’évènement ou bien le transmet à son parent, ainsi de suite.