[Xquartz-dev] override-redirect problems

Bob Murphy bobert at lavitanuova.com
Fri Oct 17 16:11:02 PDT 2008


On Oct 17, 2008, at 3:21 PM, Jeremy Huddleston wrote:

>>> 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
>
> Yes.  The X11 parent window is the root window, and WM_TRANSIENT_FOR  
> is not set.

Ah. Very annoying. :-)

>> , or
>> (b) there's no place to store the parent in the child, or
>
> There is a place... WM_TRANSIENT_FOR... but o-r windows are not  
> required to set WM_TRANSIENT_FOR, so we aren't told this information  
> (such is the problem with nedit and xemacs)

If one *could* figure out (or guess) the parent window, would it help  
to flip this flag on and set the transient parent on the window?

>> 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.
>
> Eek.  Not at all kosher or trivial.

Absolutely a kludge. But any solution for this problem will be a  
kludge, and walking the X window tree to calculate intersections is  
both fairly easy, and reasonably efficient if done inside the X server.

>
>
>> 2. If there is no intersection, pick the highest Window the mouse is
>> over
>
> Again, feels too kludgey to me...

Again, yes, a kludge, but if you're dealing with a pop-up menu in an X  
program, the pop-up will usually be triggered by a mouse click in the  
parent window. So I suppose you could use the location of the last  
mouse click, if that is cached.

>> 3. If 1 and 2 both fail, pick the highest top-level Window.
>
> Yeah, but this fails due to async:
>
> 1) Click on the File menu
> 2) Activate xterm
> 3) file window is mapped and now child of xterm

I'm not clear on how to do this. In which app do you click on the File  
menu, and then how do you activate xterm?

>
>
>> If (b), and you don't want to re-use any of the existing Window
>> fields, devPrivates is an option.
>
> This needs to be something the WM has access to...
>
> I think what I might just do is always move the window to the  
> current space when it is ordered in if it is override-redirect.


This exposes my ignorance of how OS X menus and windows work with  
Spaces and how X windows interact with them...

In the Ubuntu/GNOME multiple workspaces, as well as older Mac OS 9  
workspace apps, the physical screen is kind of a window onto a much  
larger canvas. And the way you switch workspaces is to move the canvas  
around by traversing the window list and moving all the windows by a  
uniform offset so the ones you want to see are visible on-screen and  
the rest are somewhere else. (There's more to it than that - lots of  
bookkeeping and exceptions, but that's the gist.)

Is that how Spaces works, or is something else going on?

- Bob





More information about the Xquartz-dev mailing list