Matthew D. Fuller responded to my report of strange menu-painting
behaviour on
Scientific Linux release 6.7 (Carbon)
>
> > menus come up initially without the menu items showing, only the
> > menu name at the top and the menu frame.
> >
> > Below that I see the whole menu only as a black rectangle.
>
> Wacky wacky. I remember you mentioning having seen it once before;
> it's happening repeatably?
Yes I first noticed it mid november, when I installed the (then) new ctwm.
> 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).
Perhaps I am missing somethig.
> - Is there a compositor running on the display?
Not one knowingly run by me (I don't know what a compositor is/does).
> - Does it affect the "synthetic" menus (e.g., f.menu "TwmWindows")?
Yes. They have to be 'manually' painted every time by sliding the pointer
down across buttons.
> The only thing that immediately comes to mind trying to track through
> the code is that somehow when it gets pulled up it doesn't think they
> get exposed right the first time. You could maybe try just painting
> them unconditionally in PaintMenu(), with something like
>
>
> === modified file 'menus.c'
> --- menus.c 2016-02-08 11:10:48 +0000
> +++ menus.c 2016-04-24 09:38:29 +0000
> @@ -686,10 +686,7 @@
> /* be smart about handling the expose, redraw only the entries
> * that we need to
> */
> - if(e->xexpose.y <= (y_offset + Scr->EntryHeight) &&
> - (e->xexpose.y + e->xexpose.height) >= y_offset) {
> PaintEntry(mr, mi, True);
> - }
> }
> XSync(dpy, 0);
> }
I have just tried that and it makes no difference.
I also tried restarting ctwm using /usr/bin/ctwm, i.e. the version that
installed from SL 7 libraries (ctwm-3.8a-27.1.x86_64) and that has the
same problem.
So I conclude that something has changed in the X window system on SL 7
and it's not a bug in Ctwm ?
Anyhow it's possible that the problem is connected with use of gnome 3
utilities even though I don't run gnome.
I've found this review of SL 7, which is very critical:
http://www.dedoimedo.com/computers/scientific-linux-7.html
Conclusion
Well, well, Scientific Linux 7 is a flop. One, this particular
edition with Gnome 3 is completely useless. The desktop simply
sucks. It must be eradicated with acid, so if you have to, choose
wisely, go for KDE. If possible. Which brings us to the second part
of this suckfest.
Scientific Linux 7 has been badly stitched together, and it lacks
the fundamental components to be a useful distro. Or even call
itself by a different name, because there's nothing at all, I
repeat, nothing at all that distinguishes it from any generic
distro, let alone Fedora, CentOS or the rest of the pack. Gnome 3
plus missing functionality plus no apps. Wow. Amazing. This
warrants a beautiful score of 1.7/10.
Most of the bad points go to horrible repo management and the
dreadful desktop environment. We shall test again in the future,
once my ire levels go down, and I can lay my hands on a KDE
edition. The worst part is, Gnome 3 remains a terrible terrible
choice, and as long as it exists, it will continue crippling Linux.
Today's effort, a waste of time. Pointless. Bye bye.
So perhaps we can ignore the problem. I hardly ever re-start the window
manager (or reboot) so having to force a menu to show its labels the first
time I use it after a restart is no great hardship.
Thanks.
Aaron
