Sur le blog de Martin Gräßlin (qui contient un lien vers sa présentation de KDE sur Wayland au Desktop Summit), on apprend que KDE conservera l'actuel système de "server side décoration"(*), même sur Wayland, au lieu d'utiliser le (probable) comportement de Wayland par défaut(**) où les applications dessinent elles-mêmes le bord de leur fenêtre.
Donc à priori, on devrait éviter les applications figées ainsi que le "Cette application ne répond plus, voulez-vous la fermer?" sur KDE/Wayland(***), ouf!
*: le serveur d'affichage dessine le bord des fenêtres des applications
**: un email de Kristian Høgsberg le développeur principal de Wayland sur le sujet
***: bon les Windowsiens se seraient senti chez eux, mais non merci!
# Décorations côté client
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Je ne comprends pas bien cette histoire de décorations de fenêtres qui devraient être effectuées par les logiciels eux-mêmes. Outre le dégoût profond que cela m'évoque (non, les logiciels complètement disparates comme les horribles lecteurs multimédia ne sont pas un modèle à suivre), est-ce à dire que cela signerait la mort des gestionnaires de fenêtres ?
[^] # Re: Décorations côté client
Posté par Victor . Évalué à 3.
Wayland n'est pas le gestionnaire de fenêtre, donc ici le client c'est kwin, pas les applications elles-même, heureusement !!
[^] # Re: Décorations côté client
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Eh bien alors, qu'est-ce qui change par rapport à X Window ? Le gestionnaire de fenêtres est un client graphique, particulier, qui a entre autres pour rôle de décorer les autres. rien de nouveau sous le soleil, on dirait.
[^] # Re: Décorations côté client
Posté par navaati . Évalué à 3.
Ben justement si : un serveur wayland a le rôle de compositeur et de gestionnaire de fenêtres, et le "kwin compatible wayland" est une implémentation d'un serveur wayland. Et les applications sont les clientes.
[^] # Re: Décorations côté client
Posté par reno . Évalué à 4.
La justification semble être que c'est plus simple à faire et plus efficace (cf l'email de Kristian Høgsberg), mais à mon avis, ça ne réduit pas la complexité globale, ça la déplace juste vers le client et puis ça pose des problèmes de fiabilité et de sécurité:
si une application affiche une fenêtre transparente sur tout l'écran, elle peut tout espionner??
En tout cas, ça diminuerait de beaucoup leur fonctionnalités mais il resterait des fonctionnalités il me semble: le verrouillage d'écran, le "force quit" a ajouter..
[^] # Il y a bien longtemps...
Posté par Arthur Accroc . Évalué à 10. Dernière modification le 12 août 2011 à 09:04.
Il y a bien longtemps (même bien avant BeOS), sur Amiga, le serveur graphique gérait les fenêtres, tous les widgets courants (boutons, barres de défilement, menus...) et l’affichage, le tout avec une priorité supérieure absolue par rapport aux applications.
Résultat :
Malgré des machines bien plus puissantes, il arrive à l’heure actuelle de ne pas avoir la même réactivité (le clou, c’est quand un navigateur part en sucette et bouffe un max de swap, et que le serveur X rate des touches du clavier pendant qu’on essaie de taper la commande pour killer le navigateur), les applications sont alourdies par différents toolkits et doivent gérer elles-mêmes plusieurs threads si elles veulent garantir une bonne réactivité, et leurs interfaces ne sont pas toujours très cohérentes entre elles.
À mon avis, c’est plus négatif pour l’« expérience utilisateur » qu’une petite différence en performances pures.
Wayland aurait pu être une bonne occasion d’avancer dans la bonne direction.
Malheureusement, il semble bien que ce sera le contraire.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Il y a bien longtemps...
Posté par ndv . Évalué à 1.
En même temps, à l'époque, tu n'avais pas de navigateur web proposant des webapps et du flash... Avec des besoins plus simples, tout est plus simple.
Quand aux différents toolkits, tu n'es pas obligé de les utiliser. Soit tu as le beurre (le choix entre d'avoir Amarok sous GNOME) soit tu as l'argent du beurre (que des applis KDE sous KDE), pas les deux.
Comme quoi, il faut se méfier des moulins qui étaient mieux avant...
[^] # Re: Il y a bien longtemps...
Posté par reno . Évalué à 7.
Tu ne peux pas comparer Amiga aux OS modernes: Amiga n'avait pas la protection mémoire, ça change énormément de choses..
BeOS était très réactif et moderne, mais je ne sais pas exactement le découpage qu'il y avait entre les applications et le serveur d'affichage, je sais par contre que chaque application avait une thread séparée pour l'affichage..
Il y a eu plusieurs serveur d'affichage "lourds": NeWS, Berlin/Fresco (n'est pas aller très loin) mais a l'heure actuelle ce n'est pas la tendance effectivement..
[^] # Re: Il y a bien longtemps...
Posté par nud . Évalué à 2.
Tu peux aussi avoir plusieurs threads: un pour la GUI et d'autres pour le reste. Tu peux même avoir plusieurs process pour être sûr, mais c'est peut-être plus chiant à gérer.
[^] # Re: Il y a bien longtemps...
Posté par dave . Évalué à 1.
En général, c'est comme ça que les GUI sont faites : un thread séparé du reste de l'application pour l'interface graphique. Les commandes de la gui sont envoyées de manière asynchrone au moteur de l'application, qui les gère une par une dans une file d'attente.
Ça a peut être changé maintenant ?
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: Il y a bien longtemps...
Posté par drakmaniso . Évalué à 3.
BeOS avait un fonctionnement similaire: un serveur était chargé de toute la partie GUI. Avec le même avantage: une interface qui reste toujours réactive, quelque soit les bugs ou la charge. Le tout sur un système très proche de nos OS modernes, donc l'argument "tout est plus simple quand on a moins de besoin" ne tient pas pour le cas présent.
En revanche, il y a plusieurs points négatifs à ce type d'approche:
Il est plus difficile (pour l'utilisateur) de distinguer entre une appli qui rame, qui est bloquée ou complètement plantée: dans tous les cas boutons et les menus continuent de réagir. Difficile de savoir s'il faut attendre, recliquer sur le bouton, ou fermer et relancer…
Cela demande beaucoup d'échanges de messages haut-niveau entre l'appli et le serveur GUI; du coup même si la réactivité apparente est meilleure, la charge système est plus importante. Suivant l'équilibre obtenu et les besoins de l'utilisateur, cela peut-être une bonne chose, ou non.
Dès que l'on a besoin de widgets customs, les choses se compliquent.
[^] # Re: Il y a bien longtemps...
Posté par Arthur Accroc . Évalué à 2.
On cliquait une fois sur le bouton, il s’enfonçait, et on savait que le serveur graphique avait ajouté l’évènement dans la liste d’évènements de l’application.
Après, si elle ne le traitait pas, c’est qu’elle déconnait.
Ce ne sont pas forcément des messages plus gros que des messages de bas niveau et en quantité, c’est négligeable par rapport à la quantité de messages de bas niveau de X11, par exemple.
Tu as juste un message du style le bouton « OK » a été cliqué ou la barre de défilement est à telle position. Le serveur s’occupe en local d’afficher l’image bouton enfoncé et de réafficher l’image normale lorsqu’on relâche le bouton de la souris.
Avec X11, tu as un message le pointeur est entré dans le bouton (sa « fenêtre » au sens X11, c’est à dire le rectangle qu’il occupe), une floppée d’évènements pour indiquer ses changements de position (bon, ça fait très longtemps que je n’ai pas touché à X11, il me semble qu’heureusement l’application n’est peut-être pas obligée d’écouter les évènements sans intérêt pour elle), un évènement pour indiquer que le bouton gauche a été enfoncé ; à ce stade-là, l’application doit répondre par les commandes permettant d’afficher le bouton enfoncé ; ensuite, elle recevra un évènement bouton relâché et devra faire de même pour réafficher le bouton en position normale...
Au final, ça fait une très grosse quantité de messages (jette un coup d’œil avec xev si tu veux). Ceux qui ont essayé de faire passer du X11 sur une liaison modem 56k ont pu s’en rendre compte...
L’intérêt de X11, c’est la souplesse : tes applications peuvent ressembler à tout ce que tu veux, avoir une ergonomie aussi originale que tu veux et ton gestionnaire de fenêtre peut être aussi absolument comme tu le veux, sans que tu aies à modifier le serveur X lui-même.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Il y a bien longtemps...
Posté par drakmaniso . Évalué à 2.
Il me semble qu'aujourd'hui GTK et Qt court-circuitent une très grande partie de l'architecture classique de X11. Il n'y a plus une fenêtre pour chaque widget, mais une seule pour la totalité de l'appli, le dispatching est fait par le toolkit. La situation était très différente à l'époque de Motif et autre Athena Widgets, mais aujourd'hui la plus grande partie du travail se fait à l'intérieur même de la bibliothèque; donc, au sein du même processus que l'application.
Après, je ne sais pas quel est le surcoût exact des communications inter-processus. Ça n'est certainement pas énorme, mais sans doute pas négligeable non plus.
Pour ce qui est des applis plantées, je me souviens clairement de mon temps sous BeOS que c'était une source de frustration. Mais c'est peut-être une histoire de goûts. Et il est certain qu'une interface qui rame est aussi une source de (parfois grande) frustration.
Honnêtement, je ne sais pas quelle est la meilleure solution; je voulais juste souligner qu'un serveur GUI n'a pas que des avantages.
[^] # Re: Il y a bien longtemps...
Posté par houra . Évalué à 3.
Ah mon avis, c'est un faux problème.
La fenêtre représente la frontière entre le logiciel et le bureau.
Le problème est plutôt de savoir si le bureau est un objet simple lancé par un autre logiciel ( cas protocole X ), ou si c'est l'élément de dialogue avec l'OS ( tous les autres cas ).
Si le bureau n'est qu'un élément , que celui ci dessine la fenêtre ou que ce soit l'appli qui la dessine n'entraîne que des conséquences simples sur les signaux envoyés au reste de l'OS.
Si le bureau est ou fait partie de l'élément qui dialogue avec l'OS, l'affichage des fenêtres par le bureau entraîne une possibilité supplémentaire: cet affichage contraindra l'application à mourir si on tue le bureau. Ce qui n'est pas le fonctionnement normal d'Explorer.exe .
Si on tue Explorer ( testé sous Windows 2000 , XP, Vista et Sept ) , l'application ne meurt pas. Si on tue Xorg, ou les éléments de gnome ou de KDE ... l'application meurt.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Décorations côté client
Posté par nud . Évalué à 4.
Tu peux déjà faire une fenêtre transparente qui couvre tout l'écran avec X11, et tu peux observer pas mal de choses même sans avoir de fenêtre...
[^] # Re: Décorations côté client
Posté par reno . Évalué à 1.
Oui, enfin si tu as un gestionnaire de fenetre qui se préoccupe de la sécurité, il pourrai lui mettre une bordure ce qui ne sera pas très discret, non?
[^] # Re: Décorations côté client
Posté par zebra3 . Évalué à 2.
Pas sûr, tu peux par exemple avec MPlayer mettre une vidéo en fond d'écran avec la commande -rootwin.
D'après la page de man, il semble que la « root window » est une fenêtre particulière qui n'a pas de bordure, et il y en a peut-être d'autres.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Décorations côté client
Posté par needs . Évalué à 1.
La root window est la première "fenêtre" lancé par X, c'est celle qui contiendra toutes les autres. par exemple, le programme 'nitrogen' ce sert de cette root window pour afficher un fond d'écran, enfin plus précisément, il met l'image voulut en pixmap dans la root-window. Lorsque je dit fenêtre, c'est fenêtre dans le sens du serveur X, pour simplifier c'est un cadre personnalisable dans lequel on peut mettre d'autres cadres, un peu comme les Widget de Gtk.
[^] # Re: Décorations côté client
Posté par Michaël (site web personnel) . Évalué à 4.
X11 n'a aucune nuance de sécurité: ou bien l'accès au serveur est interdit ou bien il est total, c'est à dire que n'importe quelle application peut zieuter ses petites voisines, ce que fait le programme
xwatchwin(1).Si on utilise un logiciel auquel on ne fait pas confiance (genre Skype), le mieux est de créer un compte dédié à son utilisation, de le jailer et de l'exécuter dans un serveur Xnest: une bonne solution va beaucoup plus loin que la simple sécurité de l'interaction avec l'utilisateur.
Peut être que le focus grabbing permet d'avoir une petite conversation privée avec l'utilisateur, mais son utilisation n'est pas encouragée.
# Ça existe déjà.
Posté par claudex . Évalué à 8.
J'ai régulièrement ce message quand une application a freezé et que j'essaye de la fermer sur KDE/X11.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ça existe déjà.
Posté par yellowiscool . Évalué à 1.
Pareil avec Unity. Et je ne vois pas le problème.
Envoyé depuis mon lapin.
[^] # Re: Ça existe déjà.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Le problème, c'est que si les décorations, notamment la barre de titre et son bouton « fermer » étaient produits par le logiciel qui a planté et non par Unity, KWin ou Metacity, tu pourrait toujours cliquer : planté, il n'irait pas non plus se fermer spontanément.
[^] # Re: Ça existe déjà.
Posté par yellowiscool . Évalué à 2.
Je parlais de la présence du message avertissant que l'application est bloquée.
Envoyé depuis mon lapin.
[^] # Re: Ça existe déjà.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1.
Et il est censé s'afficher quand ? Avec Metacity par exemple, c'est lorsque tu demandes à fermer une fenêtre, et que le logiciel qui en est responsable n'obéit pas, que Metacity te propose de le tuer.
[^] # Re: Ça existe déjà.
Posté par Thomas Douillard . Évalué à 3.
En même temps il doit y avoir d'autres solutions à ce problème, genre "pinger" régulièrement l'appli. Plus sur mais il me semble que sous OSX par exemple, voire sous linux avec compiz les fenêtres se grisent quand l'appli répond pas. Et je ne pense pas qu'il y ait besoin d'interraction utilisateur pour faire ça. Dans ce cas il suffirait de proposer de tuer l'appli au lieux de simplement la griser.
Quitte à refaire un nouveau système graphique autant penser ce genre de chose à la conception.
[^] # Re: Ça existe déjà.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Horrible. Comment proposer une solution inférieure à l'existant…
[^] # Re: Ça existe déjà.
Posté par Thomas Douillard . Évalué à 2.
Les applis graphiques ont toutes une boucle pour gérer les évènements, il suffit d'intégrer ce traitement dans la boucle. Et ça permet de prévenir l'utilisateur qu'une appli a plantée, je vois pas ce qu'il y a d'horrible.
[^] # Re: Ça existe déjà.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -2.
Elles ont une boucle, oui, mais aucune raison de causer au serveur graphique à chaque passage, si ?
[^] # Re: Ça existe déjà.
Posté par monde_de_merde . Évalué à 4.
Bah dans la mesure où la boucle gère les événements et provoque le dessin des zones ayant changées depuis la dernière fois elle cause au serveur graphique plusieurs fois par passage (quand elle est active) : pour demande s'il y a eu des événements d'entrées, pour lui demander de redessiner des trucs.
[^] # Re: Ça existe déjà.
Posté par Thomas Douillard . Évalué à 2.
et quand elle est dans un état inactif pour cause d'attente d'événement neuf il y a plus forcément de raison de la "poller" pour voir si elle est active, si le serveur a connaissance de cet état.
[^] # Re: Ça existe déjà.
Posté par barmic . Évalué à 3.
Je présume (j'espère) que cette boucle n'est pas du polling mais une attente d'évènement envoyé par le serveur graphique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ça existe déjà.
Posté par Thomas Douillard . Évalué à 2.
la boucle non bien sur, mais le serveur graphique qui envoie son message pour savoir si l'appli est vivante ressemble plus à du polling ... "t'es vivante ?"->oui ... "t'es vivante ?"->oui ... "t'es vivante ?" -> oui. Il faut se débrouiller pour pas poller en permanence.
Je vois pas spécialement comment tu peux faire du pur réactif événementiel, sauf à avoir une action de l'utilisateur comme actuellementt.
[^] # Re: Ça existe déjà.
Posté par Thomas Douillard . Évalué à 2.
Ce serait jute un événement parmi d'autres que le serveur envoie, avec les I/O et autres, rien de très différent et qui ahma s'intègrerait très naturellement et presque gratuitement. Si c'est pas totalement gratuitement par rapport à l'existant, faudrait voir comment ça marche aujourd'hui dans le détail.
[^] # Re: Ça existe déjà.
Posté par dinomasque . Évalué à 2.
Dans un certain OS qui faisait des tas de choses il y a 15 ans chaque application avait au moins 2 threads : 1 pour l'application elle-même et 1 pour son affichage.
BeOS le faisait il y a 20 ans !
[^] # Re: Ça existe déjà.
Posté par barmic . Évalué à 2.
C'est encore le cas normalement, même s'il est encapsulé par la bibliothèque graphique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ça existe déjà.
Posté par hervé Couvelard . Évalué à 3.
euh... je suis peut être à coté mais ce n'est pas idiot de demander à l'application de se surveiller pour savoir si elle plante ? Parce que si elle est planté, c'est pas qu'elle est planté et donc ne peut pas "parler" à l'utilisateur ?
[^] # Re: Ça existe déjà.
Posté par BAud (site web personnel) . Évalué à -1.
hint: threads :)
[^] # Re: Ça existe déjà.
Posté par Michaël (site web personnel) . Évalué à 6.
Et comment il fait ton thread pas planté pour savoir que l'autre thread de l'application est planté?
De plus ajouter un thread à toutes les applications graphiques n'est quand-même pas tout à fait gratuit au niveau des ressources systèmes!
[^] # Re: Ça existe déjà.
Posté par Thomas Douillard . Évalué à 2.
La boucle serait juste pour donner l'occasion à l'appli de répondre au "ping". L'envoyeur n'est évidemment pas l'appli elle même. C'est wayland lui même qui poserait la question dans mon hypothèse.
[^] # Re: Ça existe déjà.
Posté par reno . Évalué à 8.
Oui, mais si tu veux attendre car tu pense que l'application est juste figée temporairement, tu peux iconifier la fenetre et attendre, avec la décoration coté client, tu as juste une fenêtre figée au milieu de ton écran et puis c'est tout..
# Autres informations sur son blog
Posté par Altor . Évalué à 3. Dernière modification le 12 août 2011 à 00:56.
Soit avec une mauvaise traduction : "Le développement du bureau n'est pas du tout influencé par le frameworks 5 (de Qt NDT). Cela signifie que nous continuerons à sortir les versions 4.x de kde."
Nous basculerons (vers wayland NDT) quand nous serons sûr de ne pas casser le bureau des utilisateurs.
Ceci est une très bonne nouvelle.
[^] # Re: Autres informations sur son blog
Posté par fearan . Évalué à 6.
Ça va nous changer :)
pastaper c'est presque vendredi
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# étoiles, renvoi et lisibilité
Posté par Adrien . Évalué à 9.
Franchement à par emmerder les lecteurs, à quoi servent les petites étoiles de renvoi ??
On peut très bien les mettre dans le texte, c'est quand même vachement plus lisible. Et si tu veux te la péter, tu pourrais mettre des ¹²³ ou autres truc un peu plus évolués.
Voila, c'était mon coup de gueule contre les renvois, on en voit de plus en plus sur linuxfr et perso je trouve ça vraiment illisible !
[^] # Re: étoiles, renvoi et lisibilité
Posté par claudex . Évalué à 8.
Quand le journal est court, comme ici, ça ne me dérange pas, ça permet même de renforcer le message en évitant de diluer le message dans des explications.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # La critique est facile, l'art est difficile
Posté par reno . Évalué à 5.
Dans la première version il n'y avait pas les renvois, résultat c'était lourd à lire.
Alors après j'aurais pu faire plus concis mais si tu ne sais pas ce qu'est "server side décoration", où qui est Kristian Høgsberg, tu perds des infos..
Bref c'est facile de critiquer mais pas si facile de rédiger.
[^] # Re: La critique est facile, l'art est difficile
Posté par Adrien . Évalué à 0.
Par exemple pour la première étoile, on aurait pu écrire par exemple :
On apprend que KDE conservera l'actuel système de « server side décoration » – le serveur d'affichage dessine le bord des fenêtres des applications – même sur Wayland…
la deuxième étoile aurait pu être remplacé en mettant directement un lien vers l'email en question, comme pour le lien sur « Martin Gräßlin »
La dernière étoile n'apporte rien :-)
[^] # Re: La critique est facile, l'art est difficile
Posté par claudex . Évalué à 2.
Cette forme est beaucoup plus pénible à lire quand on connaît le sujet, je préfère la version avec le renvoi. Surtout qu'il ne faut pas défiler beaucoup (voire, pas du tout) pour y accéder.
Si, ça apporte un point de vue de l'auteur sur un comportement auquel il a déjà été confronté mais qu'il n'apprécie pas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: La critique est facile, l'art est difficile
Posté par Adrien . Évalué à 4.
« Cette forme est beaucoup plus pénible à lire quand on connaît le sujet, je préfère la version avec le renvoi. Surtout qu'il ne faut pas défiler beaucoup (voire, pas du tout) pour y accéder. »
Autant quand le texte à lire est très long je trouve les renvoi tout à fait justifier pour ne pas surcharger. Mais là l'article fait cinq lignes !!
Avec les étoiles, tu est obligé de lire l'article en commençant par le haut, puis en bas pour la première étoile, puis en haut, puis en bas, puis haut et enfin en bas… Pour un texte aussi court je trouve ça vraiment gênant, la lecture n'est pas du tout fluide et naturelle.
En plus la plupart du temps sur linuxfr les articles sont pour ceux qui ne s'intéressent pas particulièrement au sujet, donc autant détailler un peu, ça ne nuit pas, surtout que là on parle de rajouter… une ou deux lignes. De toute façon les connaisseurs ont souvent déjà eu connaissance des nouvelles avant (blogs, listes de diffusion du projet, etc.)
Regarde les articles de patrick_g sont long, très détaillés et sans une étoile par ligne comme ici et pourtant ils sont très fameux !
[^] # Re: La critique est facile, l'art est difficile
Posté par reno . Évalué à 3.
Pour la première étoile, je l'avais mis entre parenthèses au début, mais je l'ai déplacé pour la raison indiqué par Xavier Claude.
Pour la deuxième étoile, j'aurais pu mettre un lien oui, sauf que si tu ne sais pas que Kristian Høgsberg est le développeur principal de Wayland, tu te demande pourquoi son avis a de l'importance.
Pour la dernière étoile, c'est mon avis, j'aurais pu le mettre sous une forme différente, mais ayant des applications freezées sous Windows et Linux, je persiste: avec une décoration faite par le serveur d'affichage/gestionnaire de fenêtre, c'est moins pénible.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.