April 2012 - xmonad - Haskell.org

How set new floating window gets on top ?
by David Unric 29 Apr '12

29 Apr '12

Hi, even with manageHook set to manageHook of defaultConfig, all new floating windows created on workspace with simplestFloat or simpleFloat layouts recieve focus but are placed _bellow_ current windows which I find very frustrating. For example on empty simplestFloat workspace I launch xterm, then launch gvim. Gvim gets focus but appears behind xterm (bellow in window stack sense). Maybe I'm not smart enough but I can't find how to change this behaviour of floating layout. I'd simply need all new floating windows are placed on top of the stack. Any idea ? Thanks in an advance. David

2 1

Issue 495 in xmonad: XMonad.Util.Run.safeRunInTerm does not work correctly
by codesite-noreply＠google.com 28 Apr '12

28 Apr '12

Status: New Owner: ---- New issue 495 by woofy1...@gmail.com: XMonad.Util.Run.safeRunInTerm does not work correctly http://code.google.com/p/xmonad/issues/detail?id=495 What steps will reproduce the problem? 1. Add a keybinding such as ((myModMask, xK_a ), safeRunInTerm "" "alsamixer" ) 2. Recompile and press M-a What is the expected output? What do you see instead? Expected: an xterm window with alsamixer running in it. Actual: nothing, xterm silently dies ('xterm: bad command line option "-e"') What version of the product are you using? On what operating system? xmonad 0.10-2 and xmonad-contrib 0.10-1 on Arch Linux. Please provide any additional information below. The definition of safeRunInTerm is broken: safeRunInTerm :: String -> String -> X () safeRunInTerm options command = asks (terminal . config) >>= \t -> safeSpawn t [options, " -e " ++ command] In the example, 'safeRunInTerm "" "alsamixer"' will run 'safeSpawn xterm ["", " -e alsamixer"], which is not the format that xterm, urxvt nor lxterminal expect (I have not tested with other terminals). A possible fix would be a definition such as safeRunInTermP :: [String] -> [String] -> X () safeRunInTermP options command = asks (terminal . config) >>= \t -> safeSpawn t (options ++ ["-e"] ++ command) which gives the desired behaviour for 'safeRunInTerm [] ["alsamixer"]', and correctly allows the specification of multiple arguments to both the terminal and the program to be run, eg 'safeRunInTerm ["-fg","#ffff00"] ["alsamixer","-V","capture"]' works correctly. The Strings passed to safeRunInTerm could be broken up with 'words' for a back compatible wrapper.

1 1

X.H.FadeInactive: Better support for multi monitor setups
by Jesper Reenberg 25 Apr '12

25 Apr '12

Hi, I have added fadeInactiveCurrentWSLogHook which given a rationale fades all windows that are not active. However unlike fadeInactiveLogHook, then it only does it for the current active workspace which makes it much easier to read the content on the other screens. Most of the code is courtesy of Morten Brøns-Pedersen. This is my first official patch, hope it is done correctly. -- Reenberg

2 4

Rave reviews
by Gwern Branwen 24 Apr '12

24 Apr '12

Famous Internet personality Xah Lee has graced XMonad with one of his classic reviews: http://xahlee.org/linux/why_tiling_window_manager_sucks.html -- gwern http://www.gwern.net

5 5

[patch] Add emacs-like Keymap to XMonad.Prompt
by Carlos López Camey 22 Apr '12

22 Apr '12

