|For weeks on end now I've been trying to work out why various XLib calls seem to fail without warning, and without returning an error code.
XMoveResizeWindow(XDisplay(), Window, x, y, width, height);
When executed, in some cases it fails to set the window position after mapping the window. But only in a few repeatable isolated cases, and usually only after the first time it's executed. For instance in a dialog a child window is in the correct place initially then every time after that it's in the wrong place. The return values are the same, the Window's are all recreated, i.e. not reusing the same objects. Xlib/X11 is just busted.
Then there is my other fravorite. I implement menus in Scribe/LGI with Windows created with XSetWindowAttributes::override_redirect = true, as you do. And I then "attach" it to the owning application window with:
XSetTransientForHint(XDisplay(), Window, Owner);
Which should make sure that the popup menu is always ABOVE the owner window. And it works for the first hour or so and then suddenly it STOPS working and the menus appear BEHIND the owning window... for no apparent reason and with no apparent user interaction (i.e. the app is at idle). So you click the menu and nothing appears because the Z-order is all screwed up. This can also be caused by calling XSetTransientForHint with None as the owner parameter (which is a bug in X, it should just ignore the call, but I can deal with that) so I fixed that but it's still happening.
So unfortunately I'm stuffed... Xlib is broken. I'm sure there is a way to work around these problems however I have less and less patience to look for the solution. All my code that does this is part of the open source GUI library: LGI which I'll update today, that anyone who is interested in looking at the raw code they can.
Update2: 2nd bug NOT worked around.
|On the second issue of popups mapping below their transient for window, I've changed the XMapWindow call to XMapRaised and the first 8 hour test (which usually caused the bug to manifest) was passed successfully. So I might have worked around this successfully. But apparently it's still happening, so thats not it. You'd think that XMapRaised was pretty explicit about what the programmer wanted, but no X / WM / Xlib has to screw that up too.
I also figured out a really annoying bug today, and that was when dlopen'ing the LGI shared object it would overwrite all the global variables. Which obviously creates havok, as it's not designed to be loaded twice, or maybe it's that the 2nd copy is the "other" build of LGI (i.e. Debug / Release) which would obviously have different memory layouts. This bug would occur in Scribe's plugin window when you go to add a new plugin. It does a recursive search for possible plugins (shared objects) and it was finding copies of LGI and attempting to load them to see if they we're plugins.