Ce n'est pas très clair : Wayland intègre son gestionnaire de fenêtres mais les fenêtres doivent elles-mêmes dessiner leurs décorations ?
Oui, c'est le comportement par défaut.
Ça semble un peu idiot,
Non: aucune solution n'est idéale, c'est un compromis.
L'idée ici c'est que le client soit responsable de l'affichage de toute la fenêtre afin d'être sûr que la fenêtre soit "parfaite" en permanence,
ça a des conséquences:comment iconifier la fenetre si le client ne répond pas?, mais c'est défendable.
ça promet un beau bordel bien disparate,
Bah pas beaucoup plus que si tu mélanges du GTK, Qt, EFL, pur X à l'heure actuel.
La synchro se fera par du EWMH j'imagine.
la résistance à Wayland promet d'être féroce.
Il y a des raisons de ne pas aimer Wayland:
-non portabilité actuelle sur les *BSD
-un client "pur" Wayland en WAN utiliserait beaucoup trop de bande passante
mais les décorations clientes, non, je ne pense pas que ce soit un gros problème une fois que les bugs de jeunesses seront résolus.
[^] # Re: Gestionnaire de fenêtres
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 5.
Oui, c'est le comportement par défaut.
Non: aucune solution n'est idéale, c'est un compromis.
L'idée ici c'est que le client soit responsable de l'affichage de toute la fenêtre afin d'être sûr que la fenêtre soit "parfaite" en permanence,
ça a des conséquences:comment iconifier la fenetre si le client ne répond pas?, mais c'est défendable.
Bah pas beaucoup plus que si tu mélanges du GTK, Qt, EFL, pur X à l'heure actuel.
La synchro se fera par du EWMH j'imagine.
Il y a des raisons de ne pas aimer Wayland:
-non portabilité actuelle sur les *BSD
-un client "pur" Wayland en WAN utiliserait beaucoup trop de bande passante
mais les décorations clientes, non, je ne pense pas que ce soit un gros problème une fois que les bugs de jeunesses seront résolus.