Hello, please find attached the following patch. Feel free to change the function's name, in case the patch gets through that is. 1 patch for repository http://code.haskell.org/XMonadContrib: Sat Apr 21 03:10:55 CEST 2012 Carlos Lopez-Camey <c.lopez(a)kmels.net> * Add emacs-like Keymap in XMonad.Prompt Combination keys C-d, C-f, C-b, M-f, M-b, M-x, M-Backspace. It misses ESC-p and ESC-n, sometimes used to browse history, but it was not possible since xK_Escape isn't part of the enumeration KeyMask. New patches: [Add emacs-like Keymap in XMonad.Prompt Carlos Lopez-Camey <c.lopez(a)kmels.net>**20120421011055 Ignore-this: c268dd79b555ab5b89aacb916bca25bf ] { hunk ./XMonad/Prompt.hs 23 , mkXPromptWithReturn , amberXPConfig , defaultXPConfig + , emacsLikeXPKeymap , greenXPConfig , XPType (..) , XPPosition (..) hunk ./XMonad/Prompt.hs 445 , (xK_Escape, quit) ] +emacsLikeXPKeymap :: M.Map (KeyMask,KeySym) (XP ()) +emacsLikeXPKeymap = M.fromList $ + map (first $ (,) controlMask) -- control + <key> + [ (xK_u, killBefore) --kill line backwards + , (xK_k, killAfter) -- kill line fowards + , (xK_a, startOfLine) --move to the beginning of the line + , (xK_e, endOfLine) -- move to the end of the line + , (xK_d, deleteString Next) -- delete a character foward + , (xK_b, moveCursor Prev) -- move cursor forward + , (xK_f, moveCursor Next) -- move cursor backward + , (xK_y, pasteString) + , (xK_g, quit) + , (xK_bracketleft, quit) + ] ++ + map (first $ (,) mod1Mask) -- meta key + <key> + [ (xK_BackSpace, killWord Prev) + , (xK_f, moveWord Next) -- move a word forward + , (xK_b, moveWord Prev) -- move a word backward + , (xK_d, killWord Next) -- kill the next word + , (xK_BackSpace, killWord Prev) -- kill the previous word + ] + ++ + map (first $ (,) 0) -- <key> + [ (xK_Return, setSuccess True >> setDone True) + , (xK_KP_Enter, setSuccess True >> setDone True) + , (xK_BackSpace, deleteString Prev) + , (xK_Delete, deleteString Next) + , (xK_Left, moveCursor Prev) + , (xK_Right, moveCursor Next) + , (xK_Home, startOfLine) + , (xK_End, endOfLine) + , (xK_Down, moveHistory W.focusUp') + , (xK_Up, moveHistory W.focusDown') + , (xK_Escape, quit) + ] + keyPressHandle :: KeyMask -> KeyStroke -> XP () keyPressHandle m (ks,str) = do km <- gets (promptKeymap . config) } Context: [add 'withNthWorkspace' to DynamicWorkspaceOrder. jakob@pipefour.org**20120407184640 Ignore-this: f5f87ffe9ddf1a12fab775e6fb8e856f Note this is very similar to the function of the same name exported by DynamicWorkspaces. Ultimately it would probably be cleaner to generalize the one in DynamicWorkspaces to accept an arbitrary workspace sort as a parameter; this is left as an exercise for future hackers. ] [XMonad.Layout.OnHost allows host-specific modifications to a layout, which allbery.b@gmail.com**20120320030912 Ignore-this: 4c0d5580e805ff9f40918308914f3bf9 is otherwise very difficult to do. Similarly to X.L.PerWorkspace, it provides onHost, onHosts, modHost, and modHosts layout modifiers. It attempts to do smart hostname comparison, such that short names will be matched with short names and FQDNs with FQDNs. This module currently requires that $HOST be set in the environment. You can use System.Posix.Env.setEnv to do so in xmonad.hs if need be. (Properly, this should be done via the network library, but I'm trying to avoid adding that dependency.) An alternative would be to shell out to get the name, but that has considerable portability hurdles. ] [Bump version to 0.10.1 Adam Vogt <vogt.adam(a)gmail.com>**20120320005311 Ignore-this: f0608ffaa877f605eaa86c45a107a14d Raising the X11 dependency while keeping the xmonad version the same leads to problems where cabal install uses the dependency versions following hackage, not what is installed. ] [narrower BorderResize rectangles placed within border edges Jens Petersen <juhp(a)community.haskell.org>**20120314064703 Ignore-this: 3a43bbdb7f2317d702edafb231f58802 Change the border resize rectangles to be narrower and only extend inside the window not outside. Most window managers just seem to use the border decoration area for starting resizes which is often just 1 pixel wide but as a compromise the width is now 2 pixels (before it was 10!). The rectangles are now placed symmetrically within the border and window. This seems to work ok with PositionStoreFloat for the Bluetile config. ] [add-dynamic-bars-module Ben Boeckel <mathstuf(a)gmail.com>**20120316002204 Ignore-this: 41347c8f894d8d0b5095dfad86784cf4 This adds the X.H.DynamicBars module. It allows per-screen status bars to be easily managed and dynamically handles the number of screens changing. ] [bump X11 dependency so that noModMask is available Daniel Wagner <daniel(a)wagner-home.com>**20120316000302 Ignore-this: 971a75dcad25f66848eef4174cd4ddd1 ] [Paste.hs: rm noModMask, shifted definition to X11 binding (see previous email) gwern0@gmail.com**20111203203038 Ignore-this: dcd164ff8f8f135c8fdef08f42f9244d ] [GroupNavigation: fix import typo in usage Jens Petersen <juhp(a)community.haskell.org>**20120312103349 Ignore-this: 65367218ca50a33a37813469b4616f34 ] [add sendToEmptyWorkspace to FindEmptyWorkspace Jens Petersen <juhp(a)community.haskell.org>**20120312102331 Ignore-this: 50e7992d80d2db43e4d0adf5c95e964f sendToEmptyWorkspace is like tagToEmptyWorkspace except it does not change workspace after moving the window. ] [xmonad-contrib.cabal: simplify xmonad dependency to >=0.10 && < 0.11 Jens Petersen <juhp(a)community.haskell.org>**20120312101800 Ignore-this: 1ff5a0caa2a1e3487e9a0831e385b3d2 Unless there is a particular reason for listing the lower and upper bounds separately then this seems simpler and cleaner. ] [ShowWName: Increase horizontal padding for flash crodjer@gmail.com**20120305164517 Ignore-this: de5fd30fad2630875c5c78091f07c324 Currently the flash window width leaves a very small amount of padding. This patch adds some extra horizontal width, governed by text width and length. ] [persist-togglehook-options Ben Boeckel <mathstuf(a)gmail.com>**20120311050143 Ignore-this: 580bacb35b617c1198f01c5a7c0d3fef Save the state of ToggleHook options over a restart. ] [ShowWName flash window background color Rohan Jain <crodjer(a)gmail.com>**20120306065224 Ignore-this: 9cd8fcfc13cc326b9dcc79ef3cc21b26 While calling paintAndWrite for flash window, the background color from config should also be passed on as window background in addition to as text background color. Otherwise the window color gets set to the default black which shows up when text cannot span whole of the window. This issue becomes visible when the font size is considerably large or even in small size with truetype fonts. ] [ShowWName: Fix flash location by screen rectangle crodjer@gmail.com**20120305161240 Ignore-this: 83ec4cce2297efc6736a1fe55f44ee73 In case of using this hook with multiple monitors, the Tag flash was not following the screen's coordinates. This patch shifts the new window created for flash according to the Rectangle defined by the screen. ] [Fix typo in tabbed layout link for font utils docs crodjer@gmail.com**20120229070022 Ignore-this: 2f7e90269e08ce08264d7b1d05bb16f9 ] [L.WorkspaceDir: cleanup redundant {definitions,imports} Steffen Schuldenzucker <sschuldenzucker(a)uni-bonn.de>**20120229112124 Ignore-this: 7a796b18a64e693e071e9ea3a6a01aa3 ] [fix L.WorkspaceDir special char handling: remove "echo -n" processing Steffen Schuldenzucker <sschuldenzucker(a)uni-bonn.de>**20120227122004 Ignore-this: ab48687eb4c9018312089a13fd25ecd8 ] [Add BorderUrgencyHook to XMonad.Hooks.UrgencyHook allbery.b@gmail.com**20120225082616 Ignore-this: 9fac77914ff28a6e9eb830e8c9c7e21e BorderUrgencyHook is a new UrgencyHook usable with withUrgencyHook or withUrgencyHookC; it allows an urgent window to be given a different border color. This may not always work as intended, since UrgencyHook likes to assume that a window being visible is sufficient to disable urgency notification; but with suppressWhen = Never it may work well enough. There is a report that if a new window is created at the wrong time, the wrong window may be marked urgent somehow. I seem to once again be revealing bugs in underlying packages, although a quick examination of X.H.UrgencyHook doesn't seem to show any way for the wrong window to be selected. ] [Adding use case for namedScratchpad. nicolas.dudebout@gatech.edu**20120122235843 Ignore-this: 44201e82bcd708cd7098f060345400f1 ] [Actions.WindowGo: typo fix - trim 's' per cub.uanic https://code.google.com/p/xmonad/issues/detail?id=491 gwern0@gmail.com**20120116224244 Ignore-this: fb1d55c1b4609069c55f13523c091260 ] [XMonad.Actions.PhysicalScreens: fix typo spotted by Chris Pick <haskell(a)chrispick.com> gwern0@gmail.com**20120115223013 Ignore-this: eb73b33b07dc58a36d3aa00bc8ac31c2 ] [roll back previous incorrect fix Daniel Wagner <daniel(a)wagner-home.com>**20120111214133 Ignore-this: 91496faef411e6ae3442498b528d119b ] [Extending: fix http://code.google.com/p/xmonad/issues/detail?id=490 gwern0@gmail.com**20120111211907 Ignore-this: 515afbed507c070d60ab547e98682f12 ] [another documentation patch: XMonadContrib.UpdatePointer -> XMonad.Actions.UpdatePointer Daniel Wagner <daniel(a)wagner-home.com>**20120111211226 Ignore-this: 1444e4a3f20ba442602ef1811d0b32c7 ] [documentation patch, fixes issue 490 Daniel Wagner <daniel(a)wagner-home.com>**20120111210832 Ignore-this: 8d899e15f9d1a657e9fc687e2f649f45 ] [X.H.EwmhDesktops note that fullscreenEventHook is not included in ewmh Adam Vogt <vogt.adam(a)gmail.com>**20120102211404 Ignore-this: 92f15fa93877c165158c8fbd24aa2360 Just a documentation fix (nomeata's suggestion at issue 339). ] [X.H.EwmhDesktops haddock formatting. Adam Vogt <vogt.adam(a)gmail.com>**20120102211203 Ignore-this: cfff985e4034e06a0fe27c52c9971901 ] [X.A.Navigation2D Norbert Zeh <nzeh(a)cs.dal.ca>**20111208205842 Ignore-this: 3860cc71bfc08d99bd8279c2e0945186 This is a new module to support directional navigation across multiple screens. As such it is related to X.A.WindowNavigation and X.L.WindowNavigation, but it is more general. For a detailed discussion of the differences, see http://www.cs.dal.ca/~nzeh/xmonad/Navigation2D.pdf. ] [documentation patch: mention PostfixOperators Daniel Wagner <daniel(a)wagner-home.com>**20111210234820 Ignore-this: 20a05b1f396f18a742346d6e3daea9a8 ] [P.Shell documentation and add missing unsafePrompt export Adam Vogt <vogt.adam(a)gmail.com>**20111207163951 Ignore-this: a03992ffdc9c1a0f5bfa6dafc453b587 Haddock (version 2.9.2 at least) does not attach documentation to any of a b or c when given: -- | documentation a,b,c :: X ] [Paste: 3 more escaped characters from alistra gwern0@gmail.com**20111129160335 Ignore-this: 46f5b86a25bcd2b26d2e07ed33ffad68 ] [unfuck X.U.Paste Daniel Wagner <daniel(a)wagner-home.com>**20111129032331 Ignore-this: d450e23ca026143bb6ca9d744dcdd906 ] [XMonad.Util.Paste: +alistra's patch for fixing his pasting of things like email address (@) gwern0@gmail.com**20111128215648 Ignore-this: 4af1af27637fe056792aa4f3bb0403eb ] [XMonad.Util.Paste: rm myself from maintainer field; I don't know how to fix any of it even if I wanted gwern0@gmail.com**20111128213001 Ignore-this: 87a4996aaa5241428ccb13851c5eb455 ] [XMonad.Prompt.Shell: improve 'env' documentation to cover goodgrue's problem gwern0@gmail.com**20111127231507 Ignore-this: 7b652a280960cbdf99c236496ca091b0 ] [Fix spelling 'prefered' -> 'preferred'. Erik de Castro Lopo <erikd(a)mega-nerd.com>**20111125010229 Ignore-this: f2eac1728b5e023399188becf867a14d ] [Restore TrackFloating behavior to an earlier version. Adam Vogt <vogt.adam(a)gmail.com>**20111120045538 Ignore-this: 1a1367b4171c3ad23b0553766021629f Thanks for liskni_si for pressing the matter: without this change it is very broken, with the patch it is still not perfect but still useful. ] [Explicitly list test files in .cabal Adam Vogt <vogt.adam(a)gmail.com>**20111118232511 Ignore-this: ac48a0d388293cc6c771d676aaf142e3 In the future, require Cabal >= 1.6 to be able to just write tests/*.hs ] [TAG 0.10 Adam Vogt <vogt.adam(a)gmail.com>**20111118225640 Ignore-this: 8f81b175b902e985d584160fc41ab7d1 ] Patch bundle hash: 282e8e8f8d60de48dd42fbb111d40c4a53843f8b

3 3

FAQ, UTF-8-Question
by 1126 19 Apr '12

19 Apr '12

Hello List! I don't know if this is the proper place to ask, but I don't know where else I should drop this. I browsed through the FAQ on the website and stumbled over a TODO at question 3.20 (http://www.haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#How_ca…) I don't know whether xmonad >=0.8 supports (and uses) UTF-8 as default, but I guess that this could be answered and thus this answer could and should be adjusted ;) So, how is it with xmonad and UTF-8? Greetings from Cologne, Christian.

1 0

XMonad Efficiency
by Norbert Zeh 18 Apr '12

18 Apr '12

Hi folks, I must admit that I for now gave up on trying to make the decoration module more efficient. I tried two of the three ideas I had, and they didn't work well at all. My third idea (turning most of the lists in the decoration module into binary trees) is likely to work well, but for now I don't have time to implement it, particularly because it's not one of my main issues I would like to see addressed in xmonad. Related to the above, however, I noticed that even without decoration, fast focus switches drive my CPU usage up, much more so than in other non-tiling window managers. Running top gave me a surprising insight: it's not xmonad but the X server that consumes that many cpu cycles when focus switching. Here's my theory of the source of the issue: every focus change triggers the recomputation of the layout (as it should because some layouts rearrange windows in response to focus changes), and every recomputation of the layout updates the geometry of every window currently visible - that's a lot of work on the X server's side for a simple focus change. (1) Can anybody who is more familiar with the inner workings of xmonad core confirm that this is indeed what's going on? (2) A fairly simple fix for the above would be to cache the geometries of visible windows and tell the X server to update a window only if its geometry has in fact changed. Does anyone on the list have a feel for how hard it would be to add such a caching mechanism to xmonad core? Would it break anything? At this point, I'm simply pondering what can be done about it, as one of the reason's I'm using xmonad is that I want a lightweight desktop environment. (When fast focus changes drive one of my cores to 50%, that's hardly lightweight.) It'll be a while before I would get around to trying to implement the above. Cheers, Norbert -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

3 8

Issue 505 in xmonad: Strip the executable file created during recompilation
by codesite-noreply＠google.com 18 Apr '12

18 Apr '12

Status: New Owner: ---- New issue 505 by jach...@gmail.com: Strip the executable file created during recompilation http://code.google.com/p/xmonad/issues/detail?id=505 What steps will reproduce the problem? 1. recompile xmonad I think it's a good idea to strip the executable file generated during recompilation to make it even more lightweight. My xmonad version is 0.10 I believe the following code is pretty self-explanatory: $ cd $ xmonad --recompile $ ls --size .xmonad/xmonad-x86_64-linux 2552 .xmonad/xmonad-x86_64-linux $ file .xmonad/xmonad-x86_64-linux .xmonad/xmonad-x86_64-linux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xfec31cee9b5541ce3310171ffa299d0282a5cfb8, not stripped $ strip .xmonad/xmonad-x86_64-linux $ ls --size .xmonad/xmonad-x86_64-linux 1648 .xmonad/xmonad-x86_64-linux $ file .xmonad/xmonad-x86_64-linux .xmonad/xmonad-x86_64-linux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xfec31cee9b5541ce3310171ffa299d0282a5cfb8, stripped

1 4

Issue 504 in xmonad: Suggested modification to XMonad.Actions.WindowsGo.runOrRaiseNext
by codesite-noreply＠google.com 16 Apr '12

16 Apr '12

Status: New Owner: ---- New issue 504 by dansp...@gmail.com: Suggested modification to XMonad.Actions.WindowsGo.runOrRaiseNext http://code.google.com/p/xmonad/issues/detail?id=504 Best explained by an example: Currently: I have 2 instances of chrome running: Chrome1 (runRaiseNext Pidgin) Pidgin (runRaiseNext Chrome) Chrome2 (runRaiseNext Chrome) Chrome1 Proposed Change: I have 2 instances of chrome running: Chrome1 (runRaiseNext Pidgin) Pidgin (runRaiseNext Chrome) Chrome1 (runRaiseNext Chrome) Chrome2 I think the current behavior is not ideal, as it makes it difficult to swap between a particular window of an application and any other window. Very simply put my suggestion is NOT to cycle to the next window if the window we are coming from is not an instance of the window type.

1 0

Mail-plugin from xmobar
by 1126 16 Apr '12

16 Apr '12

Hello list! I'm not sure wether this is the right list to ask, but the Xmobar-List itself seems pretty dead to me. At least that's what I figured when browsing through the archives. Anyway, here's my problem: I try to add the mail-plugin to my xmobarrc and it complains: unexpected "s" expecting space or "Run" Here's what my xmobarrc looks like: Config { font = "xft:terminus-8" , bgColor = "#121212" , fgColor = "#ECECEC" , border = TopB , borderColor = "#F0E800" , position = Bottom , lowerOnStart = True , commands = [ Run Com "uname" ["-s", "-r"] "" 0 -- , Run MPD ["-t", "<state> (<lapsed>/<length>) | <artist> - <album> - <track> - <title>"] 10 , Run Mail [("inbox", "~/mail/mailboxes/uni/INBOX")] "mail" ] , sepChar = "%" , alignSep = "}{" , template = " %uname% }{ %mail% " } Any help is appreciated. Thank you :) Greetings from Cologne, Chris

3 3