This came up as a side effect of my attempts to pin down the problems with
popracer.
This used to be a problem with motif/lesstif + an earlier version of 64bit
poplog but I somehow thought it was no longer a problem in V16.
To demonstrate the bug:
(I think this should work with or without the Birmingham extensions.)
The following should be done with and without linking in motif (see below).
Run pop11
then
: uses rc_graphic;
: rc_start();
That should display an empty graphical window with label
Xgraphic
Use the kill-window button on the title bar (which will depend on which
window manager you are using -- I use ctwm).
If you have installed poplog linked with motif that will kill the window
AND kill pop11. At least, that's what happens to me.
However, if I run pop11 with motif and open an XVed window, using the mouse
to kill that window does not kill pop11 or any other windows opened by
that poplog process.
I.e. The effect is the same as simply quitting that file.
Presumably that means that 64bit motif on linux has a feature in its text
windows that should be in its non-text graphical windows but is missing,
though it isn't missing in 32-bit motif graphical windows!
You can unlink motif with this linux command
$usepop/pop/src/newpop -link -x=-xt -norsv
Then run pop11, as before
: uses rc_graphic;
: rc_start();
Then kill the Xgraphic window with the mouse.
That kills the window, but not the poplog process.
Relink poplog with motif, if needed:
$usepop/pop/src/newpop -link -x=-xm -norsv
Unfortunately motif can be very useful, as pointed out earlier on this
list.
So this mal-feature in 64 bit motif is serious if it means graphical
windows can be killed *safely* only by program commands, not by use of
mouse.
I wonder whether it affects only redhat versions of linux, or also others.
I have searched online for reports of this bug but cannot find anything.
Is there any way 64-bit poplog can *force* a motif object to hand
interrupts to poplog instead of handling them itself, e.g. when the
object is created, or does the motif library code have to be changed.
I have no experience of programming at that level!
(And no time to learn now...)
Aaron
PS I am still working (slowly) on trying to summarise the problems revealed
by or related to the popracer problems. It's a bit messy.
