When changing orientation, the panel does not update the struts/partial struts correctly. To reproduce: 1) place the panel on the left side. 2) change the settings so that the panel goes to top 3) the struts are set temporarily so that the top are as hight as the panel height when it was vertically 4) the window manager moves all windows toward the bottom of the screen to obey the struts wrongly set by the panel I think the problem comes from the way the panel updates its struts during orientation update. It would make a lot more sense to update the struts only when the panel is placed and resized.
Bah, that code is awful :( I had a quick look and _set_struts is called a million times while changing the position, because of all kinds of gtk signals and direct calls to _set_struts. I'm sure it can be fixed, but I need a closer look at it to do it properly. I will do it as soon as I can. Thanks.
Well, priority/severity on this bug can be lowered IMHO, it's not a crash or a security threat, after all ;)
(In reply to comment #2) > Well, priority/severity on this bug can be lowered IMHO, it's not a crash or a > security threat, after all ;) > Heh, well, it was ugly. It's still ugly, but as far as I can tell this issue should be fixed with revision 23944 ;-)
Humm, sorry, the problem remains even with revision 23947.
(In reply to comment #4) > Humm, sorry, the problem remains even with revision 23947. > Ah, I was a little afraid you might say that... I guess the panel size is still not up-to-date when I turn the callback back on. I'll investigate further.
Could you try again (rev. 23948)?
(In reply to comment #6) > Could you try again (rev. 23948)? Still reproducible. The use of the idle callback doesn't remove the race condition, it just makes it a bit less likely to trigger IMHO :)
I would add that I can "see" the panel being move vertically from the left side to the top center of the screen before the orientation changes. And when that happen, the stuts are not updated correctly. Why not simply hide the panel when switching orientation? Xfwm4 should ignore struts of hidden windows.
(In reply to comment #8) > I would add that I can "see" the panel being move vertically from the left side > to the top center of the screen before the orientation changes. And when that > happen, the stuts are not updated correctly. > > Why not simply hide the panel when switching orientation? Xfwm4 should ignore > struts of hidden windows. > Unfortunately the panel doesn't seem to be able to handle this: the panel becomes full-screen, interesting experience ;-). This code is rather fragile, I'm afraid. I don't understand entirely what is going on and I think that to properly fix it I need to do a major cleanup of the panel internals, so that's not something I can do for 4.4.0. I just committed a small change that seems to improve things. At least I have not been able to reproduce the problem anymore. I do believe the race condition still exists, though.
Yes, the problem doesn't show anymore.
Unfortunately, it still shows. I've committed a patch in xfwm4 that detects when apps set buggy struts and the problem still arises. ** (xfwm4:30644): WARNING **: Strut value for application window 0x120001c changed from 1280 to 200
Also, I noticed that the panel updates the struts at every mouse click on the panel. When the panel updates its struts, xfwm4 updates the work area and check for all apps positioning, are recomputes the size of maximized windows. That's a lot of wasted computation IMHO. I've added a workaround that checks to actually see if the struts are really updated (ie check if every new strut value is different from the previous value). It should improve things, but the panel needs fixing I think.
Pff, that was quite bad. I have added a few check to at least not update the struts quite as often and to try and catch incorrect intermediate values of the panel size when changing orientation. I hope this again helps a little, but I don't think it will be completely fixed until I do a major cleanup.
This should be fixed now, and I don't think I heard of any more cases of this problem.