November 2014 - xmonad

Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes
by codesite-noreply＠google.com 15 Feb '15

15 Feb '15

Status: New Owner: ---- New issue 576 by martin.s...(a)gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 What steps will reproduce the problem? 1. Install FreeBSD (amd64). 2. Write a minimal xmonad.hs with xterm binding. 3. Start xmonad in Xorg. 4. Try (multiple times) Mod+Shift+Return. What is the expected output? What do you see instead? It's expected that xterm opens with the first time Mod+Shift+Return is pressed. Sometimes Xmonad loses the key-combo and you need to press it twice in fast succession. If you wait too long between the first and the second time in sequence, the hotkey will be lost again and again. I repeat once again: it happens SOMETIMES, but on average every 4th time. Try to open terminal and exit it again (Mod+Shift+Return -> Ctrl-D -> Mod+Shift+Return -> Ctrl-D -> ...). What version of the product are you using? On what operating system? hs-xmonad-0.11_7 FreeBSD 10.0 RELEASE (amd64). Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". You don't need mine. Use a minimal one: import XMonad main = xmonad defaultConfig { modMask = mod1Mask , terminal = "xterm" } Additional info: Cannot be reproduced on Linux. Everything works as expected there. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 22

Re: Issue 254 in xmonad: XMonad.Contrib.Util.Run.runInTerm does not work with terminal = "gnome-terminal"
by codesite-noreply＠google.com 06 Feb '15

06 Feb '15

Comment #6 on issue 254 by klu...(a)gmail.com: XMonad.Contrib.Util.Run.runInTerm does not work with terminal = "gnome-terminal" http://code.google.com/p/xmonad/issues/detail?id=254 I wrote a routine to double-quote and escape shell input, and it _seems_ to work for me. I've added it to Prompt.Ssh instead of changing runInTerm, but it logically belongs there. That is, I call ssh s = runInTerm "" (bashDblQuote ("ssh " ++ s)) where bashDblQuote is the quoting function. Attachments: dblquote.hs 866 bytes OtherSsh.hs 3.4 KB

1 3

Walking Fullscreen Windows
by Chris Bell 21 Jan '15

21 Jan '15

Hi all, I've noticed an interesting issue with some Fullscreen windows when using SmartBorders. I apologize in advance if this has been addressed - I couldn't find anything, but I'm not sure I was asking Google right. I am using the current release of Xmonad with SmartBorders. When I am running an application fullscreen, SmartBorders removes the borders, as it should. However, every time the window gains or loses focus, the window will grow by a pixel or two. Specifically, the lower right corner will extend down and to the right. All UI elements in the window follow accordingly. Specific example: Using Chrome to watch fullscreen HTML5 video (Netflix). Every time the window gets/loses focus, the UI elements will walk a pixel down, and extend a pixel right, like it's scaling to a resized window. When focus changes again, it again creeps. Eventually the window is far larger than the actual screen. When I leave/re-enter fullscreen, the size is initially correct. Then it starts growing again as I interact. Chrome has handled this admirably - the video simply scales up a couple pixels to compensate. Fullscreen (OpenGL) games, on the other hand, totally freak out. The graphics won't scale, instead a border of corrupt pixels slowly grows around the image; the new pixel rows/columns are filled with random data. I run 3 monitors, and if this happens on the left or center monitors, the windows start overlapping the screen to the right. It almost seems as if the window is getting hints from Xmonad that don't quite correspond to the actual dims, and it keeps compensating. The other idea is that SmartBorders is trying to cover up a border that it thinks exists, but really doesn't. Either way, I'm not quite sure where to start debugging. There's one glaring exception: I have defined a window hook to force VLC to go FullScreenFloat when FullScreen is detected (since VLC fullscreen didn't work out of the box). VLC's window *doesn't* creep like Chrome or any of the others do. Has anyone else seen this? Any fixes/debug suggestions? I'm really hoping I just screwed up something simple. Thanks! Regards, Chris Bell Ph.D. Student University of South Florida College of Engineering Department of Computer Science and Engineering NarMOS Research Team

4 5

patch: Add search string to X.A.GridSelect grid
by Dmitri Iouchtchenko 22 Dec '14

22 Dec '14

I find it very convenient to be able to use GridSelect to choose an option that isn't in the original list of options. One of the uses of this is to switch to a dynamic workspace that doesn't yet exist.

3 4

darcs patch: BinarySpacePartition downstream changes
by benweitzman＠gmail.com 22 Dec '14

22 Dec '14

