awesome 3 : premier gestionnaire de fenêtres basé sur XCB

Posté par (page perso) . Modéré par Nÿco.
Tags :
31
19
sept.
2008
Serveurs d'affichage
Après 6 mois de développement et près de 1000 change-sets, la version finale de awesome 3.0 est sortie. Pour rappel, awesome est un gestionnaire de fenêtres se définissant comme un framework, et supportant le « tiling ».

Cette version majeure apporte son lot de nouvelles fonctionnalités, avec principalement la réécriture complète de la configuration utilisateur qui est maintenant exportée sous forme d'une simple API en Lua. Cela permet de personnaliser son gestionnaire de fenêtres jusque dans ses moindres recoins.

Cette version est également basé sur XCB, une bibliothèque bas niveau permettant de communiquer avec le serveur X. Cela permet à awesome de se passer totalement de la vieillissante Xlib et d'être asynchrone : il est donc plus rapide que bon nombre de gestionnaire de fenêtres. L'utilisation de Pango améliore également le rendu des textes.
  • # J'avais essayé

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

    J'avais essayé awesome 2 sur mon netbsd/ppc mais j'ai assez rapidement abandonné car jaimais ni les raccourcis clavier, ni l'algo de tiling... Je suis passé sur wmii que je garde pour l'instant. Faudra que j'essaye awesome3, que je vérifie qu'il mérite bien son nom...
    • [^] # Re: J'avais essayé

      Posté par . Évalué à 9.

      Il y a quelque chose d'un peu énervant lorsque l'on utilise un clavier azerty avec awesome, c'est que les raccourcis clavier par défaut qui permettent de changer de vues ne marchent pas. D'après ce que j'ai pu comprendre, lorsque l'on fait Meta - 1 sur un clavier français cela donne Meta - Majuscule - & . Donc dés le départ, faut que tu te retape la conf des raccourci clavier. Chez moi, j'ai réaffecté tout ça sur les touches de fonction, ça permet de garder la boucle bien pratique dans le script de conf. Ça donne ça dans le rc.lua (à partir de la version 3, c'est plus le même fichier de conf) (Il faut aussi penser à réaffecter les Meta - Touche de Fonction déjà utilisées)
      for i = 1, keynumber do
          keybinding({ modkey }, "F" .. i,
                         function ()
                             local screen = mouse.screen
                             if tags[screen][i] then
                                 awful.tag.viewonly(tags[screen][i])
                             end
                         end):add()
          keybinding({ modkey, "Control" }, "F" .. i,
                         function ()
                             local screen = mouse.screen
                             if tags[screen][i] then
                                 tags[screen][i].selected = not tags[screen][i].selected
                             end
                         end):add()
          keybinding({ modkey, "Shift" }, "F" .. i,
                         function ()
                             local sel = client.focus
                             if sel then
                                 if tags[sel.screen][i] then
                                     awful.client.movetotag(tags[sel.screen][i])
                                 end
                             end
                         end):add()
          keybinding({ modkey, "Control", "Shift" }, "F" .. i,
                         function ()
                             local sel = client.focus
                             if sel then
                                 if tags[sel.screen][i] then
                                     awful.client.toggletag(tags[sel.screen][i])
                                 end
                             end
                         end):add()
      end
      
      A part ça, je trouve que c'est le meilleur gestionnaire de fenêtre de ce type que j'ai pu essayer. Son mode de configuration est tel que tu peux pratiquement faire ce que tu veux, les différents modes de placement des fenêtres sont extra. C'est costaud, simple et pratique. Et contrairement à wmii, il supporte les configurations à plusieurs écrans. En tout cas, merci aux devs pour ce chouette gestionnaire de fenêtre !
  • # Argh

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

    C'est quand je lis ce genre de chose que je me dis que jamais je n'aurais dû m'habituer à la gestion par colonnes de wmii, tellement Awesome a l'air bien conçu. Tellement moderne qu'il mérite vraiment de faire parler de lui.
    • [^] # Re: Argh

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

      Pour toutes les personnes qui vont poser la question bientôt, il y actuellement pas mal de boulot de fait niveau dévelopement pour exporter tout plein de choses, dont les layouts en Lua, ce qui permettra de créer sa propre gestion de l'organisation des fenêtres, soit comme actuellement (dwm style) soit à la ion ou bien encore à la wmii.

      Bref ca évolue, et si vous voulez que ca arrive plus vite, un coup de main est le bienvenue.

      Le code est d'ailleurs ultra-documenté et assez simple.
      • [^] # Re: Argh

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

        Et bien avec ça, si tout le monde ne déserte pas la concurrence…

        Il y a un truc fantastique avec Awesome, c'est que ça fait de très belles captures d'écran, très propres. Je ne peux pas en dire autant de mon wmii, malheureusement.
      • [^] # Re: Argh

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

        À mon avis, avant ça, il serait important de rédiger un guide de l'utilisateur, basé sur la configuration par défaut. Peut-être que ça existe déjà, mais je n'ai pas trouvé, et essayer un par un toutes les commandes listées dans le wiki, ce n'est pas ce qu'on fait de plus accueillant.
    • [^] # Re: Argh

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

      Le petit problème c'est que le format/la syntaxe du fichier de config change à chaque version et y'a pas de procédure de migration prévue. Du coup j'ai dû rester à la 2.0 car réécrire ma config totalement custom ça me lourde pas mal quand même...

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: Argh

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

        Tout à fait d'accord avec ca, j'en suis bien désolé.

        L'avantage de a3 c'est que c'est basé sur Lua: la syntaxe ne change pas (c'est un language).

        L'API peut évoluer, mais il y aura toujours un tant d'adaptation: aucune fonction de la version N ne sera (dans la mesure du possible) retirer violemment de l'API, mais marquer comme « deprecated » dans la version N+1 et retirer en N+2.
        • [^] # Re: Argh

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

          Et fournir des outils pour migrer automatiquement une conf d'une version à une autre c'est pas prévu ?

          Moi je veux juste utiliser mon window manager, une fois configuré, qu'il correspond à mes besoins je vois mal l'intérêt de me retaper la conf puisqu'elle ne bouge pas dans son utilisation...

          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: Argh

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

        Bon, je viens d'essayer Awesome 2 et 3. Je trouve la configuration du 3 un tout petit peu moins lisible. :->

        Arrivant d'Ion, je suis également un peu énervé par la gestion statique des tags et des vues, mais je n'ai pas encore bien compris comment ça fonctionnait, donc je vais prendre le temps de m'y mettre.
        • [^] # Re: Argh

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

          Tu peux regarder du cote d'eminent pour les tags dynamiques.
        • [^] # Re: Argh

          Posté par . Évalué à 2.

          Je vais rester sur awesome2, le changement est trop bouleversant.
          Et les RC d'exemples ne sont pas claires et nécessite à un tas de scripts personnalisés.

          Et puis dans awesome3, j'ai noté un petit soucis de rendu dans la barre principal quand les valeurs changent il y a de la persistence.

          Si vous avez des rc propres et bien commenté, ça serait sympa de partager.
          • [^] # Re: Argh

            Posté par . Évalué à 3.

            Si tu veux ma conf par exemple, c'est là : https://trac.poildetroll.net/trac/akoya/browser/config/aweso(...)
            C'est plus ou moins commenté, mais c'est lisible en tout cas. Le code de mes widgets sont encore un peu bricolo par contre, mais j'y travaille...
            Faut pas oublier d'installer luafilesystem aussi pour que ma config fonctionne :P

            Aussi, je me cherche une lib mpd pour Lua, qui n'utilise pas de soft externe comme mpc ou netcat comme j'ai pu voir dans des confs ion3... mais je crois que je vais me coder ça avec luasocket au final. :)

            Sinon perso au contraire je préfère nettement cette conf en Lua que celle en confuse d'awesome 2, parce que je peux faire mes fonctions direct dans la conf et non plus par des scripts externes, c'est plus propre et ça fait des process en moins. :)
            • [^] # Re: Argh

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

              tu peux faire un binding de libmpd, en Lua, les bindings sont très facile à faire.

              Sinon, perso, j'utilise os.execute("mpc ...") et ça me convient. Je n'ai pas encore trouvé le temps de faire mieux, et je ne trouve pas ça si mal. De même avec le mixer audio: os.execute("amixer ...")

              Mildred
              • [^] # Re: Argh

                Posté par . Évalué à 1.

                Oui c'est ce que je fais actuellement si tu mattes ma conf, à coup de io.popen("mpd ...") :)
                Mais étant sur un laptop, je veux réduire au max l'utilisation de softs externes pour réduire les accès au hdd, donc en exploitant directement les fichiers "virtuels", sockets, etc. Enfin bref, avec luasocket ça devrait le faire :)
          • [^] # Re: Argh

            Posté par . Évalué à 1.

            Idem je trouve la config Awesome 3 imbuvable. J'étais content d'avoir dans Awesome 2 un beau fichier de config tout clair et simple, mais maintenant...
  • # XCB

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

    Je suis intéressé par l'utilisation de XCB. Est-ce le premier window manager à se baser dessus ? Est-ce que l'écart de perf par rapport à xlib est notable ?
    • [^] # Re: XCB

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

      Oui c'est le premier WM à utiliser XCB (et une des rares applications)

      L'écart de perf est discutable: c'est largement mesurable au démarrage par exemple, mais
      à l'utilisation quotidienne, c'est plus discutable, mais c'est quand même notable de mon point de vue.

      Par contre, en tant que développeur, l'API est infiniment plus clair et propre que la Xlib, et rien que pour ca, ca vaut le coup.
      • [^] # Re: XCB

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

        Et en déport d'affichage ? Vu qu'XCB est fait pour être asynchrone, ça a moyen d'être globalement plus réactif, non ?
        • [^] # Re: XCB

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

          Globalement oui, c'est plus réactif dans un cas comme celui ci.

          Maintenant, il y a aussi beaucoup de cas où quand tu envoies une demande au serveur X, tu n'as rien à faire d'intéressant tant que tu n'as pas la réponse. Dans ce cas, il n'y a aucun gain en performance.

          Il y a aussi possibilité de gagner beaucoup plus avec une application multi-threadé (ce qu'awesome n'est pas (mal)heuresement).
          • [^] # Re: XCB

            Posté par . Évalué à 1.

            Il y a aussi possibilité de gagner beaucoup plus avec une application multi-threadé (ce qu'awesome n'est pas (mal)heuresement).
            Peux-tu approfondir sur le fait qu'il soit bon que awesome3 ne soit pas multi-threadé ?
            • [^] # Re: XCB

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

              Peut-être qu'il n'a pas envie de se prendre la tete à developper en utilisant un modèle de concurrence completement cassé ?
              • [^] # Re: XCB

                Posté par . Évalué à 0.

                sous archlinux, j'ai ce problème :

                cairo-xcb: conflicts with cairo

                vu que beaucoup de paquets dépendent de cairo, je n'arrive pas à le retirer proprement pour mettre cairo-xcb à la place. Une astuce ? Je n'arrive pas à le forcer non plus.

                Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                • [^] # Re: XCB

                  Posté par . Évalué à 3.

                  pacman -Rd cairo
                  pacman -U cairo-xcb

                  c'est indiqué dans le message d'erreur...
                  • [^] # Re: XCB

                    Posté par . Évalué à 2.

                    oups, où avais-je la tête, ça fonctionne, merci.

                    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

              • [^] # Re: XCB

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

                Oui, je disais cela en rapport avec la complexite du model et du code que ca impliquerait.
          • [^] # Re: XCB

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

            Et dans une utilisation en client léger (genre www.ltsp.org)? on y gagnerait (charge réseau, charge serveur)?

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: XCB

        Posté par . Évalué à 5.

        Oui c'est le premier WM à utiliser XCB (et une des rares applications)

        Dans mon école y'avait des élèves qui avaient fait un WM XCB il y a 3 ans. À l'époque c'était très novateur (et puis du coup ils avaient un peu essuyé les plâtres vu que XCB était récent et pas forcément très testé).

        http://home.gna.org/gfaim/
      • [^] # Re: XCB

        Posté par . Évalué à 7.

        les avantages de xcb :

        1) asynchrone. donc si une application est bien ecrite (donc il faut bien connaitre X), son temps de demarrage sera plus court. Le gestionnaire de fenetre sera plus reactif mais comme dit julien, ca ne se voit pas trop. Il m'avait dit qu'avec 200 fenetres, ca se voit :)

        2) xcb est plus leger (les shared lib sont bien plus petites que xlib). Donc pour de l'embarque, c'est nickel

        3) c'est thread safe. Xlib n'est pas thread safe, donc l'utilisation d'xlib dans des appli peut se reveler fastidieux (xine ou gstreamer par exemple). Ave xcb, beaucoup moins de problemes

        4) l'utilisation de clients (applications) a travers un tunnel ssh est largement plus sympathique : temps de demarrage 5 fois plus court (sur ma machine) et reactivite beaucoup plus importante. Ca rejoint bien sur le point 1), dans la mesure ou executer une appli via ssh ralentit l'appli et donc les differences entre xlib et xcb se voient beaucoup plus.

        5) par contre, xlib integre une quantite monstrueuse de petites fonctions qui ident le developpement. XCB essaie de pallier a ca avec un petit package (nome util), mais on est loin de xlib pour ca.

        pour l'api, pareil que jullien

        pour les appli / lib :

        * xine a un support xcb
        * les bibliotheques d'enlightenment (evas, par exemple, et bientot ecore)
        * cairo
        * xlib (dans xorg >= 7.2) utilise une sous-couche basee sur xcb. Ca n'est pas aussi puissant que xcb, mais c'est un debut
        • [^] # Re: XCB

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

          XCB est en fait plus bas niveau que la Xlib puisqu'elle est au niveau protocolaire (protocole X). Ce qui fait donc qu'elle remonte à la surface la caractéristique asynchrone de X11 qui avait été trop longtemps cachée par la Xlib.
          C'est pour cette raison qu'il faut écrire plus d'instructions pour faire la même chose avec une ou deux fonctions de la Xlib.

          Par contre, je pense que XCB n'est pas à utiliser comme tel par un développeur d'IHM. C'est aux toolkits (Gtk+, Qt, ...) d'encapsuler XCB, ce qui fait que le développeur n'aura alors pas à modifier son code existant et qu'il pourra toujours se concentrer sur son IHM et pas sur des détails techniques de bas niveau.
    • [^] # Re: XCB

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

      il y a une liste des projets utilisant XCB
      http://xcb.freedesktop.org/adoption/
      C'est petit :
      - Xlib itself has replaced Xtrans with XCB for the low-level transport layer
      - The http://cairographics.org/ library has an experimental XCB backend.
      - Vincent Torri has worked to port evas canvas component of http://www.enlightenment.org/ from Xlib to XCB.
      - The recent MPX (multi-pointer) extension was prototyped using XCB.
      - Work is ongoing to port selected default X apps from Xlib and Xt to XCB.
      - awesome, a window manager, uses XCB instead of Xlib.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # A tester

    Posté par . Évalué à 2.

    Depuis un petit temps je voulais un peu apprendre un wm tilling.
    Ion3 me tentait vraiment beaucoup, mais sa licence me fait vraiment chier ... awesome m'a l'air très prometteur, je tenterai certainement ça.
    :D
    • [^] # Re: A tester

      Posté par . Évalué à 4.

      Ion3 me tentait vraiment beaucoup, mais sa licence me fait vraiment chier
      Pour ceux que ça intéresse, le problème vient du fait que cette licence indique que le nom" ion" ne peut être utilisé par les distributions que si la version fournie ne diffère pas trop de la version upstream et n'est pas trop vieille ( 4 semaines )
      Plus d'infos : http://modeemi.fi/~tuomov/ion/news/Down_with_the_distros.htm(...)
      • [^] # Re: A tester

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

        En même temps, il n'y a pas forcément que la licence de gênante. L'état d'esprit du développeur ne donne vraiment pas envie d'utiliser ou de continuer à utiliser Ion… Et c'est d'autant plus vrai que toute licence est soumise à une interprétation, notamment de la part de l'auteur du code qui y est soumis.
  • # Je suis perdu avec X

    Posté par . Évalué à 3.

    Il y a plein de truc qui ont trait avec l'interface utilsateur sous Linux et je me perds totalement.

    J'entends parler de X, X/Motif, Xorg, Xfree, enlightenment, KDE, GNOME...

    Existe-t-il un endroit où se retrouver parmi tout ce foisonnement ou bien une bonne âme pour nous faire une explication limpide ?
    • [^] # Re: Je suis perdu avec X

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

      X, X11 ou encore X11R7 (sa version actuelle) : le protocole sur lequel reposent les systèmes graphiques utilisés pas la plupart des Un*x, dont GNU fait partie.

      X.org : une implémentation libre d'X11, qui gère donc l'affichage sous GNU.

      XFree86 : une ancienne implémentation libre d'X11, qui a été remplacée par X.org.

      Motif, GTK+ et Qt : des bibliothèques d'éléments graphiques (menus, cases à cocher, ascenseurs…) utilisés par bon nombre de programmes. Seule une partie de GTK+ et Qt s'occupe de cela, ces deux bibliothèques offrant bien d'autres fonctions.

      Enlightenment, KDE, GNOME, Xfce et bien d'autres : des environnements graphiques complets pour systèmes Un*x.
      • [^] # Re: Je suis perdu avec X

        Posté par . Évalué à 0.

        gnu n'a rien a voir avec X11 ou xorg

        xfree86 n'est pas vraiment une ancienne implementation. xorg est un fork de xfree86 et cette derniere continue d'etre developpee en parallele (mais pas beaucoup). La plupart des efforts se font sur xorg
      • [^] # Re: Je suis perdu avec X

        Posté par . Évalué à 2.

        Je sais que des bibliothèques sont incompatibles.

        Je sais aussi que "Enlightenment, KDE, GNOME, Xfce et bien d'autres" sont basés sur des bibliothèques différentes.

        Est-ce à dire qu'un programme peut ne pas fonctionner parce qu'il a été programmé avec une bibliothèque qui n'est pas la bibliothèque de l'environnement graphique que j'utilise ?
        • [^] # Re: Je suis perdu avec X

          Posté par . Évalué à 4.

          tu peux, par exemple, utiliser des application ecrites avec gtk+ sous l'environnement kde (et plus precisement en utilisant kwin, le gestionnaire de fenetre de kde). La seule chose qu'il faut pour que cette application fonctionne est la presence des bibliotheques partagees de gtk+ et de ses dependances (les fichiers ayant pour extension .so)

          c'est pareil avec n'importe quel autre gestionnaire de fenetres. Avec enlightenment, tu peux utiliser des applis utilisant gtk+ ou qt, avec metacity (le gestionnaire de fenetres de gnome), tu peux utiliser des applis utilisant les efl ou qt, etc... Le seul chose requise est la presence des bibliotheques partagees necessaires a l'appli en question.

          pareil pour awesome.
          • [^] # Re: Je suis perdu avec X

            Posté par . Évalué à 2.

            Comment connais-je les bibliothèques dont le programme que je souhaite utiliser aura besoin ?

            Qui installe les bibliothèque nécessaires à ce programme ?
            • [^] # Re: Je suis perdu avec X

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

              Tant que tu fais confiance à ta distribution, elles sont installées par dépendances lorsque tu installes un logiciel qui en as besoin.
            • [^] # Re: Je suis perdu avec X

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

              Généralement (sauf utilisation de libdl.so/dlopen/dlsym/dlclose) les bibliothèques nécessaires à un binaire peuvent être découvertes en utilisant l'utilitaire ldd. Par exemple:

              ldd /usr/bin/awesome
              linux-gate.so.1 => (0xb8065000)
              libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb8021000)
              libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb8018000)
              libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7fda000)
              libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7f9f000)
              libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7f9c000)
              libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7ee6000)
              libxcb-randr.so.0 => /usr/lib/libxcb-randr.so.0 (0xb7ee0000)
              libxcb-xinerama.so.0 => /usr/lib/libxcb-xinerama.so.0 (0xb7edd000)
              libxcb-aux.so.0 => /usr/lib/libxcb-aux.so.0 (0xb7eda000)
              libxcb-keysyms.so.0 => /usr/lib/libxcb-keysyms.so.0 (0xb7ed7000)
              libxcb-icccm.so.1 => /usr/lib/libxcb-icccm.so.1 (0xb7ed1000)
              libxcb-atom.so.1 => /usr/lib/libxcb-atom.so.1 (0xb7ecd000)
              libxcb-property.so.1 => /usr/lib/libxcb-property.so.1 (0xb7ecb000)
              libxcb-event.so.1 => /usr/lib/libxcb-event.so.1 (0xb7ec9000)
              libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb7e60000)
              libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0xb7e5c000)
              libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb7e54000)
              libev.so.3 => /usr/lib/libev.so.3 (0xb7e49000)
              liblua.so => /usr/lib/liblua.so (0xb7e22000)
              libm.so.6 => /lib/libm.so.6 (0xb7dfc000)
              libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb7dc4000)
              libImlib2.so.1 => /usr/lib/libImlib2.so.1 (0xb7d60000)
              libc.so.6 => /lib/libc.so.6 (0xb7c1d000)
              libX11.so.6 => /usr/lib/libX11.so.6 (0xb7b2e000)
              libXau.so.6 => /usr/lib/libXau.so.6 (0xb7b2b000)
              libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7b26000)
              libdl.so.2 => /lib/libdl.so.2 (0xb7b22000)
              libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7afb000)
              libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7a76000)
              libz.so.1 => /usr/lib/libz.so.1 (0xb7a62000)
              libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7a37000)
              libpcre.so.0 => /lib/libpcre.so.0 (0xb7a06000)
              libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb79de000)
              libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb79d6000)
              libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb79ad000)
              librt.so.1 => /lib/librt.so.1 (0xb79a4000)
              /lib/ld-linux.so.2 (0xb8066000)
              libXext.so.6 => /usr/lib/libXext.so.6 (0xb7996000)
              libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7993000)
              libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7973000)
              libpthread.so.0 => /lib/libpthread.so.0 (0xb795b000)
  • # Le rendu de la police?

    Posté par . Évalué à 0.

    Avez-vous des paramètres à faire partager?
    Linux ne brille pas de ce côté là.
    • [^] # Re: Le rendu de la police?

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

      Linux ne brille pas de ce côté là.

      Ah bon. Jamais remarqué de défaut, pour ma part, et le réglage par défaut d'Awesome est tout à fait agréable.
      • [^] # Re: Le rendu de la police?

        Posté par . Évalué à 1.

        Je suis entrain de compiler awesome3, pango met une plombe!!!
        encore un nom à la con comme seul le libre sait en trouver! :)

        As-tu jamais remarqué? Pose tes yeux sur un MacOSX, tu verras le gouffre.
        Cela dit, pas besoin d'avoir ce système, j'avais déjà vu un xorg très bien configuré mais comment, je ne sais pas.

        Les distros les plus répandues n'offrent cette qualité par défaut.
        • [^] # Re: Le rendu de la police?

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

          Pose tes yeux sur un MacOSX, tu verras le gouffre.

          Déjà fait, je n'ai pas vu la différence. Ce qu'il me faudrait, c'est un comparatif avec images à la clef.
          • [^] # Re: Le rendu de la police?

            Posté par . Évalué à -10.

            Et tu vas me moinsser à chaque fois???

            Je n'ai pas de macosx sous la patte, mais demain je pourrais!
            • [^] # Re: Le rendu de la police?

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

              Eh, ce n'est pas moi qui te moinsse ! Je ne demande que ça, de voir ce qui ne va pas !
              • [^] # Re: Le rendu de la police?

                Posté par . Évalué à 3.

                Et bien sur le lien que donne notre ami ci-dessous - sharpfonts.com - tu as l'illustration exact du rendu critiqué, bienque le rendu windows affiché ici n'est pas encore tout à fait celui dont je parle, mais il sagit bien d'un problème de police baveuse ( ou polies soit disante! ) et police "affûtée".
                Remarque toutefois qu'il n'y a pas besoin de ces polices non-libres, c'est vraiment un soucis de configuration.
                • [^] # Re: Le rendu de la police?

                  Posté par . Évalué à 4.

                  Ce n'est pas un problème uniquement de configuration. Les polices True Type sont vectorielles, mais possèdent un système de "hint" pour améliorer le rendu sur écran. Or, ce système de hint:

                  - est couvert par un brevet, et pendant longtemps, sur la plupart des distribs, la bibliothèque freetype était compilée sans son support (je ne sais pas si c'est encore le cas); c'était remplacé par un "autohinter".

                  - demande beaucoup de travail supplémentaire par rapport à une police vectorielle simple; il n'y a pas beaucoup de polices libres qui en soient équipées. Je pense que DejaVu ne l'est qu'en partie, les Liberation fonts de RedHat le sont, il y en a peut-être d'autre.

                  Note que tu peux choisir le degré de "hint" appliqué (sous gnome, c'est dans les réglages avancé des polices).

                  (hum... quelqu'un aurait une traduction parlante pour "hint"?)
                  • [^] # Re: Le rendu de la police?

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

                    J'ajoute qu'un bon hinting demande un travail manuel et que c'est mieux avec une police bien conçue dès le départ. C'est un travail long, minutieux, qui demande un oeil exercé.

                    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                • [^] # Re: Le rendu de la police?

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

                  Tu veux dire que tu préfères la capture on l'on voie la sharpfonts blindé de crénelage ? La moindre courbe et diagonale est dessiné par des patés de pixels en escalier, c'est horrible !

                  Non mais cette page c'est un fake non?

                  Bon après tout les goûts sont dans la nature vous me direz.
                  • [^] # Re: Le rendu de la police?

                    Posté par . Évalué à 2.

                    Non l'exemple de droite est un peu exagéré, et de plus je parle de rendu, pas de type de police! Néanmoins au niveau de la "finesse" c'est à peu près cela.
                    Je signale que "Déjà Vu" est capable d'être rendue parfaitement sous Xorg.

                    Non mais cette page c'est un fake non?
                    Un fake, non, c'est souvent la configuration standard sur pas mal de distrib.
                    Que tu arrives à faire mieux, bravo, pourrais-tu faire part de ta config?

                    En tout cas, la capture de gauche est dégueux!

                    S'en rendre compte? Y a pleins de personnes qui possèdent une télé HD, sont impressionnés lorsqu'il matte un DVD SD, c'est dire!
                    • [^] # Re: Le rendu de la police?

                      Posté par . Évalué à 3.

                      "En tout cas, la capture de gauche est dégueux!"
                      Désolé mais voici l'avis d'un novice : je prefere largement la capture de gauche à celle de droite. C'est bien plus agréable à l'oeil.
                      • [^] # Re: Le rendu de la police?

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

                        Heureusement qu'il y a plus que les images sur le site en question : ils disent aussi quel est le meilleur rendu et surprise, ça dépend de tes préférences et de tes habitudes. C'est vrai quoi, chacun a le droit de préférer des lettres floues ou alors des lettres crénélées...
                      • [^] # Re: Le rendu de la police?

                        Posté par . Évalué à 2.

                        Je n'ai pas dit que celle de droite était mieux! Manifestement, la police est mauvaise.

                        Novice? si tu veux, mais entre une belle courbe nette (pas celle sur la capture de droite bien sûr!!!) et une coube baveuse (celle sur la capture de gauche surtout!!!), je choisie la nette.

                        Si tu lisais ce que j'écrivais, la police "Déjà Vu" est capable d'être rendue parfaitement sous Xorg de la "Xorg Foundation k'est libre" et de faire beaucoup mieux que sur la capture de gauche! Mais par défaut, ce n'est pas le cas!

                        Fait chier, j'ai l'impression que dés qu'il y a mention d'Apple ou de crosoft, vous perdez toute objectivité.
                        • [^] # Re: Le rendu de la police?

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

                          Fait chier, j'ai l'impression que dés qu'il y a mention d'Apple ou de crosoft, vous perdez toute objectivité.

                          Non, au contraire, en ce qui me concerne, j'aimerais avoir des faits objectifs, justement. Je ne sais pas ce que vaut un affichage de MacOS X, je n'en ai pas sous la main. Je sais en revanche ce qu'affiche mon X.org sous Debian, et je trouve ça parfait, avec même de l'anti-crénelage sous-pixel. Bon, l'anticrénelage sous-pixel, j'ai du le demander dans une boîte de dialogue de GNOME, mais ça n'a rien de compliqué.

                          Donc tant qu'on ne m'aura pas présenté une vraie démonstration, pour moi, dire que le rendu des polices est moche sous GNU/Linux et beau sous MacOS X, ce n'est rien d'autre que du FUD.
                    • [^] # Re: Le rendu de la police?

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

                      Bon bon j'ai décidé de tester moi même pour comparer : http://moipetit.free.fr/test/Linux_vs_OS_X.png

                      À gauche nous avons un firefox sous debian linux (configuration par défaut) et à droite nous avons un firefox sous Mac OS X. Il y a une différence de résolution entre les deux écrans mais ça ne gène pas trop.

                      Je laisse les linuxiens jugés de la supériorité des caractères flous de Mac OS X. Personnelement je préfère largement le rendu par défaut de debian. Après je peux peut-être avoir mieux mais je ne me suis jamais penché dedans.
                      • [^] # Re: Le rendu de la police?

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

                        Merci, voilà un mythe qui tombe : oui, le rendu des polices est différent sous GNU et sous MacOS, puisqu'il est largement supérieur sous GNU.
                        • [^] # Re: Le rendu de la police?

                          Posté par . Évalué à 5.

                          "Merci, voilà un mythe qui tombe : oui, le rendu des polices est différent sous GNU et sous MacOS, puisqu'il est largement supérieur sous GNU."

                          Sous GNU ? C'est pas xorg / cairo et tout le reste qui s'occupe du rendu ? Qu'est ce que vient faire les outils GNU ici ?
                          • [^] # Re: Le rendu de la police?

                            Posté par . Évalué à 0.

                            ça montre surtout qu'ils ont manqué le coche! crispés à la seule lecture de Apple - Windows XP dans mes écrits!

                            Je rappellé 3 fois que Xorg en était capable! mais que la config par défaut ne satisfait pas dans tous les cas!!! (4 fois maintenant!!)

                            Enfin...
                            • [^] # Re: Le rendu de la police?

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

                              C'était une configuration par défaut, le comparatif de tiot. Et elle ne laisse pas le moindre doute, le rendu est largement supérieur sous Debian que sous MacOS X.
                            • [^] # Re: Le rendu de la police?

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

                              As-tu jamais remarqué? Pose tes yeux sur un MacOSX, tu verras le gouffre.
                              Cela dit, pas besoin d'avoir ce système, j'avais déjà vu un xorg très bien configuré mais comment, je ne sais pas.

                              Les distros les plus répandues n'offrent cette qualité par défaut.


                              En gros tu dis que par défaut la configuration de Mac OS X est bien meilleur. J'ai pris une photo d'écran de DLFP avec debian configuré par défaut et Mac OS X configuré par défaut.

                              On voit clairement que le rendu de Mac OS X est flou.

                              crispés à la seule lecture de Apple

                              Quand on FUD pour dire que Mac OS X est supérieur à X.org alors oui, ça crispe.
                              • [^] # Re: Le rendu de la police?

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

                                Déjà, première question, histoire de voir si on peut vraiment comparer : les polices sont les même ou non ?
                                Car avec des polices différentes ça devient difficile de comparer objectivement ...

                                Maintenant, pour ma part je trouve la capture de gauche plus mauvaise, on voit très bien que les lettres sont trop fines, les lettres sont trop espacées.

                                Sur la droite, les polices sont peut-être un peu plus "baveuses", moins nettes, mais aussi moins crénélées (bon faudrait aussi voir avec la même résolution pour avoir une vrai comparaison...)

                                Le truc c'est que mac a un objectif légèrement différent (en tout cas pour les softs d'édition, et pour avoir bossé un peu dans le domaine - journaux - le problème est très sérieux) : le but est d'avoir un rendu très proche entre celui de l'écran et la sortie impression, ce qui n'est pas toujours le cas sur les autres systèmes, calibration des écrans, gestion des polices, etc.
                                Ca peut expliquer en partie les différences qu'on a visuellement.

                                Maintenant, je ne trouve pas pour autant que le rendu sous X soit mauvais, mais ils ne sont pas pareils, n'ont pas spécialement les même objectifs, et dire que l'un est "bien meilleur" que l'autre serait à mon avis une erreur.

                                Et je fini vite fait avec l'histoire des polices différentes. Si on a pas la même police sur les deux systèmes, il est quasiment impossible de critiquer quoi que ce soit, les polices ayant des paramètres différents (Tracking_(typography), kerning, etc). Ce qu'il faudrait comparer c'est le rendu d'un même texte avec la même police, histoire de voir si tous les systèmes lisent les même paramètres et les implémentent bien. Ca serait à mon avis un bon début (mais désolé j'ai pas de mac sous la main...)
                                • [^] # Re: Le rendu de la police?

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

                                  Je crois que tout le monde attend maintenant ton test objectif, copie d'écran à l'appui :-)
                                  • [^] # Re: Le rendu de la police?

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

                                    désolé, j'ai pas de mac...
                                    mais si ça intéresse réellement quelqu'un, voici un lien pas mal : http://www.howardesign.com/exp/compare/

                                    On voit tout de suite la différence entre les rendus, mais pour le comprendre faut aller un peu plus loin que 2 captures sur 2 systèmes avec des polices différentes et chercher un peu pourquoi...

                                    Mais je reste surtout sur le fait que le meilleur système est pour moi celui qui aura le rendu le plus proche ... des spécifications de la police...
                                • [^] # Re: Le rendu de la police?

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

                                  Ton histoire de police différente, on s'en fou. La question était de savoir quel rendu par défaut, donc avec les polices par défaut, nous semblait le meilleur.
                                  • [^] # Re: Le rendu de la police?

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

                                    ho ben merde, désolé de vouloir expliquer pourquoi plusieurs systèmes ont des rendus de police différents hein...

                                    Et sur le rendu par défaut (puisque les raisons te semble tellement peu intéressantes) :
                                    > Maintenant, pour ma part je trouve la capture de gauche plus mauvaise, on voit très bien que les lettres sont trop fines, les lettres sont trop espacées.

                                    Mais c'est vrai, j'aurais juste du mettre cette phrase, et pas le reste histoire d'expliquer pourquoi c'est différent (et si sur mon système j'ai comme police par défaut une autre police, j'en fait quoi de ta comparaison foireuse ?)
                                    • [^] # Re: Le rendu de la police?

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

                                      (et si sur mon système j'ai comme police par défaut une autre police, j'en fait quoi de ta comparaison foireuse ?)

                                      Tu installes Debian. ;-)
                                      Non, sérieusement, je vois mal quelle police pourrait remplacer les DejaVu ou Bistream Vera comme choix par défaut.
                                      • [^] # Re: Le rendu de la police?

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

                                        Ben pour ma part j'ai "Sans Serif" comme police par défaut... (proche d'une Arial)
                                        Et en regardant un peu plus, DejaVu Sans et Bistream Vera Sans ne me plaisent pas du tout, beaucoup trop d'espace entre les lettres entre autre.

                                        Mais bon, ce à quoi je voulais en venir, c'est qu'on peut aimer ou non un paramètrage par défaut (de police, de rendu, ...) mais on ne peut pas en déduire que le système est mieux (X mieux que le système équivalent sous mac - non pas que je mette l'un au dessus de l'autre)
                                        • [^] # Re: Le rendu de la police?

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

                                          Sans Serif, ce n'est rien du tout, sinon un alias pour une autre police nommée. Donc csi ce n'est pas Bistream Vera Sans ou DevaVu Sans, c'est sans doute FreeSans. Ou alors Arial, mais ce n'est alors sûrement pas un réglage par défaut, ou bien c'est une distribution pas du tout libre.
                                          • [^] # Re: Le rendu de la police?

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

                                            oui, c'est bien pour ça que j'ai indiqué que c'était proche d'une Arial, ça en est très très proche mais pas exactement (le P majuscule, en tout cas dans l'édition des paramètres de police de kde)

                                            Et si c'est le réglage par défaut... (mandriva 2008.1 + kde4.1, ok + 1 paquet d'autres polices, y compris windows)
                          • [^] # Re: Le rendu de la police?

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

                            J'aurais dû dire quoi, sous Linux ? Qu'est-ce que le noyau vient faire dans tout ça ? Bon, ok, disons sous X.org.
                • [^] # Re: Le rendu de la police?

                  Posté par . Évalué à 3.

                  Je vais me fendre d'un message peu constructif, puisque j'ai la flemme de regarder quels réglages j'utilise. En effet, le rendu lissé sur sharpfonts.com est assez mauvais, mais il est bien loin de ce que j'ai sur ma machine ! Je ne me souviens pas avoir passé particulièrement de temps sur la configuration de mes polices et de leur rendu, je pense avoir juste choisi la police et le lissage sous-pixel. Je trouve le rendu plus agréable que ce que j'ai par défaut sur MacOS, mais je ne sais pas si c'est dû au lissage ou tout bêtement à la police choisie.
                • [^] # Re: Le rendu de la police?

                  Posté par . Évalué à 3.

                  Mes 2 cents:
                  - pour les fontes 'normale' la différence entre les police polies et les police affutées est juste une affaire de gouts: les deux sont différents mais l'un n'est pas supérieur a l'autre.
                  - l'italique des fontes affutée est *horrible*
                  - le mode gras des fontes affutées est mieux que celui des fontes polies.

                  Donc au final, je prefere les polices polies: je ne supporterai de voir de l'italique affutée sur mon écran..
    • [^] # Re: Le rendu de la police?

      Posté par . Évalué à 1.

      sharpfonts.com et ça va de suite beaucoup mieux...
  • # Par rapport à xmonad?

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

    Est-ce qu'il y a de vraies différences, ou c'est du pareil au même? Xmonad marche très bien, et est simple à configurer, à condition de savoir programmer en haskell ;-)
    • [^] # Re: Par rapport à xmonad?

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

      simple à configurer, à condition de savoir programmer en haskell

      Erreur d'analyse : oxymore détectée. Non que Haskell soit compliqué, je n'en sais rien, je n'ai pas essayé, mais apprendre le Haskell, ce n'est pas ce que j'appelle simple, quand il s'agit de configurer un gestionnaire de fenêtres.

      Ah, on me souffle que c'est pareil pour Awesome, moyennant s/Haskell/Lua/. Enfin, le fichier de configuration d'Awesome est très compréhensible, et tant qu'on ne veut pas trop personnaliser, ça reste simple.
      • [^] # Re: Par rapport à xmonad?

        Posté par . Évalué à 5.

        hypothèse : il suffit probablement de connaître un sous-ensemble du langage, et ce sous-ensemble est probablement 15x plus simple que du XML (sALE!)
      • [^] # Re: Par rapport à xmonad?

        Posté par . Évalué à 2.

        le fichier de configuration d'Awesome est très compréhensible, et tant qu'on ne veut pas trop personnaliser, ça reste simple.
        Extraits de du code de Xmonad (Config.hs), qui est typé, donc ça fait une ligne de code en plus à chaque fois mais au moins on est sûr que c'est bon puisque le compilo le vérifie (oui, faut le recompiler ...) :
        defaultModMask :: KeyMask
        defaultModMask = mod1Mask

        normalBorderColor :: String
        normalBorderColor = "gray" -- "#dddddd"

        manageHook :: ManageHook
        manageHook = composeAll
        [ className =? "MPlayer" --> doFloat
        , className =? "Gimp" --> doFloat ]

        layout = tiled ||| Mirror tiled ||| Full
        where
        tiled = Tall nmaster delta ratio
        nmaster = 1
        ratio = 1/2
        delta = 3/100

        terminal :: String
        terminal = "xterm"

        focusFollowsMouse :: Bool
        focusFollowsMouse = True

        keys :: XConfig Layout -> M.Map (KeyMask, KeySym) (X ())
        keys conf@(XConfig {XMonad.modMask = modMask}) = M.fromList $
        [ ((modMask .|. shiftMask, xK_Return), spawn $ XMonad.terminal conf) -- %! Launch terminal
        , ((modMask, xK_p ), spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\"") -- %! Launch dmenu
        , ((modMask .|. shiftMask, xK_p ), spawn "gmrun") -- %! Launch gmrun
        , ((modMask .|. shiftMask, xK_c ), kill) -- %! Close the focused window


        J'ai même enlevé les commentaires, mais je pense que ça reste lisible et compréhensible.
        • [^] # Re: Par rapport à xmonad?

          Posté par . Évalué à 2.

          Extraits de du code de Xmonad (Config.hs), qui est typé, donc ça fait une ligne de code en plus à chaque fois mais au moins on est sûr que c'est bon puisque le compilo le vérifie (oui, faut le recompiler ...) :

          Ça fait un bout de temps (Xmonad 0.5 il me semble) qu'on fait plus la configuration dans Config.hs mais dans xmonad.hs, qui est recompilé automatiquement au redémarrage de XMonad si un changement est détecté (Et vu qu'on peut forcer le redémarrage de XMonad avec une séquence de touche, sans redémarrer X, ben c'est génial pour faire des changements de config à la volée).
          • [^] # Re: Par rapport à xmonad?

            Posté par . Évalué à 1.

            Ah, et je rajoute également qu'en général, le type est automatiquement détecté par le compilateur (c'est la magie de l'haskell), donc, il n'y a souvent pas besoin de le déclarer.
            • [^] # Re: Par rapport à xmonad?

              Posté par . Évalué à 2.

              Merci pour ces précisions, je n'utilise pas Xmonad mais je connais un peu Haskell, c'est pour ça que je suis allé voir à quoi ça ressemblait.
  • # nb_users++

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

    Cette dépêche n'aura pas servi à rien, vous venez de convertir au moins une personne à awesome. Pour être plus précis :
    nb_users_wmii-- ;
    nb_users_awesome++ ;
    • [^] # Re: nb_users++

      Posté par . Évalué à 10.

      T'as pas honte de faire des effets de bords alors que y a des bouts de langage fonctionnel pur pastés pas loin au dessus ? :)
  • # tabulous

    Posté par . Évalué à 3.

    il semblerait que dans la v3 d'awesome, il y ait un mode tabbing (a la ion3)
    mais impossible de trouver de la doc dessus.

    je cherche a changer de ion3, mais j'ai pas trouvé de tiled wm en mode tabbing qui le fasse simplement (la config de xmonad est vraiment trop obscure pour un non codeur)
    • [^] # Re: tabulous

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

      Le manuel d'awesome dit :
      - Mod4 + Contrôle + y : place la fenêtre suivante dans un onglet avec la fenêtre sélectionnée ;
      - Mod4 + Maj + y : retire la fenêtre sélectionnée d'un groupe d'onglets ;
      - Mod4 + y : sélectionne la fenêtre suivante d'un groupe d'onglets.
      • [^] # Re: tabulous

        Posté par . Évalué à 1.

        merci, je vais retenter. mais j'aurais aimé avoir ca comme comportement par defaut.

        je crois que mon changement de wm est pas encore gagné :-)
        • [^] # Re: tabulous

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

          <pub>À tout hasard, jette un coup d'oeil sur clfswm.</pub>
          http://common-lisp.net/project/clfswm/
          • [^] # Re: tabulous

            Posté par . Évalué à 0.

            \o/ CLFSWM for ever !

            Faudrait que je le reinstalle sur mon eeepc flambant neuf.
          • [^] # Re: tabulous

            Posté par . Évalué à 1.

            j'avais tenté, mais je sais plus pourquoi j'avais pas accroché, je retenterai

            tu veux pas le proposer comme paquet debian ? ;-)
            • [^] # Re: tabulous

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

              Il y a énormement de choses qui ont changé depuis l'annonce sur linuxfr.
              En particulier les cadres peuvent contenir des fenêtres avec des positionnements aux choix (les unes derrière les autres comme dans ion, tiled, ...) mais aussi d'autres cadres.
              Bon je ne m'étale pas plus puisqu'une nouvelle version est prévue dans peu de temps et ce sera plus l'endroit pour les détails.

              Je vais voir pour le paquet debian :)
        • [^] # Re: tabulous

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

          Mais c'est le comportement pas défaut, tu n'as pas besoin de définir toi-même ces combinaisons, c'est déjà fait !
          • [^] # Re: tabulous

            Posté par . Évalué à 1.

            le comportement par defaut serait de mettre une fenetre devant l'autre avec des tabs, et pas de la placer par rapport a l'autre dans le meme espace
            • [^] # Re: tabulous

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

              la placer par rapport a l'autre dans le meme espace

              Qu'est-ce que ça veut dire ?
              • [^] # Re: tabulous

                Posté par . Évalué à 1.

                la plupart des tiled wm divisent l'espace existant pour placer les fenetres, alors que ion les mets l'une derriere l'autre avec des "onglets" pour les selectionner
  • # Xmonad et awesome.

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

    Actuellement, à mon travail, j'utilise XMonad que j'apprécie bcp.
    Ce que j'aime bien de cet environnement est sa légèreté, sa facilité de conf (même si on ne connaît pas trop Haskell), et le tiling. Ha et aussi qu'il est écrit en Haskell, un langage de de haut niveau et de qualité, ce qui permet des évolutions et des corrections de bogues rapides et d'écrire soit même rapidement des choses (la contre partie est la courbe d'apprentissage de haskell).

    Sinon, il m'a fait découvrir le syst. de tags et je trouve ça vachement sympa ; dommage que je n'ai pas encore trouvé comme attribuer un tag à une fenêtre applicative précise au démarrage de celle-ci.

    J'ai remarqué que le système de tag semble plus intégré et abouti dans awesome. Faudra que je l'essai un jour. Dommage qu'il soit écrit tout en C (mais comme il propose un framework de dév, il propose probablement des fonctions de haut niveau pour s'abstraire de détails trop techniques (comme la gestion de la mémoire par exemple)).
    • [^] # Re: Xmonad et awesome.

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

      Le système de tags est surtout intéressant avec wmii, où il est dynamique, les tags étant créés lorsqu'on marque une fenêtre, et détruits lorsqu'ils ne concernent plus aucune fenêtre. Ce comportement est reproductible avec awesome, paraît-il.

      Pour attribuer un tag à une application lors de son lancement, il y a ce qu'il faut dans le fichier de configuration par défaut… Enfin, c'est codé en C, mais de façon à être accessible en Lua.
    • [^] # Re: Xmonad et awesome.

      Posté par . Évalué à 1.

      Alors, pour les tags, c'est possible de les assigner au démarrage :
      myManageHook = composeAll [ className =? "Claws-mail" --> doF (W.shift "2:mail")]
      (Le className se trouve avec xprop)

      Et avec XMonad.Actions.CopyWindow on peut duppliquer une fenêtre sur plusieurs tags.
      Après, les tags dynamiques, faut voir du côté de XMonad.Actions.DynamicWorkspaces, je crois.
      • [^] # Re: Xmonad et awesome.

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

        Dans ton exemple, tu ne fais que déplacer la fenêtre dans le workspace au doux nom "mail".
        Je le fais aussi. Ce que j'aimerai, c'est de pouvoir aussi taguer la fenêtre (extension XMonad.Actions.TagWindows).

        Sinon, pour déplacer la fenêtre, au lieu de
        doF (W.shift "2:mail")
        tu peux écrire aussi :
        doShift "mail"
  • # Pas mal

    Posté par . Évalué à 1.

    Bien que compiler cette bestiole sur une slackware est loin d'être aisé, j'y suis parvenu (preveu que je voulais vriament le tester).

    J'ai testé et ... pas convaincu que ce WM soit mieux ou moins bien que la concurrence (ion, dwm stumpwm, clfswm, xmonad etc.).

    J'aimerais vraiment qu'on me donne l'argument massue qui va bien parce que pour le moment, c'est tout ce qu'il y a de plus classique pour moi.

    Autre chose, est-ce qu'il y a de vrais exemples d'extensions Lua pour awesome (autre que les bind de touches ou les appels a mpd) ?

    Perso, je ne troquerais pas mon CLFSWM pour awesome qui est certes, un bon WM, mais qui n'apporte rien de plus que les concurrents n'ont deja.

    Je vais rester avec awesome pour les prochaines semaines (je n'ai rien d'autre pour le moment ;)), peut-être que je vais m'y faire.
    • [^] # Re: Pas mal

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

      Oui il y a eminent (tag dynamique) et wicked (gestion des widgets genre CPU, etc).

      C'est sur le wiki.
      • [^] # Re: Pas mal

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

        Ah oui est j'ai oublie de dire: tu peux aussi utiliser n'importe quel lib Lua.

        i.e. fait un tour sur Luaforge et tu peux utiliser n'importe quoi, donc tu peux controler awesome via un serveur web en Lua par exemple. ;)

Suivre le flux des commentaires

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