- xmonad - Haskell.org

Re: [xmonad] Issue 526 in xmonad: avoidStruts uses getWindowInfo dpy rootWindow instead of getCleanedScreenInfo
by codesite-noreply＠google.com 11 Aug '15

11 Aug '15

Updates: Summary: avoidStruts uses getWindowInfo dpy rootWindow instead of getCleanedScreenInfo Comment #2 on issue 526 by allber...(a)gmail.com: avoidStruts uses getWindowInfo dpy rootWindow instead of getCleanedScreenInfo https://code.google.com/p/xmonad/issues/detail?id=526 ...and it occurs to me that we can't represent docks on multiple screens properly anyway, since any in the direction of monitor stacking can only be on the ends anyway. (I'm poking at our incorrect _NET_WORKAREA implementation.) I don't think this can be fixed properly. In particular, since EWMH assumes the workspace lives across all monitors, *it* (via strut and _NET_WORKAREA) does not support docks between screens properly. We could still do better than we currently are, but it's going to be a major pain. Also: it has been claimed that the current screen info is from the first Xlib check and not updated by monitor changes. The workaround of using the current bounds of the root window is flat-out wrong, because we *need* to know the boundaries between monitors; some other solution should be found. -- 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 4

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

Issue 559 in xmonad: Redraw of Gnomeapps fails
by codesite-noreply＠google.com 31 Jul '15

31 Jul '15

Status: New Owner: ---- New issue 559 by dragonch...(a)gmail.com: Redraw of Gnomeapps fails http://code.google.com/p/xmonad/issues/detail?id=559 What steps will reproduce the problem? 1. Start Gnome3 Application 2. Click a widget within that application What is the expected output? What do you see instead? Expected: The application should perform the requestet action and redraw the app with the results. Displayed: The Gnome app performs the action but does not redraw the ui, when switching to another desktop and back the App shows the proper output. What version of the product are you using? On what operating system? - Gentoo hardened (Kernel 3.10.8 and 3.11.1) - xmonad 0.11 - Gnome 3.8.4 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. -- 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 12

Issue 598 in xmonad: Join stackage
by codesite-noreply＠google.com 21 Jul '15

21 Jul '15

Status: Accepted Owner: nome...(a)gmail.com New issue 598 by nome...(a)gmail.com: Join stackage https://code.google.com/p/xmonad/issues/detail?id=598 Currently, xmonad does not build against the packages in the latest Stackage LTS release, in particular utf8-string-1. It would be great if xmonad would join stackage so that such problems are detected early. It also gives you some QA for free: http://www.stackage.org/authors -- 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 7

[xmonad-contrib] XMonad.Prompt.Pass patch
by ardumont 21 Jul '15

21 Jul '15

