- xmonad - Haskell.org

many dzen instances
by Jesús Guerrero 02 Sep '08

02 Sep '08

Hello, I am including two new instances of dzen2 to monitor my local box and a remote machine using a piped conky. It mostly works, however there's a minor -I hope- glitch. The two new instances of dzen appears above the windows. There's another -previous- instance of dzen on the top of the screen which I use to log info about the workspaces, layouts and window title. That one fits ok into the layout without a problem. http://jesgue.homelinux.org/other-files/3-dzens.jpg In the pic you can see the problem illustrated. And the relevant snippet from my config is: ===================================== -- dynamiclog pretty printer for dzen robPP h = defaultPP { ppCurrent = wrap "^fg(#000000)^bg(#0390e1)^p(2)" "^p(2)^fg()^bg()" , ppHidden = wrap "^fg(#0390e1)" "^fg()^bg()" , ppHiddenNoWindows = wrap "^fg(grey70)" "^fg()^bg()" , ppSep = " ^fg(gray70)^r(3x3)^fg() " , ppTitle = dzenColor "#90e103" "" . wrap "[ " " ]" , ppOutput = hPutStrLn h } statusBarCmd = "dzen2 -bg '#222222' -fg '#00ff00' -sa c -fn '-*-dejavu sans-*-r-*-*-12-*-*-*-*-*-*-*' -e '' -xs 1" statusBarCmd2 = "ssh root@server conky | dzen2 -bg '#222222' -fg '#00ff00' -sa l -fn '-*-dejavu sans-*-r-*-*-11-*-*-*-*-*-*-*' -e '' -xs 1 -y 1160" statusBarCmd3 = "conky -c ~/.conkyrc-xmonad | dzen2 -bg '#222222' -fg '#00ff00' -sa l -fn '-*-dejavu sans-*-r-*-*-11-*-*-*-*-*-*-*' -e '' -xs 1 -y 1180" main = do din <- spawnPipe statusBarCmd din2 <- spawnPipe statusBarCmd2 din3 <- spawnPipe statusBarCmd3 xmonad $ defaultConfig { terminal = myTerminal , focusFollowsMouse = myFocusFollowsMouse , borderWidth = myBorderWidth , modMask = myModMask , numlockMask = myNumlockMask , workspaces = myWorkspaces , normalBorderColor = myNormalBorderColor , focusedBorderColor = myFocusedBorderColor , keys = myKeys , mouseBindings = myMouseBindings , manageHook = manageDocks <+> manageHook defaultConfig <+> myManageHook , logHook = dynamicLogWithPP $ robPP din , layoutHook = myLayout , startupHook = myStartupHook } ===================================== My question is why does one instance of dzen is respected by the layout, and the other two are ignored? Or, how to make the two dzens at the bottom fit into my layout, so they do not mess up the visibility of my windows. Thanks for reading. -- Jesús Guerrero <i92guboj(a)terra.es>

1 0

Issue 212 in xmonad: xmonad and xkb features
by codesite-noreply＠google.com 02 Sep '08

02 Sep '08

Issue 212: xmonad and xkb features http://code.google.com/p/xmonad/issues/detail?id=212 New issue report by mauricio.antunes: What steps will reproduce the problem? 1. Just use xmonad for a few minutes What is the expected output? What do you see instead? I use a xkb feature that allows one to press Ctrl-Shift-NumLock and then control the mouse with the keyboard. After a while, that feature just stops working. I can restart it, although it will be disabled again after some time. I don't have that problem with the other window manager I use (metacity, I think). What version of the product are you using? On what operating system? I'm using version 0.7 in Ubuntu 8.04. The problem already existed in xmonad 0.6. I do have the same problem if I config xmonad not to use any contrib extensions. I'm attaching my xorg.conf. Attachments: xorg.conf 1.3 KB Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- 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 211 in xmonad: Error output inconsistency
by codesite-noreply＠google.com 01 Sep '08

01 Sep '08

Issue 211: Error output inconsistency http://code.google.com/p/xmonad/issues/detail?id=211 New issue report by m...(a)twifkak.com: Some of our output goes to xmonad.errors, and some goes to stdout/stderr. Our xmessage only says to check the former. I suggest we consolidate to one output. Since stdout/err logging is computer-dependent, I suggest we should log everything to the .errors file. Issue attributes: Status: Accepted Owner: m...(a)twifkak.com Labels: Type-Defect Priority-Low Component-Core Usability -- 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 210 in xmonad: xmonad.hs not accepted, xmonad.errors empty
by codesite-noreply＠google.com 01 Sep '08

01 Sep '08

