Discussion :

[Laurent Gomila]

Salut

Je réalise actuellement une bibliothèque qui doit gérer des fenêtres X11. Ces fenêtres sont créées par l'utilisateur, mais ma bibliothèque doit absolument pouvoir intercepter les évènements qu'elle génère avant l'utilisateur.

Je pourrais me contenter d'aller inspecter la file d'évènements sans retirer ceux-ci, mais un évènement pourra très bien être généré entre le moment où j'inspecte la file et le moment où l'utilisateur y retire l'évènement, donc je ne le verrais jamais.

Y a t-il un moyen infaillible d'intercepter les évènements d'une fenêtre avant tout le monde ? Un peu comme le subclassing sous Windows, qui détourne les évènements vers une fonction perso avant de les envoyer à l'utilisateur.

[souviron34]

XSelectInput ??

et XCheckWindowEvent et associés..

[Laurent Gomila]

D'accord, c'est bien ce que je fais, mais ensuite si j'implémente une boucle classique pour les évènements je ne pourrais jamais être sûr que je vais tout intercepter avant l'utilisateur ?!

Et puis d'ailleurs ça me pose un autre problème : certains évènements ne peuvent être écoutés que par un client (genre ButtonPress), donc comment faire pour que ma lib puisse écouter ces évènements si l'utilisateur le fait déjà ?

[souviron34]

tu ne te sers toujours que de la Xlib ?

Tu connais la fenêtre que tu veux surveiller ?

Si oui, il y a une manip ( très délicate) qui consiste à aller lire la liste des callbacks et placer la tienne en tête...

[Laurent Gomila]

tu ne te sers toujours que de la Xlib ?

Tu connais la fenêtre que tu veux surveiller ?

Oui, et oui.

Si oui, il y a une manip ( très délicate) qui consiste à aller lire la liste des callbacks et placer la tienne en tête...

Ah ça commence à me plaire, vas-y je t'écoute.

Et on va voir jusqu'à quel point on peut pousser cette technique : ensuite il faut que ça se mixe parfaitement avec wxWidgets ou Qt (ce qui marche très bien sous Windows, ceci-dit).

[souviron34]

Bon ça marche pas c'était avec Motif...

ça dépend des toolkits je pense (dans la Xlib, pas de notions de callbacks (pas de widgets)).

Ce que je te conseille :

Normalement, avec le selectinput, tu dois pouvoir spécifier que tu veux que ce soit envoyé vers toi. Et avec XCheckTypedWindowEvent tu devrais le recevoir avant qu'il soit traité (puisqu'il est dans la queue), et en plus il l'enlève de la queue.. Donc tant que tu ne le remets pas, c'est toi qui l'as.. Et juste avant de le remettre, tu te mets un flag "passage=True", et en début de routine juste "if (passage==True) {passage = False ; return;}"..

[Laurent Gomila]

Normalement, avec le selectinput, tu dois pouvoir spécifier que tu veux que ce soit envoyé vers toi

Je pensais que XSelectInput permettait simplement de filtrer les évènements qui étaient générés par la fenêtre, mais que tout le monde pouvait ensuite les consulter.

Et avec XCheckTypedWindowEvent tu devrais le recevoir avant qu'il soit traité (puisqu'il est dans la queue), et en plus il l'enlève de la queue.. Donc tant que tu ne le remets pas, c'est toi qui l'as..

Et s'il le retire avant que je l'ai traité ?
En gros je vais me retrouver avec ça :

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
while (true)
{
    ...
 
    (2)
    // Traitement des évènements par l'utilisateur
    while (XPending(display))
    {
        XNextEvent(...);
        ...
    }
 
    ...
 
    // Traitement des évènements par ma bibliothèque
    MyLibProcessEvents();
    (1)
 
    ...
}

Tout évènement généré entre (1) et (2) n'arrivera jamais jusqu'à ma lib, et je n'ai aucun contrôle sur la façon dont l'utilisateur va gérer la pile d'évènements, donc je ne pourrais même pas lui imposer un ordre dans les appels ou quoique ce soit.

[souviron34]

