avec juste 2646 lignes de code C, je pense que trouvers les mécanismes X
essentiels devrait etre facile :)
Si mes souvenirs sont bons, le principe de base pour etre un WM c'est:
-Verifier qu'un autre WM ne tourne pas deja ;) Je crois qu'on utilise pour ça un "atome" special de la root window dans lequel un WM s'inscrit et que les autres doivent regarder avant de se lancer.
- obtenir l'id de la root-window du display
- Dire à X qu'on est intéressé par certains événements en rapport avec cette root-window, en particulier l'aparition de nouvelles fenetres (c-à-d les fenetres créees par les applications)
- Se mettre en attente d'événement.
- A reception d'un evenement "nouvelle fenetre", on l'inscrit dans sa base de fenetres à gérer.
- Pour les décorations de fenetres, en general le WM va créer une nouvelle fenetre qui ne dessinera que les bordures et la barre de titre, puis demander à X de "reparenter" la fenetre de l'appli, c'est-à-dire la faire passer de fenetre fille de la root-window à fenetre fille de la fenetre du WM. A partir de là, le tout forme une seule entité, qui peut donc se déplacer en bloc. Le WM doit sans-doute aussi intercepter les commandes de redimmensionnement de l'appli pour redimensionner sa fenetre de décorations.
- apres je ne sais pas trop comment le WM intercepte les evenement clavier/souris pour décider de ce qui l'interesse et ce qui doit etre transmis aux fenetres.
# Lightweight Window Manager
Posté par daggett . En réponse au journal gestion des fenêtres... Évalué à 1.
http://www.boognish.org.uk/enh/lwm/(...)
avec juste 2646 lignes de code C, je pense que trouvers les mécanismes X
essentiels devrait etre facile :)
Si mes souvenirs sont bons, le principe de base pour etre un WM c'est:
-Verifier qu'un autre WM ne tourne pas deja ;) Je crois qu'on utilise pour ça un "atome" special de la root window dans lequel un WM s'inscrit et que les autres doivent regarder avant de se lancer.
- obtenir l'id de la root-window du display
- Dire à X qu'on est intéressé par certains événements en rapport avec cette root-window, en particulier l'aparition de nouvelles fenetres (c-à-d les fenetres créees par les applications)
- Se mettre en attente d'événement.
- A reception d'un evenement "nouvelle fenetre", on l'inscrit dans sa base de fenetres à gérer.
- Pour les décorations de fenetres, en general le WM va créer une nouvelle fenetre qui ne dessinera que les bordures et la barre de titre, puis demander à X de "reparenter" la fenetre de l'appli, c'est-à-dire la faire passer de fenetre fille de la root-window à fenetre fille de la fenetre du WM. A partir de là, le tout forme une seule entité, qui peut donc se déplacer en bloc. Le WM doit sans-doute aussi intercepter les commandes de redimmensionnement de l'appli pour redimensionner sa fenetre de décorations.
- apres je ne sais pas trop comment le WM intercepte les evenement clavier/souris pour décider de ce qui l'interesse et ce qui doit etre transmis aux fenetres.
En gros :)