[Xlib] Intercepter les évènements

Version imprimable

Voir 40 message(s) de cette discussion en une page

23/07/2007, 15h48
Laurent Gomila

Citation:

Admettons qu'il ait enregistré pour sa fenêtre qui contient(va contenir) ton widget, une callback sur l'événement Expose. Là il peut appeler MyDisplay dans le callback.

C'est ce que je fais dans mes widgets persos : j'intercepte l'évènement paint / expose / whatever ... et j'y mets l'appel à MyDisplay. En gros ma bibliothèque ne peut pas fonctionner si on n'appelle pas au moment adéquat (lors d'un rafraîchissement de la fenêtre) la fonction MyDisplay.
23/07/2007, 16h07
souviron34

ok alors c'est relativement simple, non ? dans l'interface de MyDisplay, il suffit qu'il y ait l'événement (qui normalement doit être en paramètre de la callback).

Pas besoin de while(Pending). Ce sera appelé à chaque fois que la callback est appelée...

Non, me trompe-je ?

Il suffit alors dans ton MyDisplay de regarder les événements que tu veux et de faire un switch de traitement en fonction du type d'événement...
23/07/2007, 16h13
Laurent Gomila

Citation:

ok alors c'est relativement simple, non ? dans l'interface de MyDisplay, il suffit qu'il y ait l'événement (qui normalement doit être en paramètre de la callback).

Je décroche un peu là... Quel évènement ? Quelle callback ?
Tu peux développer un peu ton idée ?
23/07/2007, 16h16
souviron34

Citation:

Envoyé par Laurent Gomila

En gros ma bibliothèque ne peut pas fonctionner si on n'appelle pas au moment adéquat (lors d'un rafraîchissement de la fenêtre) la fonction MyDisplay.

Donc c'est à la personne qui utilise ta biblothèque d'appeller MyDisplay, si j'ai bien compris... (le "on").

D'où ma réponse...
23/07/2007, 16h23
Laurent Gomila

Citation:

Donc c'est à la personne qui utilise ta biblothèque d'appeller MyDisplay, si j'ai bien compris... (le "on").

Oui. Et donc ? :aie:
23/07/2007, 16h26
souviron34

donc lui il l'appelle pace qu'il est dans une callback de sa biblio préférée pour son Widget, non ? Et dans les paramètres de cette callback, il y a normalement un pointeur (ou une copie) de l'événement ayant généré l'appel de la callback.. Donc celui qui t'intéresse...
23/07/2007, 16h36
Laurent Gomila

Citation:

donc lui il l'appelle pace qu'il est dans une callback de sa biblio préférée pour son Widget, non ? Et dans les paramètres de cette callback, il y a normalement un pointeur (ou une copie) de l'événement ayant généré l'appel de la callback.. Donc celui qui t'intéresse...

J'appelle MyDisplay à chaque fois que la fenêtre doit être redessinée (donc évènement Expose, ou appel manuel), mais les autres évènements ne génèrent pas de rafraîchissement. Par exemple je ne vais pas appeler MyDisplay lorsqu'une touche du clavier a été enfoncée.
23/07/2007, 16h44
souviron34

