February 2012 - xmonad

Issue 346 in xmonad: xmonad will not render dialog windows.
by codesite-noreply＠google.com 09 Sep '12

09 Sep '12

Status: New Owner: ---- New issue 346 by Monkey.Andrew: xmonad will not render dialog windows. http://code.google.com/p/xmonad/issues/detail?id=346 What steps will reproduce the problem? Opening (so far) any gtk application's open dialog (file > open), and the dialog will not render, as if it were an invisible window. The proof of its existence lies in how it steals focus from its parent window and how the cursor changes when on top of it. When I move the dialog window, it appears and I can interact with it normally from there on out. This has happened with chromium, firefox, openoffice, and gvbam. What is the expected output? What do you see instead? See above. What version of the product are you using? On what operating system? 0.9 on archlinux Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". main=do xmonad $ defaultConfig { terminal ="urxvt -bg black -fg white +sb -tr -sh 50" , modMask =mod4Mask , borderWidth=3 Please provide any additional information below. -- 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 15

Issue 380 in xmonad: Infer shiftMask given keysyms that otherwise will not be received
by codesite-noreply＠google.com 15 Aug '12

15 Aug '12

Status: Accepted Owner: ---- Labels: Type-Defect Priority-Low New issue 380 by vogt.adam: Infer shiftMask given keysyms that otherwise will not be received http://code.google.com/p/xmonad/issues/detail?id=380 What steps will reproduce the problem? A keybinding to (0, xK_plus) doesn't work What is the expected output? What do you see instead? Instead you have to bind to: (shiftMask, xK_equal) Maybe doing this correctly regardless of the keymap isn't possible, but perhaps a reasonable approximation can be done like this: * if the keymap contains 'unreachable keys' like "M-+", grab "M-+" and "M-S-=" * if we actually get a "M-+", ungrab the "M-S-=", and run the normal action for "M-+" This can be done with a handleEventHook outside of core, but for users, the current workaround is probably easier having an optional handleEventHook to EZConfig (note how uncommon the use of the optional startupHook from that module is). -- 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 1

Issue 340 in xmonad: Error In Passing Clicks in Multi-Head non-Xinerama Setup
by codesite-noreply＠google.com 11 Aug '12

11 Aug '12

Status: New Owner: ---- New issue 340 by llcawthorne: Error In Passing Clicks in Multi-Head non-Xinerama Setup http://code.google.com/p/xmonad/issues/detail?id=340 What steps will reproduce the problem? 1. Set 'Option "Xinerama" "0"' in xorg.conf in a multi-head non-xrandr setup. 2. Run xmonad on the primary display 3. Run another copy of xmonad, or another WM on the secondary display. What is the expected output? What do you see instead? I should be able to re-enter a window managed by XMonad and click on things after leaving it. There are two different setups that respond slightly differently. 1) Xmonad on DISPLAY 0.0 and No WM on DISPLAY 0.1 (or Openbox). I can leave the XMonad display perfectly every time and click on things on the secondary display. The problem pops up when XMonad needs to re-accept control of the pointer. I come back to my main screen and clicks are not accepted by whatever window I entered into. Buttons highlight like I am over them; links get little boxes around them, but clicks do not register. The problem can be remedied by moving my mouse over any other window on the same display, and things "catch up". Ex: DISPLAY=0.0. I usually run Firefox, and three terminals. DISPLAY=0.1. I usually have Thunderbird open. If I go to Thunderbird, I never have any problem getting there (as long as I am not running XMonad on display 0.1 also). If I come back from thunderbird to Firefox (which is in the master tile), I cannot successfully click anything. If I move my mouse over to a terminal (with or without clicking on it) and then back to Firefox, I can click things fine. 2) Running xmonad on Display 0.0 and Display 0.1 Same as above, except I have problems moving to each display. Previous Example but: If I leave Display 0.0 and go to Thunderbird, I cannot click anything. Once again, messages shadow when the mouse is over them, as do buttons in Thunderbird. If I hit Mod+Shift+Return at this point, the terminal will open on Display 0.0, even though I am on Display 0.1 with my pointer. Now, if I move my pointer back to Display 0.0, I cannot click on Firefox and if I hit Mod+Shift+Return the terminal will open on Display 0.1 even though the mouse is on Display 0.0. Everything is back to normal if I mouse over a terminal and back to Firefox. (This was especially annoying until I figured out what was going on.. Now I run with a clock open on Display 0.1 so I have a second window to mouse over on the way to read my e-mail, because otherwise I had no way to make Thunderbird start receiving clicks). Things work the same with application other than Firefox/Thunderbird termimal in both examples, they are just what I tend to have open. What version of the product are you using? On what operating system? Xmonad 0.8 or Xmonad 0.9. Gentoo Linux or ArchLinux. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Problem exists with default xmonad.hs or with a custom xmonad.hs (or with a randomly grabbed off the website xmonad.hs). Please provide any additional information below. I can set "Xinerama" "1" and there is no problem; I just don't particularly care for Xinerama. A) It turns off compositing. B) I cannot (at least don't know how to) launch apps to other screens from a prompt (ie 'DISPLAY=:0.2 mplayer -fs South.Park.S01312.avi'). Also, I generally use three monitors, but I can recreate the problem with the secondary card and tertiary monitor removed from my configuration, so it has not been mentioned here. (Things get even stranger when I try running xmonad on all three displays without Xinerama). If you need more info than my wordy description, I have a forum post on the ArchLinux boards and sent a message to the mailing list a bit back relating to this problem. (Note that the first few messages of the posting were before I figured out clearly what was happening). http://bbs.archlinux.org/viewtopic.php?id=83789 -- 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 3

