From codesite-noreply at google.com Wed Nov 5 07:09:37 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Wed, 05 Nov 2014 07:09:37 +0000 Subject: [xmonad] Issue 527 in xmonad: Google Hangouts screen sharing crashes In-Reply-To: <4-3425899027203913298-6564075030709383626-codesite-noreply=google.com@googlecode.com> References: <4-3425899027203913298-6564075030709383626-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6564075030709383626-codesite-noreply=google.com@googlecode.com> Message-ID: <5-3425899027203913298-6564075030709383626-codesite-noreply=google.com@googlecode.com> Comment #5 on issue 527 by codd... at gmail.com: Google Hangouts screen sharing crashes https://code.google.com/p/xmonad/issues/detail?id=527 How to solve this problem? -- 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 From codesite-noreply at google.com Wed Nov 5 23:27:43 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Wed, 05 Nov 2014 23:27:43 +0000 Subject: [xmonad] Issue 580 in xmonad: WIndows using OpenGL don't resize properly when partially offscreen Message-ID: <0-3425899027203913298-17647985301445994153-codesite-noreply=google.com@googlecode.com> Status: New Owner: ---- New issue 580 by StevensE... at gmail.com: WIndows using OpenGL don't resize properly when partially offscreen https://code.google.com/p/xmonad/issues/detail?id=580 What steps will reproduce the problem? 1. Start a program that uses OpenGL such as glxgears 2. Drag the program window partially off the top of the screen 3. Resize the window to be longer vertically What is the expected output? What do you see instead? I expect to see the window expand to fill the new space. Instead I see a blank black space in that area (for glxgears, for my own personal program at https://gitorious.org/linted/linted I see old and stale data from what was last drawn there by other programs.) What version of the product are you using? On what operating system? $ xmonad --version xmonad 0.11 $ uname -a Linux proteus 3.17.2-gnu #1 SMP Thu Oct 30 19:27:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux I'm using Trisquel 7 from trisquel.info and the Linux-Libre kernel from http://www.fsfla.org/ikiwiki/selibre/linux-libre/ Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". xmonad --recompile gives no errors or warnings. My xmonad.hs is attached. Please provide any additional information below. Two pictures of the bug are provided. Attachments: xmonad.hs 1.9 KB Screenshot from 2014-11-05 15:18:57.png 26.6 KB Screenshot from 2014-11-05 15:19:28.png 107 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 From codesite-noreply at google.com Wed Nov 5 23:30:15 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Wed, 05 Nov 2014 23:30:15 +0000 Subject: [xmonad] Issue 580 in xmonad: WIndows using OpenGL don't resize properly when partially offscreen In-Reply-To: <0-3425899027203913298-17647985301445994153-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-17647985301445994153-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-17647985301445994153-codesite-noreply=google.com@googlecode.com> Comment #1 on issue 580 by StevensE... at gmail.com: WIndows using OpenGL don't resize properly when partially offscreen https://code.google.com/p/xmonad/issues/detail?id=580 It occurs to me I should probably give the details of my 3D graphics stack in case the problem lies there. Attached is the output of glxinfo.2 Attachments: glxinfo 16.9 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 From codesite-noreply at google.com Thu Nov 6 00:20:24 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 06 Nov 2014 00:20:24 +0000 Subject: [xmonad] Issue 580 in xmonad: WIndows using OpenGL don't resize properly when partially offscreen In-Reply-To: <1-3425899027203913298-17647985301445994153-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-17647985301445994153-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-17647985301445994153-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-17647985301445994153-codesite-noreply=google.com@googlecode.com> Comment #2 on issue 580 by allber... at gmail.com: WIndows using OpenGL don't resize properly when partially offscreen https://code.google.com/p/xmonad/issues/detail?id=580 Window contents, including redrawing, is not under the control of the window manager. When the window is resized, the X server sends Expose events... but I admit I do not know how this is reflected to OpenGL programs, which do not talk to the X server directly. In any case, it is more or less xorg driver <-> X server (Mesa component in the case of OpenGL) <-> program, with the window manager only involved in the interaction with the user during the resize. -- 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 From benweitzman at gmail.com Mon Nov 10 20:28:00 2014 From: benweitzman at gmail.com (benweitzman at gmail.com) Date: Mon, 10 Nov 2014 15:28:00 -0500 (EST) Subject: [xmonad] darcs patch: BinarySpacePartition downstream changes Message-ID: <20141110202800.469345C1013@bw.dhcp.tripadvisor.com> 1 patch for repository http://code.haskell.org/XMonadContrib: Mon Nov 10 15:22:59 EST 2014 benweitzman at gmail.com * BinarySpacePartition downstream changes Pulled in changes from my repo for this layout on github (https://github.com/benweitzman/BinarySpacePartition) Includes a new mode for resizing windows in a more intuitive way, also contains a bug fix that was preventing users from resiving a window up. Includes changes from github users egasimus (Adam Avramov) and SolitaryCipher (Nick) -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-preview.txt Type: text/x-darcs-patch Size: 10850 bytes Desc: Patch preview URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: binaryspacepartition-downstream-changes-.dpatch Type: application/x-darcs-patch Size: 34411 bytes Desc: A darcs patch for your repository! URL: From codesite-noreply at google.com Fri Nov 14 19:56:11 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Fri, 14 Nov 2014 19:56:11 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes In-Reply-To: <17-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> References: <17-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Message-ID: <18-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Comment #18 on issue 576 by reaper.t... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes https://code.google.com/p/xmonad/issues/detail?id=576 I can reproduce this issue under stock GENERIC FreeBSD/amd64 10.0 (running directly on the hardware, i.e. no virtualization). -- 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 From mathstuf at gmail.com Tue Nov 18 02:51:30 2014 From: mathstuf at gmail.com (Ben Boeckel) Date: Tue, 18 Nov 2014 02:51:30 +0000 (UTC) Subject: [xmonad] Startup Arguments References: <87wq8ae6r5.fsf@desiato.home.uhoreg.ca> Message-ID: [ Sorry for the necro; finally catching up on mailing lists after a long break from them. ] On Wed, 08 Oct, 2014 at 18:49:50 GMT, Hubert Chathi wrote: > Are there any examples available of how it's used? I use it in my setup extensively. My xmonad.hs is: http://paste.fedoraproject.org/151630/62785441/ Everything related to it is from lines 515 to 566 (I won't deny that my xmonad.hs might be a little over-engineered). My xmobarrc uses the %_XMONAD_LOG% expansion which is provided by a command in the argument list (-C) to each invocation. It also uses xmonadpropwrite rather than pipes to xmobar so that xmobar can be restarted independently of xmonad. I have seen issues with instances not always starting on all the monitors, but it's very sporadic (even on my triple monitor setup at work) that I haven't taken the time to track it down. --Ben From mathstuf at gmail.com Tue Nov 18 02:59:35 2014 From: mathstuf at gmail.com (Ben Boeckel) Date: Tue, 18 Nov 2014 02:59:35 +0000 (UTC) Subject: [xmonad] darcs patch: needs update for mplayer2 References: Message-ID: On Fri, 04 Jul, 2014 at 22:58:39 GMT, adam vogt wrote: > Mpv doesn't seem to be terribly popular according to popcon > (), so I'm hesitant to > add something that very few users will use. Seems to have gained popularity (almost double since July): https://qa.debian.org/popcon-graph.php?packages=mpv&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 Though looking at it against a (declining) mplayer and (rising) mplayer2 shows that its numbers are low in an absolute sense :) . I expect mpv is probably more popular in Arch or Fedora circles anyways (though I compile from git). An mpv user, --Ben From codesite-noreply at google.com Tue Nov 18 03:13:29 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 18 Nov 2014 03:13:29 +0000 Subject: [xmonad] Issue 538 in xmonad: X.H.DynamicBars call to xrrSelectInput has no effect In-Reply-To: <0-3425899027203913298-10257946323529592623-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-10257946323529592623-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-10257946323529592623-codesite-noreply=google.com@googlecode.com> Comment #1 on issue 538 by MathStuf at gmail.com: X.H.DynamicBars call to xrrSelectInput has no effect https://code.google.com/p/xmonad/issues/detail?id=538 Finally getting back to this. I'm running with: ghc-xmonad-contrib-devel-0.11.2-5.fc22.x86_64 xmonad-core-0.11-12.fc21.x86_64 ghc-X11-1.6.1.1-5.fc22.x86_64 xorg-x11-server-Xorg-1.16.1-1.fc22.x86_64 % xrandr --version xrandr program version 1.4.3 Server reports RandR version 1.4 and I can't reproduce the first 1./2. step failure: ``` % pgrep -c xmobar 2 % xrandr --output HDMI3 --primary --mode 1920x1080 --output HDMI1 --off % pgrep -c xmobar 1 % xrandr --output HDMI3 --primary --mode 1920x1080 --output HDMI1 --left-of HDMI3 --mode 1440x900 % pgrep -c xmobar 2 ``` Can you still reproduce this? -- 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 From sschuldenzucker at uni-bonn.de Tue Nov 18 09:52:14 2014 From: sschuldenzucker at uni-bonn.de (Steffen Schuldenzucker) Date: Tue, 18 Nov 2014 10:52:14 +0100 Subject: [xmonad] xinerama and per-screen automatic layout modification Message-ID: <546B16CE.5020906@uni-bonn.de> Hi, I'm using xmonad with two equally-sized screens the left one of which I sometimes turn into pivot mode (rotate 90?) to read articles. Now 'Tall' isn't great on a portrait monitor, so I'm looking for a layout modifier that acts as follows: * If on the right monitor: No modification * If on the left monitor: o If in pivot mode, apply the Mirror layout modifier. o Otherwise, apply the Reflect layout modifier. (because I like my master windows in the center) Has anybody worked on something like this before? If not, I'd try to write a contrib module, probably re-using some code from Actions.PhysicalScreens. Any pointers / pitfalls to be expected? kthx. Best, Steffen -------------- next part -------------- An HTML attachment was scrubbed... URL: From carstenmattner at gmail.com Wed Nov 19 17:18:09 2014 From: carstenmattner at gmail.com (Carsten Mattner) Date: Wed, 19 Nov 2014 18:18:09 +0100 Subject: [xmonad] darcs patch: needs update for mplayer2 In-Reply-To: References: Message-ID: On Tue, Nov 18, 2014 at 3:59 AM, Ben Boeckel wrote: > On Fri, 04 Jul, 2014 at 22:58:39 GMT, adam vogt wrote: >> Mpv doesn't seem to be terribly popular according to popcon >> (), so I'm hesitant to >> add something that very few users will use. > > Seems to have gained popularity (almost double since July): > > https://qa.debian.org/popcon-graph.php?packages=mpv&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 > > Though looking at it against a (declining) mplayer and (rising) mplayer2 > shows that its numbers are low in an absolute sense :) . I expect mpv is > probably more popular in Arch or Fedora circles anyways (though I > compile from git). > > An mpv user, My impression is that mpv is more actively maintained than the other two. From mathstuf at gmail.com Wed Nov 19 19:00:08 2014 From: mathstuf at gmail.com (Ben Boeckel) Date: Wed, 19 Nov 2014 14:00:08 -0500 Subject: [xmonad] darcs patch: needs update for mplayer2 In-Reply-To: References: Message-ID: <20141119190008.GB1493@megas.kitwarein.com> On Wed, Nov 19, 2014 at 18:18:09 +0100, Carsten Mattner wrote: > My impression is that mpv is more actively maintained than the other two. I agree as well (wm4 is responsive and has a good eye during review), and I find the code to be very readable (certainly more than the last time I dove into mplayer; never tried mplayer2 with any real oomph behind it). That said, I know Reimar is still actively developing mplayer, but, IMO, mpv is on a better course. --Ben From vogt.adam at gmail.com Thu Nov 20 17:50:52 2014 From: vogt.adam at gmail.com (adam vogt) Date: Thu, 20 Nov 2014 12:50:52 -0500 Subject: [xmonad] xinerama and per-screen automatic layout modification In-Reply-To: <546B16CE.5020906@uni-bonn.de> References: <546B16CE.5020906@uni-bonn.de> Message-ID: Hi Steffen, I think it is simpler to check if the screen has height > width, and then do what Mirror does if that happens to be the case. The following code is a slight modification of the code for Mirror probably does that (it compiles but I have not tested it): {-# LANGUAGE MultiParamTypeClasses #-} -- at the top of the file {-# LANGUAGE FlexibleInstances #-} import XMonad import Control.Arrow import qualified XMonad.StackSet as W -- | Mirror a layout, compute its 90 degree rotated form. newtype MirrorAspect l a = MirrorAspect (l a) deriving (Show, Read) instance LayoutClass l a => LayoutClass (MirrorAspect l) a where runLayout (W.Workspace i (MirrorAspect l) ms) r@(Rectangle _ _ w h) = (map (second mirrorRect) *** fmap MirrorAspect) `fmap` runLayout (W.Workspace i l ms) (mirrorRect r) where -- | possibly Mirror a rectangle mirrorRect :: Rectangle -> Rectangle mirrorRect r0@(Rectangle rx ry rw rh) | h > w = Rectangle ry rx rh rw | otherwise = r0 handleMessage (MirrorAspect l) = fmap (fmap MirrorAspect) . handleMessage l description (MirrorAspect l) = "MirrorAspect "++ description l Regards, Adam From codesite-noreply at google.com Mon Nov 24 01:58:34 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Mon, 24 Nov 2014 01:58:34 +0000 Subject: [xmonad] Issue 538 in xmonad: X.H.DynamicBars call to xrrSelectInput has no effect In-Reply-To: <1-3425899027203913298-10257946323529592623-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-10257946323529592623-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-10257946323529592623-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-10257946323529592623-codesite-noreply=google.com@googlecode.com> Comment #2 on issue 538 by johnnysp... at gmail.com: X.H.DynamicBars call to xrrSelectInput has no effect https://code.google.com/p/xmonad/issues/detail?id=538 I have roughly the same versions as you (slightly newer where different): xmonad-contrib-0.11.3-1 xmonad-0.11-9 haskell-x11-1.6.1.2-1 xorg-server-1.16.2-1 xrandr program version 1.4.3 Server reports RandR version 1.4 I can still reproduce this: 1. Run xmonad with the attached xmonad.hs. Two xmobars are started, so barCreator works. 2. Kill the xmobars. 3. Toggle the external display off and on. No new xmobars are spawned, so barCreator isn't being called. In other words: ``` $ pgrep -c xmobar 2 $ killall xmobar $ pgrep -c xmobar 0 $ xrandr --output HDMI1 --off $ pgrep -c xmobar 0 $ xrandr --output HDMI1 --preferred --right-of LVDS1 $ pgrep -c xmobar 0 ``` Any suggestions for what to try next? Is there something that I overlooked in the attached minimal xmonad.hs? -- 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 From codesite-noreply at google.com Tue Nov 25 06:39:31 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 25 Nov 2014 06:39:31 +0000 Subject: [xmonad] Issue 414 in xmonad: Wrong floating window sizes on multimon setup In-Reply-To: <5-3425899027203913298-11446432011421070927-codesite-noreply=google.com@googlecode.com> References: <5-3425899027203913298-11446432011421070927-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-11446432011421070927-codesite-noreply=google.com@googlecode.com> Message-ID: <6-3425899027203913298-11446432011421070927-codesite-noreply=google.com@googlecode.com> Comment #6 on issue 414 by ezy... at mit.edu: Wrong floating window sizes on multimon setup https://code.google.com/p/xmonad/issues/detail?id=414 This chunk of code in XMonad.Operations is the buggy code: -- --------------------------------------------------------------------- -- | -- Window manager operations -- manage. Add a new window to be managed in the current workspace. -- Bring it into focus. -- -- Whether the window is already managed, or not, it is mapped, has its -- border set, and its event mask set. -- manage :: Window -> X () manage w = whenX (not <$> isClient w) $ withDisplay $ \d -> do sh <- io $ getWMNormalHints d w let isFixedSize = sh_min_size sh /= Nothing && sh_min_size sh == sh_max_size sh isTransient <- isJust <$> io (getTransientForHint d w) rr <- snd `fmap` floatLocation w -- ensure that float windows don't go over the edge of the screen let adjust (W.RationalRect x y wid h) | x + wid > 1 || y + h > 1 || x < 0 || y < 0 = W.RationalRect (0.5 - wid/2) (0.5 - h/2) wid h adjust r = r f ws | isFixedSize || isTransient = W.float w (adjust rr) . W.insertUp w . W.view i $ ws | otherwise = W.insertUp w ws where i = W.tag $ W.workspace $ W.current ws mh <- asks (manageHook . config) g <- appEndo <$> userCodeDef (Endo id) (runQuery mh w) windows (g . f) Notice the floatLocation query throws out the recommended screen for the float to be placed on. I don't actually know what the right version of this code is. -- 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 From codesite-noreply at google.com Wed Nov 26 16:25:08 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Wed, 26 Nov 2014 16:25:08 +0000 Subject: [xmonad] Issue 581 in xmonad: The WM fails to adapt to non-default visuals (32-bit ARGB visual in the case). Message-ID: <0-3425899027203913298-3010135024361005017-codesite-noreply=google.com@googlecode.com> Status: New Owner: ---- New issue 581 by ptr... at gmail.com: The WM fails to adapt to non-default visuals (32-bit ARGB visual in the case). https://code.google.com/p/xmonad/issues/detail?id=581 What steps will reproduce the problem? 1. Get Xmonad 2. Get Termite (V9 or higher) from Github/your repositories Github: https://github.com/thestinger/termite (To build it, also make sure to check out the utils directory) 3. Get Compton (any release should do) 4. run Xmonad, default config is fine. To get a better idea of the bug, a bigger window border might be useful. 5. run Compton (with -e to make sure window borders are drawn solid): compton --config /dev/null -e 1.0 6. run termite What is the expected output? What do you see instead? Expected: you get a termite window and a solid window frame. You get: A non-solid, semi-transparent window frame What version of the product are you using? On what operating system? I am using Xmonad, compton and termite on Arch Linux, from their repos. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Nope, nothing special needed here. Please provide any additional information below. I already reported the bug to compton/termite. They blame Xmonad to be unable to handle non-default visuals. The same bug was found in dwm, a fix is already done. The whole discussion is here: https://github.com/chjj/compton/issues/240#issuecomment-62245919 Cheers, ptrxyz -- 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 From javran.c at gmail.com Fri Nov 28 06:14:25 2014 From: javran.c at gmail.com (Javran Cheng) Date: Fri, 28 Nov 2014 01:14:25 -0500 Subject: [xmonad] deal with EWMH focus stealing problem Message-ID: Hi all, I'd like to share my workaround dealing with focus stealing problem found when EWMH is enabled: http://javran.github.io/posts/2014-11-27-get-rid-of-xmonad-focus-thief.html Please feel free to discuss and hope you have a nice holiday :) Javran -------------- next part -------------- An HTML attachment was scrubbed... URL: