Journal dwm-custom v0.1 : faciliter l'installation et la personalisation de dwm dans le home utilisateur

Posté par . Licence CC by-sa
Tags :
18
25
jan.
2016

Sommaire

dwm-custom permet de faciliter la mise en place de dwm dans le /home de l'utilisateur. Je viens de publier la version 0.1, disponible dans AUR pour les utilisateurs d'Archlinux. Ce journal se propose d'en expliquer le fonctionnement, après une petite introduction du gestionnaire de fenêtre dwm, de ses charmes et de ses particularités.

dwm et raison d'être de dwm-custom

Présentation de dwm

dwm est un gestionnaire de fenêtre minimaliste en tiling. Il gère néanmoins les fenêtres flottantes également. Il est écrit en 2000 lignes de code avec pour uniques dépendances le serveur graphique X, make et gcc pour la compilation. Ce projet utilise aussi dmenu pour lancer les applications façon Alt-F2 avec une esthétique dépouillée, et une liste de choix navigabele : exit le menu « Démarrer » et ses clones|adaptations ! D'après Wikipedia, ce projet a eu une influence certaine sur d'autres tiling Window Managers.

Approche ludique

Du fait des choix de programmation, pas d'interface graphique de configuration, ni même de fichier de configuration en texte. Pour configurer/personnaliser dwm, il est nécessaire de modifier le code et de recompiler. Rien de bien compliqué, basiquement un make, avec une durée de compilation de l'ordre de la seconde. Une approche est un brin élitiste et intimidante de prime abord. À titre d'exemple la philosophie du groupe de devs ou une des différences clamées sur la page du projet

Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.
source : la page officielle du projet

Cette approche a toutefois une véritable dimension ludique. Elle a le mérite de rendre concrètes les libertés logicielles, leur donnant une saveur particulière et inédite.

Liberté 1 : la liberté d'étudier le fonctionnement du programme et de l'adapter à ses besoins

La longueur et la structure du code source le rendent lisible et accessible à l'utilisateur. Les paramètres à modifier sont réunis dans un fichier à part, le restant du code étant dans unique fichier. Ça permet d'obtenir facilement une vision d'ensemble. L'utilisateur est d'ailleurs invité à trifouiller lui-même pour l'adapter à ses besoins, puisque la personnalisation passe par la modification du code et la recompilation.

Liberté 3 : la liberté d'améliorer le programme et de distribuer ces améliorations au public, pour en faire profiter toute la communauté

Il existe de nombreux patches proposés par la communauté, qui permettent de modifier le comportement de dwm si quelque chose venait à manquer. Ceux-ci permettent de modifier en profondeur le comportement du gestionnaire de fenêtre, et de pouvoir en étudier le code. Le concept de patch permet en effet d'identifier le code ajouté/remplacé mais également quelle portion a été modifiée – ce qui rajoute un peu de liberté 1.

Dernier point noir

La traditionnelle approche du paquet binaire montre alors ses limites, comme cela a été pointé dans la citation plus haut. C'est pourquoi dwm-custom a été créé. Ce projet vise à faciliter la compilation personnalisée dans le $HOME de l'utilisateur.

dwm-custom, comment ça fonctionne ?

dwm-custom-build, le cœur de dwm-custom

dwm-custom propose un script bash nommé dwm-custom-build dont voici les grands étapes :
* créer un répertoire de configuration ~/.config/dwm-custom/\<VERSION\> où les sources sont téléchargées ainsi qu'une infrastructure de personnalisation
* appliquer de patches
* compiler dans /tmp/dwm-custom-build
* vérifier que la compilation s'est bien déroulée
* copier le binaire compilé dans ~/bin

Le script fournit aussi des conseils|trucs|astuces pour la configuration quant à la personnalisation avec le fichier config.h, l'application de patches et la modification de .xinitrc. Il détecte également les problèmes d'application de patches et de compilation, donnant comme indication les premiers réflexes à avoir pour résoudre les soucis rencontrés.

