- xmonad - Haskell.org

Issue 65 in xmonad: mplayer window fails to be drawn
by codesite-noreply＠google.com 09 Jul '08

09 Jul '08

Issue 65: mplayer window fails to be drawn http://code.google.com/p/xmonad/issues/detail?id=65 Comment #2 by lithis7: Is this the same issue as 79? I still have trouble with fullscreen VLC, as mentioned in 79. -- 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 0

Issue 65 in xmonad: mplayer window fails to be drawn
by codesite-noreply＠google.com 09 Jul '08

09 Jul '08

Issue 65: mplayer window fails to be drawn http://code.google.com/p/xmonad/issues/detail?id=65 Comment #1 by antoniosantoniadis: I think that this issue is fixed. Although I don't run the specific linux kernel to try, it works perfectly here (FreeBSD 7.0). Also considering the date of reporting the issue and the version of xmonad, I'm strongly suspecting that it should be fixed. -- 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 0

Re: noobish
by Bastian Webster 08 Jul '08

08 Jul '08

> That doesn’t sound familiar, but old versions of xmobar > didn’t work quite right with multiple monitors. What version > of xmobar are you running, and what is the position line of > your xmobar config? I am using version 0.9. The position line is: position = Static { xpos = 0, ypos = 0, width = 1440, height = 15 } What should I change the position line to?

3 3

Re: noobish
by Bastian Webster 08 Jul '08

08 Jul '08

Thank you very much. That worked. =-)

1 0

Floating gnome-do
by Tom Thorne 08 Jul '08

08 Jul '08

I've been trying to get a floating gnome-do without much success, I've never programmed haskell before so i'm just cutting and pasting other peoples xmonad.hs together! this is what my xmonad.hs looks like (I don't have a haskell mode for emacs either hence the no doubt hideous indentation) import XMonad import XMonad.Hooks.ManageDocks import XMonad.Hooks.DynamicLog main = dzen $ \x -> xmonad $x { terminal = "terminal" , focusedBorderColor = "blue" , manageHook = myMHook <+> manageHook defaultConfig , layoutHook = avoidStruts $ layoutHook defaultConfig } myMHook = composeAll . concat $ [ [manageDocks], [resource =? "Do.exe" --> doIgnore, title =? "Downloads" --> doFloat ] ] Obviously this doesnt work

3 4

noobish: xmobar and avoidStruts
by Bastian Webster 08 Jul '08

08 Jul '08

I have xmonad and xmonad-contrib 0.7 installed and running. I am trying to have xmobar running in it's own space on the top of the screen. When I start or restart xmonad, the windows make a gap correctly, and xmobar is shown correctly. But when I switch to the next monitor and then back again, xmobar disappears, but the space for xmobar remains. When I switch to the next monitor and back again, then the space for xmobar disappears and I can't get my xmobar instance back again without restarting xmonad. I am completely new to xmonad, haskell, etc. I have been going through the xmonad.hs samples looking for something that will get this working. I have not found anything that will keep xmobar showing. Thanks for you help. --- Bastian Webster

2 1

Screen workspaces not working on new Ubuntu 8.04 amd64 install
by Adr3nal D0S 08 Jul '08

08 Jul '08

I was using Xmonad quite successfully on Slackware 12 and 12.1. However, we were recently forced to switch to 64-bit Ubuntu 8.04 at work. Under Slackware I was able to have a separate workspace on my left and right monitors. With Hardy I have a single workspace that spans both monitors. I've even gone so far as using the same xorg.conf on both and the hand-built Xmonad I was using under Slackware, yet the behavior persists. Comparing the xdpyinfo output and the xorg.0.logs the only major difference that I see is Hardy has DRI working and a few newer versions of some X modules. I am at a loss as to what could cause this. But it makes Xmonad useless to me and I'm dying in Gnome. Please help.

3 3

Issue 168 in xmonad: gnome-panel with autohide enabled appears behind main windows
by codesite-noreply＠google.com 07 Jul '08

07 Jul '08

Issue 168: gnome-panel with autohide enabled appears behind main windows http://code.google.com/p/xmonad/issues/detail?id=168 Comment #1 by gwern0: Just to add a comment: I can reproduce this in darcs XMonad, Ubuntu Hardy Heron, using ManageDocks as well (see my xmonad.hs). This bug is kind of annoying, since autohide is the best way to save gnome-panel wasted space (once you've consolidated into a single panel and have shrunk it down as much as possible), even if you can work around it by going to an empty workspace. -- 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

5 7

Issue 168 in xmonad: gnome-panel with autohide enabled appears behind main windows
by codesite-noreply＠google.com 07 Jul '08

07 Jul '08

Issue 168: gnome-panel with autohide enabled appears behind main windows http://code.google.com/p/xmonad/issues/detail?id=168 Comment #2 by jus...(a)justinbogner.com: Attached are two patches that partially resolve this issue, but they both come with their own problems, and probably shouldn't go into the mainline without further consideration. I'm providing them in hopes that they help the discussion of the issue. (I sent the first of these to the mailing list, but I'd like it to be on the bug tracker, as per shepheb's suggestion on the list. visibleStruts.patch brings strut windows to the top of X's stacking order, which seems an appropriate thing to do. The problem here is that this breaks toggleStruts, since xmonad covers up struts by using their space, but not hiding the strut. hiddenStruts.patch unmaps struts that aren't being avoided, and maps them again when they are being avoided. This way, hiding and showing struts behaves somewhat more sanely, instead of just drawing over the panel, we remove the panel from the screen. Perhaps unfortunately though, this means that if avoidStrutsOn is being used, any struts that aren't being avoided will always be invisible --- I'm not sure if this is what people want. I strongly encourage anyone who uses avoidStrutsOn to test this patch and give feedback on whether or not the behaviour makes sense. Attachments: visibleStruts.patch 22.2 KB hiddenStruts.patch 23.3 KB -- 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 0

XMonad and another window-manager
by Stefan Monnier 05 Jul '08

05 Jul '08

I accidentally run `xmonad' (version 0.7 from Debian testing) while I had another window manager running, and rather than signal an error it went ahead and shuffled the windows. Is that intended? Stefan

2 1