Issue 488 in xmonad: new dmenu version breaks xmonad-contrib wrapper
by codesite-noreply＠google.com 23 Jul '12

23 Jul '12

Status: New Owner: ---- New issue 488 by Longp...(a)gmail.com: new dmenu version breaks xmonad-contrib wrapper http://code.google.com/p/xmonad/issues/detail?id=488 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 title: new dmenu version breaks xmonad-contrib wrapper dmenu-4.4.1 appends a newline to the outputted string representing the selected item, breaking xmonad-contrib's dmenu wrapper, which expects no newline. I've attached a patch to fix this. It's backwards compatible with old versions of dmenu. I've only tested it directly with ``dmenuMap``. What steps will reproduce the problem? 1. run code: ``dmenuMap $ M.fromList [("k_x","v_x"),("k_y","v_y"),("k_z","v_z")]`` 2. choose "k_x" in the menu bar that pops up What is the expected output? What do you see instead? Return value should be ``Just "v_x"``. Actual value is ``Nothing``. What version of the product are you using? On what operating system? reproduced on xmonad-contrib-0.10 and xmonad-contrib-0.9 with dmenu-4.4.1, worked with dmenu-4.2.1. Gentoo Linux Signature for attached file (xmonad-contrib-0.10-trim-dmenu-newline.patch): - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk7upSQACgkQ3PGpByoQpZF0ZQCePDS+cf+yH5XE3HhQoj3s70S5 hhcAoJZZntuNYbYzR7oQp6BtEuRcQnNP =Awzc - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7upeYACgkQ3PGpByoQpZHsKQCaA990E4xVGmzlvOuPo1mgOaY8 vnkAnRj49CsrdEQg0MaMd3k/q1ZF4xF6 =dgAy -----END PGP SIGNATURE----- Attachments: xmonad-contrib-0.10-trim-dmenu-newline.patch 745 bytes

1 3

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

27 Apr '12

Status: New Owner: ---- New issue 495 by woofy1...(a)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

Issue 497 in xmonad: Layout.BoringWindows provides no provision for unmarking a marked-boring window
by codesite-noreply＠google.com 04 Mar '12

04 Mar '12

Status: New Owner: ---- New issue 497 by gopsycho...(a)gmail.com: Layout.BoringWindows provides no provision for unmarking a marked-boring window http://code.google.com/p/xmonad/issues/detail?id=497 No corresponding message to IsBoring Window is exported, so one cannot unmark, for instance, the currently-focused window. One may unmark *all* boring windows at once with the ClearBoring message, however. I suggest implementing either an UnmarkBoring Window, or a ToggleBoring Window message. A possible implementation of the latter is attached. Attachments: BoringWindows.diff 790 bytes

1 2

darcs patch: L.WorkspaceDir: cleanup redundant {definitions, imports}
by Steffen Schuldenzucker 29 Feb '12

29 Feb '12

1 patch for repository http://code.haskell.org/XMonadContrib: Wed Feb 29 12:21:24 CET 2012 Steffen Schuldenzucker <sschuldenzucker(a)uni-bonn.de> * L.WorkspaceDir: cleanup redundant {definitions,imports}

2 1

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

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

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

28 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