Here is a simple test which creates/maps a windows at location (100,100) and on mouse press move the window at the same location. Under Metacity everything works fine (second move does nothing), however under Compiz we have a different story :( initially it places so decoration would placed at (100,100) and the window itself has different coordinates ((104, 124) in my case. But after XMoveWindow() it moves the window at (100,100), so decorations are at (96, 76). I may be wrong, but my interpretation of ICCM (http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.5) is that WM should treat coordinates from XMoveWindow() the same way as from hints for initial showing. #include <X11/Xlib.h> #include <X11/Xutil.h> #include <stdio.h> Display *display; Window root, w1; Window create_window(char *name, Window parent, int x, int y, int width, int height) { Window win = XCreateSimpleWindow(display, parent, x, y, width, height, 2, BlackPixel(display, 0), WhitePixel(display, 0)); XStoreName(display, win, name); XSizeHints *hints = XAllocSizeHints(); hints->width = width; hints->height = height; hints->x = x; hints->y = y; hints->win_gravity = 1 /*NorthWest*/; hints->flags = PPosition | USPosition | PSize | PWinGravity; XSetWMNormalHints(display, win, hints); XFree(hints); return win; } int main(int argc, char **argv) { XEvent ev; char *display_name = NULL; if ((display = XOpenDisplay(display_name)) == NULL) { fprintf(stderr, "Couldn't open %s\n", XDisplayName(display_name)); return -1; } root = RootWindow(display, 0); w1 = create_window("Window", root, 100, 100, 100, 100); XSelectInput(display, w1, StructureNotifyMask | ExposureMask | ButtonPressMask); XMapWindow(display, w1); XFlush(display); while (1) { XNextEvent(display, &ev); if (ConfigureNotify == ev.type) { XConfigureEvent e = ev.xconfigure; fprintf(stderr, "ConfigureNotify: w=%x, x=%d, y=%d, send=%d\n", e.window, e.x, e.y, e.send_event); } else if (ButtonPress == ev.type) { XMoveWindow(display, w1, 100, 100); fprintf(stderr, "button pressed\n"); } } return 0; }
Created attachment 14964 [details] [review] Possible fix Here is a patch that seems to fix this problem. I didn't spot any bad side effects. It doesn't fix Java bug 6632124 though.
Created attachment 15219 [details] [review] Better fix Better fix attempt. The patch in comment #1 only works for windows with NorthWestGravity. This fix should work for all kinds of gravity - please test.
Created attachment 15220 [details] [review] Better fix, take 2 I just noticed that my first fix attempt didn't work correctly for e.g. SouthEastGravity. Inspection showed that seemingly just the north / west adjustments were missing from the moveResizeWindow function. Please test this one, it should work fine.
(In reply to comment #3) > Created an attachment (id=15220) [details] > Better fix, take 2 > > I just noticed that my first fix attempt didn't work correctly for e.g. > SouthEastGravity. Inspection showed that seemingly just the north / west > adjustments were missing from the moveResizeWindow function. > Please test this one, it should work fine. After thinking a bit more about that, I decided that this fix is the correct one and thus pushed it. Should be fixed in commit 61f8473ed79d679f0c9dd068340b14ad964dda12.
I tested the latest git version with your commits, and it works fine for all gravities. Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.