Je pensais que XSelectInput permettait simplement de filtrer les évènements qui étaient générés par la fenêtre, mais que tout le monde pouvait ensuite les consulter.

Non, d'où le nom.. Une fenêtre reçoit (enfin le X serveur), tous les événements possibles. Quand tu fais SelectInput, tu dis que TOI tu es intéressé à ceux-là..

Et s'il le retire avant que je l'ai traité ?
Tout évènement généré entre (1) et (2) n'arrivera jamais jusqu'à ma lib, et je n'ai aucun contrôle sur la façon dont l'utilisateur va gérer la pile d'évènements, donc je ne pourrais même pas lui imposer un ordre dans les appels ou quoique ce soit.

L'utilisateur n'a pas de contrôle sur la pile (sauf si il fait comme toi ).

Pour l'ordre, c'est le serveur qui détermine (X garanti que les requêtes sont traitées dans l'ordre d'arrivée).

Et en fait, tu aurais plutot quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
while ( Fini != 1 )
{
   XNextEvent (display, &event );
 
   switch (event.type )
        {
               case ButtonPress :
                        XRaiseWindow ( display, event.xany.window );
                        break ;
 
               default :
                        XPutBackEvent (display, &event );
                        break ;
        }
}

et si là normalement il l'ENLEVE de la pile... donc les autres ne le voit plus.. Jusqu'à ce que tu remettes PutBack...

[souviron34]

en fait, si c'est tjs le même projet, si c'est toi qui crée la fenêtre, pas de problème. Si ce n'est pas toi, le seul moyen de lister les callbacks, comme je disais 2 posts plus hauts, est de connaitre le toolkit utilisé, en tirer la liste des callbacks, et insérer la tienne.

[Laurent Gomila]

Non, d'où le nom.. Une fenêtre reçoit (enfin le X serveur), tous les événements possibles. Quand tu fais SelectInput, tu dis que TOI tu es intéressé à ceux-là..

Que représente "TOI" ici ? Le thread courant ? Je veux dire, lorsque je fais un XNextEvent, comment le serveur va savoir si c'est "moi" qui ai fait le XSelectInput ou un utilisateur de ma bibliothèque ?

L'utilisateur n'a pas de contrôle sur la pile (sauf si il fait comme toi ).

Là je ne comprends pas. L'utilisateur n'est pas censé utiliser des fonctions qui retirent les évènements de la pile au fur et à mesure qu'il les traite ?

Et en fait, tu aurais plutot quelque chose comme :
[...]

C'est la boucle utilisateur ou bibliothèque, ça ?

Et toujours la même question : qu'est-ce qui m'assure que je lire l'évènement avant qu'il ne soit viré de la pile par l'utilisateur ?

[Laurent Gomila]

en fait, si c'est tjs le même projet, si c'est toi qui crée la fenêtre, pas de problème. Si ce n'est pas toi, le seul moyen de lister les callbacks, comme je disais 2 posts plus hauts, est de connaitre le toolkit utilisé, en tirer la liste des callbacks, et insérer la tienne.

Oui c'est le même projet, et il y peut y avoir les deux cas de figure. Ici seul celui où je ne crée pas la fenêtre me pose problème.
Quant à cette solution, tu pourrais préciser ? Où y a t-il une telle liste de callbacks ?

[Laurent Gomila]

Ah oui, et je suis tombé aussi sur la fonction XESetEventToWire. Ca peut aider ? Ou rien à voir avec la choucroute ?

[souviron34]

je ne connais pas cette fonction (jamais entendu parler), mais vu son entête (XE) ça doit être une extension...

Quant à cette solution, tu pourrais préciser ? Où y a t-il une telle liste de callbacks ?

Par exemple, dans la XToolkit, tu peux avoir accès aux callbacks (XtVaGetValues ( widget, XtNexposeCallback, .....) )..

ça ça te donne la liste.. Sauf que c'est une copie éventuellement (non définie par le guide. A définir par les implémenteurs. Donc à vérifier suivant l'implémentation).

Mais DANS le widget tu as un pointeur sur la liste des callbacks, et là tu peux aller tripatouiller.. Mais je dis bien tripatouiller

