February 2011 - 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 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: 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

Problem with anti-aliased fonts in Java/Swing applications
by Christophe Garion 21 Jan '12

21 Jan '12

Hello, I have a problem with xmonad under Debian with no particular config (no Config.Gnome etc.): in every Swing application, fonts are not anti-aliased, which is ugly. If I add the -Dawt.useSystemAAFontSettings=on option when I start a jvm, fonts are anti-aliased. There is no global property file in Oracle jdk to configure this (notice that the problem is the same for openjdk). I can use the _JAVA_OPTIONS environment variable to set this option, but it adds comments in the console every time I launch a java application, which I do not want. There is no problem with GTK applications. If I start a gnome-session from xmonad, fonts in swing applications are correctly anti-aliased. Is there a way to correct this problem? Sorry if an answer has already been provided, but I did not find any searching the web and Xmonad website. Thanks in advance, Christophe -- Christophe Garion ISAE/DMIA - SUPAERO/IN garion(a)isae.fr 10 avenue Edouard Belin Tél : (33)5 61 33 80 57 BP 54032 Fax : (33)5 61 33 83 45 31055 Toulouse Cedex 4

3 4

Re: Issue 339 in xmonad: Support for toggling totem movie player fullscreen
by codesite-noreply＠google.com 02 Jan '12

02 Jan '12

Updates: Summary: Support for toggling totem movie player fullscreen Status: Accepted Labels: -Priority-Low Priority-Medium Comment #5 on issue 339 by wirtwo...(a)gmail.com: Support for toggling totem movie player fullscreen http://code.google.com/p/xmonad/issues/detail?id=339 Nice work audunskaugen. Thanks for researching this and providing the _NET_WM_STATE_FULLSCREEN event hook (totemFullscreen.hs sample xmonad.hs). IMO, this will be good to get into contrib soon to make it available for more usage, testing and further development. There are some aspects to improve so if anyone wants to take on ownership and submit a patch addressing them that would be great. Otherwise if no action in a week or so I'll send a patch to add it to EwmhDesktops as is, initially as a standalone 'fullscreenEventHook'. Eventually, though, I think it would be good to include an improved version in the standard ewmhDesktopsEventHook, plus having it available by itself. (sjanssen feedback on IRC when asked for thoughts as to where to put this: "enabling the full screen event hook in EWMH would be fine, and would probably make sense.") As is it gives more function for totem users and surely some other similar apps too than the current (0.9) situation, but also with some additional work it seems like it can cover uses of the doFullFloat manageHooks with isFullscreen and the fullscreen query alexey attached to http://code.google.com/p/xmonad/issues/detail?id=333 It seems it covers tiled to fullscreen and back usage plus allowing multihead users to focus other screens without affecting fullscreened apps. In my quick tests it works for totem, flash, mplayer, mplayer-plugin, gnome-mplayer plugin. (This is with all fullscreen manageHooks disabled.) It doesn't seem to help with ooimpress unfortunately, nor evince. Areas to address: * Toggling seems less smooth than it should be. In my tests it appears that the window untiles, goes to hinted float size, then finally fullscreen although it's hard to tell as it's very rapid. There is some glitch anyway that I didn't research yet as to cause. Also other tiled windows from the same workspace look briefly as if they are composited with the fullscreen app since they change size to fill the space as the fullscreen app floats. Not sure how much improvement can practically be made here, but hopefully can something close to the nice mapping with fullscreen manageHook. * Whether a window starts out tiled or floating, once toggled fullscreen and back it restores to tiled state. My reading of wm-spec and probably most users expectations is that floats return to float instead. I don't think PositionStore would be needed for this but didn't look into it yet either. audunskaugen, thanks again. If you'd like please send a darcs patch to X.Hooks.EwmhDesktops, or if you want to be credited by some other name you are welcome to email me privately with your preference and I'll include in any patch I prepare. -- 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 12

Issue 410 in xmonad: Real fullscreen support without floating
by codesite-noreply＠google.com 24 Dec '11

24 Dec '11

Status: New Owner: ---- New issue 410 by demelier.david: Real fullscreen support without floating http://code.google.com/p/xmonad/issues/detail?id=410 The mplayer fullscreen bug is a quite famous right now. Some people use NoBorders as workaround, but the window is still moveable. I mean real fullscreen as the window can't be moved by the user and of course won't have any borders without any workaround. This applies for mplayer's fullscreen mode, not for SDL.

1 3

Issue 363 in xmonad: non-positive argument error on NVidia Xinerama set
by codesite-noreply＠google.com 13 Dec '11

13 Dec '11

Status: New Owner: ---- New issue 363 by seanerussell: non-positive argument error on NVidia Xinerama set http://code.google.com/p/xmonad/issues/detail?id=363 What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". 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 10

Issue 412 in xmonad: Using a compositing manager shifts windows 2px to top and left
by codesite-noreply＠google.com 27 Nov '11

27 Nov '11

Status: New Owner: ---- New issue 412 by DaPatti: Using a compositing manager shifts windows 2px to top and left http://code.google.com/p/xmonad/issues/detail?id=412 What steps will reproduce the problem? 1. Start XMonad 2. Start cairo-compmgr or xcompmgr What is the expected output? What do you see instead? Instead of their normal positioning, windows are shifted to the top left a bit so that the borders on the top and left aren’t visible anymore. As soon as I kill the compositing manager, the windows are repositioned correctly. What version of the product are you using? On what operating system? XMonad 0.9.1; Arch Linux x86_64. Tried with cairo-compmgr-git and xcompmgr. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". The only relevant part might be borderWidth = 2. I don’t use FadeInactive or things like that. No messages on xmonad --recompile. Please provide any additional information below.

1 2