et pourquoi pas ? Pourquoi faire des traitements différents (du point de vue de l'utilisateur) suivant les événements ? Ce serait plus simple à implanter et à expliquer..

Mais ok.. Maintenant que je sais ça, je vais tester mes idées.

Citation:

et pourquoi pas ? Pourquoi faire des traitements différents (du point de vue de l'utilisateur) suivant les événements ? Ce serait plus simple à implanter et à expliquer..

Non non, ce serait beaucoup plus compliqué à implanter ;)
Par exemple j'ai ce genre de choses (en pseudo C) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 void init(widget* w) { // J'envoie ma callback sur l'évènement repaint widget_on_repaint(w, &refresh); } void refresh(widget* w) { // Je met à jour ma bibliothèque w->MyDisplay(); }
Si je devais le faire pour chaque évènement je devrais faire ça :
Code:

1 2 3 4 5 6 7 8 9 void init(widget* w) { widget_on_repaint(w, &refresh); widget_on_mouse_move(w, &refresh); widget_on_key_press(w, &refresh); widget_on_close(w, &refresh); widget_on_resize(w, &refresh); ... }
Et encore, les callbacks n'auraient pas le même prototype et il faudrait passer par des fonctions intermédiaires. En plus tu le vois bien, les autres évènements n'ont rien à voir avec le rafraîchissement de la fenêtre. Et puis MyDisplay n'a pas pour vocation de recevoir un évènement, au contraire c'est elle qui doit les capter/générer pour que l'utilisateur puisse les récupérer via ma bibliothèque.

Mais bon je peux séparer MyDisplay et gestion des évènements, et dans ce cas on tombe dans le plan de secours qui consiste à capter les évènements au niveau de la bibliothèque plutôt qu'avec X11 :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 void Init(widget* w) { widget_on_repaint(w, &refresh); widget_on_mouse_move(w, &on_event); widget_on_key_press(w, &on_event); widget_on_close(w, &on_event); widget_on_resize(w, &on_event); ... } void on_event(widget* w, event* e) { switch (e->type) { case mouse_move : w->InjectEvent(MouseMove, ...); break; case key_press : w->InjectEvent(KeyPress, ...); break; case close : w->InjectEvent(Close, ...); break; ... } }
Un truc de ce genre.

23/07/2007, 18h04
souviron34
ben là on commence à ressembler plus à du X ;)

Je ne comprend pas ton paramètre "refresh" dans ton premier exemple ("alors je devrais faire").

En fait , tu viens du C++, non ?

Normalement, la philosophie "evenement" est un dispatcher qui reçoit tous les event. Les Event sont une union de tous les éevénements possibles, et dont la structure minimale est un AnyEvent ..

C'est pour ça que je considère que ta dernière forme serait plus en conformité avec l'esprit widget et X.

Je ne comprend donc pas pourquoi dans ta dernière forme tu as un cas particulier pour refresh dans Init... Ni pourquoi tu appelles une fonction dans ce Init comme OnRepaint , OnMouseMove, etc...

Si tu suis la philosophie, tu devrais avoir, pour ton Widget, un certain nombre d'événements (les tiens) : EXPOSE, MOVE, KEYPRESS, RESIZE.... Qui bien sûr peuvent être ceux de X.

A chaque type correspond un type de structure de données (pour toi) (éventuellement la même).

Ensuite, à l'init, tu devrais avoir une fonction RegisterEventHandler, où tu lui passes le type, et le nom d'une fonction à toi (fonction de traitement).

Enfin, dans l'Init, tu devrait avoir un RegisterAllEventHandler , qui sélectionnera dans X tous ce qu'il faut (par les selectinput etc...), et qui mettra comme fonction de traitement la fonction OnEvent citée dans ta dernière forme.. Et dans cette fonction, lorqu'elle est appelée, il y aura un switch ( type), et cela appelera (tu peux généraliser) tes EventHandler particulier...

ça ce serait dans l'esprit de X et des widgets (à mon avis).

Tu mets

Citation:

Et puis MyDisplay n'a pas pour vocation de recevoir un évènement, au contraire c'est elle qui doit les capter/générer pour que l'utilisateur puisse les récupérer via ma bibliothèque.

Je crois que là il y a un truc qui cloche....

Comme je disais plus haut :
- Soit l'utilisateur à dans sa librairie préférée une MainLoop, qu'il a mise en dernière (normalement) instruction de son main. A partir de là, c'est la MainLoop qui capte les événements. Et qui les dispatch dans les callbacks.
- Soit il n'a pas de MainLoop, et là c'est à toi de gérer, mais TOUT.
Mais si l'utilisateur a une MainLoop, il ne récupère pas les événements VIA ta routine.. Et donc il peut te les passer...

En résumé :

d'après ce que je comprend, tu fais une sorte de Widget, sauf que comme tu veux le faire multi-plateforme d'une part, et possiblement pas grâce à TON widget, tu te bases sur le minimum commun qui est la fenêtre X11.

Dans ce minimum commun, tu veux qu'il soit sensible à certains événements, et que lors de tels événements tes fonctions soient appelées (EN PLUS de celles par défaut).

Jusque-là j'ai bon ?