Mais c'est lié à la notion de Widget, et non pas de fenêtres. Donc pas dispo dans la Xlib...

Que représente "TOI" ici ? Le thread courant ? Je veux dire, lorsque je fais un XNextEvent, comment le serveur va savoir si c'est "moi" qui ai fait le XSelectInput ou un utilisateur de ma bibliothèque ?

Toi représentais ta bibliothèque. Le serveur dispatch l'événement à qui a signalé qui était intéressé (en fait c'est l'équivalent d'un "broadcast").

Donc lui il s'en fout de savoir qui c'est...

C'est à toi de le gérer (ce que tu peux facilement faire poisque tu sais si c'est ta fenêtre ou une fenêtre déjà créée, donc avec l'id tu peux te débrouiller).

C'est la boucle utilisateur ou bibliothèque, ça ?

bibliothèque

Et toujours la même question : qu'est-ce qui m'assure que je lire l'évènement avant qu'il ne soit viré de la pile par l'utilisateur ?

Rien non je plaisante

Le serveur envoie à TOUS les clients qui ont fait un SelectInput.

Si l'utilisateur fait juste une boucle normale, aucun problème (normalement on doit TOUJOURS remettre l'evénement (dispatch à tout un tas de trucs, dont le WM)).

Si il le supprime totalement, vu que c'est une biblothèque, AUCUN moyen de prévenir... Mais pour ça il faudrait que comme toi il descende au niveau de X, et pas sous Qt ou GTK ou autre... Car dans ces cas-là tu as une MainLoop qui dispatch, mais tu n'as pas accès aux évènements directs.

