Discussion :

[souviron34]

Bon ça s'éclaircit...

En fait si c'est la même chose.. C'est juste que Windows ne fournit pas (sauf avec la xlib sous cygwin) de modèles en vraies couches (il y en a, mais c'est plus complexe). Mais comme je dis, si tu as des "callbacks", c'est que tu utilises des Widgets, et donc un toolkit.... X ne connait que des événements...


En fait, ce que tu voudrais, ça doit pouvoir se faire au moyen de 2 routines :

• Pour ceux qui utilisent la routine de création de ta biblo, pas de problèmes, c'est toi qui contrôles.
  
  
• Pour ceux qui fabriquent une fenêtre à l'extérieur, il y a 3 solutions :
  
  
  
  • Soit il y a une routine dans ta biblio Register_Window , qui a en entrée le Window (de X), et tu rajoutes tes événements à toi (tout en sachant que tu n'as pas le contrôle de l'ordre dans lequel ça se passe)
    
    
  • Soit il y a une fonction dans ta biblio Register_Window, qui a en entrée une fonction que EUX doivent définir (mais dont tu contrôles certains paramètres) qui te donne le WindowId de leur topWidget...
    Et dans ce cas, tu pourras ajouter tes événements sur ce topWidget, sachant que dans le traitement les événements doivent descendre la hiérarchie.
    
    
  • Soit tu ajoutes tes select sur la RootWindow, et tu gères....

En fait, à mon avis le plus simple (même si apparaît plus compliqué) est d'utiliser la 3ième solution (en analysant au premier appel d'une fenêtre non-crée par toi la hiérarchie pour stocker les Window enfants).

La première solution est la plus simple, mais comme je dis tu n'as pas (tu ne pourras pas) avoir le contrôle de l'ordre. Et tu devra re-dispatcher les évènements...

En fait en gros, tu as tes "callbacks" en fonction des évènements, identifiées par des types, et tu mets des flags pour dire si c'est intéressant ou non, et si tu as déjà traité (du coup tes while() ne seront pas infinis). Le mieux est à ce compte-là de faire XPeekIfEvent (ou l'équivalent, je ne me souviens plus) qui vérifie si l'événement existe mais ne le retire pas de la liste...

Les outils/toolkit/IDE comme GTK, Motif, SDL, OpenGL etc... (c'est tout le problème, et le fait que les Widgets Motifs et OpenGL sont nettement plus élaborés que les autres) ne sont pas standards, mais sont deux couches au-dessus de la Xlib (d'abord la XToolkit, puis eux).

Et que c'est fait pour faire des applis "bateaux". Dès que tu veux faire de la programmation fine, tu dois tombr sous X, et là tu as le problème que des propriétés sont cachées, diffciles à atteindre, etc...


Je dirais donc en conclusion :

