Intercept WM_DELETE_WINDOW on X11?

I don't know X11, but I googled using "Intercept WM_DELETE_WINDOW X11" as keywords. Found 17k - MarkMail and Mplayer-commits r154 - trunk/libvo. In both cases they are doing the same thing.

 /* This is used to intercept window closing requests.  */ static Atom wm_delete_window;

within static void x11_init(),

XMapWindow(display, win);wm_delete_window = XInternAtom(display, "WM_DELETE_WINDOW", False);XSetWMProtocols(display, win, &wm_delete_window, 1);

then, within static int x11_check_events(),

XEvent Event;while (XPending(display)) {    XNextEvent(display, &Event);    if (Event.type == ClientMessage) {        if ((Atom)Event.xclient.data.l[0] == wm_delete_window) {            /* your code here */        }    }}

See XInternAtom, XSetWMProtocols and XNextEvent.

After I wrote the above, I found Handling window close in an X11 app:

When a user clicks the close button [x] on our X11 application we want it to pop a a dialog asking “do you really want to quit?”. This is a plain X app. No fancy GTK or QT widgets here. So how to catch the “window is being closed” message?

The answer is to tell the Window Manager we are interested in these event by calling XSetWMProtocols and registering a WM_DELETE_WINDOW message with it. Then we’ll get a client message from the Window Manager if someone tries to close the window, and it won’t close it, it’ll leave that us up to us. Here’s an example….

// example.cpp#include <X11/Xlib.h>#include <X11/Xatom.h>#include <iostream>int main(){   Display* display = XOpenDisplay(NULL);   Window window = XCreateSimpleWindow(display,                                       DefaultRootWindow(display),                                       0, 0,                                       500, 400,                                       0,                                       0, 0);   // register interest in the delete window message   Atom wmDeleteMessage = XInternAtom(display, "WM_DELETE_WINDOW", False);   XSetWMProtocols(display, window, &wmDeleteMessage, 1);   std::cout << "Starting up..." << std::endl;   XMapWindow(display, window);   while (true) {      XEvent event;      XNextEvent(display, &event);      if (event.type == ClientMessage &&          event.xclient.data.l[0] == wmDeleteMessage) {         std::cout << "Shutting down now!!!" << std::endl;         break;      }   }   XCloseDisplay(display);   return 0;}

Unfortunately, the best answer to this question is a series of non-answers; there are technically ways to accomplish it, but they all have downfalls that make them extremely impractical:

1. Create an X11 proxy for an application, passing all X11 protocol messages back and forth between the application and the X server. The proxy would then filter out any interesting messages. The downside to this is that this is an awful lot of overhead for a single little tiny feature, and the X11 protocol is complex. There could also be unintended consequences, which makes this an even more unattractive option.
2. Launch as a standard application that acts as an intermediary between the window manager and “interesting” client applications. This breaks some things, such as XDnD. In effect, it is not unlike the first option, except that the proxy is at the Window level as opposed to the X11 protocol level.
3. Use the non-portable LD_PRELOAD library trick. This has several downsides:
   1. It is non-portable across dynamic linkers: not all dynamic linkers support LD_PRELOAD, even among UNIX-like systems.
   2. It is non-portable across operating systems: not all operating systems support featureful dynamic linkers.
   3. It breaks network-transparency: the shared object/dynamic link library must reside on the host as the child process that is being executed.
   4. Not all X11 applications use Xlib; it would be necessary to write one LD_PRELOAD module for each of the libraries that an application might use to talk with X11.
   5. In addition to the last point, not all applications would be susceptible to LD_PRELOAD even if they ran under a linker that supported it, because they may not use a shared object or DLL in order to communicate with X; consider, for example, a Java application which uses an X11 protocol library written in Java itself.
   6. On some UNIX-like operating systems, LD_PRELOAD libraries must be setuid/setgid if they are to be used with setuid/setgid programs. This is, of course, a potential security vulnerability.
   7. I am quite sure that are more downsides that I cannot think of.
4. Implement an extension to the X Window system. Non-portable among X11 implementations, complex and convoluted as all get out, and absolutely out of the question.
5. Implement extensions or plug-ins to window managers. There are as many window managers as there are opinions on window managers, and therefore this is utterly infeasible.

Ultimately, I was able to finally accomplish my goal by using a completely separate mechanism; anyone who is interested, please see the Close-to-Tray support in AllTray 0.7.5.1dev and later, including the git master branch available on github.

Ok, to elaborate on my earlier suggestion, you might want to investigate XEmbed. At the least, that might give you some ideas to try.

Failing that, I'd have a look at how other similar software might be working (e.g. wmdock, or how GtkPlug/GtkSocket is implemented), though I believe in both those cases explicit support is required in the applications.

Hope that is more helpful.