C'est également X qui à la base dessine la bordure de fenêtre (qui est un "Window Attribute"). Cependant, tout ce qu'on obtient par ce moyen c'est une bordure de couleur unique de n pixels tout autour de celle-ci. C'est pour cela que la plupart des WM "reparentent" les fenêtres de chaque application : ils créent une fenêtre dont la fenêtre de l'application devient l'enfant.
D'accord, je viens de comprendre pourquoi les « non-parenting window manager » comme Awesome ne permettent pas d'avoir des cadres élaborés, je croyais que c'était lié avec la fonctionnalité de tilling.
Par contre les ombrages qui sont créées avec un logiciel comme compton, comme ça se passe ? Est-ce que c'est une fenêtre créée (pour avoir de la place pour faire l'ombre), avec ensuite l'application placée dedans en tant qu'enfant ?
Et ça me fait penser, un menu contextuel, est-ce aussi une sous-fenêtre de l'application ?
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par Dreamkey . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 4.
D'accord, je viens de comprendre pourquoi les « non-parenting window manager » comme Awesome ne permettent pas d'avoir des cadres élaborés, je croyais que c'était lié avec la fonctionnalité de tilling.
Par contre les ombrages qui sont créées avec un logiciel comme compton, comme ça se passe ? Est-ce que c'est une fenêtre créée (pour avoir de la place pour faire l'ombre), avec ensuite l'application placée dedans en tant qu'enfant ?
Et ça me fait penser, un menu contextuel, est-ce aussi une sous-fenêtre de l'application ?