À mon sens, le choix des développeurs de Wayland qu’il en fasse le moins possible et de déléguer presque tout aux clients est de très loin leur choix le moins judicieux.
Le fait qu'ils ne s'occupent pas des décorations de fenêtre ne me choque pas, en soit.
Du peu que je connais, rien ne semble empêcher l'implémentation du paradigme:
Par flemme, tout le monde construit la logique de la gestion des fenêtre dans le serveur graphique, mais je ne vois rien qui empêche de split la chose. En fait, ça serait probablement, la meilleure chose à faire: moins de code dans l'une des parties les plus critiques, qui pourrais (devrais?) ne faire que gérer le respawn de certains services critiques (s'ils existent: le wm, un VNC en entreprise par exemple, un presse-papier, etc) et leur donner les informations dont elles ont besoin (principalement la position et les dimensions des fenêtres, en fait, probablement aussi le temps sans que la fenêtre ait été actualisée, le focus, et 2-3 bricoles?).
Le «seul problème» ici, bien sûr, c'est qu'il est nécessaire de construire un protocole entre wayland-serverd et window-manager, ainsi, forcément, qu'entre le wm et le wd.
Avoir ces protocoles séparés ne me choque pas plus que ça, puisque ça permets notamment que, le jour ou wayland sera moisi parce qu'on aura de nouveaux usages, on pourra peut-être ne changer que le coeur, le reste fonctionnerait potentiellement encore, chose qui ne semble pas vraie sous X11.
Le fait est par contre que les bibliothèques (gtk et qt) ont choisi d'embarquer la décoration côté client: c'est plus simple pour aller vite, je dirais.
[^] # Re: Décorations de fenêtres côté client, une régression
Posté par freem . En réponse à la dépêche Xfce 4.16 : La souris fait la fête !. Évalué à 9.
Le fait qu'ils ne s'occupent pas des décorations de fenêtre ne me choque pas, en soit.
Du peu que je connais, rien ne semble empêcher l'implémentation du paradigme:
Par flemme, tout le monde construit la logique de la gestion des fenêtre dans le serveur graphique, mais je ne vois rien qui empêche de split la chose. En fait, ça serait probablement, la meilleure chose à faire: moins de code dans l'une des parties les plus critiques, qui pourrais (devrais?) ne faire que gérer le respawn de certains services critiques (s'ils existent: le wm, un VNC en entreprise par exemple, un presse-papier, etc) et leur donner les informations dont elles ont besoin (principalement la position et les dimensions des fenêtres, en fait, probablement aussi le temps sans que la fenêtre ait été actualisée, le focus, et 2-3 bricoles?).
Le «seul problème» ici, bien sûr, c'est qu'il est nécessaire de construire un protocole entre
wayland-serverdetwindow-manager, ainsi, forcément, qu'entre le wm et le wd.Avoir ces protocoles séparés ne me choque pas plus que ça, puisque ça permets notamment que, le jour ou wayland sera moisi parce qu'on aura de nouveaux usages, on pourra peut-être ne changer que le coeur, le reste fonctionnerait potentiellement encore, chose qui ne semble pas vraie sous X11.
Le fait est par contre que les bibliothèques (gtk et qt) ont choisi d'embarquer la décoration côté client: c'est plus simple pour aller vite, je dirais.