On Sun, May 22, 2016 at 07:07:41PM -0700 I heard the voice of
Greg A. Woods, and lo! it spake thus:
>
> So the bug is not in the X libraries supplied by Xquartz -- it must be a
> quirk in the Xquartz server that modern ctwm is either unable to cope
> with, or somehow triggers unintentionally.
'k. That's probably not too surprising.
> As a result Ctwm-3.6 remains the last version that works with XQuartz.
It's possible a little bisecting might narrow the scope, but I suspect
not. My guess is that it's related to the various *Root bits, and
that's part of the ~8000 line change in the single rev right after the
3.6 release ("This constitutes all the changes Claude had done since
version 3.6."), which predates our proper VCS history.
[few bits from earlier mails]
> One other interesting quirk, which may provide a critical clue to
> solving this mystery: The special menus "TwmWindows" and
> "TwmAllWindows" always appear in their correct location under the
> mouse cursor!
This affirms a problem with moving; when you pull up those magic
menus, they're actually destroyed and re-created each time, which
means they get a whole new X window. Regular menus only get a new
window when they're created on startup, and just map/unmap it.
The windows are all created at (0,0), and are moved to the "right"
location every time they're popped up, just before being mapped. We
can assume the calculations of the right location are right-ish, since
they're doing it right the first time. One thing you could do is
stick a printf at the top of PopupMenu. e.g., against 3.8.2:
--------
=== modified file 'menus.c'
--- menus.c 2014-05-09 13:48:53 +0000
+++ menus.c 2016-05-23 23:54:31 +0000
@@ -1367,6 +1367,7 @@
int hasmoz = 0;
#endif
if (!menu) return False;
+ fprintf(stderr, "PopUpMenu (%d,%d)\n", x, y);
InstallRootColormap();
--------
and make sure the coordinates eyeball out as reasonable for where
you're clicking. I'd assume they will.
So, the problem is, that somehow the window isn't being moved right
the second time. A few other things that might be tryable:
- Maybe XQuartz doesn't react well in general to moving windows that
aren't mapped? Try moving the XMoveWindow() down to after the
XMapRaised() call a few lines lower (and leaving it unconditionally
called, of course).
- Or maybe it's responding to messages out of order from them? Maybe
put a copy of the XSync() call before doing the XMapRaised().
- Or possibly the whole dealing with roots is wrong there; try just
deleting the block with the XReparentWindow() calls, leaving just
the (unconditional) XMoveWindow().
Possibly in some combinations...
> > > 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.
As it happens, this may actually be solvable via the patch discussed a
few weeks ago dealing with warping and focusing. Against 3.8.2:
---------
=== modified file 'menus.c'
--- menus.c 2014-05-09 13:48:53 +0000
+++ menus.c 2016-05-24 00:06:53 +0000
@@ -4796,6 +4796,7 @@
if (wlist != NULL) GotoWorkSpace (Scr->currentvs, wlist);
}
XWarpPointer (dpy, None, Scr->Root, 0, 0, 0, 0, x + t->frame_x, y +
t->frame_y);
+ SetFocus(t, LastTimestamp());
#ifdef DEBUG
{
Window root_return;
---------
It'd be good to get some testing of that, so we can decide whether to
put it in. Particularly I'm interested in feedback along the lines of
"it doesn't break/give surprising results on anything else", since I'd
be fairly sure "it fixes the particular problem in question" is there.
[ back to the present ]
> BTW, I'm very sad that CMake has been chosen for the build system.
> I can no longer directly build ctwm from the git repository, and so
> can no longer test it easily (I do not, and will not ever, install
> CMake on any of my systems.
That's a little discouraging. Can I ask the source of your antipathy?
My only particular negative with it is that it's a fairly sizable
thing to depend on (building it takes many times longer than ctwm, and
requires a competent C++ compiler). But I can't claim massive
expertise. It's certainly not impossible that we could change our
minds and switch to a different build system (at least before 4.0;
once we get out into the wild with one, we should probably stick for a
while).
I'm not sure what else we'd go with, though. We moved away from imake
for IMO overwhelming reasons; there's no way going back there is going
to be anything but step way backward. Stuff like cons or ant or the
like are gonna have at least the same drawbacks as cmake (assuming
they even cover all the ground we need). I think qmake is all the
same negatives and more, for no additional positives. Doesn't seem
like gyp would be an improvement either (and it's even more fringe
than the other options). autoconf is just too miserable to
countenance, at least without an assurance that it will lead to
massive karmic rebalancing (I mean, the lottery is _right_ _there_
...). I'm open to suggestions.
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
