- xmonad - Haskell.org

darcs patch: GridSelect.hs: navigate grid with h, j, k, l as well as a...
by sean.escriva＠gmail.com 22 Nov '08

22 Nov '08

Sat Nov 22 00:47:25 PST 2008 sean.escriva(a)gmail.com * GridSelect.hs: navigate grid with h,j,k,l as well as arrow keys

2 1

Issue 97 in xmonad: xmonad stops responding to keyboard input after running xscreensaver
by codesite-noreply＠google.com 21 Nov '08

21 Nov '08

Comment #18 on issue 97 by kralph: xmonad stops responding to keyboard input after running xscreensaver http://code.google.com/p/xmonad/issues/detail?id=97 I haven't had this happen for a while now, so I think it had to do with configuration files. I'm attaching my xmonad.hs, .xsession, and xmobar.config so we can compare. I'm now using xscreensaver with locking and power saving, and Firefox 3.0.4 with no problems. Attachments: xmonad.hs 779 bytes .xsession 310 bytes xmobar.config 917 bytes -- 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 97 in xmonad: xmonad stops responding to keyboard input after running xscreensaver
by codesite-noreply＠google.com 20 Nov '08

20 Nov '08

Issue 97: xmonad stops responding to keyboard input after running xscreensaver http://code.google.com/p/xmonad/issues/detail?id=97 Comment #17 by drewfrank: Same trouble here -- xmonad randomly "freezes up" so that I can't switch to another desktop, invoke dmenu, or even shift-mod-q. If I am focused on an application at the time of the freeze, however, I can continue to control that single application with both my mouse and keyboard. Other than that, nothing works but ctrl-alt-backspace. This is very frustrating, because it's pretty much a deal-breaker for an otherwise excellent WM. I have no idea how to debug it. The only advice I've found that seems potentially relevant is this: http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#An_app_see… I added the relevant line to my xorg.conf, but control-alt-kpdivide doesn't seem to do anything for me at all. -- 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

Default settings: Prompt.hs's defaultXPConfig
by Gwern Branwen 18 Nov '08

18 Nov '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So, in my never-ending quest to have as short and concise an xmonad.hs as possible, I've turned my attention to my 'greenXPConfig'. This definition is eating up a gargantuan 10 lines of my xmonad.hs! Thus, I'm wondering about people's use of 'defaultXPConfig'; from Prompt.hs: defaultXPConfig :: XPConfig defaultXPConfig = XPC { font = "-misc-fixed-*-*-*-*-10-*-*-*-*-*-*-*" , bgColor = "#333333" , fgColor = "#FFFFFF" , fgHLight = "#000000" , bgHLight = "#BBBBBB" , borderColor = "#FFFFFF" , promptBorderWidth = 1 , position = Bottom , height = 18 , historySize = 256 , historyFilter = id , defaultText = [] , autoComplete = Nothing , showCompletionOnTab = False } According to my xmonad archive, 15 configurations make use of the default in some way. My question is: are these defaults really optimal? I'll take them in order. 1) The font strikes me as a bad setting. I checked it out just now, and my eyes water at the tininess of 10. It seems to me that a far more reasonable setting would be something like 14 or 16; but I don't know whether a 16 setting would be alright for EE users. I feel though that 10 works out for no one. 2) The color scheme is currently a sort of white-on-grey. It lacks contrast, IMO. Here I have 2 suggestions: 2.1) The current color values are pretty opaque. Unless you have color-values memorized, ', bgColor = "#333333"' is absolutely meaningless to you. Intrigeri's xmonad.hs has a XPConfig which looks like: fgColor = "grey80" , bgColor = "grey22" , borderColor = "grey22" The prompt appears much the same, but the values are far more comprehensible. Even if we don't change the color scheme, this would constitute a code cleanup IMO. 2.2) I would like to switch to either green text on black (which gets us bonus hacker points :) and better contrast), or white text on black - - as opposed to white text on gray. Thoughts on either color scheme? (Green-on-black would be , bgColor = "black"\n, fgColor = "green" obviously.) 3) Do people actually like the border? 5 xmonad.hss specifically disable it by setting 'promptBorderWidth = 0'. I confess it just seems like wasted space to me. It's not like a dark-gray/green/black background make it hard to make out the prompt against the application window. 4) Positioning: top, or bottom? I myself am weakly in favor of top. The configs are odd here - there are ~4 which set to Top, and 5 or so which set it to Bottom. Even though Bottom is the default. 4 configurations override the config to put the box at the top of the screen. ??? - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkbnO4ACgkQvpDo5Pfl1oJtZwCeP3AYcnR0CY8Qnh0eJHUfYUcI fI4AniFqx7+Ikclqvngb7989ZfMsJFAi =oDtp -----END PGP SIGNATURE-----

5 6

Issue 238 in xmonad: Layout.Monitor leaves Cairo-clock in tiling layer, causes windows to flicker randomly
by codesite-noreply＠google.com 17 Nov '08

17 Nov '08

Issue 238: Layout.Monitor leaves Cairo-clock in tiling layer, causes windows to flicker randomly http://code.google.com/p/xmonad/issues/detail?id=238 Comment #1 by r...(a)ro-che.info: Window must be unmanaged to work properly. Add , className =? "Cairo-clock"--> doIgnore to your manageHook. Documentation mentions that, but I'll make it more prominent, since it leads to confusion. Issue attribute updates: Status: Fixed Owner: r...(a)ro-che.info Labels: Documentation -- 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 238 in xmonad: Layout.Monitor leaves Cairo-clock in tiling layer, causes windows to flicker randomly
by codesite-noreply＠google.com 17 Nov '08

17 Nov '08

Issue 238: Layout.Monitor leaves Cairo-clock in tiling layer, causes windows to flicker randomly http://code.google.com/p/xmonad/issues/detail?id=238 New issue report by aleks.dimitrov: What steps will reproduce the problem? 1. Use a minimal XMonad.hs, something like: > import XMonad > import XMonad.Layout.Monitor > > myLayout = > addMonitor (ClassName "Cairo-clock" `And` Title "MacSlow's Cairo-Clock") > (Rectangle (1400-150) (1050-150) 150 150) > (XMonad.Tall 1 (1/2) (3/100)) > > main = do xmonad $ defaultConfig { > layoutHook = myLayout > } 2. Recompile XMonad, launch cairo-clock 3. Try to move around workspaces and windows What is the expected output? What do you see instead? I'd expect the clock just to sit there in the lower right corner of my desktop. Instead, it has its own window: http://omploader.org/veG55 When I move away from the workspace I launched cairo-clock on, everything shows up fine, but hovering the clock's window with the mouse pointer causes the focus to rapidly switch. Windows start to flicker, the whole desktop becomes unusable for about two seconds or so. What version of the product are you using? On what operating system? Arch Linux, current darcs version, cairo-clock is 0.3.4, cairo is 1.8.2-1, ghc is 6.8.2. Please provide any additional information below. Everytime I switch back to cairo-clock's original birth-workspace, it shows up in the upper left corner of its window in its original size (150x150) and then expands to the ugly ellipsoid you can see in the screenshot. This error also occurs with main xmonad.hs. Issue attributes: Status: New Owner: ---- -- 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 237 in xmonad: focusedBorderColor sometimes fails to follow focus after a window shuffle [low priority]
by codesite-noreply＠google.com 15 Nov '08

15 Nov '08

Issue 237: focusedBorderColor sometimes fails to follow focus after a window shuffle [low priority] http://code.google.com/p/xmonad/issues/detail?id=237 Comment #1 by thomas.szczarkowski: It occured to me - if your terminal background color is light, you should probably change the highlight color from "yellow" to something darker. -- 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 237 in xmonad: focusedBorderColor sometimes fails to follow focus after a window shuffle [low priority]
by codesite-noreply＠google.com 15 Nov '08

15 Nov '08

Issue 237: focusedBorderColor sometimes fails to follow focus after a window shuffle [low priority] http://code.google.com/p/xmonad/issues/detail?id=237 New issue report by thomas.szczarkowski: What steps will reproduce the problem? 1. Install the trivial xmonad.hs that is attached 2. Open an empty workspace: alt+[num] 3. Open two terminals: ctrl+shift+Enter twice (NB - no more than two windows, otherwise the bug may not appear!) 4. Shuffle with mod-shift-J. What is the expected output? What do you see instead? The focused window's border should be 'focusedWindowBorder'; instead it is 'normalWindowBorder'. The shuffle operation does not correctly update the window border colors. What version of the product are you using? On what operating system? 0.8, on Ubuntu 8.04/amd64 Attachments: xmonad.hs 120 bytes Issue attributes: Status: New Owner: ---- -- 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 212 in xmonad: xmonad and xkb features
by codesite-noreply＠google.com 14 Nov '08

14 Nov '08

Issue 212: xmonad and xkb features http://code.google.com/p/xmonad/issues/detail?id=212 Comment #6 by mauricio.antunes: Interesting! As I said, I only have this problem with xmonad, never with other window managers. However, it seems I never left the mouse for 120 seconds outside xmonad. After 'xkbset exp =m' everything works as expected. Thanks! Problem solved. -- 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 212 in xmonad: xmonad and xkb features
by codesite-noreply＠google.com 14 Nov '08

14 Nov '08

Issue 212: xmonad and xkb features http://code.google.com/p/xmonad/issues/detail?id=212 Comment #5 by hpnpwd: This problem seems no to be a bug of xmonad, but the feature of XKB. In default, the MouseKeys of XKB expires in 120 second (try "xkbset q exp"). You can change this expire time by executing "xkbset exp [TIME_IN_SECONDS]" Also, you can set MouseKeys not to expire by executing "xkbset exp m". But however, xkbset seems not to work in Ubuntu 8.04. So I updated to Ubuntu 8.10, then now xkbset works. -- 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