Journal Une info sur KDE on Wayland

Posté par . Licence CC by-sa
Tags :
18
11
août
2011

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 (page perso) . É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 . É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 (page perso) . É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 . É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 . Évalué à  4 .

      Je ne comprends pas bien cette histoire de décorations de fenêtres qui devraient être effectuées par les logiciels eux-mêmes.

      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??

      est-ce à dire que cela signerait la mort des gestionnaires de fenêtres ?

      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 . Évalué à  10 . Dernière modification : le 12/08/11 à 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 :

        • l’interface restait réactive, même avec plusieurs applications qui pédalaient : pas de blocage temporaire du pointeur souris, pas d’application qui peinait à redessiner le contenu de sa fenêtre quand on la faisait passer au premier plan, des boutons qui s’enfonçaient toujours quand on cliquait dessus (et on savait que l’évènement était envoyé à l’application) ;
        • une interface utilisateur cohérente ;
        • des applications plus simples et plus légères.

        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.

        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

        • [^] # Re: Il y a bien longtemps...

          Posté par . É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 . É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 . É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 . É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 . É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 . Évalué à  2 .

            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…

            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.

            Cela demande beaucoup d'échanges de messages haut-niveau entre l'appli et le serveur GUI

            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.

            Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

            • [^] # Re: Il y a bien longtemps...

              Posté par . É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 . É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 . Évalué à  4 .

        si une application affiche une fenêtre transparente sur tout l'écran, elle peut tout espionner??

        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 . Évalué à  1 .

          Tu peux déjà faire une fenêtre transparente qui couvre tout l'écran avec X11

          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 . É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 . É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 (page perso) . É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 (page perso) . Évalué à  8 .

    bon les Windowsiens se seraient senti chez eux, mais non merci!

    J'ai régulièrement ce message quand une application a freezé et que j'essaye de la fermer sur KDE/X11.

    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Ça existe déjà.

      Posté par (page perso) . Évalué à  1 .

      Pareil avec Unity. Et je ne vois pas le problème.

      Envoyé depuis mon lapin.

      • [^] # Re: Ça existe déjà.

        Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 . É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 (page perso) . Évalué à  7 .

                En même temps il doit y avoir d'autres solutions à ce problème, genre "pinger" régulièrement l'appli.

                Horrible. Comment proposer une solution inférieure à l'existant…

                • [^] # Re: Ça existe déjà.

                  Posté par . É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 (page perso) . É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 (page perso) . É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 . É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 . É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.

                          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                          • [^] # Re: Ça existe déjà.

                            Posté par . É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 . É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 . É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 15 ans !

                      • [^] # Re: Ça existe déjà.

                        Posté par . Évalué à  2 .

                        C'est encore le cas normalement, même s'il est encapsulé par la bibliothèque graphique.

                        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                  • [^] # Re: Ça existe déjà.

                    Posté par (page perso) . Évalué à  3 .

                    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.

                    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 (page perso) . Évalué à  -1 .

                      hint: threads :)

                      • [^] # Re: Ça existe déjà.

                        Posté par (page perso) . É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 . É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 . É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 . Évalué à  3 . Dernière modification : le 12/08/11 à 00:56

    Frameworks 5 does not influence our development of the desktop at all. This means we will continue to release further 4.x releases of the KDE Plasma Workspaces.

    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."

    We will switch when we are confident that we do not break the users’ desktops.

    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 . Évalué à  6 .

      Ceci est une très bonne nouvelle.

      Ç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 . É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 (page perso) . É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.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # La critique est facile, l'art est difficile

      Posté par . É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 . É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 (page perso) . Évalué à  2 .

          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…

          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.

          La dernière étoile n'apporte rien :-)

          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.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: La critique est facile, l'art est difficile

            Posté par . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.