Donc en fait, si l'on prend le cas d'un Widget pré-existant, en cas d'expose, tu veux que ça passe par ta routine ? Donc en fait tu "ajoutes" des callbacks... D'où ton problème de priorité..

Et dans le cas de TON Widget, c'est toi qui contrôles les callbacks.

Mais comme ton Widget est créé via des outils comme Qt ou ... , la gestion des événements dans ce cas est faite par cet outil. Même chose si l'utilisateur fait une MainLoop...

En fait on dirait que tu veux remplacer la MainLoop.. T'as du boulot.. :aie:

Alors qu'en fait tu veux faire un Widget un peu particulier, mais comme tous les Widgets...
23/07/2007, 18h28
Laurent Gomila

Citation:

Je ne comprend pas ton paramètre "refresh" dans ton premier exemple ("alors je devrais faire").

Oui, ça signifiait "lorsque l'évènement repaint est généré, appelle la fonction refresh".

Citation:

En fait , tu viens du C++, non ?

Complétement ;)
D'ailleurs ma bibliothèque et celles haut-niveau que j'utilise (Qt, wxWidgets) le sont aussi, donc au niveau de la gestion des évènements ça peut varier de ce qu'on a l'habitude de voir en C.
Bon ce que je fais ici est faisable en C, mais ce n'est pas la manière de procéder de Xlib. Plutôt que de recevoir tous les évènements au même endroit et d'avoir un gros switch, on associe une fonction différente à chaque évènement. En gros, le switch est fait en interne plutôt que par l'utilisateur. Ce qui fait que pour recevoir tous les évènements dans la même fonction, il faudrait que j'associe cette fonction à chaque évènement. Il n'y a pas de RegisterAllEventHandler.

Citation:

Soit l'utilisateur à dans sa librairie préférée une MainLoop, qu'il a mise en dernière (normalement) instruction de son main. A partir de là, c'est la MainLoop qui capte les événements. Et qui les dispatch dans les callbacks.

Oui, mais pour que ma bibliothèque reçoive ces évènements, plutôt que de mettre en place tout un tas de callbacks différentes pour chaque évènement et pour chaque bibliothèque, j'aurais aimer les capter directement avec X11. En gros là ça fait un détour, moi j'aimerais que ce soit direct.

Citation:

Mais si l'utilisateur a une MainLoop, il ne récupère pas les événements VIA ta routine.. Et donc il peut te les passer...

On est d'accord, ce sera la solution en dernier recours.

Citation:

Jusque-là j'ai bon ?

Yep.

Citation:

Donc en fait, si l'on prend le cas d'un Widget pré-existant, en cas d'expose, tu veux que ça passe par ta routine ? Donc en fait tu "ajoutes" des callbacks... D'où ton problème de priorité..

Non, pour le cas particulier de l'expose, je récupère bien l'évènement depuis la bibliothèque haut niveau et je le renvoie à ma bibliothèque. Je ne peux pas chopper l'évènement depuis X11, car il faut tout de même passer par la bibliothèque haut niveau, sinon ça ferait n'importe quoi. Et puis surtout, l'évènement Expose n'est pas généré en permanence, or il faut que ma bibliothèque soit rafraîchie régulièrement (genre 60 fois par seconde).

Mais pour les autres évènements (clavier, souris, fermeture, resize, ...) je n'ai pas besoin d'intervenir sur le comportement par défaut, je veux juste les lire pour faire des trucs internes à ma bibliothèque.

Donc en fait je ne veux pas remplacer la MainLoop, bien au contraire, je veux juste pouvoir jeter un oeil aux évènements avant qu'ils ne disparaissent.

Alors évidemment si le but était juste de redispatcher les évènements via ma bibliothèque, je lacherais l'affaire tout de suite. Mais j'ai besoin d'effectuer d'autres traitements selon l'état du clavier, de la souris, etc...
23/07/2007, 18h32
Laurent Gomila

En fait pour synthétiser un peu, on va dire que :
- Nous sommes d'accord sur le fait qu'une utilisation "normale" écouterait les évènements de la bibliothèque haut niveau, et les transmettrait à ma lib
- Je ferai comme ça s'il n'y a pas d'autre solution
- Mais que j'aimerais intercepter les évènements (juste les regarder, mais ne rien changer au comportement de la bibliothèque haut niveau) lorsqu'ils passent par X11 (puisque j'ai justement à disposition l'id de la fenêtre)

