Question

I’d like to intercept the WM_DELETE_WINDOW message that is posted to a certain selection of windows that an application I’m writing (AllTray), so that I can act on it instead of the application receiving it. I’m currently looking at trying this at the GDK level via gdk_display_add_client_message_filter if possible, but I’d be happy with an Xlib solution if there is one as well; it seems to be possible, but I just don’t seem to be understanding how I am to do it successfully.

Currently, I have two programs (written in C) that I am trying to use to get this figured out, the first one does nothing but create a window and register that it knows about WM_DELETE_WINDOW, and the second one attempts to catch that message, but seems to fail in doing so; it appears to do precisely nothing. Am I understanding the documentation wrong on this, or is there something additional that I need to be doing (or do I need to avoid using GDK entirely for this)?

The background is this: Prior to my re-write of AllTray, the way it would do things appears to be to try to intercept a mouse-click on the X button itself. For some window managers, this worked properly, for others it didn’t work at all, and for others, the user had to configure it manually and instruct AllTray where the button for closing the window was. What I am looking for is a solution that doesn’t involve a LD_LIBRARY_PRELOAD and will work for any window manager/application combination that conforms to the current standards and sends a WM_DELETE_WINDOW ClientMessage when the window is closed.

UPDATE: I’m still looking for an answer. The route that I am taking at the moment is to try to reparent the window and manage it myself, but I just cannot make it work. Upon reparenting, I don’t seem to be able to get it back in any way. I may be missing something very fundamental, but I can’t figure out how to actually make it appear it my own window again, to bring it back on the screen.

UPDATE 2: Alright, so I’ve hit another brick wall. The X server documentation says to set the StructureNotifyMask on the window’s event mask to receive both MapNotify and ReparentNotify events. I’d be interested in receiving either. My current thinking was to create a window that served just as an event receiver, and then when I get events for interesting things, act on them by creating and reparenting. However, this simply doesn’t seem to be working. The only events I actually receive are PropertyNotify events. So, this route doesn’t seem to be doing very much good, either.

Answer 1

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.