Intercepting ClientMessage for "foreign" windows

[Michael B. Trausch]

Hello,

I am the maintainer of AllTray and I come with a question that I have been 
banging my head against a wall with for the past couple of weeks.  I 
either am totally missing something that is really very simple, or what I 
am trying to do is of some difficulty, I don't know which.

Basically, the situation is thus: AllTray docks applications to the system 
tray.  It does this by handling various things; when the user clicks on 
the system tray icon, the window is iconified and hints are set that 
effectively hide the window from window managers, and then the user need 
only to click the icon to bring the window(s) back.

However, one of the "killer features" (at least, it seems, in the eyes of 
others who run the software) is the ability to click the "X" on a window 
and instead of the application closing, it gets docked back to the system 
tray.

Now, I've re-written AllTray from the ground up, trying to bring it more 
up-to-date (the old one was very ad-hoc about many things) and be 
compatible with more window manager/desktop environment systems without 
kludges to support them all.  The last problem (and it is proving to be 
one that I simply just cannot figure out) for me to solve is this 
close-to-dock functionality.

My thinking was that I could somehow intercept the WM_DELETE_MESSAGE 
ClientMessage that is sent to a window, so that I could act on it and 
never send it to the application.  It would seem that this thought was 
completely incorrect---or at least, I can't find a way to do it.

So, while trying to find other ways to do something functionally 
equivalent, I've come up with two options, with varying degrees of "eww" 
factor:

  * Proxy the connection to the X server by acting as an X server myself. 
This is the worst option from my point of view, but it would be X protocol 
library independent and work with all X clients and servers.  I have 
searched for a library that might do this that I could simply hook into 
and pass-through everything _except_ the WM_DELETE_MESSAGE ClientMessage 
and just act on that.  I was unable to find any such library.  Besides, 
this would cause AllTray to be heavier than it really need be, at least, I 
think.

  * Reparent the window to a top-level that I create, and pass through 
everything to the application save for the WM_DELETE_MESSAGE 
ClientMessage.  The thing is, though, that (at least as far as I have been 
able to implement it with various test programs) it seems to have 
unintended consequences.  Among these unintended consequences would be 
that it breaks the view of applications and application windows from at 
least the POV of libwnck, and I suspect that there may be more than that 
which could go wrong in doing this.  The other major downside to this is 
that it would require re-writing (I think) much of the application to work 
slightly differently, but again, I'm not sure.

  * Use LD_PRELOAD trickery to intercept Xlib calls and steal the 
WM_DELETE_MESSAGE ClientMessage before it is processed by the application 
or any toolkit that the application might be using.  This would 
conceivably work on platforms that implement LD_PRELOAD, at least in 
situations where the X client both uses Xlib and is not a setuid or setgid 
program.

Of these, the first and third options won't work when AllTray is used to 
"attach" to an already-running application, and so these options are 
extremely non-desirable.  This means that they also won't work with 
applications running over the network, unless there is an AllTray 
installed on the machine where the X client is running.

The second option seems to be the most promising, but either I don't know 
how to correctly implement it, or it has potential for breakage. 
Honestly, I'm not sure which of those is the case; I'd highly suspect that 
I simply don't know what I am doing and therefore cannot implement it 
correctly; my (admittedly uneducated, or maybe just plain stupid) guess is 
that given the right knowledge and understanding, this option would work. 
However, I've been reading and reading and... well, you get the idea.  I 
don't know what to do.

I'd very much appreciate any helpful information or resources that would 
help me get to the point where I can reliably handle this single 
problematic situation.  Thank you.

 	--- Mike