I've been spending some time in ctwm code and X/Xlib lately, so I
figured I'd start fresh and take another run at this.
On Sat, Sep 05, 2015 at 02:23:35PM -0700 I heard the voice of
Greg A. Woods, and lo! it spake thus:
>
> and in doing so I did a bit of a binary search through all releases
> from 3.5.2 to 3.8.2 for the "bug" and found that it introduced
> somewhere between 3.6 and 3.7 and continues on from there unchanged.
As somewhat expected from prior discussions. It might be interesting
to try even narrower; I suspect it'll crop up from r20 (3.6) to r21.
I'm going to work on the assumption that that's the case, since the
rest of the way from r21 to 3.7 changes practically nothing in
PopUpMenu() that would be remotely relevant (with one potential nit,
mentioned later). So at any rate, I can only guess it's something
related to the CaptiveRoot changes.
e.g., test spike (all patches vs. 3.8.2):
----------
=== modified file 'menus.c'
--- menus.c 2014-05-09 13:48:53 +0000
+++ menus.c 2016-06-17 04:44:26 +0000
@@ -1638,6 +1638,7 @@
MenuDepth++;
if (Scr->Root != Scr->CaptiveRoot) {
+fprintf(stderr, "CAPTIVE %s\n", menu->name);
XReparentWindow (dpy, menu->shadow, Scr->Root, x, y);
XReparentWindow (dpy, menu->w, Scr->Root, x, y);
} else
----------
If that doesn't trigger, then I'm totally wrong, and most of the rest
of the mail is bogus.
> I did notice one curious difference when using the stock
> system.ctwmrc file instead of my ~/.ctwmrc: Namely the area where
> the window should appear showed as a black box on the root window.
> I've tried toggling various settings that are different between the
> system.ctwmrc and my own, but I've had no luck so far in reproducing
> this effect.
I would say that's almost certainly the menu shadow window, and you
have NoMenuShadows in your config, which is why you don't see it then.
This is interesting; it means the shadow window _is_ getting
repositioned properly, but the menu window isn't. This suggests that
the part of the changes related to determining whether the menu needed
to be clipped to screen is _not_ the culprit, because the coordinates
for moving the shadow window are figured the same as the main. You
could take a look at that with a spike like
----------
=== modified file 'menus.c'
--- menus.c 2014-05-09 13:48:53 +0000
+++ menus.c 2016-06-17 04:31:12 +0000
@@ -1637,6 +1637,7 @@
MenuOrigins[MenuDepth].y = y;
MenuDepth++;
+fprintf(stderr, "clipped=%d\n", clipped);
if (Scr->Root != Scr->CaptiveRoot) {
XReparentWindow (dpy, menu->shadow, Scr->Root, x, y);
XReparentWindow (dpy, menu->w, Scr->Root, x, y);
----------
You'd probably expect it to be 0, unless you popup up the menu in such
a way that it would be off-screen and had to be moved.
Now, the one possibly 3.7 nit above, is that there's that XWarpPointer
when things are clipped. IF the CaptiveRoot changes were causing
bad behavior related to clipping, AND XWarpPointer had some bad
effect, you could test that in 3.7+ by setting NoWarpToMenuTitle in
the config. I'm going to assume that's not the case.
Now, for what else the shadow window tells us. One question I have:
do you know offhand whether you saw that behavior (the shadow window
popping up in the right place, but the menu not) ONLY on 3.7, or did
it appear on 3.8+ as well? One of the 3.6->3.7 changes was adding the
XReparentWindow() call for the _menu_, but it wasn't until 3.7->3.8
that the _shadow_ window started being reparented too. So, if you can
get that shadow menu moving to the right place with 3.7, but it sticks
like the menu with 3.8, that's an excellent indication that it's the
XReparentWindow() situation that's the source of it.
You previously said you tested the patch to unconditionally
XMoveWindow(), so if you can demonstrate the prior, try just
force-skipping the reparents. e.g.,
----------
=== modified file 'menus.c'
--- menus.c 2014-05-09 13:48:53 +0000
+++ menus.c 2016-06-17 04:40:01 +0000
@@ -1637,7 +1637,7 @@
MenuOrigins[MenuDepth].y = y;
MenuDepth++;
- if (Scr->Root != Scr->CaptiveRoot) {
+ if (0 && Scr->Root != Scr->CaptiveRoot) {
XReparentWindow (dpy, menu->shadow, Scr->Root, x, y);
XReparentWindow (dpy, menu->w, Scr->Root, x, y);
} else
----------
If that does it, then we can start looking at what we should be doing
here. I'm a little curious as to whether they're meaningful or proper
anyway. A similar condition/action is marked up as "XXX dubious test"
down in ReMapOne(), which is interesting. The menu windows are
_already_ being created as children of Scr->Root in MakeMenu(), so
what's the point of reparenting them to their current parent?
Scr->Root isn't reassigned anywhere I can see, so it's not like it
might be changed...
Also, I'm pretty sure CaptiveRoot (through 3.8.2; not the case in
current head) is getting initialized with junk unless you're running
with -name anyway! The more I look at this stuff, the less I feel
like I understand what it's trying to do[0].
(also, it _does_ move to the right place the first time, too! What
the heck?)
> BTW, one of the other obvious differences between 3.6 and 3.7 was
> the introduction of the GNOME support. However I've been compiling
> without (i.e. with #undef USE_GNOME), so I'm hoping that means it
> can't be the culprit.
I'm thinking this may bear closer looking... on my list.
> > > 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.
As mentioned in an earlier mail, this is almost certainly fixable with
that SetFocus() change.
[0] "I don't know what you're talking about, and neither do you."
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
