Réapparition nette de xmobar lors du rechargement de xmonad


9

C'est juste une petite gêne, mais j'ai fait charger le fichier de configuration XMonad xmobar en utilisant ce code:

xmproc <- spawnPipe "/use/bin/xmobar ~/.xmobarrc"

Cela fonctionne bien, mais il engendre un nouveau processus xmobar à chaque fois que XMonad est rechargé. Je me demande s'il y a un moyen facile de tuer l'ancien?

mise à jour : comme suggéré par entropo, j'ai créé un script bash comme celui-ci:

#!/bin/bash

for PID in `pgrep xmobar`; do
    kill ${PID} > /dev/null &
done

/usr/bin/xmobar &

et appelez ce script à partir du fichier de configuration XMonad.

Réponses:



16

Si vous avez un script shell pour démarrer XMobar, vous vous trompez. Vous devez démarrer xmobar en utilisant les fonctions Haskell correctes dans le fichier source de configuration xmonad.hs. Jetez un oeil à ma fonction principale de configs:

-- put it all together
main = do
    nScreens <- countScreens    -- just in case you are on a laptop like me count the screens so that you can go
    xmonad =<< xmobar myBaseConfig
      { modMask = myModMask
      , workspaces = withScreens nScreens myWorkspaces
      , layoutHook = myLayoutHook nScreens
      , manageHook = myManageHook
      , borderWidth = myBorderWidth
      , normalBorderColor = myNormalBorderColor
      , focusedBorderColor = myFocusedBorderColor
      , keys = myKeys
      , mouseBindings = myMouseBindings
      , logHook = myLogHook
      }
    where
        myLogHook = dynamicLogXinerama

myBaseConfig = gnomeConfig

La ligne saillante est celle-ci:

xmonad =<< xmobar myBaseConfig

Cela exécute xmobar comme il se doit, même lorsque vous rechargez xmonad. Vous obtenez la fonction 'xmobar' de l'instruction:

import XMonad.Hooks.DynamicLog (xmobar)

Qui à son tour provient du paquet xmonad-contrib .

Donc vous voyez, la plupart des choses que vous voulez faire avec XMonad sont déjà un problème résolu, il vous suffit de savoir où chercher. Fondamentalement, abandonnez simplement votre script et utilisez-le à la place. J'espère que ça aide.


2
Eh bien, j'ai trouvé le spawnPipecode sur le site XMonad, ce n'est vraiment pas facile de savoir où chercher! Mais au final, je préfère la technique que j'utilise car elle est plus propre, l'utilisation DynamicLogn'a pas tué l'ancien processus dans mes tests. J'aime vraiment XMonad, mais Haskell n'est pas un bon langage de configuration.
Nicolas Buduroi

1
D'accord, tout ce qui fonctionne pour vous est bon à la fin. Mais je pense que vous y pensez mal. Vous ne configurez pas XMonad: vous l'étendez. Haskell le préfet apte à l'extension.
Robert Massaioli du

Pour moi, cela crée 2 nouveaux processus chaque fois que je recharge xmonad. L'utilisation de spawnPipe crée 2 processus supplémentaires. ps -ax renvoie: "/ bin / sh -c /.cabal/bin/xmobar ~ / .xmobarrc:", "/ bin / sh -c xmobar", "~ / .cabal / bin / xmonad ~ / .xmobarrc" et "xmobar".
fsanches

La réinstallation des deux a résolu le problème dans ma recommandation ci-dessus.
fsanches

1
Je suis presque sûr que vous spawnPipebifurquerez un processus dans un nouveau thread. Si vous voulez spawnPipeplutôt créer un processus enfant (qui se ferme lorsque le processus principal le fait), je crains que vous n'ayez à écrire votre propre spawnPipefonction.
yyny
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.