Hi Pedro and Vincent, On Sat, Aug 24, 2013 at 4:59 PM, Vincent Lefevre <vinc...@vinc17.net> wrote: > Any news?
Well, I finally (where does the time go!) thought about xcompmgr again. I applied the patch posted by Brandon Gooch in https://bugs.freedesktop.org/show_bug.cgi?id=46285#c3 and got mixed results. Under xfwm4 I still get no shadows at all. Under metacity with server-side compositing (xcompmgr -s), the shadows are drawn but don't obey the parameters (-t -l -r) I supply. Under metacity with client-side compositing (xcompmgr -c), the shadows are drawn according to my parameters, but when moving a window over top of a Chrome window, the old shadow frames are not removed but stay visible until Chrome redraws itself. (I'm running google-chrome-stable, not chromium). I pushed my changes up to Github (https://github.com/rtandy/xcompmgr) and uploaded a package to mentors (http://mentors.debian.net/package/xcompmgr), so please try it in case I made a mistake. The patch does seem to be applied by dpkg-source. Pedro, you wrote before that it behaved correctly for you, right? Considering that xcompmgr is more or less inactive upstream and still buggy, and at least two alternatives (compton and unagi) are now in Debian (besides some WMs gaining built-in compositors), I'm wondering whether spending time on xcompmgr is worth it, or whether RM/RoQA would be more appropriate. That said, if someone else still prefers xcompmgr over its alternatives, I'm happy to work on improving it. Looking forward to your response. Thanks Ryan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
