June 2013 - xmonad - Haskell.org

Issue 548 in xmonad: Feature request: greedyFocusWindow
by codesite-noreply＠google.com 19 Jun '13

19 Jun '13

Status: New Owner: ---- New issue 548 by yurac...(a)gmail.com: Feature request: greedyFocusWindow http://code.google.com/p/xmonad/issues/detail?id=548 It would be nice to have a greedy counterpart of the focusWindow function. I work with two screens, one of which is my main screen and the other one used occasionally. I use WindowGo.runOrRaise to focus my browser window and I expect the focusing to be greedy. Currently I use the following code (with focusWindowGreedy being a copy of focusWindow with view replaced by greedyView). If you find this relevant, I can provide a patch. Thanks! focusWindowGreedy :: (Eq s, Eq a, Eq i) => a -> W.StackSet i l a s sd -> W.StackSet i l a s sd focusWindowGreedy w s | Just w == W.peek s = s | otherwise = fromMaybe s $ do n <- W.findTag w s return $ until ((Just w ==) . W.peek) W.focusUp (W.greedyView n s) raiseGreedy :: Query Bool -> X () raiseGreedy = raiseMaybeGreedy $ return () runOrRaiseGreedy :: String -> Query Bool -> X () runOrRaiseGreedy = raiseMaybeGreedy . safeSpawnProg raiseMaybeGreedy :: X () -> Query Bool -> X () raiseMaybeGreedy f qry = ifWindow qry raiseHookGreedy f raiseHookGreedy :: ManageHook raiseHookGreedy = ask >>= doF . focusWindowGreedy browserQuery = className =? "Google-chrome" -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 2

darcs patch: DynamicBars-use-ExtensibleState
by gopsychonauts＠gmail.com 19 Jun '13

19 Jun '13

1 patch for repository http://code.haskell.org/XMonadContrib: Tue Jun 18 17:47:55 EST 2013 gopsychonauts(a)gmail.com * DynamicBars-use-ExtensibleState Hooks.DynamicBars was previously using an MVar and the unsafePerformIO hack ( http://www.haskell.org/haskellwiki/Top_level_mutable_state ) to store bar state. Since ExtensibleState exists to solve these sorts of problems, I've switched the file over to use unsafePerformIO instead. Some functions' types had to be changed to allow access to XState, but the public API is unchanged.

2 1

Issue 547 in xmonad: XMonad.Prompt.Shell does not open a prompt if a directory in PATH is inaccessible
by codesite-noreply＠google.com 17 Jun '13

17 Jun '13

Status: New Owner: ---- New issue 547 by ttue...(a)gmail.com: XMonad.Prompt.Shell does not open a prompt if a directory in PATH is inaccessible http://code.google.com/p/xmonad/issues/detail?id=547 What steps will reproduce the problem? 1. Add a directory to PATH that user does not have permission to access. 2. Try to open a shell prompt. What is the expected output? What do you see instead? The prompt does not appear. I would expect a prompt to open, although tab completion obviously will not know about commands below the inaccessible directory. What version of the product are you using? On what operating system? xmonad-0.11, xmonad-contrib-0.11.1 Solution: If a directory in the PATH is inaccessible, getDirectoryContents will throw an exception. The exception prevents the tab completion list from being compiled and the prompt from being opened. If an exception is encountered accessing any element of PATH for any reason, I think the response should simply be to return an empty list of commands for that element. I am attaching a patch that does exactly that. Attachments: catch-exceptions-when-finding-commands-on-path-in-prompt_shell.dpatch 8.8 KB -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 3

Issue 546 in xmonad: Suggested improvement to CycleRecentWS for multiple screens
by codesite-noreply＠google.com 03 Jun '13

03 Jun '13

Status: New Owner: ---- New issue 546 by ch...(a)cmears.id.au: Suggested improvement to CycleRecentWS for multiple screens http://code.google.com/p/xmonad/issues/detail?id=546 XMonad.Action.CycleRecentWS defines a function to cycle through workspaces according to how recently they were shown. The code specifically puts the current workspace at the end (although it is technically the most recent), which is a good idea. With multiple screens, the visible workspace on the other screen is then considered to be the most recent visible workspace, so it switches there first. I reckon it should not do this, and instead that workspace should be demoted to the end of the list, just like the current one. Here is my suggested change to cycleRecentWS. I can't be really confident that I fixed it the right way, but it does seem to work for me. cycleRecentWS = cycleWindowSets options where options w = map (view `flip` w) (recentTags w) nscreens w = length (screens w) recentTags w = map tag $ drop (nscreens w) (workspaces w) ++ reverse (take (nscreens w) (workspaces w)) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 5