I sent this message to the main xorg list, but thought I should pop it in here as well... --Jeremy === 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? xwininfo: Window id: 0x800044 (has no name) Absolute upper-left X: 4 Absolute upper-left Y: 67 Relative upper-left X: 4 Relative upper-left Y: 67 Width: 202 Height: 418 Depth: 24 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x21 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: yes Map State: IsViewable Override Redirect State: yes Corners: +4+67 -3154+67 -3154-715 +4-715 -geometry 202x418+4+67 xwininfo: Window id: 0x800044 (has no name) No window manager hints defined xwininfo: Window id: 0x800044 (has no name) Root window id: 0xbf (the root window) (has no name) Parent window id: 0xbf (the root window) (has no name)
Quoted Jeremy Huddleston <jeremyhu@apple.com>:
I sent this message to the main xorg list, but thought I should pop it in here as well...
--Jeremy
===
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?
I have an ugly idea to fix this. The XIDs are not random that are used for Windows. The application has a base XID, and it allocates Windows with a certain pattern. So there should be a common prefix for the XIDs allocated for a client. This prefix varies depending on how many clients the X server supports IIRC (MAXCLIENTS), which seems to be 256 for XQuartz. See: xserver/dix/resource.c RESOURCE_CLIENT_BITS is also involved. See: xserver/include/resource.h I added an optional feature to my window manager (Whim) that would arrange related windows with a group. I think you might be able to find the parent based on the common prefix, such as 0x8000 or something similar. It's a hack, but I don't know of a better way. There is also an X AppGroup extension in Xext, but I don't think it's specifically designed for such purposes. I may be mistaken though. You might be able to use it. Look for Xag*(). George -- http://people.freedesktop.org/~gstaplin/
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
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.
, 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)
(c) you know what the parent should be, but there's no way to communicate that to the Mac OS windowing system?
Not at all.
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.
2. If there is no intersection, pick the highest Window the mouse is over
Again, feels too kludgey to me...
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
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.
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
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?
I'm just describing a series of events where it is possible for you to send a mouse click event to nedit, then raise the xterm window before nedit actually registers the mouse click and maps the menu window.
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?
The problem is that when we order in a window that was ordered out on another space, it is automatically ordered in on that original space.
===
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. """
BTW, are there any instructions on how to replicate this problem with nedit? I was trying to see how Ubuntu handles things like this, but couldn't find any obvious way to get a pop-up menu or anything else that looked like it used this mechanism. The pull-down menus appear to be getting decorated by the window manager. - Bob
1) Open nedit 2) Click 'File' 3) close the file menu 4) Move nedit to another space 5) Follow nedit to that space 6) Click on 'File' This is something ubuntu does not need to worry about since they don't have a native windowing system on top of X11. On Oct 17, 2008, at 13:04, Bob Murphy wrote:
===
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. """
BTW, are there any instructions on how to replicate this problem with nedit? I was trying to see how Ubuntu handles things like this, but couldn't find any obvious way to get a pop-up menu or anything else that looked like it used this mechanism. The pull-down menus appear to be getting decorated by the window manager.
- Bob
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Oct 17, 2008, at 3:22 PM, Jeremy Huddleston wrote:
1) Open nedit 2) Click 'File' 3) close the file menu 4) Move nedit to another space 5) Follow nedit to that space 6) Click on 'File'
This is something ubuntu does not need to worry about since they don't have a native windowing system on top of X11.
True enough, although they've got their own set of bookkeeping problems. I've got one box running Hardy with a Perforce shortcut icon in the upper panel - and no matter what I tell it or what workspace I'm in, the main P4V windows insist on appearing in workspace 1. - Bob
participants (4)
-
Bob Murphy
-
George Peter Staplin
-
Jeremy Huddleston
-
Jeremy Huddleston