August 2010 - xmonad - Haskell.org

Issue 326 in xmonad: floating windows can break Actions.UpdatePointer
by codesite-noreply＠google.com 20 Feb '13

20 Feb '13

Status: New Owner: ---- New issue 326 by OrbisVicis: floating windows can break Actions.UpdatePointer http://code.google.com/p/xmonad/issues/detail?id=326 What steps will reproduce the problem? 1. UpdatePointer (TowardsCentre 1 1) 2. spiralWithDir West CW (4/5) 3. scratchpadManageHook (W.RationalRect 0.25 0.3 0.5 0.55) 4. Open two windows in the spiral layout, launch the scratchpad, and start tabbing 5. One of the windows will never receive focus -- 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 389 in xmonad: Some applications are unresponsive after workspace switch
by codesite-noreply＠google.com 13 Feb '13

13 Feb '13

Status: New Owner: ---- New issue 389 by mr.schyte: Some applications are unresponsive after workspace switch http://code.google.com/p/xmonad/issues/detail?id=389 What steps will reproduce the problem? 1. open an effected application (urxvt, gvim ...) 2. switch to another workspace 3. switch back What is the expected output? What do you see instead? After switching back the selected window doesn't register keyboard input, however after selecting another window (using alt-tab; mouse focus doesn't work) everything works fine until the next workspace switch. What version of the product are you using? On what operating system? xmonad 0.9.1, Linux synapse 2.6.32-ARCH #1 SMP PREEMPT Mon Mar 15 20:44:03 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz GenuineIntel GNU/Linux Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". The problem occurs even when using the default configuration. Please provide any additional information below. Some applications work, while others doesn't (xterm works, urxvt doesn't). -- 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 8

Issue 393 in xmonad: XMonad.Prompt.Shell should use user-defined searchPredicate
by codesite-noreply＠google.com 02 Feb '13

02 Feb '13

Status: New Owner: ---- New issue 393 by hgabreu: XMonad.Prompt.Shell should use user-defined searchPredicate http://code.google.com/p/xmonad/issues/detail?id=393 What steps will reproduce the problem? 1. Set-up XMonad.Prompt.Shell with defaulXPConfig changing the searchPredicate to something else. e.g. \x y -> map toLower x `isPrefixOf` map toLower y 2. run your prompt, start typing anything to see that your searchPredicate is ignored. In the above example case IS ignored, so typing 'VI' should show 'vi' or 'vim' on the list, but they're not. What version of the product are you using? On what operating system? latest darcs on up-to-date Archlinux x86_64 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". recompile prints nothing and my cluttered xmonad.hs is attached but only line 166 is related (which is a keybind to X.A.SpawnOn shellPromptHere). Please provide any additional information below. X.P.Shell also completes filenames using bash's compgen, it should respect user's setting (~/.inputrc) telling it to ignore-case (set completion- ignore-case on). But that's another problem, I'm just complaining about command completion for now. Attachments: xmonad.hs 16.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 5

Re: Issue 135 in xmonad: toggleBorders (XMonad.Action.NoBorders) Causes floating windows to grow in size
by codesite-noreply＠google.com 16 Jan '13

16 Jan '13

Comment #2 on issue 135 by neoraider: toggleBorders (XMonad.Action.NoBorders) Causes floating windows to grow in size http://code.google.com/p/xmonad/issues/detail?id=135 This bug occurred when I tried to disable the border of a Gnome-Do window automatically (it doesn't look nice with one), causing the Gnome-Do window to grow indefinitely, filling the whole screen after a few seconds. The attached patch solves the problem for me, making XMonad.Operations.floatLocation use the actual window border width instead of the globally configured one. Attachments: xmonad.patch 588 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 2

Re: Issue 306 in xmonad: Magnifier: keep magnified status if transient focused
by codesite-noreply＠google.com 11 Jan '13

11 Jan '13

Updates: Status: Accepted Labels: Type-Enhancement Component-Contrib Comment #3 on issue 306 by byorgey: Magnifier: keep magnified status if transient focused http://code.google.com/p/xmonad/issues/detail?id=306 This shouldn't be too difficult to implement (either Riccardo or Daniel's proposed behavior) given the new extensible state. -- 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 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