Re: [xmonad] servermode patch for xmonad-contrib

Yeah, I agree with you. I started thinking about that after submitting the patch. I was modeling it after the version that was already there (which wasn't that great, hence why I rewrote it). At the very least, I intend to have the "sendCommand" function, and maybe the "sendAll" function in the main module, instead of in the comments, which would allow any Haskell application to very easily talk to xmonad. I think that option #1 is a good idea. How would that work, since it would require the same binary to either start the window manager or send the command to the running instance of xmonad. I'm guessing that looking at the code for xmonad --restart and xmonad --recompile would help with this? I'm not really sure what option 2 entails, since I am not very familiar with ghc/cabal. Thanks for the advice, Peter On 12/19/2013 12:24 PM, adam vogt wrote:

Hi Peter,

I applied your patch.

Having substantial code in the comments is not very convenient, since then people have to copy-paste to run it even if there is no customization. But that's how it was before you make changes. Furthermore there's no guarantee that it can compile. There are a couple options I think are better than the current situation:

1. have a (xmonadServerMode :: XConfig layout -> IO ()) which picks up on environment variables, so I think you could then send commands like:

xmonad DO_SOMETHING=parameter

2. export a XMonad.Hooks.ServerMode.main, which is the same as the example code:

runghc -e XMonad.Hooks.ServerMode.main -a ...

3. something else

Regards, Adam

On Sun, Dec 15, 2013 at 11:34 PM, Peter Olson wrote:

...

Some stuff that I have been working on to generalize XMonad.Hooks.ServerMode so that it will be more useful. This is my first time contributing to an open-source project, so sorry if I made any obvious mistakes.

Peter Olson

_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad