Re: [xmonad] Re: Patch: improved support for replacing an existing window manager

12 Oct 2009

      * On Monday, October 12 2009, Justin Bogner wrote:
...
Adam Vogt  writes:
...
For reference, I've added to contrib the module XMonad.Util.Replace,
which seems to work as well as these core patches, other than the lack
of command line flag support (the xmonad binary does not pass flags
other than --resume to the ~/.xmonad/xmonad-$arch-$os).
Any suggestions for addressing that problem (or the alternative of
running `~/.xmonad/xmonad-$arch-$os --replace' instead of
/usr/bin/xmonad)
I've thought for quite a while that it would be convenient for xmonad to
pass any unknown flags on to ~/.xmonad/xmonad-$arch-$os, as that would
allow for a lot of nice flexibility.
The disadvantage, of course, is that unimplemented flags would probably
just be ignored, adding a whole new dimension of user errors.
What does everyone else think?
Perhaps a wrapper around the official Main.hs is a cleaner solution:

Those additional flags are passed passed to the xmonad-$arch-$os via an
environment variable, which isn't pretty, but it's more likely to
happen than than adding some kind of --additional-flags flag to core:

] #!/usr/bin/env runghc
] import System.Environment
] import System.Posix.Env (setEnv)
] import System.Process
] import Control.Applicative
] import Data.Maybe
] import Data.List
] 
] main = do
]     xmd <- mapMaybe (listToMaybe . words) . drop 2 . lines
]             <$> readProcess "xmonad" ["--help"] ""
]     x <- getArgs
]     setEnv "XMONAD_EXTRA_ARGS" (unwords $ x \\ xmd) True
]     rawSystem "xmonad" (x `intersect` xmd)

Then the xmonad.hs includes some argument checking on the string from
(getEnv "XMONAD_EXTRA_ARGS").

Some sanity checking is possible here too, either that the args in `x'
are sufficiently far away from the official flags, (by edit distance) or
a comparison against a manually compiled list of contrib flags. But
perhaps Yaakov's suggestion is best:

Using Daniel Schoepe's extensible state patch, we can store a key
containing those additional args, and after each startup hook reads
them, they are removed. A final startupHook complains if any arguments
have not been looked at. I'm not sure whether any more complexity is
necessary to handle flags with the restarts / recompilation that we do.

--
Adam