[xmonad] servermode patch for xmonad-contrib

[adam vogt]

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 <polson2 at hawk.iit.edu> 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 <polson2 at hawk.iit.edu>
>> 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 at haskell.org
>>> http://www.haskell.org/mailman/listinfo/xmonad
>>>
>