GNOME Bugzilla – Bug 58814
move to current position is not idempotent
Last modified: 2004-12-22 21:47:04 UTC
If I repeatedly press the "Move to current position" button in the "window sizing" test of testgtk, the test window keeps jumping to the northwest direction. This happens under fvwm2, enlightenment, windowmaker and twm, so I guess your window sizing patch does some not quite ICCCM-savy things there. It doesn't happen with kwin for some reason. I didn't test sawfish.
And I just found out that you can influence the direction of the jump with the window gravity settings.
To say something positive: it works without a window manager.
Without looking deeper, the reason for this is that gtk_window_get_position returns the reference point for the wm frame window, not for the window itself. This is broken, since according to ICCCM, clients should ignore wm frames and operate as if there were no window manager.
You need to look at: http://www.freedesktop.org/standards/wm-spec.html In particular: http://www.freedesktop.org/standards/wm-spec/x280.html The ICCCM is very difficult to interpret the ICCCM in this area, but the general consensus is that positions should be interpreted in the same way for move as for map. The wm-spec tries to clarify this, and the only way we are going to get everything working is if everybody conforms to this interpretation, rather than implementing what they think the ICCCM means. Many (perhaps most) window managers are in fact currently broken. I do want to write a simple X only test suite for window positioning and moving at some point, which would make window manager breakage unambigiously clear. [ Despite all of the above, it is possible that GTK+ has bugs in its currently code. But positioning the window in the same place as the window manager frame is currently located is the correct thing for NW gravity. ]
I have looked at the URLs you cite and I have also studied the relevant ICCCM sections in detail. But you seem to misinterpret the bw that is mentioned in the WM spec note as referring to the frame window size. In fact it is referring to the internal border of each X Window (which X11 inherited by design mistake from X10 and which usually 0 these days). I still maintain that it is very wrong to interpret the ICCCM in a way that would force clients to know anything about the frame windows which a possible wm may place around their toplevels.
A client that wants to position its window at a particular location uses static gravity. Otherwise, the client is positioning itself at a logical location on the screen - the upper left of the screen, the lower right of the screen, etc. This is why the ICCCM defines positioning the way it does, both on initial map and move.If I want to position the window at the upper left of the screen, with your interpretation, I would have to figure out my window frame sizes, and position at (window_frame_left_border, window_frame_top_border).
(And no, this is not interpreting bw as the frame width, which is, after all different for each border, the algorithm described, with bw == 0, gives the behavior GTK+ expects For NorthWest gravity, the reference point is at the x,y specified, and the wm spec says: window frame's left top corner will be placed at (ref_x,ref_y)
Sorry, I missed the reference to §4.1.2.3 explaining the relation between gravity and the window to which the reference point refers. You are in fact right that this seems to indicate breakage throughout the twm line of the wm anchestry (twm, fvwm2, enlightenment, windowmaker(?)). This makes me think again that a really useful thing to write (instead of yet another window manager) would be a ICCCM-compliance test suite) - I even have some test programs lying around somewhere testing some arcane aspects of ICCCM2 vs ICCCM1.
To save the honour of the twm-anchestry: I just discovered that kwin is just as broken if you change the gravity to anything different from northwest or static.
Created attachment 874 [details] Test case for gravity and XMoveWindow
I've attached a test for all gravities other than Static that simply maps a window with each gravity at the corresponding location on the screen. (NorthWest to upper left), then when that window is clicked upon, moves the window to the same place as it originally requested mapping it. sawfish seems to pass the test. WindowMaker treats all gravities like StaticGravity. fvwm2 behaves like WindowMaker. twm is off by odd small amounts.. icewm tries to honour the initial requests with respect to a "workarea", so it is hard to tell if its MoveWindow implementation or not. wm2 passes. BlackBox is buggy. (No guarantee that any of these tests are with the latest version of the window manager.)
Ok, I've changed the headline according to our findings, but kept the bug open, since it might be a good idea to contact the authors of maintainers of the offending WMs with your testcase.
Whew, now that is the fastest-growing bug report I've ever seen. ;-) Yes, I believe most window managers are in fact broken. However since testgtk is only guessing frame sizes, it can't be treated as a definitive test (if a WM doesn't use reparenting into a single X window for borders, then the testgtk test will legitimately not work properly). With Sawfish I get different behavior for "move to starting position" and "move to current position," and I haven't fully figured out the reason for it. This may be a GTK bug. Metacity does work with testgtk, so it's at least mathematically possible to work with it. Of course this only proves that I have consistent delusions on both WM and client side. ;-)
Havoc, sorry to burst your bubble. I've extended Owens testcase to include static gravity and resizing, and now metacity fails like any other wm :-(
Created attachment 913 [details] extended testcase
I should have mentioned that wm2, which is the only wm found to be flawless by Owens testcase, passes the move test for all gravities including static, but fails the resize test.
Crap!
I fixed Metacity move test for StaticGravity in CVS, it was a trivial thing. Resize was never known to work in Metacity, I hadn't ever tried it. ;-) I actually have a FIXME about that. We investigated Sawfish; it appears to be broken for move, with gravities Center/N/S/E/W. It centers windows without accounting for their frame. This seems to be just a failure to handle those gravities in its switch statement that adjusts coordinates for gravity.
I sent a mail to John Harper today with a patch for Sawfish which fixes the problem. With sawfish's current lack of maintainence, not sure if that will appear in a released version any time soon.
Ok CVS metacity gets the honour of being the first wm to pass both the move and the resize tests. I'm going to devise more devious tests now: change gravity and border width on the fly - be prepared :-)
Since the GTK+ test now works with CVS sawfish and with metacity, I think we can close this bug.