Configuration de dwm

Les sources de dwm sont composées de plusieurs fichiers :
config.h, variables pour l'apparence générale, les raccourcis clavier, le comportement des fenêtres, etc…
dwm.c, cœur du code
Makefile qui permet de lancer la compilation

Les deux façons « faciles » de configurer dwm sont :
* modifier les variables existantes dans le fichier config.h
* appliquer des patches existants pour ajouter des fonctionnalités

Configuration personnalisée avec dwm-custom-build

Ceci se traduit par le dossier ~/.config/dwm-custom/\<VERSION\> dont le contenu typique est :
— le .tar.gz des sources de la version <VERSION>
— le config.h qui sera copié avant la compilation
— un dossier patches dans lequel mettre les patches qu'on voudra

La configuration dans ~/.config/dwm-custom/\<VERSION\> en éditant config.h et en faisant des liens vers les patches téléchargés (la seule contrainte étant que les liens soient nommés \<quelque chose\>.diff. En cas de problème, l'ordre d'application des patches peut être modifié en renommant les liens, l'ordre d'application étant fourni pas la commande ls.

Utilisation avec X

Avoir un binaire dans le $HOME utilisateur c'est bien, pouvoir l'utiliser pour une session X c'est mieux. dwm-custom-build sensibilise sur la configuration de ~/.xinitrc pour pouvoir utiliser le dwm customisé en lançant X via startx. Cela ne couvre toutefois pas tous les usages.

Pour les utilisateurs de display managers (gdm, kdm, slim, lightdm, etc…), un .desktop est fourni pour être mis le répertoire adéquat (/usr/share/xsessions pour Archlinux). Il lance le binaire $HOME/bin/dwm au travers du script dwm-custom-session, libre adaptation des méthodes d'openbox (le paquet AUR xinit-session m'a mis sur la voie). Il sera alors possible de sélectionner « dwm-custom » dans les bureaux disponibles à l'ouverture de session utilisateur.

Cas d'utilisation

Comme il s'agit d'un script bash et de fichiers texte, tout ceci devrait être théoriquement portable sur n'importe quel système d'exploitation utilisant X.

Il s'adresse également aux personnes qui n'auraient pas les droits administrateur sur leur machine : la compilation se passe en espace utilisateur. J'ai pu faire celà au travail en 2014 sur une RedHat 5.4 pour pouvoir l'utiliser via NX client 3 (les autres alternatives m'interdisant d'utiliser BÉPO avec bugs à la saisie de caractères spéciaux). Le seul soucis reste alors de lancer la session X avec le dwm personnalisé dans le cas d'un display manager. Les 2 fichiers dwm-custom.desktop et dwm-custom-session, pourront sans doute inspirer des gens dans la recherche de contournement…

Conclusion

J'espère vous avoir donné envie de tester dwm, avec ou sans dwm-custom, et de faire un peu de bricolage logiciel. Il s'agit de ma première contribution au libre, de ma première publication de paquet et de mon premier journal sur LinuxFR.org. Ce petit hack m'aura permis d'apprendre pas mal de choses, que j'espère avoir bien synthétisées ici.

Pour les curieux, le site suckless.org recense tous les projets affiliés. À titre perso j'adore slock, un verrouilleur d'écran mono-utilisateur à l'interface très sobre. Il y a moyen de faire des trouvailles… et d'être étonné|surpris.

Tout retour sur dwm-custom est le bienvenu, notamment des suggestions d'améliorations. J'ai essayé de faire en sorte que le code soit lisible (de toute façon je ne connais pas assez de bashismes) sans toutefois adopter un style « suckless » ;-)

Liens relatifs au sujet

Les pages git du projet

Communications existantes à propos du projet

