Fluxbox ignores window position when the window is created, even if I specify -x 10 -y 10.
The window manager decides where to put it (it forces 0;0 position)
It needs XMoveWindow(disp,win,uposx,uposy) call immediately after XMapRaised(...). It doesn't work if it is placed before the XMapRaised, only after.
I thought that the window will be firstly made visible on position 0:0 and then moved to new coordinates, but if I put sleep(2) just between the XMapRaised and XMoveWindow, nothing is really visible on the screen until the event loop is reached anyway. So it looks like this is safe approach to force the window position even for fluxbox.
@PMunch what do you think? Can I simply put it there?
Patch follows:
@@ -1881,8 +1881,11 @@ int main(int argc, char **argv){
}
XSetClassHint(disp, win, classHint);
XFree(classHint);
+
/* show the window */
XMapRaised(disp, win);
+ /* force move window to x/y pos */
+ XMoveWindow(disp,win,uposx,uposy);
// prepare for keyboard UTF8 input
if (XSetLocaleModifiers("@im=none") == NULL) {
I don't see why not. The position is just hints to the WM, it's free to ignore them should it wish, so this is probably closer to what the user expects anyhow.
Fluxbox ignores window position when the window is created, even if I specify -x 10 -y 10. The window manager decides where to put it (it forces 0;0 position)
It needs XMoveWindow(disp,win,uposx,uposy) call immediately after XMapRaised(...). It doesn't work if it is placed before the XMapRaised, only after.
I thought that the window will be firstly made visible on position 0:0 and then moved to new coordinates, but if I put sleep(2) just between the XMapRaised and XMoveWindow, nothing is really visible on the screen until the event loop is reached anyway. So it looks like this is safe approach to force the window position even for fluxbox.
@PMunch what do you think? Can I simply put it there? Patch follows: