March 2010 - xmonad - Haskell.org

Re: Issue 304 in xmonad: CycleWS should actually track workspace history rather than depending on order of hidden workspaces
by codesite-noreply＠google.com 09 Jan '13

09 Jan '13

Updates: Summary: CycleWS should actually track workspace history rather than depending on order of hidden workspaces Status: Accepted Labels: Type-Enhancement Component-Contrib Comment #2 on issue 304 by byorgey: CycleWS should actually track workspace history rather than depending on order of hidden workspaces http://code.google.com/p/xmonad/issues/detail?id=304 The problem is that toggleWS simply assumes that the "previous workspace" is the one at the head of xmonad's internal list of hidden workspaces. But there are various operations other than switching away from a workspace which will also place it at the head of this list. There is nothing special about scratchpads here; if you shift any window on the current workspace to another workspace, that other workspace will now be the "previous workspace" as far as toggleWS is concerned. The real problem is that the order of workspaces in xmonad's list of hidden workspaces is not really supposed to mean anything, so toggleWS is depending on undefined behavior. The only way to really fix this would be to have CycleWS track the workspace history itself. Here's a sketch of a possible solution: CycleWS could use the new extensible state to track the workspace history, and provide something to put in the logHook that would notify CycleWS every time the current workspace changes. (It would be nicer if putting something in the logHook was not necessary, but otherwise it is not clear how CycleWS would find out about workspace changes.) -- 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

Re: Issue 316 in xmonad: AvoidStruts gives wrong window heights with vertically stacked screens
by codesite-noreply＠google.com 03 Jan '13

03 Jan '13

Comment #3 on issue 316 by liskni.si: AvoidStruts gives wrong window heights with vertically stacked screens http://code.google.com/p/xmonad/issues/detail?id=316 http://www.haskell.org/pipermail/xmonad/2009-November/009145.html This, I believe, fixed the issue and discusses why it changes the strut semantics incompatibly with wm-spec. -- 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 2

Re: Issue 240 in xmonad: recompilation fails silently
by codesite-noreply＠google.com 31 Dec '12

31 Dec '12

Updates: Status: Patch Owner: SpencerJanssen Comment #3 on issue 240 by vogt.adam: recompilation fails silently http://code.google.com/p/xmonad/issues/detail?id=240 Attached is a patch to accomplish the same indirectly by checking that the target executable is actually updated. But given that we have enough trouble to include the code for popping up an xmessage to welcome new users, then this patch might not be worth including since it addresses a rarer issue with somewhat more code. Attachments: check-that-the-expected-xmonad__arch__os-is-actually-updated_.dpatch 12.1 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 2

Re: Issue 211 in xmonad: Error output inconsistency
by codesite-noreply＠google.com 31 Dec '12

31 Dec '12

Comment #1 on issue 211 by byorgey: Error output inconsistency http://code.google.com/p/xmonad/issues/detail?id=211 Status? This seems like a pretty simple change, do other developers have an opinion on this? -- 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 360 in xmonad: shellPromptHere from XMonad.Actions.SpawnOn freezes upon files with Chinese names
by codesite-noreply＠google.com 15 Dec '12

15 Dec '12

Status: New Owner: ---- New issue 360 by wei.hoo: shellPromptHere from XMonad.Actions.SpawnOn freezes upon files with Chinese names http://code.google.com/p/xmonad/issues/detail?id=360 What steps will reproduce the problem? 1. Bind a key combination to shellPromptHere 2. mkdir /tmp/new; cd /tmp/new 3. touch 1; touch 测试 4. Invoke shellPromptHere, type in "emacs /tmp/new/", press TAB What is the expected output? What do you see instead? Observe that the shell prompt window freezes. No keybindings are accepted, such as C-a, C-e, C-g. However, XMonad keybindings are still effective. At this point we have to press M-q to restart XMonad. What version of the product are you using? On what operating system? xmonad-darcs and xmona-contrib-darcs on Arch Linux. GHC-6.12. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. If we remove /tmp/new/1 and only keep /tmp/new/测试, typing "emacs /tmp/new/ [TAB]" doesn't freeze the shell prompt. The Chinese-named file isn't shown in the completion, but we can still press C-g to cancel the shell prompt. The font I'm using does support Chinese. PS: I kind of remember this wasn't a problem with ghc-6.10, but I'm not sure. Attachments: xmonad.hs 6.8 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 1

Re: Issue 177 in xmonad: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol
by codesite-noreply＠google.com 04 Dec '12

04 Dec '12

Comment #24 on issue 177 by vogt.adam: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol http://code.google.com/p/xmonad/issues/detail?id=177 Geoff Reedy's last patch doesn't apply cleanly against latest darcs (due to the merging of extensible state stuff). Attached is a patch bundle including the old ones that probably works as the old one did. Attachments: track-currently-processing-event.dpatch 16.1 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

4 108

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

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