- xmonad - Haskell.org

Issue 549 in xmonad: OPTIONS Pragma Deprecated
by codesite-noreply＠google.com 20 Jun '13

20 Jun '13

Status: New Owner: ---- New issue 549 by ad.mason...(a)gmail.com: OPTIONS Pragma Deprecated http://code.google.com/p/xmonad/issues/detail?id=549 The following files contain the deprecated OPTIONS pragma: xmonad/XMonad/Config.hs xmonad/tests/Properties.hs XMonadContrib/XMonad/Config/Bluetile.hs According to Section 7.18.2. OPTIONS_GHC pragma in the latest GHC documentation, OPTIONS_GHC should be used in place of OPTIONS (http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html) This issue was found in the latest (as of today) development darcs repo for xmonad and XMonadContrib. The following script was used to discover the used OPTIONS pragma in named files, using the find and grep utilities in FreeBSD 9.1: find ./ -type f -exec egrep -q "^{-# OPTIONS .*#-}$" {} \; -print I am a beginner Haskell programmer and Xmonad user so I have not yet been able to check whether the latest ghc ignores the OPTIONS pragma. -- 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 0

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

Multi-display layout help
by Mark Watts 30 May '13

30 May '13

Hi, I have two monitors and I'd like to configure Xmonad so that if I switch to a workspace and it's on a different monitor from the one with the currently focused window, the workspace gets pulled to that monitor, BUT when I leave that workspace it should return to the monitor it was pulled from. Is there a layout that already handles this? -- Cheers, Mark Watts Department of Computer Science University of Texas at Austin

1 0

rcxterm - a colorful terminal emulator script that goes great with xmonad.
by Yanom Mobis 26 May '13

26 May '13

Tired of all your terminals having the same color scheme? I wrote program that fixes that. #!/usr/bin/python import random import os available_colors = ["magenta","yellow", "white", "green", "cyan", "orange","red"] fontsize = 22 font = "terminus" color = random.choice(available_colors) font = "-*-" + font + "-*-*-*-*-" + str(fontsize) + "-*-*-*-*-*-*-*" command = 'xterm -font \"' + font + '\" -bg black' + ' -fg ' + color os.system(command) save that as /usr/bin/rcxterm and make it executable. Now set terminal="rcxterm" in xmonad.hs. Now, every time you open an XTerm, it gets assigned a random foreground color from the list. Here's a screenshot: http://i43.tinypic.com/334us1e.png You may have to change font = "terminus" to a font name you have on your system. The xfontsel program can find one for you. Also, I'm pretty sure there's a way to write this script in Haskell, but I only know Python. enjoy!

1 0

XMonad.Layout.ShowWName patch
by FA - ML 18 May '13

18 May '13

Hello, I use xmonad on a 512MB laptop. I noticed that using |showWName| (from XMonad.Layout.ShowWName) in my layoutHook slowed down Xmonad when switching between workspaces. I logged into #xmonad and enquired about it. Let me quote user geekosaur, who correctly diagnosed the problem: geekosaur "The XSync function flushes the output buffer and then waits until all requests have been received and processed by the X server." that's gonna hurt... geekosaur looks like a case of premature optimization, from the patch history So I deleted that particular call; workspace switching is more responsive after that (on my other machine, with more RAM, the difference is barely noticeable). I attach the .dpatch -Francesco

3 2

Xmonad 0.10, Xfce, Wheezy Stable
by Alexander Genaud 17 May '13

17 May '13

Hello All, In the four years I've been using Xmonad, I have only convinced one other human to try it and she too has become an addict. For most of that time, I had been using Ubuntu with either Gnome 2 or fallback/classic. However, in an attempt to ween myself from most DE candy, I have installed stable Debian Wheezy with Xfce. Starting up Xmonad, Xfce on Wheezy was much easier than the Xmonad wiki would have you believe. I installed xmonad and libghc6-xmonad-contrib-dev, a four line xmonad.hs using xfceConfig, and had the option to choose the WM at login. But I am having some trouble with the panel. Perhaps you can help. Because I do not need it often, I am starting the xfce4-panel from the command line as needed. But the panel behaves strangely: floating above or behind other windows. Only after moving windows around to different workspaces, the panel eventually behaves like other well tiled windows. I wonder if there is a better way. Can I have the panel hidden by default but appear with the standard mod-b key? Should I be concerned by these warnings whenever I start xfce4-panel?: "g_error_new_valist: runtime check failed (domain ! = 0)" and "Failed to connect to session manager: SESSION_MANAGER environment variable not defined" Also I'm curious. Is there any difference between xfceConfig and desktopConfig? Cheers, Alex [ B068 ED90 F47B 0965 2953 9FC3 EE9C C4D5 3E51 A207 ]

3 5

Re: [xmonad] XMonad avoidStruts really slow
by Joachim Breitner 14 May '13

14 May '13

Dear Svein, Am Donnerstag, den 25.04.2013, 15:49 +0100 schrieb Svein Ove Aas: > I've had some speed issues with XMonad and Chrome lately, which I > eventually tracked to avoidStruts. (And Chrome, but never mind that.) > > > I think the problem is probably that ManageDocks.calcGap recalculates > the gap every time you switch windows, and not for instance every time > a new window is created.. but that's as much as I've managed to figure > out. > > > Things work pretty well if I just swap avoidStruts for a > statically-configured 16-pixel gap, so I'm going to leave it at this > for now, in hopes that the fix will be immediately obvious to you. I > might give it a shot if you don't have time, though. thanks for spotting the issue! It’s been a while since I hacked on xmonad, and I don’t see an immediate fix. Some way to approach it would be to extend the xmonad core so that the result of getStrut is stored along with the window. Another way would be to extend the datatype of the AvoidStruts to remember some data. But what? The gap? The strut of each window? Only on the current workspace or everywhere? I suggest you take this discussion on the xmonad mailing list, which I have CCed, and maybe you can come up with a fix! Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

3 2