Hello, You will find enclosed a patch to propose a new XMonad.Prompt.Pass. >From the header description documentation: -- Provides a shell prompt to lookup passwords in a password-storage (located on user's home @$HOME\/.password-store@). -- The password storage used is <http://git.zx2c4.com/password-store the password-store cli>. -- -- When one validates its input, the corresponding password is loaded -- in the clipboard for a limited period of 45 seconds. -- -- Greatly inspired from <http://babushk.in/posts/combining-xmonad-and-pass.html> I'm open to any suggestions on how to improve on this. Cheers, -- @ardumont

9 31

Issue 603 in xmonad: Problems with toggling focus on Chrome
by codesite-noreply＠google.com 10 Jul '15

10 Jul '15

Status: New Owner: ---- New issue 603 by p...(a)cnphil.com: Problems with toggling focus on Chrome https://code.google.com/p/xmonad/issues/detail?id=603 What steps will reproduce the problem? 1. In tiling mode, open up Chrome 2. Open up another window, say urxvt 3. Try toggling back and forth the focus with <Mod-Tab> What is the expected output? What do you see instead? Chrome should be responding to keyboard, mouse movement. But it just does not seem to realize it is on focus. What version of the product are you using? On what operating system? xmonad 0.11.1 ghc 7.10.1 Chrome 43 beta Arch Linux Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". The problem persists even without an xmonad.hs Please provide any additional information below. In the attached image, you can see that the currently focused window is red-bordered (lower right), but it's not responding to keyboard strokes or anything unless I explicitly move the cursor there and click on it. Attachments: 2015-05-01-003015_2560x1600_scrot.png 468 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 6

Issue 609 in xmonad: Xmonad.Util.Paste.pasteString leaves out spaces
by codesite-noreply＠google.com 06 Jul '15

06 Jul '15

Status: New Owner: ---- New issue 609 by abimel...(a)gmail.com: Xmonad.Util.Paste.pasteString leaves out spaces https://code.google.com/p/xmonad/issues/detail?id=609 This is an issue for pasteSelection, which uses it. Saw this patch on the list; wondering if it ever went anywhere? https://mail.haskell.org/pipermail/xmonad/2013-October/013889.html -- 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

2 1

Re: [xmonad] Sticky Windows with CopyWindows & DynamicWorkspaceGroups on Xinerama multihead setup
by Daniel Wagner 03 Jul '15

03 Jul '15

Hi Alexis -- First off, sorry for not CC'ing the mailing list. Dunno how that happened; they're back in the loop. I haven't played with workspace groups very much, so I'm going to take a guess about how they work. Let me know if I'm wrong. My guess is this: you have a collection of workspace groups, which is just a list of workspaces. When you switch to a group, this changes which workspace is visible on all the screens in some deterministic way -- e.g. switching to group ["foo", "bar", "baz"], the left screen is always showing workspace "foo", middle screen "bar", right screen "baz". (I don't care if this is the actual mapping -- so long as the mapping is always the same.) Then, you have a window on one of the screens, and you always want it to be visible on that screen, even when you change workspace groups. I have two more assumption, which is that you are only ever changing workspaces by changing workspace groups; and that any given workspace only appears in one group. If all these assumptions are correct, then one solution to your problem would be simply to copy the window of interest to the appropriate workspaces (rather than using `copyToAll`). You can use `copy` to copy to a single other workspace, and `foldr` to copy to a collection of workspaces: XMonad.Actions.CopyWindow XMonad.StackSet> :t foldr copy foldr copy :: (Eq i, Eq a, Eq s, Foldable t) => StackSet i l a s sd -> t i -> StackSet i l a s sd All that remains for you is to find out which are the right workspaces to copy to. That involves checking which workspace is currently focused, and which other workspaces are in the same "position" in your groups. We can help you craft this code, though we'll need to see your existing config to give good advice. You may also be interested in combining WorkspaceGroups with IndependentScreens ( http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-IndependentScree…) which would give you a systematic way to name your workspaces and ease the computation of which other workspaces are in the same "position" in your groups. Good luck, ~d On Mon, Jun 22, 2015 at 2:00 PM, Alexis de BRUYN < alexis.mailinglist(a)de-bruyn.fr> wrote: > Hi Daniel, > > Thanks for your answer. > > I have 3 monitors in Xinerama mode with 3 workspace groups. I am using > viewWSGroup [1] to navigate through my workspace groups. Sometimes I want > to set a window to be visible to all my workspace groups (so when I do a > viewWSGroup, I always want to see this particular window). > > Long times ago, I used Gnome in a similar multihead setup, I was able to > right clic on a window and mark it as visible on all workspaces (the 3 > monitors were seen as one workspace, which is not with Xmonad, but I am > trying to reproduce this behaviour with DynamicWorkspaceGroups). So when I > changed the workspace, I was able to see my window. > > I hope, I am clear. > > Thanks for your time, > > [1] > http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-DynamicWorkspac… > > On 06/21/15 23:42, Daniel Wagner wrote: > >> X's architecture makes it impossible to show a window on the screen in >> two different locations (e.g. on two different screens) without >> compositing. xmonad doesn't know anything about compositing. The >> behavior you are seeing is xmonad doing its best to reconcile your >> request (show this window on all workspaces, and show several workspaces >> at once) with what it knows how to do (pick a subset of the windows it >> knows about and put at most one place). >> >> What exactly do you want sticky windows to do? I could imagine many >> behaviors one could want that mesh with the "only appears once" >> restriction, with varying levels of code required on your part. >> >> If you really want it to appear on both screens, you're out of luck with >> xmonad. >> ~d >> >> On Thu, Jun 11, 2015 at 2:17 AM, Alexis de BRUYN >> <alexis.mailinglist(a)de-bruyn.fr <mailto:alexis.mailinglist@de-bruyn.fr>> >> wrote: >> >> Hi List, >> >> I am trying to get Sticky windows on my xinerama setup. >> >> After switching into another WorkspaceGroup, the new window which I >> previously copyToAll, appears in the new WorkspaceGroup but it is >> 'attached' to my mouse pointer. I need to killAllOtherCopies. >> >> That fact that this window follows the mouse across the >> screens/monitors is annoying especially if I have more than one >> sticky window. >> >> How can I get rid of this? Is there another way to achieve this? >> >> Thank for help, >> >> -- >> Alexis de BRUYN >> _______________________________________________ >> xmonad mailing list >> xmonad(a)haskell.org <mailto:xmonad@haskell.org> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >> >> >> > -- > Alexis de BRUYN > >

1 0