October 2012 - xmonad

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

Updated old patch for bug 225
by Conrad Irwin 03 Jan '13

03 Jan '13

Hello Xmonad, I applied the patch mentioned at http://code.google.com/p/xmonad/issues/detail?id=225 to a current version of Xmonad. This may be useful to other people who also want the same behaviour, Conrad

2 1

Issue 429 in xmonad: X.A.DynamicWorkspaces command to delete specified tag
by codesite-noreply＠google.com 03 Jan '13

03 Jan '13

Status: New Owner: ---- New issue 429 by jjfoe...(a)earthlink.net: X.A.DynamicWorkspaces command to delete specified tag http://code.google.com/p/xmonad/issues/detail?id=429 X.A.DynamicWorkspaces contains 'removeWorkspace' which deletes the current workspace. It would be useful to me to have a similar command with which I could delete any workspace by name. I would use this to write a 'workspaces cleanup' procedure that auto-deletes empty auxiliary workspaces.

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 242 in xmonad: inter screen handling doesn't work with xrandr --right-of, works with --left-of
by codesite-noreply＠google.com 01 Jan '13

01 Jan '13

Comment #1 on issue 242 by nwfilardo: inter screen handling doesn't work with xrandr --right-of, works with --left-of http://code.google.com/p/xmonad/issues/detail?id=242 At least on my ThinkPad X200, the problem is that the LVDS output is not by default the primary display. It appears that the particular xinerama calls xmonad makes do not enumerate displays in left-to-right order but in some other order (as might be obvious, I'm not an expert at X11). Try running "xrandr --output LVDS --primary"; then -w should be the LVDS panel and -e should be the VGA output.

1 5

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: [xmonad] Issue 225 in xmonad: Allow single click to focus and pass click to window
by codesite-noreply＠google.com 31 Dec '12

31 Dec '12

Updates: Summary: Allow single click to focus and pass click to window Comment #8 on issue 225 by wirtwo...(a)gmail.com: Allow single click to focus and pass click to window http://code.google.com/p/xmonad/issues/detail?id=225 cirwin on #xmonad reports that manually merging the code in the referenced patch with current darcs enables one click to focus and pass the event to the window. An updated patch that applies cleanly to current darcs X.Main and X.Operations would be welcome. Updating title to remove "synthetic events" since they are not relevant here.

1 7

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 507 in xmonad: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14
by codesite-noreply＠google.com 25 Dec '12

25 Dec '12

Status: New Owner: ---- New issue 507 by smp...(a)gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 **What steps will reproduce the problem?** I'm not sure that I can exactly describe how I get it. Generally speaking, it's `shellPrompt' call and fast `t' pressing. Than I get xmonad totally freezed and message in terminal where I call `xinit', which run xmonad: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 At 601 line of Prompt.hs there is unsafe pattern matching: Just bgcolor <- io $ initColor d (bgColor c) Just border <- io $ initColor d (borderColor c) **What is the expected output? What do you see instead?** What I want is some `fromJust' there or hadling this situation with `case'. It's xmonad-contrib-0.10-r1 build from gentoo-haskell overlay. (https://github.com/gentoo-haskell/gentoo-haskell/tree/master/x11-wm/xmonad-…)

1 11

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