May 2009 - xmonad - Haskell.org

Window manager replacement (--replace flag)
by Jan Vornberger 02 May '09

02 May '09

Hi there! I have looked a little bit into enabling XMonad to replace an existing window manager when starting. I think it's a useful feature to help a new user to try out the window manager (e.g. from a running Gnome-Session with Metacity). I also found a corresponding 'issue' on the bug tracker (http://code.google.com/p/xmonad/issues/detail?id=99) which however has been closed as 'WontFix'. I have a rough version of the feature ready, which is good enough for my needs for now. It's not in a shape to go into the repository though, I'm only posting this here in case someone wants to continue working on it and for reference. The current version of the patch is attached. It's also available at my repository (http://tuvok.home.dyndns.org/xmonad-dev/xmonad/) I had a look at http://tronche.com/gui/x/icccm/sec-2.html#s-2.8 for reference, but mostly followed the code of other window managers. Namely XFWM4, Compiz and Metacity. If someone wants to look into it, here are the relevant parts: apt-get source xfwm4 -> edit screen.c -> search for myScreenSetWMAtom apt-get source compiz -> edit display.c -> search for replaceCurrentWm apt-get source metacity -> core/screen.c -> search for replace_current_wm My code does not everything these window managers do for this feature. The steps that I have skipped out of laziness and/or limited understanding of X11 programming, are marked with 'SKIPPED' in the code. Basically my code right now always replaces an existing window manager and assumes that everything goes fine. One other thing I noticed: While XMonad can now replace other window managers, it doesn't allow itself to be replaced in this manner. I haven't looked into it further, but we would need to play nice and terminate when we see another WM trying to take over. Things to do: - implement 'SKIPPED' parts - add '--replace' flag and only replace when the user specifies this flag - allow replacement of XMonad by another WM As I said, I have paused working on this feature for now. If anyone wants to have a shot at it, feel free to do so! :-) Cheers! Jan

1 0

darcs patch: Config.hs, Operations.hs: +unfloat, unfloatFocused fun...
by gwern0＠gmail.com 02 May '09

02 May '09

Sat May 2 14:26:31 EDT 2009 gwern0(a)gmail.com * Config.hs, Operations.hs: +unfloat, unfloatFocused functions 'unfloat' is the obvious inverse of the existing 'float' function, and so makes the API a little more rational. 'unfloatFocused' is easy once you have unfloat, and more importantly, is defined in >20 user configs; so obviously there's a need!

4 4

Recompiling on reinstallation
by Gwern Branwen 01 May '09

01 May '09

Don today in #xmonad linked http://braindump.dk/tech/2009/05/01/xmonad-upgrade/ The problem seems to be that the custom xmonad binary was not being recompiled even when XMonad was upgraded/reinstalled. Fortunately, I had seen a Yi technique which asked Cabal for the installed binary's patch; then it could get the last-modified times of the installed binary & the custom binary, and force a recompile if the former was newer than the latter. I coded this up for xmonad-core, but whenever I try it out, I get link errors. This is not the first time I've seen such errors, so I do not know whether my patch is flawed or my setup. If anyone wants to try it themselves and perhaps fix it, I'm attaching it. The changes: hunk ./XMonad/Core.hs 55 +import System.FilePath.Posix ((</>)) hunk ./XMonad/Core.hs 60 +import Paths_xmonad (getBinDir) + hunk ./XMonad/Core.hs 399 +-- * the installed xmonad executable is more recent than the custom xmonad +-- hunk ./XMonad/Core.hs 408 --- hunk ./XMonad/Core.hs 411 + cabalBinDir <- getBinDir + let cabalBin = cabalBinDir </> "xmonad" + cabalBinT <- getModTime cabalBin hunk ./XMonad/Core.hs 421 - if (force || srcT > binT) + if (force || srcT > binT || cabalBinT > binT) hunk ./XMonad/Main.hsc 43 + + hunk ./XMonad/Main.hsc 124 - + -- have recompile check for a stale custom binary + recompile False hunk ./xmonad.cabal 44 - build-depends: base < 4 && >=3, containers, directory, process + build-depends: base < 4 && >=3, containers, directory, process, filepath -- gwern

1 0