Issue 210: xmonad.hs not accepted, xmonad.errors empty http://code.google.com/p/xmonad/issues/detail?id=210 New issue report by h.stenstrom: What steps will reproduce the problem? 1. Install latest xmonad on Ubuntu 2. Create the directory ~/.xmonad 3. Copy the file xmonad.hs.gz from /usr/share/doc/libghc6-xmonad-doc/examples and ungzip it. 4. Log out 5. Tell gdm that you want xmonad as a window manager 6. There is one window, which fills the screen. It says: Error detected while loading xmonad configuration file: /localhome/helge/.xmonad/xmonad.hs Please check the file for errors. (note: my account is not on /home, but on /localhome. I use /home for NIS accounts only) 7. Note that there is a newly created or updated file ~/xmonad/xmonad.errors. Note that it is empty (0 bytes) 8. Deliberately insert some syntax errors in the xmonad.hs file, to see if they are logged in the xmonad.errors file. 9. Note that the error file is still empty. What is the expected output? What do you see instead? I expect error explanations in the xmonad.errors file Or I expect the example file to work out-of-the-box. What version of the product are you using? On what operating system? xmonad: 0.6-3 OS: Ubuntu 8.04 (Linux) Please provide any additional information below. There is a file ~/.xsession-errors which has the following last line: /localhome/helge/.xmonad/xmonad-i386-linux: executeFile: does not exist (No such file or directory) Indeed, there is no such file. I created the directory myself. How should the file come into existance? If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' below. Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- 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 209 in xmonad: Re-layouting when switching workspaces
by codesite-noreply＠google.com 01 Sep '08

01 Sep '08

Issue 209: Re-layouting when switching workspaces http://code.google.com/p/xmonad/issues/detail?id=209 Comment #4 by tommi.virtanen: I have the standard mod+h/l binding. I am not complaining about the switch from workspace 1 to 2 redrawing to adjust layout from 1 to 2; I am complaining about the switch first redrawing windows of workspace 2 based on the unadjusted layout, then based on the adjusted layout. -- 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 209 in xmonad: Re-layouting when switching workspaces
by codesite-noreply＠google.com 31 Aug '08

31 Aug '08

Issue 209: Re-layouting when switching workspaces http://code.google.com/p/xmonad/issues/detail?id=209 Comment #3 by Braden.Shepherdson: Okay, I think I see where the confusion came from. When you adjust the layout on one workspace with mod+h/l it doesn't typically change the layout of other workspaces. Each workspace is independent of the others. Do your workspaces all change layout together? Do you have nonstandard bindings for mod+h/l? -- 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 209 in xmonad: Re-layouting when switching workspaces
by codesite-noreply＠google.com 31 Aug '08

31 Aug '08

Issue 209: Re-layouting when switching workspaces http://code.google.com/p/xmonad/issues/detail?id=209 Comment #2 by tommi.virtanen: This isn't about old workspace's layout. The bug is that it draws first the *unadjusted* new workspace layout, and then the *adjusted* new workspace layout. Remember the part about alt-l above.. It doesn't take that long but causes annoying flicker. -- 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 209 in xmonad: Re-layouting when switching workspaces
by codesite-noreply＠google.com 30 Aug '08

30 Aug '08

Issue 209: Re-layouting when switching workspaces http://code.google.com/p/xmonad/issues/detail?id=209 Comment #1 by Braden.Shepherdson: What's the time scale here? If this all happens in half a second, I don't think it's a bug. If it's an obvious, drawn out process of: * fully redraw under old workspace's layout * fully redraw under this workspace's layout that's quite visible, then maybe it is a bug. -- 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 209 in xmonad: Re-layouting when switching workspaces
by codesite-noreply＠google.com 30 Aug '08

30 Aug '08

Issue 209: Re-layouting when switching workspaces http://code.google.com/p/xmonad/issues/detail?id=209 New issue report by tommi.virtanen: What steps will reproduce the problem? 1. Open two workspaces (say alt-1, alt-2) with some windows (say Firefox, as the slow redraw makes the bug more apparent) 2. Adjust the layout in both (e.g. alt-l a few times) 3. Toggle between the workspaces (alt-1, alt-2) What is the expected output? What do you see instead? I expected the workspace switch to draw the layout in its adjusted form. Instead, I see a redraw of the unadjusted layout, immediately followed by the adjusted layout (alt-l). I'm using a ResizableTall 1 (6/100) (1/2) [] layout on both workspaces. What version of the product are you using? On what operating system? Ubuntu Hardy with xmonad 0.7-1~hardy1, rebuilt for Xinerama support. Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- 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 208 in xmonad: Focus on mouse enter seems racy with Xinerama
by codesite-noreply＠google.com 30 Aug '08

30 Aug '08

Issue 208: Focus on mouse enter seems racy with Xinerama http://code.google.com/p/xmonad/issues/detail?id=208 New issue report by tommi.virtanen: I have a fullscreen mplayer playing on a second Xinerama head and miscellaneous windows open on the main screen. Both heads are using a ResizableTall layout. It seems that if I move the pointer quickly from the main screen to the screen with mplayer, focus stays where it was. I need to move the pointer back, and then move it over slower, to get the focus on mplayer. It seems reasonably hard to reproduce reliably, but has happened to me several times within this movie. It might be related to my main screen being 1680x1050, and the mplayer being 1280x800. The mplayer screen is above of the main screen, so there's an area on the right where the mouse can enter no mans land. However, even if I move the pointer there first, the bug is only reproducible with very fast movement. I'm running Ubuntu Hardy's xmonad 0.7-1~hardy1, recompiled to support Xinerama. Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- 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