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

Hi Adam, I split out the program in the comment into a separate client module. I have tried to make it friendly for both developers and users. Thanks for the help, Peter On 12/19/13 14:03, adam vogt wrote:

Hi Peter,

For #1, the trick is that when /usr/bin/xmonad calls ~/.xmonad/xmonad-$arch-$os, the latter can access environment variables (System.Environment.getEnv / getEnvironment). Actually I made a mistake and the syntax is the slightly uglier:

CMD=1 xmonad

Then the xmonad.hs can contain something like:

main = do e <- getEnvironment case lookup "CMD" e of Just n -> print n -- or whatever the sendCommand does _ -> xmonad theNormalConfig

The code above could be hidden in another function: xmonadServerMode :: XConfig layout -> IO ())

We kind of discussed this earlier: http://www.haskell.org/pipermail/xmonad/2013-August/013814.html.

For #2, the idea is: ghc -e 'anything allowed in ghci' -e 'a second line you type into ghci'

Then somebody just makes this definition for their shell:

function xmonadCtrl () { ghc -e 'let main = XMonad.Hooks.ServerMode.exampleMain' -e ":main $*" } # Brandon probably has some portability suggestions?

Or they could compile a very simple file:

import XMonad.Hooks.ServerMode; main = exampleMain

Or we could add an `executable xmonadcmd' section to the .cabal file... as in the commented-out bit of http://hackage.haskell.org/package/xmonad-extras-0.12/xmonad-extras.cabal. I prefer the the other three options, since an xmonadcmd binary included by default incorrectly suggests that the feature is supported by out-of-the-box.

Hope this helps.

Adam

On Thu, Dec 19, 2013 at 1:56 PM, Peter Olson wrote:

...

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