Apache OpenOffice (AOO) Bugzilla – Issue 19157
no pop-down on Unix, of palettes ...
Last modified: 2004-01-27 17:15:03 UTC
Hi Philipp, I had a poke to see if indeed Metacity is moving the windows around, and (from my debug) it seems we're not - however, we're getting some eroneous move/re-size action happening, apparently based on some decrementing of border dimensions; This patch fixes it for me :-) -- vcl/unx/source/window/salframe.cxx +++ vcl/unx/source/window/salframe.cxx @@ -3295,8 +3295,8 @@ &nLeft, &nTop, &hDummy ); - pFrame_->maGeometry.nLeftDecoration = nLeft > 0 ? nLeft-1 : 0; - pFrame_->maGeometry.nTopDecoration = nTop > 0 ? nTop-1 : 0; + pFrame_->maGeometry.nLeftDecoration = nLeft; + pFrame_->maGeometry.nTopDecoration = nTop; /* * decorations are not symmetric, HTH.
Strange. I'll have a further look at that.
Fix should go into 1.1
For a time you had me thinking i was a complete idiot. Now I'm down to only half an idiot again :-) I see the problem now; but the solution as i see it is a little different: diff -r1.164 salframe.cxx 3314,3315c3314,3315 < pFrame_->maGeometry.nX = xp + pFrame_->maGeometry.nLeftDecoration; < pFrame_->maGeometry.nY = yp + pFrame_->maGeometry.nTopDecoration; --- > pFrame_->maGeometry.nX = xp + nLeft; > pFrame_->maGeometry.nY = yp + nTop; The main problem is that if any further event shows up the frame will seem to have moved because the position is off by one. But the (nLeft-1,nTop-1) for the decorations is still correct as the sum of decorations plus frame width should equal the width of the WM parent window. This is the case if the left/top decoration is decreased by one. The reason for the -1 by the way was an accessibility issue; the accessibility applications work with coordinates of the outer frame (that is the frame including decorations; i can only guess that this stems from some Windows weirdo specification). It always came with an offset of (-1,-1) but came up correctly on other platforms (well, Windows, you guessed it) so i gathered the offset was from the decorations - which proves to be true still, since now the decorations plus the (inner) frame width/height add up the WM parent's size. In addition there really are some window managers that move the window around (Dtwm, IceWm), but that's mostly because we have to set a different window gravity hint - either to get them to respect our positioning requests or to make them not do insane things (IceWM and others do weird things if you set StaticGravity - what a mess). Which was what i remembered dimly on Thursday and was why i told you, the WM would move the window around where the ICCCM conforming of them are totally innocent. Sorry. fixed in CWS vcl7pp1r2
pl->ru: please verify in CWS vcl7pp1r2, for verification you also need to check if #104086# is still fixed.
.
Verified on accessible Gnome build from 28/08/2003.
*** Issue 19299 has been marked as a duplicate of this issue. ***
*** Issue 23360 has been marked as a duplicate of this issue. ***