January 2012 - xmonad

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 12 Aug '12

12 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 24 Jul '12

24 Jul '12

Status: New Owner: ---- New issue 488 by Longp...@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 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

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

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

26 Feb '12

Status: New Owner: ---- New issue 472 by graude...@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

Comparison of "extensible window managers"
by Teika Kazura 16 Feb '12

16 Feb '12

Hi, Xmonad list. I think Xmonad is one of window managers "extensible" by users, or programmable, offering the API and allowing users to override the core code, or freely define new behaviors, though I haven't tried Xmonad actually yet. I'm a former developer of Sawfish which might be the first of such kind of WMs, using a Lisp dialect. I'm interested in comparing them, and created a wiki page for it: http://sawfish.wikia.com/wiki/Comparison_of_extensible_window_managers There Awesome and StumpWM are also studied. If someone is interested, please improve that article. Feel free to add any subjects. Or if you don't feel like editing wiki, you can comment here, and I'll do the actual edit. Of course I'll be glad to answer any questions about Sawfish. # I envy the fact that Xmonad's web site is so well tidy. I tried a lot # in improving Sawfish manual and wiki, but I felt as if I was trying # to move a mountain. With best regards, Teika (Teika kazura)

5 14

Issue 450 in xmonad: ManageDocks should check for multi window types in _NET_WM_WINDOW_TYPE
by codesite-noreply＠google.com 07 Feb '12

07 Feb '12

Status: New Owner: ---- New issue 450 by icarnales: ManageDocks should check for multi window types in _NET_WM_WINDOW_TYPE http://code.google.com/p/xmonad/issues/detail?id=450 According to the spec: _NET_WM_WINDOW_TYPE _NET_WM_WINDOW_TYPE, ATOM[]/32 This SHOULD be set by the Client before mapping to a list of atoms indicating the functional type of the window. This property SHOULD be used by the window manager in determining the decoration, stacking position and other behavior of the window. The Client SHOULD specify window types in order of preference (the first being most preferable) but MUST include at least one of the basic window type atoms from the list below. This is to allow for extension of the list of types whilst providing default behavior for Window Managers that do not recognize the extensions. http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html What steps will reproduce the problem? 1. Launch a program with multiple window types like DOCK and NORMAL (tested with unity-2d panel and launcher) What is the expected output? What do you see instead? The window should be ignored and a gap must be created to accommodate it. Instead the window is treated normally. What version of the product are you using? On what operating system? 0.9 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Any config with ManageDocks (tested with desktopConfig and manual ManageDocks) will do. Please provide any additional information below. I think checkDock function should be in a more generic place like Hooks/ManageHelpers that are currently using the isInProperty function to check for property values.

1 1