• Pourquoi autorises-tu les 2 modes de fonctionnement ? (la création de fenêtre par X dépendra du Toolkit et du WM, donc l'ornementation, les bordures, les boutons minimaux, etc..)
  
• Si tu fais une biblo qui gères le fenêtrage etc tu refais un toolkit ? tu refais un GTK ou autre ?
  
• Si tu veux fournir des fonctionalités, alors fournis des fonctionalités... MAis j'ai l'impression que là tu veux un peu "ré-inventer" la roue, en tentant d'être compatible avec les autres, ce qui n'est pas possible (fonctionalités supplémentaires spécifiques).

Enfin, si j'ai bien compris

[Laurent Gomila]

Soit il y a une routine dans ta biblio Register_Window , qui a en entrée le Window (de X), et tu rajoutes tes événements à toi (tout en sachant que tu n'as pas le contrôle de l'ordre dans lequel ça se passe)

Tu pourrais développer cette solution ? Je ne suis pas sûr de tout avoir compris.

Soit tu ajoutes tes select sur la RootWindow, et tu gères....

Ca me paraît pas mal, mais là aussi j'ai du mal à voir la suite. Si j'ajoute mes select sur la RootWindow, ça veut dire que je veux surveiller ces évènements sur toutes ses fenêtres enfant ? Et que donc dans le tas j'aurais ceux de la fenêtre qui m'intéresse ? Et que je vais les intercepter forcément avant celui qui observe directement la fenêtre ? J'ai tout bon ?

Si tu fais une biblo qui gères le fenêtrage etc tu refais un toolkit ? tu refais un GTK ou autre ?

Non absolument pas. En fait ma bibliothèque est plutôt orientée jeux vidéo / graphisme temps réel, le but ici est juste de fournir une fenêtre pour y placer la vue graphique, et intercepter les évènements du genre clavier, souris, joystick, ...
Mais je ne développe aucun widget.

Pourquoi autorises-tu les 2 modes de fonctionnement ?

Parce que, cf. le paragraphe précédent, je ne fournis aucun élément d'interface, juste un moyen de placer une vue graphique dans une fenêtre. Donc il faut que l'on puisse aussi placer cette vue dans autre chose qu'une bête fenêtre, donc que l'on puisse mixer ma bibliothèque avec une interface wxWidgets, Qt ou autre. En fait c'est exactement ce que fait SDL, d'ailleurs à la base ma bibliothèque est une version améliorée / C++ de SDL.

Si tu veux fournir des fonctionalités, alors fournis des fonctionalités... MAis j'ai l'impression que là tu veux un peu "ré-inventer" la roue, en tentant d'être compatible avec les autres, ce qui n'est pas possible (fonctionalités supplémentaires spécifiques)

Je ne cherche pas à réinventer la roue, plutôt à pouvoir greffer ma bibliothèque sur des bibliothèques qui fournissent des fonctionnalités complémentaires. D'ailleurs ça fonctionne très bien au niveau graphique, seuls les évènements posent problèmes.

[souviron34]

mm je vais réfléchir....

MAis pas ce soir ya fête au village et bal

[Laurent Gomila]

mm je vais réfléchir....

MAis pas ce soir ya fête au village et bal

Salut, t'as du nouveau ?
La fête était sympa ?

[souviron34]

Salut, t'as du nouveau ?
La fête était sympa ?

oui mais chez nous ça dure 4 soirs.. Donc pas encore finie (encore ce soir )

Sinon faudrait que je teste mes idées, mais en ce qui concerne :

Soit il y a une routine dans ta biblio Register_Window , qui a en entrée le Window (de X), et tu rajoutes tes événements à toi (tout en sachant que tu n'as pas le contrôle de l'ordre dans lequel ça se passe)

Tu pourrais développer cette solution ? Je ne suis pas sûr de tout avoir compris.

Ce que je voulais dire c'est que, la première fois où tu "vois" une fenêtre que tu n'as pas créée, tu lui rajoutes tous les événements et Event Handler dont tu as besoin.

Par contre, ça ne garanti pas l'ordre d'appel.

Mais je ne sais franchement pas si tu peux garantir l'ordre dans ce cas...

Je ne sais pas comment fonctionne SDL ou wx, mais si j'admet que c'est comme Motif, alors chaque Widget a une Window associée. Sauf que c'est le "fournisseur" de widget qui crée.

Là, vouloir insérer une Window dans un widget, c'est un peu... étrange comme philosophie... Car le widget est à priori un objet virtuel (d'ailleurs, normalement, si tu ne le "réalises" pas, les fonctions cherchant ses dimensions doivent retourner des dimensions nulles). Ensuite, le même "widget" peut être mappé sur différents écrans. Ce que nous voyons à l'écran comme "widget" est une "réalisation" de ce widget pour cet écran particulier (la Window).

Or donc, mon point est que insérer "graphiquement" un graphique dans une "réalisation" d'un widget est philosophiquement contraire à la notion de Widget.

