- xmonad - Haskell.org

Issue 436 in xmonad: XMonad.Layout.IM doesn't match UTF8 chars
by codesite-noreply＠google.com 15 Jul '13

15 Jul '13

Status: New Owner: ---- New issue 436 by o.a.stephens: XMonad.Layout.IM doesn't match UTF8 chars http://code.google.com/p/xmonad/issues/detail?id=436 I am encountering the same issue as per http://code.google.com/p/xmonad/issues/detail?id=302 using his same test case. What steps will reproduce the problem? 1. Configure withIM layout to match a window title with UTF8 chars as roster. Ex: withIM (1%7) (Title "foo™") (Tall 1 0.5 0.5) 2. Run a window with the configured name. Ex: xterm -T "foo™" -e read What is the expected output? What do you see instead? The window should be placed as withIM layout roster. In this case, on a separated column to the left. What version of the product are you using? On what operating system? Latest XMonad Darcs on Arch X86_64. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". No output from xmonad --recompile. Please provide any additional information below. Comments from #xmonad having queried my issue: <allbery_b> I'm looking at darcs... WindowProperties uses the ManageHook code (!! --- more evidence that it's mis-typed) and ManageHook.hs in the core uses getStringProperty everywhere <allbery_b> (in particular it's using it for _NET_WM_* which is completely wrong as they are all defined as Unicode stored as 32 bit lists) <allbery_b> suggest you reopen that bug report, or file a new one about _NET_WM_* being misinterpreted I am attempting to match Skype's window title, which also contains the ™ character. Attachments: xmonad.hs 483 bytes

1 3

Issue 551 in xmonad: XMonad.Prompt.Man.manPrompt uses `manpath -g`, -g appears to be an invalid option
by codesite-noreply＠google.com 08 Jul '13

08 Jul '13

Status: New Owner: ---- New issue 551 by ondrej.g...(a)gmail.com: XMonad.Prompt.Man.manPrompt uses `manpath -g`, -g appears to be an invalid option http://code.google.com/p/xmonad/issues/detail?id=551 What steps will reproduce the problem? 1. import XMonad.Prompt.Man and set up manPrompt 2. activate and use manPrompt 3. What is the expected output? What do you see instead? manPrompt should provide man pages completion but it shows only CWD directories as completion What version of the product are you using? On what operating system? Gentoo 64bit Linux kernel 3.7.10-gentoo-r1 xmonad and xmonad contrib v 0.11 standard man v 1.6g (from http://primates.ximian.com/~flucifredi/man/) Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". no output from xmonad --recompile, xmonad.hs attached (clean, not the source of the problem) Please provide any additional information below. The whole problem is the line in getMans paths <- getCommandOutput "manpath -g 2>/dev/null" `E.catch` on my system, manpath does not have the -g option so it fails silently and does not output any paths, so then the CWD path is examined instead I don't know when this option was removed, man v 1.6f doesn't have it either. Attachments: xmonad.hs 6.2 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 2

darcs patch: dynamicbars-partial-cleanup
by Ben Boeckel 05 Jul '13

05 Jul '13

1 patch for repository http://code.haskell.org/XMonadContrib: Fri Jul 5 00:45:10 EDT 2013 Ben Boeckel <mathstuf(a)gmail.com> * dynamicbars-partial-cleanup Add functions to allow cleaning up only screens which disappear. This works better where killing the statusbar for a specific screen is possible. The old way is still relevant for setups which do not have such a method (e.g., safeSpawn xmobar/spawnPipe xmonadpropwrite).

1 0

Issue 550 in xmonad: Feature request: configurable restack order
by codesite-noreply＠google.com 02 Jul '13

02 Jul '13

Status: New Owner: ---- New issue 550 by yurac...(a)gmail.com: Feature request: configurable restack order http://code.google.com/p/xmonad/issues/detail?id=550 It would be nice to be able to modify the window stacking order. Currently the core forces floating windows on top of the liled ones. I attach a patch that makes the stacking order configurable through layouts. The patch also contains a layout modifier that restacks windows in fifo order - regardless of whether floating or not. For example, if window A is focused and I now focus window B, then B moves on top of A in the stacking order and the rest remain unchanged. This behavior is the one I like. It is natural for someone who works a lot with floating windows. However, I found no way to get such behavior without modifying the core. Note that my patch cooperates well with the UpdatePointer action. In my config file I also disabled focusFollowsMouse, but this is optional. Hope this can be useful. Thanks Attachments: restack.diff 3.7 KB restackContrib.diff 4.6 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 0

jack, please add me to your LinkedIn network
by Joe Skinner 01 Jul '13

01 Jul '13

LinkedIn ------------ Joe Skinner requested to add you as a connection on LinkedIn: ------------------------------------------ jack, I'd like to add you to my professional network on LinkedIn. - Joe Accept invitation from Joe Skinner http://www.linkedin.com/e/irg6ht-hilbgay5-3h/XryFXUFKTikI8JZsT8K-I6F1Czm83Q… View profile of Joe Skinner http://www.linkedin.com/e/irg6ht-hilbgay5-3h/rso/17674314/eftS/name/1415177… ------------------------------------------ You are receiving Invitation emails. This email was intended for jack birdsong. Learn why this is included: http://www.linkedin.com/e/irg6ht-hilbgay5-3h/plh/http%3A%2F%2Fhelp%2Elinked… (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

1 0

screen resolution and xmobar
by Yakir Gagnon 27 Jun '13

27 Jun '13

Hi! Started using Xmonad and love it, but: I'm using a laptop that I sometimes dock. I then have the laptop screen turned off and use instead a much larger separate screen. The resolution gets messed up when I login Xmonad (I guess it retained the laptop's original resolution). I then run*xrandr --output HDMI3 --mode 1920x1200* to change it to the larger screen's full resolution, and everything looks nice. But the xmobar doesn't stretch across the full width of the screen and the background desktop image is tiled to fill the whole screen... I guess what I'm asking is, how can I best set up .xsession and / or xmonad.hs (and .xmobarrc) to make this work? Ultimately I'd like it to work when I dock my laptop but also when the laptop isn't docked... Many thanks in advance for any kind of help! Yakir Gagnon Queensland Brain Institute (Bldg 79) University of Queensland St Lucia, Brisbane QLD 4072 Australia cell +61 0424 393 332

5 5

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

19 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 16 Jun '13

16 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