Journal Cairo Dock pour Wayland

Posté par  . Licence CC By‑SA.
Étiquettes :
27
22
juin
2014

Fabrice Rey (alias Fabounet) vient de commencer le portage de X vers Wayland du logiciel Cairo Dock. Pour ceux qui ne connaissent pas ce logiciel, Cairo Dock permet par exemple d'imiter le dock de MacOS X.

Cairo dock avec Wayland

Il est intéressant de voir les impressions du développeur de cette adaptation. En voici un bref résumé :

Positif

Le dock et tout le bureau est plutôt fluide avec les pilotes libres. Mais Weston reste un jouet : cela n'est pas possible pour l'utilisateur final de travailler tous les jours avec Weston. Wayland est attrayant pour le développeur car le mécanisme de message serveur-client X a été remplacé par une collection d'objets proxy (avec une facilité pour étendre le protocole).

Négatif

Il manque beaucoup de fonctionnalité pour les applications client :

  • Le placement des fenêtres est impossible du côté client ;
  • Pas moyen d'accéder à la liste des fenêtre ouverte. Pas de possibilité de créer une barre de tâche ;
  • De même pas de possibilités de changer la résolution, ni ajout ou suppression dynamique de bureau possible pour le client ;
  • Pas de raccourcis clavier global possible.

Seul le compositeur peut faire ce travail.

Wayland architecture

Conclusion

