- xmonad - Haskell.org

Issue 456 in xmonad: xmonad partially eats key events comprising a WM shortcut
by codesite-noreply＠google.com 28 Feb '12

28 Feb '12

Status: New Owner: ---- New issue 456 by hramr...(a)gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 When I invoke a keyboard shortcut of XMonad this happens: Mod key down (eg. Super) is received by application action key down (eg. C) is eaten by XMonad <At this point Mod release should be sent to application> , action is performed. action key release and Mod key release is eaten by XMonad Mod is stuck down in application XMonad should send key release for modifiers it ate to the application. It should do so before performing the action bound to the key because at that point it is known the key will be eaten and the application that received the bogus key down is still active. If the action is some WM action that switches windows the only time when this fixup can reasonably happen is before performing the action.

1 10

Re: Issue 276 in xmonad: switching keyboard focus to a wine app is odd
by codesite-noreply＠google.com 28 Feb '12

28 Feb '12

Comment #2 on issue 276 by byorgey: switching keyboard focus to a wine app is odd http://code.google.com/p/xmonad/issues/detail?id=276 What is it about the way xmonad and wine interact that cause this? Obviously keyboard focus works fine for (almost) all other applications, so what's different about wine? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 4

Issue 479 in xmonad: xmonad & xft slow font rendering
by codesite-noreply＠google.com 28 Feb '12

28 Feb '12

Status: New Owner: ---- New issue 479 by wol...(a)gmail.com: xmonad & xft slow font rendering http://code.google.com/p/xmonad/issues/detail?id=479 What steps will reproduce the problem? 1. Start gnome3 environment 2. Open resource manager and vim with arbitrary large file 3. Scroll with your keyboard up and down 4. Notice that cpu-consumption and ui-performance differs considerably with the same steps reproduced in xmonad. What is the expected output? What do you see instead? I expect at least the same performance. What version of the product are you using? On what operating system? Arch linux x86_64. xmonad 0.9.2 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. I use xmonad for quite some time. But today I was curious about gnome 3 and what I noticed is that font rendering in gnome 3 was significantly faster than in xmonad. This was strange for me, because I don't even use composite managers with my xmonad setup. I dig it a little and found, that the source of problem may be xft, which is used by default. Also, it's unlikely to be a hardware problem, because my setup is i7/8gb/ati hd5470. Attachments: xmonad.hs 6.0 KB

1 1

Not passing Mod key to applications
by John Goerzen 28 Feb '12

28 Feb '12

Hi everyone, In what appears to be typical fashion, I have that pesky Windows key (mod4mask) mapped to Mod. That's been nice because it's mostly unused anywhere else. But the devil is in the word "mostly". I have to run some Windows VMs and terminals. They do actually use that key. So when I start to press, say, Mod-5 to switch to a different workspace, the Windows session does something as soon as I press mod. This is even worse with VirtualBox, which somehow prevents xmonad from seeing the keypress when VirtualBox is active. I'd rather have xmonad completely eat all Mod keypresses, and let no other application, even those Windows RDP or VirtualBox sessions, ever see it. I don't really ever use it in Windows anyhow, so it's just causing annoyance. For awhile, Google Docs popped up keyboard shortcut help when I'd press it over one if its windows. I think that behavior has now gone away, but I'm not certain if it's something they did or something I did. Is there a quick trick to accomplish this? Thanks, -- John

3 3

darcs patch: Prompt.Directory: fix completion for paths containing ...
by Steffen Schuldenzucker 27 Feb '12

27 Feb '12

Hey Guys, a tiny fix. Contributing never felt this painless. Awesome work, really! -- Steffen 1 patch for repository http://code.haskell.org/XMonadContrib: Sun Feb 26 11:52:29 CET 2012 Steffen Schuldenzucker <sschuldenzucker(a)uni-bonn.de> * Prompt.Directory: fix completion for paths containing whitespace

3 5

darcs patch: fix L.WorkspaceDir special char handling: remove "echo...
by Steffen Schuldenzucker 27 Feb '12

27 Feb '12

I'm not sure why this was introduced in the first place. 'changeDir' works fine for me now. It was introduced here: Mon Jun 11 17:40:41 CEST 2007 David Roundy <droundy(a)darcs.net> * add WorkspaceDir, which sets the current directory in a workspace. 1 patch for repository http://code.haskell.org/XMonadContrib: Mon Feb 27 13:20:04 CET 2012 Steffen Schuldenzucker <sschuldenzucker(a)uni-bonn.de> * fix L.WorkspaceDir special char handling: remove "echo -n" processing

3 2

darcs patch: Add BorderUrgencyHook to XMonad.Hooks.UrgencyHook
by allbery.b＠gmail.com 27 Feb '12

27 Feb '12

1 patch for repository http://code.haskell.org/XMonadContrib: Sat Feb 25 03:26:16 EST 2012 allbery.b(a)gmail.com * Add BorderUrgencyHook to XMonad.Hooks.UrgencyHook 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.

3 2

Issue 472 in xmonad: [PATCH] XMonad/Prompt/Directory.hs fix issue on standard unixes
by codesite-noreply＠google.com 25 Feb '12

25 Feb '12

Status: New Owner: ---- New issue 472 by graude...(a)gmail.com: [PATCH] XMonad/Prompt/Directory.hs fix issue on standard unixes http://code.google.com/p/xmonad/issues/detail?id=472 XMonad/Prompt/Directory.hs is using /bin/bash, this is not only unportable, but also very not standard. Because of this XMonad/Prompt/Directory.hs doesn't work on FreeBSD for example. Because there is no /bin/sh, you can however install bash to /usr/local/bin/ Attached patch fixes this by simply removing /bin/ and leaving shell to figure out where is bash located I'm using xmonad and xmonad-contib 0.9.2 from FreeBSD ports Attachments: patch-XMonad__Prompt__Directory.hs 490 bytes

1 1

Issue 496 in xmonad: UpdatePointer Nearest disfunctional.
by codesite-noreply＠google.com 20 Feb '12

20 Feb '12

Status: New Owner: ---- New issue 496 by egan.mcc...(a)gmail.com: UpdatePointer Nearest disfunctional. http://code.google.com/p/xmonad/issues/detail?id=496 Using XMonad.Actions.UpdatePointer Nearest: 1. Open 4 windows in Tall layout. 2. Switch windows with M-j. 3. The cursor (and focus) skips the upper right window when coming from the master window, jumping straight to the middle right window. 4. Switch windows with M-k. 5. The cursor (and focus) goes to the upper right window as expected. Additionally, there are various instances where the pointer is not moved to the focused window on a workspace change. The pointer has to be moved all the way out of the unfocused window and back in to focus it. These instances are harder to pin down so I haven't any method to reproduce. Changing from Nearest to Relative fixes the problem, so I think it has something to do with the thickness of the window borders and some rounding error. I'm using xmonad 0.10-2 on Arch Linux x86-64. Configuration file attached. Attachments: xmonad.hs 3.3 KB

1 0

Managehook which only shifts window if workspace is empty
by Toby Cubitt 18 Feb '12

18 Feb '12

I'm trying to write a Managehook that only shifts a window to workspace if that workspace is empty. But I'm quickly realising I don't have a good enough grasp of Xmonad types, and Haskell monads in general, to get it to work. So far, the closest I think I've got is the following: myManageHook = [ className =? "mutt" --> doShiftEmpty "email" ] where doShiftEmpty t = when (isEmpty t) (doShift t) isEmpty t = do wsl <- gets $ W.workspaces . windowset let mws = find (\ws -> W.tag ws == t) wsl return $ maybe True (isNothing . W.stack) mws which throws a type error: "Couldn't match expected type `Bool' with actual type `m0 Bool' In the return type of a call of `isEmpty'" I think I vaguely understand the problem, namely that "when" expects a Bool as its first argument, whereas the "return" in isEmpty returns a Bool wrapped inside a monad. But removing the "return" just throws a more confusing type error. Clearly, I'm way out of my depth here, and am doing little better than cargo cult programming. Can someone who understands these things properly explain where I'm going wrong here? More generally, is there a tutorial explaining the Xmonad types and data structures, and how they go together to make up Xmoand? I've been working through some basic Haskell tutorials, but there's still quite a step from understanding a little Haskell, to understanding enough of how Xmonad works to write a simple Managehook action. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: tsc25(a)cantab.net web: www.dr-qubit.org

3 4