En fait, d'après ce que je vois de ton problème, si l'utilisateur crée une fenêtre de son côté sans utiliser ta fonction de création, au moment où tu la chope ce serait peut-être une solution de crééer une fenêtre associée, et de lui ajouter tous les événements que tu veux sélectionner (fenêtre éventuellement transparente et "transient", c'est à dire avec un select ConfigureNotify, où tu chopes tout...).

Mais c'est une des raisons pour lesquelles je te suggérais au début d'avoir un CREATE à toi... (ou init ou n'importe quoi, mais où tu contrôles la fenêtre principale...)...

[souviron34]

je raqjouterais encore un truc..

Quand tu dis :

Tout évènement généré entre (1) et (2) n'arrivera jamais jusqu'à ma lib

C'est faux... Cà part au serveur, qui le re-broadcast.. Il suffit dans ta boucle à toi de refaire un while (Pending) ....

[Laurent Gomila]

Le serveur envoie à TOUS les clients qui ont fait un SelectInput.

Mais dans ce cas il n'y a qu'un client non ? Comment le serveur pourrait faire la différence entre la boucle d'évènement de ma bibliothèque et celle de l'utilisateur ? Ils partagent la même pile non ?

Si l'utilisateur fait juste une boucle normale, aucun problème (normalement on doit TOUJOURS remettre l'evénement (dispatch à tout un tas de trucs, dont le WM)).

Je pensais que le WM interceptait les évènements avant les clients (via SubstructureRedirect -- j'aurais bien utilisé la même méthode mais ça ne concerne qu'une petite partie des évènements).
Ensuite j'ai du mal à voir qui va vider la pile d'évènements si ce n'est pas nous ? Je veux dire, si on fait un XPutBackEvent, le XPending va boucler indéfiniment (à moins qu'il faille un XFlush pour qu'il soit repris en compte ?).
Et puis j'ai regardé le code source de bibliothèques ayant des versions X11 (Ogre, SDL) : leur boucle d'évènements est toujours la même, du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
while (XPending(...))
{
    XNextEvent(...);
}

A aucun moment l'évènement n'est replacé dans la pile.

En fait, d'après ce que je vois de ton problème, si l'utilisateur crée une fenêtre de son côté sans utiliser ta fonction de création, au moment où tu la chope ce serait peut-être une solution de crééer une fenêtre associée, et de lui ajouter tous les événements que tu veux sélectionner (fenêtre éventuellement transparente et "transient", c'est à dire avec un select ConfigureNotify, où tu chopes tout...).

Là j'ai pas compris, j'en ferais quoi de cette fenêtre ?

Mais c'est une des raisons pour lesquelles je te suggérais au début d'avoir un CREATE à toi... (ou init ou n'importe quoi, mais où tu contrôles la fenêtre principale...)...

Là non plus

En fait j'ai l'impression que j'ai une mauvaise compréhension de la manière dont sont gérés les évènements entre le client et le serveur. Je vais voir si je trouve une documentation claire sur le sujet.

[souviron34]

en gros c'est une histoire de pyramide :

-- WM

---- toolkit

------------ X


Donc lorsqu'il y a un WM, toute action de l'UTILISATEUR démarre du WM puis passe a toolkit (widget) puis à X...

Lorsque c'est traité par X, la REPONSE fait le chemin en sens inverse :

X -> widget -> WM ...

A aucun moment l'évènement n'est replacé dans la pile.

c'est parce qu'ils traitent TOUS les évènements et leurs conséquences (ils gèrent les widgets) [ comme je disais, par exemple, inversion de l'ombrage de la bordure quand tu appuies sur un bouton, puis inversion de nouveau quand tu relaches ]

Mais à moins que tu veuilles te taper tout ça, dès que toi tu fais une boucle avec NextEvent, soit tu ne veux pas que cet événement se propage, et tu ne le remets pas, mais si il a d'autres conséquences, il faut le remettre....
(je te retrouverais un bout de code demain)

Mais dans ce cas il n'y a qu'un client non ?

oui

La documentation la plus claire est le bouquin de Gettys et Scheiffler et NewMan...

[souviron34]

En fait pour être plus précis la hiérarchie est la suivante (le cheminement) :


-- WM

---- toolkit

------------ X (lib)

------------ X (protocole)

------------ X (serveur)

------------ X (protocole)

------------ X (lib)

---- toolkit

-- WM



C'est comme une communication Internet ou téléphone..

Toi ton interface c'est le clavier de ton tél. Il y a conversion en fréquence, puis envoi du signal vers le standard, puis interprétation et connection, etc..

De même internet : tu utilises par exemple ton navigateur, tu tapes "www.dvp", ça c'est le WM. Le navigateur interprète et appelles les routines de sockets IP (ça c'est toolkit), qui découpent ton message en packets (X lib) et envoient via le protocole... Et ça revient et ça remonte jusquà l'affichage....

[Laurent Gomila]

Ok je vois, merci pour l'exemple.

Par contre je suis toujours dans le brouillard concernant mon problème. En fait plus je lis de documentation plus j'ai l'impression que c'est pas vraiment prévu au niveau de la Xlib.

[souviron34]

En fait, je pense que tu poses mal le problème, éventuellement..

Que veux-tu faire exactement ?

[Laurent Gomila]

Oui, ce sera sans doute plus clair si j'expose la situation clairement.

Je développe une bibliothèque qui gère le fenêtrage / évènements (via la lib système le plus bas niveau -- donc Xlib sous Linux) et le graphisme (via OpenGL).

L'utilisation classique est de demander à la bibliothèque de créer sa propre fenêtre de rendu, mais l'utilisateur peut également dire à la bibliothèque d'utiliser une fenêtre externe déjà créée, via Xlib, Qt, wxWidgets, ou n'importe quoi d'autre.

Dans tous les cas ma bibliothèque doit intercepter les évènements associés à la fenêtre, car elle effectue quelques traitements dessus et les renvoie de manière homogène à l'utilisateur, via des structures propres à ma bibliothèque.

Lorsque c'est la bibliothèque qui crée la fenêtre aucun problème : c'est moi qui gère la boucle d'évènements, l'utilisateur n'a pas à se préoccuper de ça.

Dans le cas où la fenêtre est externe par contre, il faut que je trouve un moyen de récupérer tous les évènements, sans pour autant que cela perturbe une potentielle autre boucle d'évènements déjà en place côté utilisateur.

Sous Windows ça se fait très naturellement : tous les évènements sont reçus via un callback, il suffit donc de détourner ce callback. Par contre sous Linux avec la Xlib j'ai l'impression que les choses ne peuvent pas du tout se passer comme ça, et je cherche donc une autre technique pour arriver au même but.