On est bien ok ?
23/07/2007, 18h52
souviron34

Citation:

Envoyé par Laurent Gomila

On est bien ok ?

Oui

Par contre, quand tu dis :

Citation:

Envoyé par Laurent Gomila

.... Et puis surtout, l'évènement Expose n'est pas généré en permanence, or il faut que ma bibliothèque soit rafraîchie régulièrement (genre 60 fois par seconde).
....

J'ai bien peur qu'à part mettre un timer, ce ne soit pas possible. XLib envoie les événements quand elle le juge nécessaire... En plus des paramètres par défaut (par exemple la souris est par défaut toutes les 10?? ms je crois).
Mais si elle a bougé..

Mais un expose n'est généré que si il est nécessaire. De même le tracé d'un pixel est caché par la biblio, qui vérifie si il a déjà été tracé ou non (plusieurs lignes se croisent au même point par exemple)...

Si tu veux un expose (ou en tous cas l'appel de la callback) 60 fois par secondes, ce sera à toi de le faire... En gros l'expose arrive si la fenêtre est cachée (et apparaît (en partie)), si elle est visible (et disparait (en partie)), si un de ces enfants subit le même sort... Mais c'est tout... Sans changement (fenêtre on top et sans actions par exemple) pas d'expose... Il peut se passer 20 minutes, 2h, sans expose....

Et je ne comprends pas l'expression "faut que ma bibliothèque soit raffraichie".. Tu veux dire faut que ton graphique soit raffraichi ??

Si c'est le cas, je crois qu'il n'y a rien d'autre à faire qu'un timer....
24/07/2007, 08h19
Laurent Gomila

Ne t'inquiète pas pour ça, c'est ce que je fais. Soit je rafraîchis lorsqu'il n'y a pas d'évènement en attente (certaines libs génèrent un évènement idle dans ce cas), soit avec un timer.

je m'excuse :oops: mais il y a encore une chose que je ne comprend pas...

Tu dis :
Citation:
Citation:

et pourquoi pas ? Pourquoi faire des traitements différents (du point de vue de l'utilisateur) suivant les événements ? Ce serait plus simple à implanter et à expliquer..

Non non, ce serait beaucoup plus compliqué à implanter
Par exemple j'ai ce genre de choses (en pseudo C) :
Code:

1 2 3 4 5 6 7 8 9 10 11 void init(widget* w) { // J'envoie ma callback sur l'évènement repaint widget_on_repaint(w, &refresh); } void refresh(widget* w) { // Je met à jour ma bibliothèque w->MyDisplay(); }
Si je devais le faire pour chaque évènement je devrais faire ça :
Code:

1 2 3 4 5 6 7 8 9 void init(widget* w) { widget_on_repaint(w, &refresh); widget_on_mouse_move(w, &refresh); widget_on_key_press(w, &refresh); widget_on_close(w, &refresh); widget_on_resize(w, &refresh); ... }
Et puis tu dis :

Citation:

Bon ce que je fais ici est faisable en C, mais ce n'est pas la manière de procéder de Xlib. Plutôt que de recevoir tous les évènements au même endroit et d'avoir un gros switch, on associe une fonction différente à chaque évènement. En gros, le switch est fait en interne plutôt que par l'utilisateur. Ce qui fait que pour recevoir tous les évènements dans la même fonction, il faudrait que j'associe cette fonction à chaque évènement.

et

Citation:

Mais pour les autres évènements (clavier, souris, fermeture, resize, ...) je n'ai pas besoin d'intervenir sur le comportement par défaut, je veux juste les lire pour faire des trucs internes à ma bibliothèque.

Donc :

Comment sélectionnes-tu les événements que tu veux ?

Où les lis-tu, puisque ce n'est pas dans refresh ?

J'avoue que tu me perds un peu dans ton raisonnement....

24/07/2007, 11h18
Laurent Gomila

Citation:

1. Comment sélectionnes-tu les événements que tu veux ?

Avec XSelectInput (si c'est bien ça que tu voulais savoir).

Citation:

2. Où les lis-tu, puisque ce n'est pas dans refresh ?

Lorsque l'utilisateur va appeler MyDisplay(), cela va mettre à jour la vue, mais aussi aller traiter les évènements en attente dans la file.
24/07/2007, 11h26
souviron34

Citation:

Envoyé par Laurent Gomila

Avec XSelectInput (si c'est bien ça que tu voulais savoir).

Oui mais où ??

En quoi est-ce différent de ce que j'avais suggéré ?

Citation:

Envoyé par Laurent Gomila

Lorsque l'utilisateur va appeler MyDisplay(), cela va mettre à jour la vue, mais aussi aller traiter les évènements en attente dans la file.

A quel moment appelle-t-il MyDisplay ?

Citation:

Oui mais où ??

Au moment où l'utilisateur crée la fenêtre en lui passant l'identificateur X11.
En gros on peut créer une fenêtre de deux façons dans ma lib (j'adapte le code pour que ça se rapproche du C) :
Code:

1 2 3 4 5 6 // Là c'est ma lib qui crée la fenêtre MaLibWindow* w = MaLibCreateWindow(800, 600, "ma fenetre"); // Là c'est l'utilisateur qui a déjà créé la fenêtre Window Id = XCreateWindow(...); MaLibWindow* w = MaLibCreateWindow(Id);
Dans tous les cas je fais ce qui m'intéresse (dont XSelectInput) dans la fonction MaLibCreateWindow.

Citation:

En quoi est-ce différent de ce que j'avais suggéré ?

De quelle suggestion parles-tu ? :aie:

Citation:

A quel moment appelle-t-il MyDisplay ?

A chaque fois que je veux rafraîchir l'affichage. Donc avec une interface purement X11 ça donnerait ça :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 Window Id = XCreateWindow(...); MaLibWindow* w = MaLibCreateWindow(Id); while (1) { while (XPending(disp)) { XNextEvent(...); ... } MyDisplay(w); }
Et avec une bibliothèque haut niveau ce sera sur un évènement repaint, repaint qui sera forcé par soit un timer, soit l'évènement idle.

Citation:
Envoyé par Laurent Gomila
....
A chaque fois que je veux rafraîchir l'affichage. Donc avec une interface purement X11 ça donnerait ça :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 Window Id = XCreateWindow(...); MaLibWindow* w = MaLibCreateWindow(Id); while (1) { while (XPending(disp)) { XNextEvent(...); ... } MyDisplay(w); }
Et avec une bibliothèque haut niveau ce sera sur un évènement repaint, repaint qui sera forcé par soit un timer, soit l'évènement idle.
c'est bien ce que je disais, pourquoi ne pas mettre ton MyDisplay dans le while (et du coup tu as l'événement) ??

D'autre part tu dis "chaque fois que je veux...".. Et c'est quand ça ?
Ton timer c'est ça ? mais ça n'a rien de coordonné avec la Xlib ou la MainLoop ou le code de l'utilisateur...

24/07/2007, 13h48
Laurent Gomila

Citation:

c'est bien ce que je disais, pourquoi ne pas mettre ton MyDisplay dans le while (et du coup tu as l'événement) ??

Je crois qu'on tourne en rond là ;)
On a déjà évoqué la possibilité que l'utilisateur transmette lui-même les évènements à ma bibliothèque, je peux le faire et je le ferai si nécessaire, mais ici je cherche à ce que la bibliothèque les intercepte elle-même. Donc sans intervention de l'utilisateur.

Citation:

D'autre part tu dis "chaque fois que je veux...".. Et c'est quand ça ?

C'est dès qu'il n'y a pas d'évènement à traiter, en général. Mais a priori ça n'a pas tellement d'importance.

Citation:

Ton timer c'est ça ? mais ça n'a rien de coordonné avec la Xlib ou la MainLoop ou le code de l'utilisateur...

Non ça ce n'est pas mon timer. Ce sont les versions Qt ou wxWidgets qui utilisent un timer. Là étant donné que j'ai une main-loop explicite, je peux y placer mon MyDisplay sans avoir recours à un timer.

Voir 40 message(s) de cette discussion en une page