dzen2 not recognized by avoidStruts on non-rectangular desktop
Hi, I'm trying to use avoidStruts with dzen2 instances on a non-rectangular desktop. I have a 1920x1200 monitor on the left and a 1440x900 monitor on the right. The top edges of the monitors are aligned, so there is a 1440x300 area of dead space below the right monitor. I have 4 dzen2 instances, one anchored to both the left and right sides of the top and bottom edges of the 1440x900 screen. The two instances at the top of the screen are always recognized by avoidStruts, and windows do not overlap them. But when I have the 1920x1200 monitor connected, the instances anchored to the bottom edge (i.e., those above the dead space) are overlapped by windows. I am fairly sure it's a bug in the code, as when I disconnect the 1920x1200 monitor, I have no such problems. I'm running 64-bit Arch Linux with xmonad-darcs & xmonad-contrib-darcs installed from the AUR, though this is also an issue with xmonad 0.9.1 from the repositories. My xmonad.hs is attached. Thank you!!
Samir Unni
I have 4 dzen2 instances, one anchored to both the left and right sides of the top and bottom edges of the 1440x900 screen. The two instances at the top of the screen are always recognized by avoidStruts, and windows do not overlap them. But when I have the 1920x1200 monitor connected, the instances anchored to the bottom edge (i.e., those above the dead space) are overlapped by windows. I am fairly sure it's a bug in the code, as when I disconnect the 1920x1200 monitor, I have no such problems.
What does dzen report as its struts in both of these situations? You can run `xprop | grep STRUT` to see what _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL are reported.
On 12/22/2010 10:53 PM, Justin Bogner wrote:
What does dzen report as its struts in both of these situations? You can run `xprop | grep STRUT` to see what _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL are reported.
If I have the 1920x1200 monitor connected, the top struts give me something like this (I didn't grep the output, since there were only 2 lines): _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 18, 0, 0, 0, 0, 0, 1920, 3219, 0, 0 WM_NAME(STRING) = "dzen title" And the bottom struts both give me just this: WM_NAME(STRING) = "dzen title" If the 1920x1200 monitor isn't connected, then I get something like the top struts' output above for both the top and bottom struts.
Samir Unni
If I have the 1920x1200 monitor connected, the top struts give me something like this (I didn't grep the output, since there were only 2 lines):
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 18, 0, 0, 0, 0, 0, 1920, 3219, 0, 0 WM_NAME(STRING) = "dzen title"
And the bottom struts both give me just this:
WM_NAME(STRING) = "dzen title"
The problem is with dzen, not xmonad. Looking at the source for dzen, it looks like it's not really xinerama aware. It sets a strut if it's at the very top or very bottom of your display, based on xlib's `DisplayHeight`. I don't know enough about xlib to tell you how to fix this.
On 12/22/2010 11:40 PM, Justin Bogner wrote:
The problem is with dzen, not xmonad. Looking at the source for dzen, it looks like it's not really xinerama aware. It sets a strut if it's at the very top or very bottom of your display, based on xlib's `DisplayHeight`. I don't know enough about xlib to tell you how to fix this.
Is there some way to work around this by manually telling xmonad not to let windows overlap the dzen2 instances? I attempted this once before, but the method resulted in a gap being present at the bottom of my other monitor as well, and the docs said that the code was deprecated anyway.
Samir Unni
Is there some way to work around this by manually telling xmonad not to let windows overlap the dzen2 instances? I attempted this once before, but the method resulted in a gap being present at the bottom of my other monitor as well, and the docs said that the code was deprecated anyway.
I don't think so. The documentation for XMonad.Layout.Gaps says you'll be able to do it with XMonad.Layout.PerScreen, but that module doesn't exist. It does look like this problem has been [solved in xmobar], if you feel like switching panels. Poking around a bit more, this oesn't look like it would be too hard to fix in dzen. [solved in xmobar]: http://code.google.com/p/xmobar/issues/detail?id=6
On 12/23/2010 12:39 AM, Justin Bogner wrote:
I don't think so. The documentation for XMonad.Layout.Gaps says you'll be able to do it with XMonad.Layout.PerScreen, but that module doesn't exist. It does look like this problem has been [solved in xmobar], if you feel like switching panels.
I'd rather not switch, as I have some icons in my dzen2 instances.
Poking around a bit more, this oesn't look like it would be too hard to fix in dzen.
OK, I think I'll try this and see how it goes.
On 12/23/2010 12:53 AM, Justin Bogner wrote:
I don't have a dual head setup to try it on, but does this do the trick?
Now I'm getting the NET_WM_STRUT_PARTIAL output from xprop for the bottom instances even if the second monitor is connected, but xmonad isn't recognizing the instances and preventing the windows from overlapping even when that monitor isn't connected.
Samir Unni
On 12/23/2010 12:53 AM, Justin Bogner wrote:
I don't have a dual head setup to try it on, but does this do the trick?
Now I'm getting the NET_WM_STRUT_PARTIAL output from xprop for the bottom instances even if the second monitor is connected, but xmonad isn't recognizing the instances and preventing the windows from overlapping even when that monitor isn't connected.
Looking at my patch again, that's not surprising. Here's one that's far more likely to work.
On 12/23/2010 01:41 AM, Justin Bogner wrote:
Looking at my patch again, that's not surprising. Here's one that's far more likely to work.
Now it's working correctly without the second monitor, and has the NET_WM_STRUT_PARTIAL output whether it's connected or not. But still overlapping when there's the second monitor.
On 12/23/2010 01:49 AM, Samir Unni wrote:
On 12/23/2010 01:41 AM, Justin Bogner wrote:
Looking at my patch again, that's not surprising. Here's one that's far more likely to work.
Now it's working correctly without the second monitor, and has the NET_WM_STRUT_PARTIAL output whether it's connected or not. But still overlapping when there's the second monitor.
Does anybody else have any suggestions for fixing this? I still haven't managed to find a solution.
Excerpts from Samir Unni's message of Sun Jan 02 21:32:33 -0700 2011:
Does anybody else have any suggestions for fixing this? I still haven't managed to find a solution.
Sorry for not responding earlier. What version of dzen are you using? I'm pretty sure this was fixed in dzen over a year ago. IIRC it was dschoepe who sent the patch in, so if he or Rob is still around on #xmonad they might be able to confirm that. Anyway, using dzen svn-271 a setup like yours works fine. Also you need the xinerama support compiled in, i.e. dzen2 -xs 2 blah blah works. I suppose if arch doesn't have a svn version you might have to build it yourself. Here's an image of screens with tops aligned 1200px high on L and 768 on R. Four dzens: http://ompldr.org/vNnR0dg Hope that helps. It is a little rough in that xmonad doesn't redraw screens until something changes, so at first windows would overlap, but if your dzens are started before you start creating windows that's not an issue. Also once the dzens are started they don't adjust to screen geometry changes, so if you change resolutions you need to restart them. -- wmw
On 01/03/2011 06:01 AM, Wirt Wolff wrote:
Sorry for not responding earlier. What version of dzen are you using?
0.8.5.
I'm pretty sure this was fixed in dzen over a year ago. IIRC it was dschoepe who sent the patch in, so if he or Rob is still around on #xmonad they might be able to confirm that. Anyway, using dzen svn-271 a setup like yours works fine. Also you need the xinerama support compiled in, i.e. dzen2 -xs 2 blah blah works.
I always use the -xs 2 flag when launching dzen2, and xinerama support is compiled in.
I suppose if arch doesn't have a svn version you might have to build it yourself.
There is a dzen2-svn PKGBUILD in the AUR. I've tried using both it and version 0.8.5 from the stable repos, and both give me the same result. The _NET_WM_STRUT_PARTIAL setting being missing was only fixed when I applied the dzen2 patch Justin supplied.
Here's an image of screens with tops aligned 1200px high on L and 768 on R. Four dzens: http://ompldr.org/vNnR0dg
Are those red and blue strips the dzen2 instances? That's exactly what I'm trying to do.
Hope that helps. It is a little rough in that xmonad doesn't redraw screens until something changes, so at first windows would overlap, but if your dzens are started before you start creating windows that's not an issue.
This problem persists throughout the session, so I don't think that's it.
Also once the dzens are started they don't adjust to screen geometry changes, so if you change resolutions you need to restart them.
I only set the screen geometry once (at login), so that shouldn't be an issue.
Excerpts from Samir Unni's message of Mon Jan 03 10:09:24 -0700 2011:
I always use the -xs 2 flag when launching dzen2, and xinerama support is compiled in.
There is a dzen2-svn PKGBUILD in the AUR. I've tried using both it and version 0.8.5 from the stable repos, and both give me the same result. The _NET_WM_STRUT_PARTIAL setting being missing was only fixed when I applied the dzen2 patch Justin supplied.
Here's an image of screens with tops aligned 1200px high on L and 768 on R. Four dzens: http://ompldr.org/vNnR0dg
Are those red and blue strips the dzen2 instances? That's exactly what I'm trying to do.
Yes, the colored strips are the extra dzens on the edges of the different height screens. Okay, you should be close. If the svn build is newer than nov or dec 2009 (if memory serves) that should do it. You shouldn't need to patch anything. If you look in the shell on the left screen of the omploaded screen shot you'll see the commands I used to launch the dzens. The only thing I can think of that might be missing is if you're even 1px off from the edge of the screen dzen won't set struts. The easiest way to ensure that doesn't happen is to use the -geometry parameter as shown in that left screen shell. If that doesn't work I'm not sure what might be different between our systems that's breaking it. I guess if you have multiple binaries path troubles might have you running stable when you need svn. Good luck, and hope this works for you. -- wmw
On 01/03/2011 11:48 AM, Wirt Wolff wrote:
Okay, you should be close. If the svn build is newer than nov or dec 2009 (if memory serves) that should do it. You shouldn't need to patch anything. If you look in the shell on the left screen of the omploaded screen shot you'll see the commands I used to launch the dzens. The only thing I can think of that might be missing is if you're even 1px off from the edge of the screen dzen won't set struts. The easiest way to ensure that doesn't happen is to use the -geometry parameter as shown in that left screen shell.
OK, I'm trying to do this, but I can't get dzen2 to recognize the -geometry parameter. I'm using the latest SVN revision, and in config.mk, I've got option 7 ("With Xinerama and XPM and XFT") uncommented.
I guess if you have multiple binaries path troubles might have you running stable when you need svn.
Yeah, I made sure that the correct version is being launched.
On 01/03/2011 12:34 PM, Samir Unni wrote:
OK, I'm trying to do this, but I can't get dzen2 to recognize the -geometry parameter. I'm using the latest SVN revision, and in config.mk, I've got option 7 ("With Xinerama and XPM and XFT") uncommented.
Never mind, I found the problem. Line 1048 of main.c says "#ifdef DZEN_XMP" when it should say "#ifdef DZEN_XPM".
On 01/03/2011 01:00 PM, Samir Unni wrote:
On 01/03/2011 12:34 PM, Samir Unni wrote:
OK, I'm trying to do this, but I can't get dzen2 to recognize the -geometry parameter. I'm using the latest SVN revision, and in config.mk, I've got option 7 ("With Xinerama and XPM and XFT") uncommented.
Never mind, I found the problem. Line 1048 of main.c says "#ifdef DZEN_XMP" when it should say "#ifdef DZEN_XPM".
OK, I finally got it! Turns out that the -geometry flag isn't needed after all. When I manually compiled from SVN (rather than using dzen2-svn from the AUR), everything started working perfectly, even with the same commands to start dzen2 as before. Thanks for all the help!
Excerpts from Samir Unni's message of Mon Jan 03 12:00:01 -0700 2011:
On 01/03/2011 12:34 PM, Samir Unni wrote:
OK, I'm trying to do this, but I can't get dzen2 to recognize the -geometry parameter. I'm using the latest SVN revision, and in config.mk, I've got option 7 ("With Xinerama and XPM and XFT") uncommented.
Never mind, I found the problem. Line 1048 of main.c says "#ifdef DZEN_XMP" when it should say "#ifdef DZEN_XPM".
whoo hoo! congratulations. Looks like I'm the one running the wrong version. :embarrased: I guess my svn repo is newer than the actual dzen build. So this bug is in 271? You could send an email or patch to rob.manea@gmail.com so he can fix that. Nice work! -- wmw
participants (3)
-
Justin Bogner -
Samir Unni -
Wirt Wolff