Donc oui ça doit marcher (c'est purement du graphique) sur un seul écran, mais cela ne correspond pas au fond de X. C'est du bidouillage. Enfin c'est que je pense à ce stade (et à cette heure-ci ).

C'est pour ça qu'au départ je te parlais d'une routine de création à appeler : normalement tu devrais fournir un Widget correspondant à chaque outil avec lequel tu veux être compatible (un nouveau WxWidget, etc...). Ce serait la philosophie "normale" et logique.

Maintenant, si je prend ton point de vue, je conçois qu'on veuille ajouter des événements sur un Widget existant qu'on ne connaît pas forcément. Mais cela me semble dangereux (je vais expliquer pourquoi) de faire du graphique dessus.

Ajouter des événements et/ou des traitements associés me semble OK.

Ajouter du graphique, le problème, c'est que TOUTE fenêtre X peut contenir du graphique, et que puisque tu n'auras pas accès au "fournisseur" de Widget, comment sauras-tu si le Window qu'on te passe correspond bien à un Widget du type que tu souhaites, et non une icône, un bouton-poussoir, un toggle, un menu déroulant, un label, une échelle, ou n'importe quel widget ??

TOUT Widget a une fenêtre X sous-jacente (et même plusieurs : un "scroll-text" est composé de 3 widgets : un de texte, et 2 ascensceurs. Le widget de texte a une fenêtre X, chacun des ascensceurs en a 4 (les 2 fléches, le corps de l'ascensceur, et le bouton)). Est-ce que tu accepteras que l'utilisateur te passes la fenêtre X d'une des fléches d'un ascensceur ??

En fait c'est ça qui me gêne depuis le début... En travaillant à l'échelon inférieur, tu n'as aucune idée de ce à quoi ça sert à l'échelon supérieur (le "parent" t'est inconnu).

[EDIT]
Pour reprendre mon analogie, c'est comme si tu voulais que le standard de France Télécom aille modifier TON téléphone, ou que la couche de transport de Internet modifie un serveur Web..
[/EDIT]

Si c'est bien ça que tu veux, j'irais tester aujourdhui ou demain mes petites idées avant de t'en faire part...

[Laurent Gomila]

oui mais chez nous ça dure 4 soirs.. Donc pas encore finie (encore ce soir )

Sympa la fête

C'est pour ça qu'au départ je te parlais d'une routine de création à appeler : normalement tu devrais fournir un Widget correspondant à chaque outil avec lequel tu veux être compatible (un nouveau WxWidget, etc...). Ce serait la philosophie "normale" et logique.

C'est bien ce que je fais. Mais il faut bien que j'ai un moyen de dessiner dans mon widget perso. Et hors de question de passer par les routines de dessin de la bibliothèque utilisée pour mettre à jour le widget, ce ne serait pas suffisamment performant (imagine un widget affichant une vue 3D de 1000x1000 pixels qui doit être rafraîchie 60 fois par seconde...).
Donc je suis bien d'accord sur le fait que philosophiquement, je devrais construire par dessus la bibliothèque utilisée, mais d'un point de vue performances je n'ai pas d'autre choix que de la court-circuiter avec mes propres routines bas niveau. Mais bon c'est parfaitement prévu au niveau des bibliothèques du genre Qt ou wxWidgets, puisqu'elles fournissent des fonctions pour récupérer l'identificateur X11 des fenêtres, et des options pour court-circuiter l'affichage "normal" qui serait fait par la bibliothèque.

Ajouter du graphique, le problème, c'est que TOUTE fenêtre X peut contenir du graphique, et que puisque tu n'auras pas accès au "fournisseur" de Widget, comment sauras-tu si le Window qu'on te passe correspond bien à un Widget du type que tu souhaites, et non une icône, un bouton-poussoir, un toggle, un menu déroulant, un label, une échelle, ou n'importe quel widget ??

Aucun, mais ça c'est la responsabilité de l'utilisateur
Et puis si vraiment le gars veut afficher une vue 3D dans un bouton-poussoir, ben ma foi... ça fonctionnera.
Mais comme je te l'ai dit je fournis déjà un widget spécialisé pour chaque bibliothèque, donc les utilisateurs n'auront pas à bidouiller directement les widgets, ils pourront utiliser les miens.

Si c'est bien ça que tu veux, j'irais tester aujourdhui ou demain mes petites idées avant de t'en faire part...

Super, merci

[souviron34]

Alors attends, il y a un truc que je comprend pas trop :

C'est bien ce que je fais. Mais il faut bien que j'ai un moyen de dessiner dans mon widget perso.
....
Mais comme je te l'ai dit je fournis déjà un widget spécialisé pour chaque bibliothèque, donc les utilisateurs n'auront pas à bidouiller directement les widgets, ils pourront utiliser les miens.
...

Alors où est le problème ????

Ton dessin 3D ne fonctionne qu'avec TON widget, non ??

J'avoue que là je suis plus....

Tu fournis un Widget par biblio, donc les utilisateurs vont appeller LGCreateWidget, non ??

Donc tu as le contrôle de ta fenêtre.. Je ne vois pas en quoi ils peuvent te passer un Window ID d'un de LEURS widgets et utiliser le TIEN ??

Si tu ne fournis pas de Widget, OK, tu as le problème. Mais si tu fournis le Widget...

[Laurent Gomila]

Ben dans ce cas précis c'est moi l'utilisateur, c'est moi qui fournit l'identificateur X11 à la bibliothèque pour justement fabriquer mon widget perso. Alors évidemment je pourrais utiliser les évènements du widget et les envoyer à la bibliothèque, plutôt que de chercher à ce qu'elle les intercepte au niveau X11, mais ça m'arrangerait grandement de ne pas avoir à le faire

On peut aussi imaginer le cas où le gars code directement une interface X11 (je pense que ça reste anecdotique comme situation, mais bon imaginons), dans ce cas il n'y a bien entendu pas de widget perso.

[souviron34]

On peut aussi imaginer le cas où le gars code directement une interface X11 (je pense que ça reste anecdotique comme situation, mais bon imaginons), dans ce cas il n'y a bien entendu pas de widget perso.

Et c'est pour ce cas-là (et seulement pour ce cas-là) que tu as le problème c'est ça ?

[souviron34]

Alors évidemment je pourrais utiliser les évènements du widget et les envoyer à la bibliothèque, plutôt que de chercher à ce qu'elle les intercepte au niveau X11, mais ça m'arrangerait grandement de ne pas avoir à le faire .

Pourquoi ??

Ce serait la manière normale...


Si l'on reprend le schéma :

Soit tu crées une fenêtre X11, et tu créées une application X11 (événements).

Soit tu crées un Widget (qui a une fenêtre X11 sous-jacente). Dans ce cas, tu es en mode "objet". Dans ce cas, tu as un certain nombre de cas précis d'événements et de propriétés de ton objet, avec des méthodes définies par l'utilisateur du Widget (register widget (method Event1) ), avec éventuellement des méthodes à toi, enregistrées à la création.

[souviron34]

regarde, avec ton RAD/IDE favori :

tu "drag-and-drop" un Widget dans une fenêtre.
Tu as accès à propriétés et événements (exemple : OnClick).

Je pense (pas vérifié, mais ça semblerait logique) que le code du Widget utilise les mêmes mécanismes pour créer ses actions internes sur OnClick que l'utilisateur.. C'est juste qu'il les fait en premier, à la création.

Est-ce faux ? (je ne me suis pas penché là-dessus).

[souviron34]

Attend attend..

Je commence à voir un peu... Mais si tu utilises un Widget, tu peux utiliser la XToolkit alors, non ??

[Laurent Gomila]

Et c'est pour ce cas-là (et seulement pour ce cas-là) que tu as le problème c'est ça ?

Non, dans le cas où l'ID de la fenêtre vient d'une autre bibliothèque, c'est pareil. Il me faut un moyen d'intercepter les évènements.
C'est juste que dans ce cas je n'ai pas la solution de rechange de passer par les évènements de la bibliothèque haut niveau.

Pourquoi ??
Ce serait la manière normale...

C'est ce que je ferai si je ne peux vraiment pas passer par le bas niveau, mais ça rajoute pas mal de code sur chaque widget perso. Toute bibliothèque passe forcément, directement ou non, par X11 pour capter les évènements. Donc si j'arrive à les gérer à ce niveau (X11) ça me permettra d'avoir un code universel, plutôt que de devoir intercepter les évènements au niveau de chaque widget perso.

Mais si tu utilises un Widget, tu peux utiliser la XToolkit alors, non ??

Pour ça il faudrait que les version Linux des diverses bibliothèques d'interfaces graphiques utilisent elles-même XToolkit, or je ne pense pas que ce soit le cas.

[souviron34]

ok je commence à voir... désolé je suis un peu long...

J'ai une idée, mais je creuse et je te dis...

[Laurent Gomila]

ok je commence à voir... désolé je suis un peu long...

T'inquiète, moi aussi je patauge un peu. Ce qui est drôle ici c'est que moi j'ai une vision complétement Windows de la chose, et toi (apparemment) une vision complétement Unix. Et visiblement la philosophie est quelque peu différente

[souviron34]

T'inquiète, moi aussi je patauge un peu. Ce qui est drôle ici c'est que moi j'ai une vision complétement Windows de la chose, et toi (apparemment) une vision complétement Unix. Et visiblement la philosophie est quelque peu différente

Pas étonnant.. J'ai jamais programmé sous Windows

(enfin si peu, avec VB et Delphi).

Mais oui la philosophie est opposée. Un exemple simple :

la communication par sockets (je ne sais pas si tu connais).

Comme Windows et les PC n'avait qu'un seul port de communication externe, et que M$ est M$, un serveur (il y a 5 ou 7 ans) sous Windows tournait en regardant toutes les secondes si il y avait quelque chose sur le port. Et si éventuellement tu voulais être réveillé quand quelque chose arrivait (communication asynchrone), il fallait passer l'identificateur de la fenêtre à la routine (ce qui viole toutes les normes de développement en couches : pourquoi la couche profonde de communication avec le port aurait-elle besoin de savoir par quoi elle est utilisée ?).

Sous tous les systèmes unixoides, mais aussi VMS, MVS, etc.. il y a depuis fort longtemps (+30ans) plusieurs ports de communcation externes. Le système juste au dessus de la couche de transport, les sockets, sont une couche. Donc il y a par définition une routine de communication asynchrone, et d'autre part elle fait partie d'une bibliothèque, et donc est indépendante de ce à quoi on l'utilise. En conséquence, un serveur dort indéfiniment jusqu'à ce qu'il soit réveillé.

Comme M$ a eu pas mal de remarques sur le fait que c'était pas efficace et que ça violait les normes, et qu'ils étaient mono-user et souvent mono-tâches, ils ont développé le "multi-thread". Qui maintenant s'est déplacé vers les systèmes unixoides, mais qui n'a aucune raison d'être sur un système à plusieurs ports, multi-utilisateurs et multi-tâches.

Je ne vois pas d'exemple de serveurs unixoides "normaux" fonctionnant en multi-thread, alors que les "développeurs" de maintenant (provenant de formations axées d'abord sur Windows) en développent même pour unixoides...

Et ce n'est qu'un exemple parmi d'autres... Mais de fond...

Pour en revenir à notre problème, mais lié à ce que je viens de dire, Windows mélange l'OS et le système de fenêtrage. Sous les systèmes multi-tâches multi-utilisateurs, il y a toujours eu la distinction. Et donc un développement "en couches" ISO indépendantes. Mais sous Windows la distinction n'existe que très partiellement puisque tu n'interagis pratiquement qu'avec la partie visible (fenêtre de commande quasi inexistante).

Donc oui par rapport au graphisme (entre autres) la philosophie est profondément différente.

Par contre, avant d'approfondir mon idée, j'ai encore une question :

Normalement, un utilisateur utilisant Qt, GTK ou autre, doit faire appel à une fonction MainLoop ou quelque chose comme ça, non, en dernière instruction de son main ? Et la main loop gère les événements ?

Donc pourquoi toi as-tu besoin de refaire un while(Pending) ??

[Laurent Gomila]

Normalement, un utilisateur utilisant Qt, GTK ou autre, doit faire appel à une fonction MainLoop ou quelque chose comme ça, non, en dernière instruction de son main ? Et la main loop gère les événements ?

Oui, ça se passe généralement de cette manière.

Donc pourquoi toi as-tu besoin de refaire un while(Pending) ??

Comment accéder aux évènements sinon ?

Sinon, un doute m'assaille depuis quelques jours : vu que dans ma bibliothèque j'ouvre une nouvelle connexion avec le serveur (via XOpenDisplay) au lieu de récupérer celle ouverte par l'utilisateur, est-ce que ma bibliothèque n'est pas considérée comme un client différent de l'utilisateur ? Ca expliquerait plusieurs choses : d'une part que ma bibliothèque ne puisse pas sélectionner les évènements de type souris / clavier si l'utilisateur les écoute déjà (la doc stipule qu'un seul client peut les écouter), d'autre part que lorsque je passe à ma bibliothèque l'identificateur de la fenêtre, je me tape parfois un BadWindow, la solution étant toujours un XFlush côté utilisateur pour synchroniser tout le monde.
Si c'est bien le cas (deux clients différents), j'ai ma propre pile d'évènements, indépendante de celle de l'utilisateur non ? Dans ce cas les choses ne pourraient pas être plus faciles ??

[souviron34]

Bon attend je reprend pour voir si j'ai compris ce que tu veux faire...

Tu as une bibliothèque biblio.c qui contient :

CreateMyWindow

et

StoreOtherWindow

• Première question : pourrais-tu avoir les 2 simultanément ?
  
• Seconde question : si oui, tu fais un OpenDisplay systématique, même si tu es dans le cas de "store" ?
  
• Troisème question : comment tu te retrouves dans ton while(Pending) si l'utilisateur a fait un MainLoop ? As-tu une fonction qu'il doit appeller (MyFlush) ?

[Laurent Gomila]

Première question : pourrais-tu avoir les 2 simultanément ?

Techniquement oui, mais ce n'est pas le but, faudrait vraiment faire un truc tordu pour se retrouver dans ce cas de figure.

Seconde question : si oui, tu fais un OpenDisplay systématique, même si tu es dans le cas de "store" ?

Oui. En dernier recours je pourrais demander à l'utilisateur de passer son Display en même temps que l'id de la fenêtre, mais si je peux l'éviter c'est pas plus mal.

Troisème question : comment tu te retrouves dans ton while(Pending) si l'utilisateur a fait un MainLoop ? As-tu une fonction qu'il doit appeller (MyFlush) ?

Un truc de ce genre, oui. En fait c'est fait indirectement : la fonction à appeler pour l'utilisateur c'est plutôt un MyDisplay (pour afficher à l'écran ce qu'il vient de dessiner), et dans ce MyDisplay je fais quelques traitements internes, dont notamment la réception des évènements.

[souviron34]

ok mais si lui il a un MainLoop, comment il appelle MyDisplay ??

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.

Mais si il n'en a pas enregistré, tu fais comment ??