[Xquartz-dev] override-redirect problems

[Bob Murphy]

>
> We're having some difficulty with menus in some applications like  
> nedit and xemacs.  I believe these menus are windows with override- 
> redirect set on them per section 4.1.10 (popup windows) of ICCCM:
> http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.10
>
> """
> If the window will be visible for a very short time and should not  
> be decorated at all, the client can set override-redirect on the  
> window. In general, this should be done only if the pointer is  
> grabbed while the window is mapped. The window manager will never  
> interfere with these windows, which should be used with caution. An  
> example of an appropriate use is a pop-up menu.
> """
>
> The problem is that windows following this route don't get handled  
> by our WM and don't get their native windows parented properly by  
> quartz-wm.  When a window sets WM_TRANSIENT_FOR, we set its native  
> window as a child to its parent's native window so the menu "belongs  
> to" and "moves with" the parent.  This works fine for nedit's Open  
> dialog for example.  Menus that don't set WM_TRANSIENT_FOR and  
> follow this override-redirect approach don't get parented properly  
> and cause problems (like the menu appearing in the wrong Space  
> [virtual desktop] because that's the Space it was last rendered in  
> and thus the native window bound to).
>
> We need a way to bind the native window for this menu to the native  
> window for its parent.  Currently it is just bound to the Space in  
> which it is first rendered... so does anyone have some suggestions  
> for the least invasive way to go about this?  Doing some quick  
> investigation with xwininfo on the window, I see no wm hints, and  
> it's parent window id is the root window... so... yick.
>
> Any thoughts?

Is the problem that (a) it's not clear what the parent should be, or  
(b) there's no place to store the parent in the child, or (c) you know  
what the parent should be, but there's no way to communicate that to  
the Mac OS windowing system?

If (a), given that the thrust of this feature seems to be to support  
things like popup menus, here's a heuristic that would make a good  
guess:
1. Pick the highest Window whose bounding region the popup menu's  
bounding region intersects.
2. If there is no intersection, pick the highest Window the mouse is  
over
3. If 1 and 2 both fail, pick the highest top-level Window.

If (b), and you don't want to re-use any of the existing Window  
fields, devPrivates is an option.

If (c), that's pretty tricky! :-)

- Bob Murphy