Nous avons besoin de remplacer X (car il ne convient pas pour les smartphones, les voitures, …). Mais Wayland manque encore trop de fonctionnalités pour les ordinateurs de bureau.
La source

  • # Manque de comparaison

    Posté par  . Évalué à 6.

    C'est dommage qu'il n'ai testé qu'avec Weston alors qu'il me semble que les compositeurs d'Enlightment, de Gnome et de KDE sont plus ou moins fonctionnels. Après, je comprends tout à fait qu'il n'ait pas envie de passer son temps à tenter de les compiler et de les faire fonctionner.

    « 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: Manque de comparaison

      Posté par  (site web personnel) . Évalué à 3.

      En effet si plusieurs wm ont été portés sur wayland, c'est bien qu'ils gèrent une liste des fenêtres? qui du coup ne serait plus disponible directement côté serveur d'affichage, mais qui ne serait matérialisée qu'au niveau du compositeur? ou suis-je à l'ouest

      • [^] # Re: Manque de comparaison

        Posté par  . Évalué à 4.

        qui du coup ne serait plus disponible directement côté serveur d'affichage, mais qui ne serait matérialisée qu'au niveau du compositeur

        Il n'y a pas de distinction entre le serveur d'affichage et le compositeur sous Wayland. Par contre, il est possible que cette information soit disponible dans certains compositeur mais qu'il n'y ait pas encore d'interface standard pour cela (peut-être parce qu'il n'y a pas eu de réflexion concluante sur la sécurité, peut-être que tout le monde s'en fout).

        « 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: Manque de comparaison

          Posté par  (site web personnel) . Évalué à 8.

          En fait, la sécurité est prise au sérieux dans Wayland (contrairement à X), c'est aussi pour ça que le protocole est si fermé (par exemple un client ne peut pas agir sur une autre fenêtre que la sienne).
          L'inconvénient c'est que du coup c'est très restrictif et peu pratique à utiliser (du moins pour les développeurs tiers).
          Ce qui est possible c'est que les principaux desktops commencent à ajouter leurs propres interfaces pour leurs propres besoins, puis qu'ils se mettent d'accord pour les standardiser, un peu comme avec EWMH pour X. Le problème c'est que ça risque de prendre beaucoup de temps, ce serait mieux que Wayland fournisse directement les bonnes interfaces.

      • [^] # Re: Manque de comparaison

        Posté par  . Évalué à 2.

        Il n'y a pas de WM porte sur Wayland. Weston, l'implementation de reference de Wayland, est tres modulaire, mais la politique de placement de fenetre est interne au Composite Manager. C'est le cas pour toutes les implementations que je connais de compositeur qui support Wayland. Et je ne connais pas de WM seul ayant ete porte sous Weston.

    • [^] # Re: Manque de comparaison

      Posté par  (site web personnel) . Évalué à 10.

      Weston étant le compositeur de référence, c'est celui qui est le plus à jour par rapport au protocole (en plus, il est assez rapide à compiler).

      Normalement, tous les compositeurs implémentant Wayland sont (ou seront) équivalents, c'est transparent pour l'application cliente.
      Pour l'instant, il manque énormément de choses pour avoir l'équivalent de X au niveau du bureau.
      L'affichage des fenêtres, ce n'est pas tout; il y'a beaucoup d'interfaces manquantes (genre comment une appli signale qu'elle a fini de démarrer, comment une appli peut placer ses fenêtres, comment une appli peut recevoir un signal sur pression d'un raccourci clavier même si elle n'a pas le focus, et je pourrais remplir une page entière comme ça).

      Le compositeur peut faire tout ça (puisqu'il a toutes les infos en interne), mais si c'est pour avoir un bureau monolithique avec aucune application tierce, autant rester avec X.
      Le pire serait que chaque compositeur décide d'ajouter ses propres interfaces, et que les applis tierces ne soient pas portables d'un environnement à un autre.
      On a déjà Mir, pas besoin de fragmenter Wayland en prime :-)

      • [^] # Re: Manque de comparaison

        Posté par  . Évalué à 5.

        Normalement, tous les compositeurs implémentant Wayland sont (ou seront) équivalents, c'est transparent pour l'application cliente.

        Ouh la attention! Les compositeurs seront équivalent pour l'affichage des fenêtres mais par exemple Weston a une sortie RDP et il n'est pas du tout garanti que les autres compositeurs l'auront..

        Pour le reste, les interfaces privilégiées dont tu parles, devraient être dans xdg-shell qui est en cours de développement.

        • [^] # Re: Manque de comparaison

          Posté par  (site web personnel) . Évalué à 2.

          Weston n'est qu'une preuve de concept, son but est d'exposer des API qui une fois validées iront dans Wayland, donc à priori une application ne devrait pas utiliser ces interfaces (à terme). A la limite, Weston disparaîtra probablement une fois que les autres gestionnaires de fenêtres auront implémenté wayland (ou restera en tant que référence pour de la validation).

          xdg-shell malheureusement ne concerne que la gestion de la fenêtre du client, pas la gestion du bureau (récupérer la liste des fenêtres, changer la résolution, enregistrer un raccourci global, etc). Là ce serait plutôt desktop-shell, et il est très incomplet à l'heure actuelle. Donc pour l'instant, on a un bureau très monolithique avec un compositeur qui fait tout et aucune application tierce possible. Évidemment j'espère que cela va évoluer rapidement.

          Note que pour xdg-shell, par design il est impossible de placer sa fenêtre où l'on veut, avec les problèmes mentionnés dans l'article originel.

      • [^] # Re: Manque de comparaison

        Posté par  . Évalué à 4.

        Normalement, tous les compositeurs implémentant Wayland sont (ou seront) équivalents, c'est transparent pour l'application cliente.

        Je suis d'accord qu'ils offriront les mêmes interfaces que Weston mais il me semble qu'au moins Kwin et le compositeur de Gnome ont annoncé qu'ils implémenteront des interfaces spécifiques à leur bureau.

        « 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: Manque de comparaison

          Posté par  (site web personnel) . Évalué à 7.

          il me semble qu'au moins Kwin et le compositeur de Gnome ont annoncé qu'ils implémenteront des interfaces spécifiques à leur bureau

          Et c'est un sérieux problème de fragmentation en perspective ! J'espère vraiment qu'ils parviendront à standardiser leurs besoins (comme avec EWMH pour X) sinon on peut dire adieu à "l'année du bureau Linux" ^_^;

          • [^] # Re: Manque de comparaison

            Posté par  . Évalué à 5.

            Pour l'instant tous les bureaux qui sont entrain d'implementer Wayland sont parti sur des approches techniques apriori legerement differente autant que je sache.

            • kwin/kde: au dessus de Weston (en tant que compositeur system), mais en forcant les applications a ne pas rendre leur bordure de fenetre.
            • mutter/gnome: implementation sans compositeur system de leur propre compositeur et en laissant au toolkit la gestion des bordures de fenetre.
            • enlightenment: implementation decorele entre le backend de rendu et le support du protocol Wayland, les bordures de fenetres sont laisse aux toolkits.

            Il y aussi une autre difference probable, Enlightenment fonctionne principalement a l'aide de module et non d'executable externe, ce qui change aussi certaine chose au final. Dans l'ensemble, je ne pense pas que honnetement on puisse dire qu'il y a une meilleur piste qu'une autre a suivre aujourd'hui. Il va forcement y avoir une periode de recherche qui va donner de nombreuses variation et difference, puis les choses se stabiliseront. Clairement Wayland sur le desktop, ca va prendre un peu de temps…

            En meme temps, X n'est pas mort et continue d'evoluer aussi (meme si il y a des problemes qu'il ne pourra jamais resoudre). Et puis si vous voulez voir votre desktop plus vite vers Wayland, suffit de contribuer ;-)

            • [^] # Re: Manque de comparaison

              Posté par  (site web personnel) . Évalué à 7.

              Dans l'ensemble, je ne pense pas que honnetement on puisse dire qu'il y a une meilleur piste qu'une autre a suivre aujourd'hui.

              Pour éviter les logiciels "vilain petit canard", l'approche de kwin me semble la meilleure!

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

              • [^] # Re: Manque de comparaison

                Posté par  . Évalué à 3.

                Elle a un impact direct sur la consomation memoire et les performances de rendu, donc probablement sur la batterie.

                • [^] # Re: Manque de comparaison

                  Posté par  (site web personnel) . Évalué à 9.

                  Je ne comprends pas trop pourquoi, mais même si c'est le cas, j'ai l'impression que c'est une très mauvaise idée de laisser les applications dessiner leurs décorations: je préfère avoir une ui uniforme et qui n'est pas bloqué parce qu'une application implémente mal ce qui revient au window manager..

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                  • [^] # Re: Manque de comparaison

                    Posté par  . Évalué à 4.

                    Bof en même temps si l'intérieur des fenêtres est déjà complètement incohérent, c'est pas la bordure qui changera grand chose. Ceux qui tiennent vraiment à la cohérence priviliégient déja les applis de leur environnement de bureau/toolkits.

                    Du coup la décoration des fenêtre c'est juste un problème marginal pas différent : si on trouve des solutions pour rendre les toolkits et les interfaces à peu prêt cohérent à ce niveau, c'est pas prendre en compte les bordures qui fait une énorme différence.

                    J'ai un peu l'impression qu'en l'occurence on s'amuse juste à trouver positive une contrainte sans aller jusqu'au bout : quitte à laisser la question des bordures au gestionnaire d'affichage/compositeur, pourquoi ne pas laisser le compositeur gérer carrément tout le toolkit ?

                    C'est une position un peu trollesque, c'est juste pour dire qu'on est sans doute influencé par l'historique de X et de sa gestion historique, et qu'on regarde pas forcément objectivement le problème du coup.

                    • [^] # Re: Manque de comparaison

                      Posté par  . Évalué à 5. Dernière modification le 24 juin 2014 à 13:46.

                      En jouant sur les différents thèmes, on arrive souvent à accorder les différents toolkits graphiques (certains, comme Qt, y mettent vraiment du leur et peuvent utiliser les thèmes d’autres toolkits, d’autres nécessitent un peu de bricolage jusqu’au .Xresources). Mais à la limite la couleur des dégradés et de la sélection du texte on s’en fout pas mal. Le vrai problème des décorations côté client c’est la perte en fonctionnalités : quid des gestionnaires de fenêtres pavant ? des onglets ?

                      Si Kwin suit la voie des décorations côté gestionnaire de fenêtre, c’est parce-que c’est le seul généraliste à implémenter des fonctions avancées. À l’inverse, les programmes Gnome actuels sont dégueulasses dans Fluxbox, ils dessinent eux-mêmes leur transparence et leur ombre, sans se soucier des réglages du compositeur.

                      • [^] # Re: Manque de comparaison

                        Posté par  . Évalué à 2.

                        des onglets ?

                        Tu trouve qu'aujourd'hui c'est comment entre chrome, firefox et konqueror par exemple ?

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: Manque de comparaison

                          Posté par  . Évalué à 3.

                          Je pense qu'il parle de fenetres en onglets, comme BeOS.
                          Sinon, franchement, les messages "cette application ne repond pas, voulez vous …" je connais sous Windows, je ne suis pas impatient de retrouver l'equivalent sous Linux, tout ca pour avoir des fenetres jolies quand on les déplace/déforme..

                          • [^] # Re: Manque de comparaison

                            Posté par  . Évalué à 2.

                            Euh, on a déjà ça sous linux

                          • [^] # Re: Manque de comparaison

                            Posté par  . Évalué à 3.

                            Je l'ai déjà avec Kwin quand je veux fermer une fenêtre récalcitrante.

                            « 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: Manque de comparaison

                              Posté par  . Évalué à 2.

                              Avec Windows, c'est aussi quand tu iconifie une fenêtre.
                              Pour la fermeture d'une application, là c'est différent et indépendant du gestionnaire de fenêtres:quand tu force la fermeture d'une application, tu risque de perdre des données..

                              • [^] # Re: Manque de comparaison

                                Posté par  . Évalué à 3.

                                Il ne me semble pas que le compositeur ait besoin de la coopération de la fenêtre pour cacher son affichage. Donc, je dirais que tant que tu ne change pas le contenu (en redimensionnant par exemple), ça ne devrait pas afficher ce genre de message.

                                « 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: Manque de comparaison

                                  Posté par  . Évalué à 2.

                                  Avec Windows, c'est aussi quand tu iconifie une fenêtre.
                                  Pour la fermeture d'une application, là c'est différent et indépendant du gestionnaire de fenêtres:quand tu force la fermeture d'une application, tu risque de perdre des données..

                                  • [^] # Re: Manque de comparaison

                                    Posté par  . Évalué à 3.

                                    Il ne me semble pas que le compositeur ait besoin de la coopération de la fenêtre pour cacher son affichage. Donc, je dirais que tant que tu ne change pas le contenu (en redimensionnant par exemple), ça ne devrait pas afficher ce genre de message.

                                    « 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: Manque de comparaison

                                      Posté par  . Évalué à 2.

                                      Desole pour le doublon.
                                      Ce que je voulais dire: si la decoration de la fenetre est geree cote client, est ce que le compositeur sait qu'un clic a un endroit correspond a une iconification?

                                      • [^] # Re: Manque de comparaison

                                        Posté par  . Évalué à 3.

                                        Il y a d'autre moyen que de cliquer sur le bouton de la fenêtre, par exemple en cliquant sur sa position dans la barre des tâches.

                                        Mais pour ta question, je n'en ai aucune idée.

                                        « 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: Manque de comparaison

                          Posté par  . Évalué à 2.

                          Tu trouve qu'aujourd'hui c'est comment entre chrome, firefox et konqueror par exemple ?

                          Raison de plus pour remettre les onglets côté gestionnaire de fenêtre :-) Quoiqu’en fait tes exemples sont particuliers, si ces programmes gèrent les onglets alors que le gestionnaire de fenêtres ne le fait pas c’est parce-qu’ils en ont un usage avancé, et proposent donc autour de ces onglets des ergonomies spécifiques qui restent utiles même avec un gestionnaire de fenêtre qui gère aussi des onglets.

                          Par contre, pour associer la fenêtre de mon gestionnaire de fichiers ouvert dans mon dossier de téléchargements à ma fenêtre de firefox, ou celle d’un terminal avec celle de VI et celle de ma visionneuse PDf quand je rédige en LateX, là il faut que le gestionnaire de fenêtre connaisse les onglets, et qu’il puisse les dessiner. Ce que fait par exemple Fluxbox, mais n’est pas possible à implémenter en l’état avec Wayland et est déjà complètement affreux avec les logiciels Gnome 3.

                    • [^] # Re: Manque de comparaison

                      Posté par  (site web personnel) . Évalué à 3.

                      pourquoi ne pas laisser le compositeur gérer carrément tout le toolkit ?

                      Parce qu'il faudrait se mettre d'accord sur le toolkit.

                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Le bon lien vers l'article

    Posté par  . Évalué à 4.

  • # Le rapport avec la choucroute?

    Posté par  . Évalué à -5.

    Quel est le rapport entre ce dock et les points négatifs soulevés dans le journal?

    • [^] # Re: Le rapport avec la choucroute?

      Posté par  . Évalué à 10.

      Le placement des fenêtres est impossible du côté client ;

      Ça veut dire que le dock ne peut pas se placer automatiquement où il veut. Par exemple, dans le bas de l'écran.

      Pas moyen d'accéder à la liste des fenêtre ouverte. Pas de possibilité de créer une barre de tâche ;

      Ça veut dire que le dock ne peut pas faire une barre des tâches.

      De même pas de possibilités de changer la résolution, ni ajout ou suppression dynamique de bureau possible pour le client ;

      Ça veut dire que le dock ne peut pas contenir de widget pour gérer la résolution, ni les bureaux virtuels.

      Pas de raccourcis clavier global possible.

      Ça veut dire que le dock ne peut pas activer une fonctionnalité quand l'utilisateur fait un raccourci clavier dans une autre application. Par exemple, quand tu fais alt-shift-f1, le dock ouvre un tiroir avec les fichiers récents.

      « 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: Le rapport avec la choucroute?

        Posté par  . Évalué à 3.

        Dans Wayland, il y a une nette separation entre les clients et le serveur d'affichage/gestionnaire de fenetre/compositeur pour des raisons de sécurité et de performance.
        Donc un dock est plutot censé faire partie du serveur, eventuellement par un plugin (Weston le permet).
        Apres j'ai comme un doute que les dev de KDE ou Gnome considèrent comme prioritaire dimplementer des interfaces qui remplacent ce qu'ils font eux même..

        • [^] # Re: Le rapport avec la choucroute?

          Posté par  . Évalué à 9. Dernière modification le 23 juin 2014 à 09:30.

          Apres j'ai comme un doute que les dev de KDE ou Gnome considèrent comme prioritaire dimplementer des interfaces qui remplacent ce qu'ils font eux même..

          Pour KDE, il y a une distinction entre le compositeur, Kwin, et l'équivalent du dock, Plasma. Je pense que cette distinction existe toujours avec Wayland, du coup, ces interfaces devront exister et pourront être utilisées par d'autres. De plus, je ne sais pas si c'est toujours d'actualité mais le développeur de Kwin avait dit lors des premiers tests de Wayland : « Le but est d'avoir un compositeur qui est utilisable tout seul hors de KDE et de pouvoir aussi utiliser un autre compositeur (peut-être dans un mode dégradée si certaines API restent chez KDE) dans une sessions KDE ».

          « 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: Le rapport avec la choucroute?

          Posté par  (site web personnel) . Évalué à 7.

          Donc un dock est plutot censé faire partie du serveur, eventuellement par un plugin (Weston le permet).

          Tu te rends bien compte que ce n'est pas acceptable ("philosophie Unix", portabilité des applications, diversité, tout çaaa).
          On a trouvé une solution avec Dbus (policyKit) pour que des applications puisse invoquer des actions normalement réservées à root (genre tout simplement éteindre l'ordinateur), on doit forcément pouvoir faire un truc similaire avec Wayland.
          Dans tous les cas il faut que tout ça reste modulaire, c'est la base.

      • [^] # Re: Le rapport avec la choucroute?

        Posté par  (site web personnel) . Évalué à 6.

        Il faudra attendre qu'on se mette d'accord et qu'on avance sur comment gérer les clients privilégiés. Ensuite, on pourra avoir toutes les interfaces qu'on veut :)

  • # pas de possibilités de changer la résolution

    Posté par  (site web personnel) . Évalué à 2.

    Comment ça va se passer pour les jeux?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: pas de possibilités de changer la résolution

      Posté par  . Évalué à 4.

      Ils vont attendre une version un peu plus mature de Wayland. Il y a d'abord eu une période où on a tenté de faire un protocole qui peut afficher une application classique avec des images et des menus. Maitenant, on essaye d'y porter des environnements de bureau et d'améliorer le protocole en conséquence. Il faudra sans doute une troisième étape pour des applications plus spécifiques, qui on besoins de fonctionnalités graphiques particulières, comme les jeux.

      « 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: pas de possibilités de changer la résolution

        Posté par  (site web personnel) . Évalué à 2.

        J'ai l'impression que ça navigue à vue…

        Les environnements de bureau et les jeux sont vraiment des cas d'utilisation non pris en compte depuis le début pour un serveur graphique?

        J'espère qu'ils ont aussi pensé à la lecture de vidéo et au multiécran…

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: pas de possibilités de changer la résolution

          Posté par  . Évalué à 3.

          Les environnements de bureau et les jeux sont vraiment des cas d'utilisation non pris en compte depuis le début pour un serveur graphique?

          Ça dépend ce que tu appelle non pris en compte. Si ça veut dire non inclus dans le protocole, c'est effectivement le cas. Si ça veut dire que personne n'y a pensé, c'est faux. C'est juste qu'ils essayent d'avoir suffisamment de réflexion et de retour avant de mettre en place l'idée dans le protocole.

          « 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

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.