Event for override-redirect change

[Devin J. Pohly]

On 11/30/2010 09:23 AM, Owen Taylor wrote:
> On Mon, 2010-11-29 at 17:31 -0500, Devin J. Pohly wrote:
>> In my case, the motivating example is a tiling window manager.  If a
>> window is already mapped and part of the tiled layout, I'd want it to
>> pop out of the tiled arrangement if it switches to unmanaged.  As it
>> stands, the WM has to recheck each window every time it arranges them.
>
> If the window is override redirect, the window manager doesn't have a
> say in where it is positioned. The application is completely responsible
> for positioning and stacking override redirect windows. You should not
> be touching override redirect windows or you can cause a "fight" where
> the window bounces around between multiple positions.

I understand.  I meant the other windows, which could be retiled as if 
the override-redirect window had been withdrawn.

> You might also want to note section 4.2.9 of the ICCCM which suggests
> that applications in some cases can temporarily set override-redirect on
> their toplevels. To my knowledge no toolkit has ever implemented this
> and I doubt anybody ever will, but the implication there is a change to
> override-redirect should *not* cause a window to pop out; the window
> manager should continue as normal assuming it will shortly be changed
> back.

Also, 4.2.2 says that this and "modal" windows are the only valid 
excuses for using override-redirect in the first place - though there 
seem to be a lot of clients that don't conform to that (Firefox, 
Thunderbird, xosd, and dzen2 for starters).  The reason anything would 
need ResizeRequest in addition to ConfigureNotify still eludes me, but 
that's a separate discussion.

>> The more basic issue is that X provides a way for Client A to change a
>> property which is of direct interest to Client B (the WM in this case)
>> without providing a way for Client B to find out.  It feels...
>> inconsistent... since X is generally really good about this.
>
> In general, yes, X does have a lot of notification. But lack of
> notification in one area, isn't in itself a reason for protocol
> additions. Motivation has to be something that clients need to do that
> will make things better for the user.

I figured it might be minor enough, since it only changed semantics and 
not any actual protocol messages, but I do see what you're saying.  I 
can do a little scribbling on the "X12" wikipage instead, if that'd be 
more appropriate.

Thanks!
*dp