On Thu, Jun 25, 2015 at 10:37:03PM -0700 I heard the voice of
Greg A. Woods, and lo! it spake thus:
>
> Sub-menus also seem to appear relative to the cursor, if you can
> manage to move the cursor into the right area where they should be
> activated, but only the first time, then they appear where they
> first appeared.
Interesting. So each menu is popping up in the right place when first
brought up, but sticks there afterward.
> I'm afraid I won't have enough time in the near future to debug very
> much further, nor do I have all that much experience with
> lower-level X11 programming, especially not as related to window
> managers.
Oh, don't let that stop you. I don't have any idea what I'm doing
either 8-} (no, really, I don't...)
So, here's my theory:
1) XQuartz winds up hitting the CaptiveRoot stuff, as a result of
being a sorta X-server-inside-some-other-environment thing. I
actually haven't the faintest idea whether this is true, but it sounds
good. The most obvious way to test this would be to drop a printf()
into the "if(Scr->Root != Scr->CaptiveRoot)" conditional near the end
of menus.c:PopUpMenu(), and pull up a couple menus watching for
output. Assuming that's the case:
2) XReparentWindow() quietly does nothing if the window is already
parented under the specified new-parent, which means the positioning
it does with the x/y coordinates winds up not happening, which then
causes the menu to "stick" in its first-mapped location.
2a) and/or, it only does that with XQuartz, due to a bug, or just
incompletely-specified behavior that XQuartz does differently from
X.org or other servers.
If that's the case (especially if !(2a) and it's normal behavior for
that function), then it's a bug in that code since it was first
introduced that it doesn't unconditionally do the XMoveWindow. In
which case, a patch like:
-----------8K---------8K-------------
=== modified file 'menus.c'
--- menus.c 2015-01-30 12:48:56 +0000
+++ menus.c 2015-06-27 01:26:53 +0000
@@ -1742,9 +1742,7 @@
XReparentWindow(dpy, menu->shadow, Scr->Root, x, y);
XReparentWindow(dpy, menu->w, Scr->Root, x, y);
}
- else {
- XMoveWindow(dpy, menu->w, x, y);
- }
+ XMoveWindow(dpy, menu->w, x, y);
if(Scr->Shadow) {
XMoveWindow(dpy, menu->shadow, x + SHADOWWIDTH, y +
SHADOWWIDTH);
XRaiseWindow(dpy, menu->shadow);
-----------8K---------8K-------------
should fix it. Diff against head, so may well not apply mechanically
to released versions. But it's trivial enough to do manually to that
bit at the end of PopUpMenu().
> One other XQuartz-only quirk that may be interesting, but probably
> isn't related: When I open a window that is a member of the
> WarpCursor list (i.e. by clicking on its icon) the mouse cursor
> jumps to the centre of the window as expected, but focus is not set
> on the window unless I wiggle the mouse. This happens with 3.5.2 as
> well as 3.8.2 on XQuartz, and it's been the case on older releases
> of XQuartz too.
Interesting. Does that happen with a "normal" X server? I don't
actually know anything about that feature; I've never used it, and I
don't have icons either. In an offhand test in an Xnest, I actually
wind up with seemingly opposite behavior, in that the window when
popped up is focused, but the cursor doesn't move to it. Maybe my
test config is missing something since I've never been near that sort
of config, or maybe Xnest is weird in a different way.
Somebody else probably knows more about such things that I.
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