Pages pertinentes à propos de dwm

  • # flattant le pavant

    Posté par . Évalué à 2.

    … Oui, pas très bon, passons…

    Sympa ce projet, ça me donne envie de tester à nouveau dwm. Ah… Je sens que je vais perdre du temps (avec bonheur). Surtout que c'était cette nécessité de recompiler pour chaque test de config' qui était un peu ennuyeuse. Même si en soi, ce projet est superbe par sa simplicité (comme de nombreux projets suckless en effet, tu peux citer aussi st).

    Ces temps, j'ai jeté mon dévolu sur bspwm, qui marche parfaitement. Même si la simplicité de dwm et le côté "haskell" de xmonad continuent de m'attirer.

    Tu devrais communiquer ton projet (si ce n'est déjà fait) à la communauté r/unixporn, des fans inconditionnels de la bidouille de WM en tout genre.

    Il y a d'ailleurs dans ce délire un peu minimaliste pas mal de gars de cette communauté qui participent à wmutils, ça peut en intéresser peut-être certains (pour des illustrations, vous pouvez jeter un coup d'oeil sur unixporn).

    Mes deux sous.

    • [^] # Re: flattant le pavant

      Posté par . Évalué à 1.

      Le concept de « unixporn » est tout de même très fort !

    • [^] # Re: flattant le pavant

      Posté par . Évalué à 1.

      Oui st (simple terminal) c'est pas mal du tout. Après un peu moins d'un an de st, j'ai tout de même changé pour urxvt (auquel j'ai appliqué un look st). Leur page vaut le coup à la lecture, surtout le passage « what's wrong with xterm ? » :D

      Le réécriture des outils UNIX est aussi intrigante : http://tools.suckless.org/9base

      • [^] # Re: flattant le pavant

        Posté par . Évalué à 4.

        Qu'est-ce qui t'as fait passer de st à urxvt?

        Perso, j'utilise aussi urxvt, en mode daemon/client, mais je n'ai jamais vraiment testé st, alors si tu pouvais me dire les pros/cons, je t'en serais reconnaissant.

        Une install rapide via apt (je suppose que c'est le bon paquet: stterm. Aussi, install via binaire, donc, pas de compilation, ce qui est contraire à la philo suckless, je sais) me montre juste une chose: juste après l'install, lancer stterm (le nom du binaire de ce paquet) montre un blanc dans mon prompt (le 1er char s'affiche, puis rien jusqu'à l'@). Après un changement de workspace, impossible de reproduire l'affichage (est-ce la faute d'i3, mon wm?).
        Pour le reste ça à l'air normal (bon à part que le .Xdefault n'est pas pris en compte, mais ça je m'y attendais).

        Le réécriture des outils UNIX est aussi intrigante : http://tools.suckless.org/9base

        Ça, ça ne me surprend pas. Dis-toi que /usr/bin/yes prend 27K sur mon système, par exemple. Je comprend qu'ils n'aiment pas trop les outils UNIX version GNU, franchement. À un moment, avec un collègue, on avait regardé les codes sources de certains outils de base fournis par diverses sources: GNU, netBSD, freeBSD et openBSD. La différence était assez flagrante en terme de nombre de lignes (en enlevant les blancs, commentaires et en mettant un style d'indentation identique) et de style de manière générale. Franchement, le GNU c'est assez lourd et blindé de trucs dont l'intérêt nous avais paru très peu clairs. En fonction de la personne (lui ou moi) on préférait les versions openBSD ou netBSD, puis freeBSD, puis GNU.
        Par contre, on avait pas regardé les implém de suckless, ça pourrais être intéressant. Après tout, ce genre d'outils s'adapte très bien à la philo de suckless.

        • [^] # Re: flattant le pavant

          Posté par . Évalué à 1.

          Pour le passage de st à urxvt, je ne me souviens plus trop à part le scroll pour remonter dans l'affichage (notamment pour des mises à jours) et des raccourcis claviers qui mettaient un temps très long à déclencher des actions avec mon ~/.vimrc (j'ai du Shift-F2 qui a des comportements différents selon les émulateurs de terminal). Il me semble que je rêvais aussi d'onglets, ajoutables à urxvt.

          [mavie]Lors de la manœurvre, j'ai eu des soucis avec l'outil de configuration de history-search avec bash et wifi-menu (de netctl), mais c'était avec urxvt : https://forums.archlinux.fr/viewtopic.php?f=5&t=17062, et lié à l'utilisation d'une ligne de code ajoutée à mon ~/.bashrc pour st qui passait mal. Je le mentionne parce que ça peut aider.[/mavie]

          Je me suis lancé avec st au même moment que je l'ai fait pour dwm. J'ai arrêté après un peu moins d'1 an. Ceci-dit, avec l'école dwm on finit par comprendre comment ça fonctionne. Du coup j'ai retrouvé mes petits dans le .Xressources/.Xdefaults (chose que je n'avais pas faite 2 ans auparavant, malgré un netbook asthmatique qui peinait à ouvrir des nouveaux terminaux). J'ai aussi finalement réussi à abandonner les onglets.

          • [^] # Re: flattant le pavant

            Posté par . Évalué à 3.

            à part le scroll pour remonter dans l'affichage

            Ah en effet, le scroll c'est bien confortable quand même. Tu cites les MàJ, je citerai la sortie du grep fait il y à 20s.

            j'ai du Shift-F2 qui a des comportements différents selon les émulateurs de terminal

            Ça ne fait rien ici, avec rxvt-unicode-lite (paquet debian avec, je cite: «la version minimale du programme, avec seulement quelques fonctionnalités supplémentaires et pas de gestion de Freetype»).

            Ceci-dit, avec l'école dwm on finit par comprendre comment ça fonctionne. […] J'ai aussi finalement réussi à abandonner les onglets.

            Je crois que ce sont des choses que l'on doit de manière plus générale aux WM en tuile, ou plutôt à la personnalité de ceux qui les utilisent et les font.

            Perso, j'ai perdu assez de temps avec des applications supportant les onglets qui font perdre le travail de la totalité des onglets en cas de crash, pour chercher celles qui ne supportent pas les onglets (more is less) tout en gardant un niveau d'utilisabilité correct (que les projets suckless ont tendance à ne pas garder, selon mon point de vue).
            Et quand j'ai goûté aux tuiles… j'ai compris à quel point je perdais mon temps avant. En plus, ça fait fuir les curieux un écran blindé de rectangles noirs eux-même remplis de lignes de texte incompréhensible et sans icônes. Cette feature est intéressante aussi à sa manière :)

            Sinon, pour urxvt, tu l'utilises en mode client-serveur, ou en standalone? (pure curiosité)

            • [^] # Re: flattant le pavant

              Posté par . Évalué à 1. Dernière modification le 31/01/16 à 22:15.

              En mode client/serveur bien sûr ! C'est la seule façon d'avoir des temps d'ouverture d'émulateur de terminal raisonnables sur mon netbook (ça m'agace quand ça ne paraît pas instantané :D et j'aime bien avoir la même config sur mon PC fixe et sur le netbook).

              st se chargeait hyper-vite aussi

              Pour le scroll, j'avais l'habitude de faire des pipes vers less… mais ça bouffait la couleur. Ça ne s'applique pas au grep fait 20 secondes avant. Du coup dans ces cas, c'était 2 émulateurs, un avec « grep […] | less » et l'autre pour faire qqch à partir de là. Ce bricolage !

              • [^] # Re: flattant le pavant

                Posté par . Évalué à 2.

                Pour la couleur avec grep | less, apprécies donc ceci: grep --color=force 'include' /usr/include/pcre.h | less -R.
                Malheureusement, on est obligé de forcer la couleur de grep, en auto il ne teste pas (le peut-il? J'en doute) si la sortie est balancée dans un pager donc ça reste assez brutal, mais quand on parse des logs c'est sympa l'astuce du less -R.

  • # Ramassage de cerises

    Posté par . Évalué à 5.

    Une idée d'évolution de ton outil serait d'utiliser un DCVS. C'est justement fait pour gérer des match tu peux choisir l'ordre des patchs, taguer chaque build pour pouvoir y revenir,… Tu peux même créer un dépôt sur internet pour faire un matket de patchs (sans pour autant empêcher d'ajouter ceux que l'utilisateur veux).

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

    • [^] # Re: Ramassage de cerises

      Posté par . Évalué à 2.

      yep j'ai pensé à ça pour une future évolution : avoir une sorte de dépôt de patches (à base de git certainement)… Je ne suis pas suffisamment à l'aise avec git ça pour le moment. Ce serait aussi un passage obligé pour aboutir à une interface ncurses pour sélectionner des patches à appliquer.

      Le gros soucis que je vois, c'est de conserver une simplicité, sans trahir l'approche. Je viens de m'apercevoir qu'il n'est pas évident de comprendre comment tout ça fonctionne, avec le premier utilisateur qui n'a pas compris comment faire après l'install du paquet AUR (pour lui ça devait fonctionner out of the box). Il va falloir bosser sur l'intégration : le fait que l'entrée "dwm-custom.desktop" me fasse rien si le binaire n'est pas trouvé c'est pourri (il va falloir que je bricole un truc qui donne des consignes pour lancer dwm-custom-build…)

      • [^] # Re: Ramassage de cerises

        Posté par . Évalué à 3.

        le fait que l'entrée "dwm-custom.desktop" me fasse rien si le binaire n'est pas trouvé c'est pourri (il va falloir que je bricole un truc qui donne des consignes pour lancer dwm-custom-build…)

        Il doit bien y avoir une application qui juste lance une fenêtre X que tu pourrais lancer pour mettre un warn (une fenêtre X, parce que sinon en cas de lancement par dmenu ou raccourcis clavier, ben pas de retour… c'est un problème qu'il m'arrive d'avoir avec i3)?

        • [^] # Re: Ramassage de cerises

          Posté par . Évalué à 1.

          C'est ma piste… Il me semble que c'est possible de lancer juste un logiciel sans WM via X. Il faut que je rassemble mes souvenirs, et cherche un peu sur le web.

          Mon plan initial était de lancer un terminal avec pour message de faire une compilation maison. Une autre alternative serait de compiler le tout si le binaire n'est pas trouvé. Ça risque de piquer pour les claviers AZERTY ou les émulateurs de terminal (quitte à appliquer le patche keycode pour le tout-terrain clavier, choisir un émulateur de terminal facile, appliquer le patche autostart et bidouiller un truc pour afficher un message d'info). Il est aussi envisageable de compilé un binaire de secours (compilé avec dwm-custom-build) lors de la création du paquet AUR; ça pourrait même être malin pour proposer un exemple.

          • [^] # Re: Ramassage de cerises

            Posté par . Évalué à 2.

            Ah, j'ai retrouvé le nom qui me trottait en tête, par contre c'est pas du gtk, mais du curses: $ whiptail --msgbox "mouhahahaha j'suis pas là!" 7 30. Je crois qu'il y a aussi un truc gtk, mais avec du curses, tu peux toujours tester si tu es sous un serveur graphique (X11 ou wayland) et afficher un nouveau terminal dans ce cas, qui n'exécuterais que cette commande. En TTY, juste balancer la commande.

  • # if( patchs & automatisme == maintenance_galere) return TRUE;

    Posté par . Évalué à 7.

    Il me semble que les patchs produits par diff nécessitent un minimum de points communs, notamment que la portion de code ciblée par le patch soit la même que celle référencée dans le patch, et placée au même endroit (il y à des numéros de ligne, ça dois pas être pour rien, quand même?).

    Du coup, le cumul de patches pour rendre un fichier source unique me semble proche du supplice de Sisyphe.
    Je suis à peu près sûr qu'il est plus simple de juste forker et de faire des pull réguliers. Bien sûr, si les fonctions étaient chacune dans un fichier différent, les choses seraient plus aisées, et puis, ça éviterais de devoir se faire chier à fouiller dans plus de 2000 lignes de code C où est la fonction ou structure intéressante quand on veut bidouiller un peu.

    J'espère vous avoir donné envie de tester dwm, avec ou sans dwm-custom,

    Non, parce que je ne vois pas l'intérêt par rapport à celui que j'ai adopté, à savoir i3. Pour être moins crû, je trouve que ton journal n'explique pas vraiment l'intérêt des WM en tuile et/ou minimalistes (typiquement et dans l'ordre: pilotage complet et rapide au clavier des fenêtres et utilisation de machines à faible perf).
    Tu t'es beaucoup concentré sur l'aspect configuration par la compilation, qui est, à mon avis, l'un des gros problèmes des logiciels interactifs produits par les gens de suckless (chacun ses goûts après, et malgré ma différence d'opinion j'ai un grand respect pour suckless.org), et tu n'as mis pour seul argument en faveur de dwm que le fait que selon toi cette approche minimaliste favorise le hack. D'ailleurs, perso, le style de codage de dwm:

    Monitor *
    dirtomon(int dir)
    {
        Monitor *m = NULL;
    
        if (dir > 0) {
            if (!(m = selmon->next))
                m = mons;
        } else if (selmon == mons)
            for (m = mons; m->next; m = m->next);
        else
            for (m = mons; m->next != selmon; m = m->next);
        return m;
    }

    Me fait plus dire que ça favorise le risque de planter à la moindre faute de frappe. Le bout de code que je viens de montrer (ligne 694) montre que la convention de codage mélange allègrement les blocs avec et sans accolades. Du coup, un malencontreux retour chariot au mauvais endroit, et on augmente le risque d'insérer un bug sans retour visuel (en lisant le code source). Par exemple, ajouter une ligne indentée sur le m = mons; fera croire à un lecteur inattentif qu'elle sera exécutée dans le if, ce qui ne sera pas le cas.
    Dans la même veine, il y a des macros qui pourraient en C moderne être remplacées par des fonctions inline, parce que les macros c'est un truc qui à tendance à attirer des bugs bien pénibles à corriger, que le compilateur ne pourra vérifier que difficilement.
    Bien sûr, on peut juste faire attention quand on programme. Mais moi, je suis partisan de m'appuyer sur des outils pour être sûr de ne pas introduire de bugs, surtout quand il s'agit d'un outil aussi central à mon usage qu'un gestionnaire de fenêtres.

    Puis, franchement, une config, ça se parse une fois au lancement, et un fichier de config INI-style est bien plus simple à modifier qu'un header C, qui respecte des règle de syntaxe autrement plus complexes (macros, p.e.).
    Bien sûr, un fichier de config il faut le parser à chaque démarrage, ça prend du temps CPU et un poil de RAM (de l'ordre de quelques Kio, peut-être?) et c'est un argument recevable… tout dépend du degré de confort vs ré-utilisabilité/performance que l'on souhaite.

    Il s'agit de ma première contribution au libre, de ma première publication de paquet et de mon premier journal sur LinuxFR.org.

    Bon courage pour la suite et au plaisir de te relire :)
    Je suis un peu critique sur dwm, mais uniquement parce que je les trouve un peu trop extrémistes sur certains cas.
    En réalité, j'ai beaucoup de respect pour leur philosophie, et lire leurs opinion m'à mené à des recherches plutôt intéressantes, même si mes opinions ne concordent pas nécessairement avec les leurs.
    Je me suis déjà dis à plusieurs reprise qu'il faudrait un site type, suckmore, qui référencerait des projets un peu moins extrêmes que ceux de suckless tout en restait hyper-spécialisés…

Suivre le flux des commentaires

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