1 patch for repository http://code.haskell.org/XMonadContrib: Mon Nov 10 15:22:59 EST 2014 benweitzman(a)gmail.com * BinarySpacePartition downstream changes Pulled in changes from my repo for this layout on github (https://github.com/benweitzman/BinarySpacePartition) Includes a new mode for resizing windows in a more intuitive way, also contains a bug fix that was preventing users from resiving a window up. Includes changes from github users egasimus (Adam Avramov) and SolitaryCipher (Nick)

2 1

Issue 538 in xmonad: X.H.DynamicBars call to xrrSelectInput has no effect
by codesite-noreply＠google.com 10 Dec '14

10 Dec '14

Status: New Owner: ---- New issue 538 by johnnysp...(a)gmail.com: X.H.DynamicBars call to xrrSelectInput has no effect http://code.google.com/p/xmonad/issues/detail?id=538 What steps will reproduce the problem? 1. Use attached xmonad.hs (vanilla + minimal DynamicBars). 2. Turn second display off and on: xrandr --output VGA1 --off xrandr --output VGA1 --preferred --right-of LVDS1 Bonus: 3. Apply select_input_fix.dpatch, rebuild and restart xmonad. 4. Turn second display off and on. 5. Undo previous patch, apply select_input_not_fix.dpatch, rebuild and restart xmonad. 6. Turn second display off and on. What is the expected output? What do you see instead? Expected: In steps 2, 4, and 6: see "DESTROYING"/"CREATING" messages in xmonad output. Actual: Only step 4 produces the expected messages. Steps 2 and 6 produce no output. What version of the product are you using? On what operating system? xmonad 0.11 (darcs) xmonad-contrib 0.11 (darcs) xorg 1.14.0 xrandr 1.4.0 X11 (Haskell binding) 1.6.1.1 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". "xmonad --recompile" produces no output. Please provide any additional information below. I'm expecting step 2 to work because dynStatusBarStartup calls xrrSelectInput. This apparently doesn't do what it's supposed to do for me, possibly for the same reason that step 6 doesn't work. Attachments: xmonad.hs 551 bytes select_input_fix.dpatch 2.2 KB select_input_not_fix.dpatch 2.3 KB -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 4

Issue 447 in xmonad: installation breaks copy/paste feature of vmware-tools
by codesite-noreply＠google.com 03 Dec '14

03 Dec '14

Status: New Owner: ---- New issue 447 by t...(a)timsears.com: installation breaks copy/paste feature of vmware-tools http://code.google.com/p/xmonad/issues/detail?id=447 Any idea why installing xmonad would break the copy/paste function of vmware? What steps will reproduce the problem? 1. Running Ubuntu 10.10 under VMware Fusion under macosx 10.6 (Snow Leopard) 2. apt-get install xmonad 3. Try and copy/paste from the mac into a terminal window on Ubuntu. Doesn't matter if xmonad is running or if the session has been restarted. What is the expected output? What do you see instead? Ubuntu loses track of the copy/paste buffer. What version of the product are you using? On what operating system? see above. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". no Please provide any additional information below. The system is repaired by running "apt-get uninstall xmonad" This only uninstalls the xmonad package not it dependencies.

1 10

Re: [xmonad] Issue 177 in xmonad: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol
by codesite-noreply＠google.com 03 Dec '14

03 Dec '14

Comment #127 on issue 177 by vogt.a...(a)gmail.com: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol http://code.google.com/p/xmonad/issues/detail?id=177 losinski.j, If I were to `cabal upload' now, it's possible that you might still need to add to the logHook `setWMName "LG3D"' to get your java app to work.

1 3

Issue 350 in xmonad: Investigate using Dyre for xmonad configuration
by codesite-noreply＠google.com 02 Dec '14

02 Dec '14

Status: Accepted Owner: gwern0 Labels: Milestone-Release1.0 New issue 350 by SpencerJanssen: Investigate using Dyre for xmonad configuration http://code.google.com/p/xmonad/issues/detail?id=350 http://hackage.haskell.org/package/dyre Things we need to know before switching: * Can we make the transition seamless for our users? This means the config file format, location remain unchanged. * Is the maintainer available and cooperative? Will bug reports and patches be attended to in a timely manner? -- 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

3 16

deal with EWMH focus stealing problem
by Javran Cheng 28 Nov '14

28 Nov '14

Hi all, I'd like to share my workaround dealing with focus stealing problem found when EWMH is enabled: http://javran.github.io/posts/2014-11-27-get-rid-of-xmonad-focus-thief.html Please feel free to discuss and hope you have a nice holiday :) Javran

1 0