August 2015 - xmonad - Haskell.org

Issue 605 in xmonad: Tearing out a chrome or chromium tab with the mouse becomes tiled when it should be floating
by codesite-noreply＠google.com 06 Aug '15

06 Aug '15

Status: New Owner: ---- New issue 605 by jeremyfl...(a)gmail.com: Tearing out a chrome or chromium tab with the mouse becomes tiled when it should be floating https://code.google.com/p/xmonad/issues/detail?id=605 What steps will reproduce the problem? 1. Use the mouse to drag (tear) a chrome tab out of your chrome window. 2. Experience annoyance when everything moves to accomodate a newly tiled window. What is the expected output? What do you see instead? This new window should float until the drag stops. This used to be the behavior a year or two ago. See the chrome issue over here https://code.google.com/p/chromium/issues/detail?id=447988. -- 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 526 in xmonad: avoidStruts uses getWindowInfo dpy rootWindow insstead of getCleanedScreenInfo
by codesite-noreply＠google.com 05 Aug '15

05 Aug '15

Status: Accepted Owner: allber...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Contrib Usability New issue 526 by allber...(a)gmail.com: avoidStruts uses getWindowInfo dpy rootWindow insstead of getCleanedScreenInfo http://code.google.com/p/xmonad/issues/detail?id=526 What steps will reproduce the problem? 1. Place a dock on a border between screens What is the expected output? What do you see instead? The dock's space is not accounted for, because the strut is set at the maxim extent over all screens in the relevant direction. The size of the root window is the bounding rectangle of all screens, not the size of the screen the dock is on. This means that if we try to make space for a dock that lives "between" two screens, it will actually be allocated on the last screen in that direction.

1 1

Issue 610 in xmonad: Can't use GridSelect with non-us keyboard layout
by codesite-noreply＠google.com 02 Aug '15

02 Aug '15

Status: New Owner: ---- New issue 610 by mic.li...(a)gmail.com: Can't use GridSelect with non-us keyboard layout https://code.google.com/p/xmonad/issues/detail?id=610 What steps will reproduce the problem? 1. Invoke `GS.gotoSelected GS.defaultGSConfig` 2. Switch to another keyboard layout. 3. Try to write anything and watch unresponsive screen. 4. Switch back to us keyboard layout. 5. Choose what you want. Steps 1 and 2 may be swapped with the same result. What is the expected output? What do you see instead? - Grid select recognizes configured keys with any keyboard layout selected. What version of the product are you using? On what operating system? - xmonad-0.11-12.fc21.x86_64 - OS: Fedora 21 I'm using MATE keyboard layout applet to switch between layouts. My keyboard settings look like this: setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete+ledscroll(group_lock)" }; xkb_symbols { include "pc+us+cz(qwerty):2+inet(evdev)+group(switch)+group(shift_caps_toggle)" }; xkb_geometry { include "microsoft(natural)" }; }; setxkbmap -query rules: evdev model: microsoft4000 layout: us,cz variant: ,qwerty options: grp_led:scroll,grp:switch,grp:shift_caps_toggle Even with modified gs config to allow all possible modificator, it still fails for me: gsConfig :: HasColorizer a => GSConfig a gsConfig = defaultGSConfig { gs_cellheight = 40 , gs_cellwidth = 100 , gs_navigate = navigation' } where navigation' :: TwoD a (Maybe a) navigation' = makeXEventhandler $ shadowWithKeymap navKeyMap navHandler navKeyMap = M.fromList (allowModifs modifs [ ((0, xK_Escape) , cancel) , ((0, xK_Return) , select) , ((0, xK_slash) , substringSearch navigation') , ((0, xK_question), substringSearch navigation') , ((0, xK_Left) , move (-1, 0) >> navigation') , ((0, xK_h) , move (-1, 0) >> navigation') , ((0, xK_H) , move (-1, 0) >> navigation') , ((0, xK_Right) , move (1 , 0) >> navigation') , ((0, xK_l) , move (1 , 0) >> navigation') , ((0, xK_L) , move (1 , 0) >> navigation') , ((0, xK_Down) , move (0 , 1) >> navigation') , ((0, xK_j) , move (0 , 1) >> navigation') , ((0, xK_J) , move (0 , 1) >> navigation') , ((0, xK_Up) , move (0 , -1) >> navigation') , ((0, xK_k) , move (0 , -1) >> navigation') , ((0, xK_K) , move (0 , -1) >> navigation') , ((0, xK_n) , moveNext >> navigation') , ((0, xK_N) , moveNext >> navigation') , ((0, xK_p) , movePrev >> navigation') , ((0, xK_P) , movePrev >> navigation') ] ++ allowModifs (drop 1 modifs) [ ((0, xK_Tab) , moveNext >> navigation') , ((shiftMask, xK_Tab), moveNext >> navigation') ] ) modifs :: [KeyMask] modifs = [ shiftMask, lockMask, mod1Mask, mod2Mask , mod3Mask, mod4Mask, mod5Mask ] allowModifs :: [ KeyMask ] -> [((KeyMask, a), b)] -> [((KeyMask, a), b)] allowModifs mods keymap = [ ((m .|. o, k), a) | m <- map (foldl (.|.) 0) $ subsequences mods , ((o, k), a) <- keymap ] -- The navigation handler ignores unknown key symbols navHandler = const navigation' -- 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