On 11 January 2012 22:47, Eckehard Berns <ecki-suckl...@ecki.to> wrote: > On Wed, Jan 11, 2012 at 10:20:43PM +0100, Anselm R Garbe wrote: >> On 11 January 2012 18:30, Eckehard Berns <ecki-suckl...@ecki.to> wrote: >> > Thinking about this, another way to fix this problem would be to >> > change all XRaiseWindow calls in dwm to restacking them just below the >> > bar and never raising the bar. That way dwm would play nicely with other >> > override redirect windows as well. I don't know if that would be worth >> > it. >> >> I need to try this, as this sounds like a sensible way to fix this >> issue. If it does, then I have no objection putting this into mainline >> dwm. > > I thought a bit more about this and I don't think the solution is so > easy. I'd assume that you don't want every override redirect window to > be always on top. Also, floating windows are above the bar at the > moment, which is what you would expect IMHO. That means that there is no > suitable window to align the stacking of floating windows to. > > And as it seems, the floating WMwindow of SDL is the main problem here. > > On a related note, while investigating the SDL-problem further I found a > leak in dwm: updatebars() always creates new barwins. I attached a patch > to skip the creation of a new barwin if the monitor already has one. > This is why I thought the barwin would be raised, but instead a new one > is created (which has the same effect). > > What remains is the floating WMwindow which will be raised in restack(). > Does anyone remember why the code in lines 1423 and 1424 is neccessary? > Without it the SDL problem doesn't occure on my system any more (without > the need to patch SDL itself). I attached the second patch for anyone > who wants to try this.
I believe these two lines relate from an earlier algorithm that was used prior to the barwin restacking. I applied your two patches to tip, this needs to be tested for side effects now. Thanks for your valuable contribution Eckehard! Cheers, Anselm
