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

• # flattant le pavant

  Posté par rdhlnn le 25 janvier 2016 à 23:01. É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 bobo38 le 26 janvier 2016 à 00:41. Évalué à 1.

    

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

    • [^] # Re: flattant le pavant

      Posté par Lutin le 27 janvier 2016 à 17:23. Évalué à 2.

      

      Dans le même esprit il y a http://dotshare.it/

  • [^] # Re: flattant le pavant

    Posté par bobo38 le 26 janvier 2016 à 11:11. É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 freem le 26 janvier 2016 à 22:30. É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 bobo38 le 27 janvier 2016 à 08:14. É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 freem le 31 janvier 2016 à 02:32. É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 bobo38 le 31 janvier 2016 à 22:13. Évalué à 1. Dernière modification le 31 janvier 2016 à 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 freem le 09 février 2016 à 01:42. É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 barmic le 26 janvier 2016 à 07:11. É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 bobo38 le 26 janvier 2016 à 11:06. É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 freem le 26 janvier 2016 à 22:33. É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 bobo38 le 26 janvier 2016 à 23:31. É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 freem le 26 janvier 2016 à 23:44. É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 freem le 26 janvier 2016 à 23:37. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.