Patch: improved support for replacing an existing window manager

Hi there! First patch from Bluetile's repository for consideration to go into xmonad mainline. This is the original patch (see http://osdir.com/ml/xmonad@haskell.org/2009-05/msg00010.html) plus two more patches, which * make this take effect only if the '--replace' flag is given * add a config option 'alwaysReplace' to override the --replace flag Best regards! Jan

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)
Mon Oct 12 01:23:06 EDT 2009 Adam Vogt
Hi there!
First patch from Bluetile's repository for consideration to go into xmonad mainline. This is the original patch (see http://osdir.com/ml/xmonad@haskell.org/2009-05/msg00010.html) plus two more patches, which
* make this take effect only if the '--replace' flag is given * add a config option 'alwaysReplace' to override the --replace flag
Best regards!
Jan
Sat Apr 18 00:25:09 CEST 2009 Jan Vornberger
* half-implemented support for replacing an existing window manager Thu Sep 17 20:47:14 CEST 2009 Jan Vornberger
* Only replace existing window manager when given '--replace' flag Thu Sep 17 20:56:56 CEST 2009 Jan Vornberger
* Add config option 'alwaysReplace' to replace window managers regardless off --replace flag

Adam Vogt
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?

2009/10/12 Justin Bogner
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?
Let it pass ignored, and then create a contrib module that complains if it doesn't have any handlers for a particular option flag. Then encourage people to use it, just like certain modules are highly encourage like EWMH for desktop environments. Just my 0.02 EUR. -Yaakov Nemoy

* 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
participants (4)
-
Adam Vogt
-
Jan Vornberger
-
Justin Bogner
-
Yaakov Nemoy