Discussion :

[souviron34]

j'avoue que je comprend pas ton schéma fonctionnel...

je comprend :

Code :

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

1
2
3
4
5
Widget    soit à toi, soit pas à toi
 
engistrement        soit du tien à la création, soit pas du tien
 
dans l'enregistrement, ajout des fonctions d'écoute d'événement

Mais après je ne comprend toujours pas où tu places ton instruction ci-dessus (while() ) ni comment c'est appelé ni par qui.... Tu parles que l'utilisateur doit appeller MyDisplay, mais là tu me montres une boucle où c'est toi qui l'appelle... Et comment l'utilisateur appelle cette boucle ?? Tu dis que tu as une ainloop explicite, mais ça veut dire que l'utilisateur appelle explicitement ta mainloop en lieu et place de celle de l'outil ?? je nage là...

Je crois que je comprend le fond, mais pas la forme.. Alors laisse tomber pour l'instant, je vais tester mes idées pour résoudre ton fond, et je te présenterais le résultat. Et continue à chercher de ton coté...

Mais par exemple, je n'ouvrirai pas de display si la fenêtre est déjà créée par l'utilisateur... Et même dans l'autre cas, d'ailleurs... Car à moins que l'appel à ton init soit la première instruction de SON programme, il aura déjà fait appel à un init (soit OpenDisplay soit un init d'un toolkit), et le display sera déjà ouvert...

Mais bon, encore une fois, continue de ta façon, et je vais chercher de la mienne, car je crois que notre philosophie est trop fondamentalement différente pour qu'on s'entende sans exemple précis....

[Laurent Gomila]

Je crois que tu as raison, je vais faire quelques tests de mon côté aussi et voir où ça mène.

Sinon juste pour répondre à ton interrogation : le code que j'ai montré plus haut est bien le code de l'utilisateur, dans le cas où celui-ci veut intégrer ma bibliothèque dans une interface X11 qu'il a créée.

[Laurent Gomila]

En tout cas merci beaucoup pour le temps que tu m'accordes, c'est vraiment sympa

[Laurent Gomila]

Bon, après quelques tests supplémentaires voici mes conclusions :

- Le fait d'ouvrir une nouvelle connexion avec le display dans ma bibliothèque n'est finalement pas une si mauvaise idée : ça lui permet d'avoir sa propre pile d'évènements, et elle peut donc les traiter indépendamment de ce que fait l'utilisateur avec sa pile d'évènements

- J'arrive donc bien à récupérer les évènements des fenêtres externes

- Sur les sous-fenêtres, je ne récupère que certaines évènements (les mouvement souris (MotionNotify) principalement) ; peut-être une histoire de focus ?

- J'avais peur de ne pas pouvoir écouter les évènements souris / clavier si l'utilisateur les écoutait déjà : en fait il apparaît que ça ne concerne que l'évènement ButtonPress (même pas ButtonRelease). Je ne retrouve plus la doc dans laquelle j'avais lu que certains évènements ne pouvaient pas être écoutés par plus d'un client à la fois, tu aurais des infos à ce sujet ?

Voilà donc en fait le problème est presque résolu. Reste à savoir pourquoi je ne choppe pas bien les évènements des sous-fenêtres, et pourquoi ButtonPress pose problème.

[Laurent Gomila]

En fait pour ButtonPressMask, c'est tout simplement indiqué dans la doc

Il semblerait que je doive utiliser XQueryPointer pour récupérer moi-même l'état des boutons.

[souviron34]

Bon ben déjà c'est bien tout ça

XQueryPointer :
oui dans le dernier champ (keys)

Pour les sous-fenêtres : ça doit venir du do_not_propagate
A ce compte-là il faut peut-être que tu explores la liste des enfants (QueryChildren) et que tu leur fasses aussi le SelectInput

Pour les événements non-écoutables par quelqu'un d'autre : c'est quand tu fais appel à GrabKeyboard ou GrabPointer. A partir de là, si tu as mis le flag, ce n'est pas trasmis aux autres..

Mais tu as toujours la ressource de le faire sur la RootWindow. Pour elle je ne crois pas que ce soit bloquant.. Je me souviens plus...

Mais avec le motionNotify et/ou le QueryPointer + keys tu dois pouvoir te débrouiller (sauf le keyboard éventuellement..à voir)

[Laurent Gomila]

Pour les sous-fenêtres : ça doit venir du do_not_propagate
A ce compte-là il faut peut-être que tu explores la liste des enfants (QueryChildren) et que tu leur fasses aussi le SelectInput

En fait je fais le XSelectInput directement sur la sous-fenêtre. Tu penses qu'il faudrait plutôt que je le fasse sur leur parent ?

Mais avec le motionNotify et/ou le QueryPointer + keys tu dois pouvoir te débrouiller (sauf le keyboard éventuellement..à voir)

Oui, je pense qu'avec XQueryPointer ça va le faire. Pour le clavier je n'ai pas de problème, et si un jour un client veut faire un GrabKeyboard et bien tant pis pour lui

[souviron34]

En fait je fais le XSelectInput directement sur la sous-fenêtre. Tu penses qu'il faudrait plutôt que je le fasse sur leur parent ?

et sur leur parent ? ou sur leur parent ?

à tester je suppose, mais sans doute je mettrais un ET sur leur parent...

Ou alors tu remontes la hiérarchie et tu vas jusquà la Window en dessous de la fenêtre la plus basse dans la hiérarchie et qui a la même dimension que la RootWindow.

En gros, l'écran est partagé comme suit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
RootWindow
 
Fen 1                        -> même dimension
....
Fen N                        -> même dimension (base du Window Manager)
 
Fen N+1     N+2      N+3     fenêtres WindowManager des applis
   |
  Fe1                         -> même dimension que celle de l'appli, Toolkit
   |
  Fe2                         -> même dimension que celle de l'appli, X
   |
F1 F2 F3                      -> sous-fenêtres de l'appli

Donc éventuellement ce que je dit c'est remonter jusqu'à Fen N+1...