On 19.09.2018 19:40, Michel Donais wrote:
So, the code actually works using append_event, but it might not be the best solution, as the WM_NCDESTROY event is terminal, so merely appending an operation for future consideration is probably not the best case.
This got me thinking: why exactly does GTK not handle WM_DESTROY? That is a message that child windows get before they are destroyed, whereas WM_NCDESTROY is only sent after everything is supposed to be dead. According to commit 820721500b4f215eebda1f2466bf4166922bfa1e, this was done deliberately. I've looked at XOrg[1] manual, and it seems to agree with that - DestroyNotify is called bottom-up (children first, parent last), and the X11 window can't be referenced after that message is received (or processed?). So yeah - it kind of works just like WM_NCDESTROY. After that i've looked at gdk_x11_window_destroy_notify(). It checks for the GDK window not being destroyed yet, and if it isn't, the window is destroyed (it warns if this is done for a non-foreign window), then detaches the GDK window from GDK display, clears its grab, if any, and unrefs it. The GDK_WINDOW_DESTROYED() (the ->destroyed field) is weird. It is only set to TRUE by _gdk_window_destroy_hierarchy(), which sets it *after* it calls impl->destroy() (which results in XDestroyWindow on X11; i.e. normal windows are supposed to be XDestroyWindow-ed first, which will cause DestroyNotify, which will be handled in gdk_x11_window_destroy_notify(), and only after that the ->destroyed field will be set to TRUE, which will allow GDK_WINDOW_DESTROYED() to evaluate to TRUE). I don't understand why gdk_x11_window_destroy_notify() doesn't warn about non-foreign windows being destroyed all the time. W32 backend does it differently - it explicitly sets ->destroyed to TRUE before calling DestroyWindow(). What a mess... [1]: https://www.x.org/archive/X11R7.5/doc/man/man3/XDestroyWindow.3.html
Attachment:
signature.asc
Description: OpenPGP digital signature