- xmonad - Haskell.org

patch: Font utils docs, fix typo in tabbed layout link
by Rohan Jain 01 Mar '12

01 Mar '12

The link to tabbed layout page is broken here: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Util-Font.html#interface, because of a typo in docs. The patch attached fixes this. -- Rohan Jain

2 1

Issue 420 in xmonad: countScreens from the contrib module X.L.IndependScreens has side effects
by codesite-noreply＠google.com 29 Feb '12

29 Feb '12

Status: New Owner: ---- New issue 420 by quesel: countScreens from the contrib module X.L.IndependScreens has side effects http://code.google.com/p/xmonad/issues/detail?id=420 The function countScreens does not close the display after counting the number of screens. This is unfortunate as counting the number of screens should be side effect free. The patch below changes this function in a way that after performing its operation the display is closed correctly. Regards, Jan Attachments: countScreensCloseDisplay.patch 51.0 KB

1 2

Re: [xmonad] Reset layout to default on last window close
by Brandon Allbery 29 Feb '12

29 Feb '12

On Tue, Feb 28, 2012 at 18:45, Nathaniel Filardo <nwfilardo(a)gmail.com>wrote: > On Tue, Feb 28, 2012 at 3:18 PM, Brandon Allbery <allbery.b(a)gmail.com> > wrote: > >[snip] > >> handleEventHook DestroyWindowEvent {} = > >> n <- (length . index) `fmap` withWindowSet > >> guard (n == 1) $ sendMessage $ JumpToLayout "name of initial layout > here" > >> return (All True) > > Unless I am terribly mistaken, won't that send a message to the focused > workspace if it has one window on it, rather than the (I assume intended) > workspace where the closing window was located? > True. You'd have to do a bit more work to find the correct workspace if that's not the case. But there's a nasty stinger in that tail: if you send a message to a workspace that is not current, the message won't actually be sent because workspace operations require access to the display, which can only be granted if the workspace is current. So if it's not the current workspace, you lose anyway. There's no way to make it work. And no, you can't approach it from the other direction, either; a different version of the same problem gets in the way. :/ (I recently filed a bug about the design issue that causes this. It won't be easily fixed.) -- brandon s allbery allbery.b(a)gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

1 0

Reset layout to default on last window close
by Alexander Batischev 29 Feb '12

29 Feb '12

Hello, I want workspace layout to reset to some default once last window is closed. Quick glance though Xmonad-related modules names didn't give me any hints on what hook (or some other facility) to use, so I'm seeking your advice, fellow Xmonaders: how can I accomplish that? -- Regards, Alexander Batischev 4096R/0C8BFD03 CE6C 4307 9348 58E3 FD94 A00F 3569 61A2 0C8B FD03

3 2

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

29 Feb '12

Status: New Owner: ---- New issue 456 by hramr...@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 29 Feb '12

29 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 29 Feb '12

29 Feb '12

Status: New Owner: ---- New issue 479 by wol...@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 28 Feb '12

28 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 28 Feb '12

28 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