Event for override-redirect change

[Owen Taylor]

On Mon, 2010-11-29 at 17:31 -0500, Devin J. Pohly wrote:
> On 11/29/2010 02:06 PM, Adam Jackson wrote:
> > On Fri, 2010-11-26 at 23:33 -0500, Devin J. Pohly wrote:
> >> The override-redirect flag is important for a window manager to know
> >> about, but there's no notification made when a window changes it.  It
> >> doesn't appear that the protocol specifies an action to take when a
> >> ChangeWindowAttributes request changes override-redirect.
> >
> > I'm not entirely sure what you're going to do about managing an
> > unmanageable window.  Which sort of determines how we'd go about getting
> > an event for this generated.  What did you have in mind here?
> 
> 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.

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.

If an application reliably wants to change a window from acting as a
toplevel to acting as an override-redirect popup, the recommended way to
do it would surely be to withdraw the window first. Nothing else is
going to work with the bulk of existing window managers.

> 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.

- Owen