On Wed, Apr 27, 2016 at 05:13:38PM +0100 I heard the voice of
Aaron Sloman, and lo! it spake thus:
>
> > Some random unsorted thoughts:
> >
> > - It might be interesting to know whether it's something about the
> > X server or the libraries. You could dig into that by running it
> > both ways across a `ssh -Y` session; sitting on the SL box ssh'd
> > into your Fedora system to seem if it's an artifact of the server,
> > and sitting on your Fedora ssh'd into the SL to see if it's the
> > libs.
>
> I am not sure what I can do with ssh -Y. I have not noticed problem
> with menus launched by applications, only ctwm menus. So I can run
> xterm, xmessage, etc. remotely, but the menus that don't
> automatically paint their contexts when they first start are
> launched only with the mouse, and run only on the local machine).
Well, technically, they run wherever ctwm does. So, I was suggesting
trying flipping it around. e.g.
SLbox% ssh -Y fedorabox -c "/some/ctwm --replace"
would run ctwm on the Fedora system, but displaying on the SL box. If
the problem still showed up, it would presumably be something
happening in the X server. Versus
fedorabox% ssh -Y SLbox -c "/some/ctwm --replace"
running ctwm on the SL system, but displaying on the Fedora. If the
problem showed up there, it would suggest it was something in the X
libraries on SL, but exonerate the server.
Now, I'm not quite sure what the next step would be after narrowing
that down...
> > - Is there a compositor running on the display?
>
> Not one knowingly run by me (I don't know what a compositor is/does).
Aside from the stupid eyecandy fads that I think have thankfully faded
into the past now ("ooh, look, my desktop is a spinning cube!!!1!!1"),
it has to do with indirecting where windows paint to with the side
effect of windows no longer painting over top of each other. If that
made no sense, rejoice in your ignorance of Scary Crap(tm) deep in
X...
In theory, that might change how expose events happen, which might
muck with how the menus get painted. OTOH, I don't see anything weird
running a compositor here like I've done for some time now, and all
the PaintEntry's get called right. You could drop some debug printf's
in around there to be sure that code's getting hit, but I'm not sure
how you could get the menu pulled up and it not be.
> > - if(e->xexpose.y <= (y_offset + Scr->EntryHeight) &&
> > - (e->xexpose.y + e->xexpose.height) >= y_offset) {
> > PaintEntry(mr, mi, True);
> > - }
>
> I have just tried that and it makes no difference.
Yeah. Probably not shocking; if expose info were messed up,
EVERYthing would be very broken.
> So I conclude that something has changed in the X window system on SL 7
> and it's not a bug in Ctwm ?
My best guess in a vacuum would be a bug or weirdness in the X server
or driver. Fedora is almost certainly a way newer version of all the
X stuff, so since it doesn't show up there you can assume it's not
"something new X is doing breaking us". And since it hasn't shown up
in the past on much older X versions over the years, it's not
"something old X used to do breaking us". So it's probably just
something odd happening in that version.
So I'd guess it's just an oddity of some window of versions, which
will Just Go Away(tm) as that window does. If we can figure a
non-invasive workaround, it wouldn't hurt to have around. 'Course,
we'd have to have ANY workaround to even start talking about
invasiveness...
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
