* Viktor Griph [EMAIL PROTECTED] [060128 16:48]:
Well, I really don't know about that. thinking about it the only x-server
I'm certain it has worked with is a version of Xsun on solaris 2.8.
Looking at the fvwm code I believe it might be that an XSync has been
changed to an XFlush in the startup code before changing the errorhandler
from the one that traps running WMs to the normal fvwm error handler. But
since I'm not sure exactly how this WM-trapping is supposed to work I
leave to someone else to decide if changing it back to XSync is correct.
I really think that is the problem (XSync vs XFlush).
Looking into the libX11 code XFlush only writes all pending things
to the X-server. Unless writing more would block[1] it does not read
anything. Thus it cannot receive any Error notification from the
server thus CatchRedirectError is never called.
When I replace the XFlush with an XSync, the message from the
CatchRedirectError handler is shown and fvwm termiantes correctly
if any other window manager is running.
Changing XSync back to XFlush and adding some diagnostics to
FvwmErrorHandler I see it receiving a BadAccess(10) Error for
a X_ChangeWindowAttributes(2) request.
And XSelectInput simply sends a ChangeWindowAttributes request
for the specified window and EXEVMASK_ROOTW contains
SubstructureRedirectMask (which fits to the name of the
CatchRedirectError handler) and xspec/proto.txt tells:
| Multiple clients can select input on the same window; their
| event-masks are disjoint. When an event is generated, it
| will be reported to all interested clients. However, only
| one client at a time can select for SubstructureRedirect,
| only one client at a time can select for ResizeRedirect, and
| only one client at a time can select for ButtonPress. An
| attempt to violate these restrictions results in an Access
| error.
Hochachtungsvoll,
Bernhard R. Link
[1] This could be the cause of it working earlier or under different
operating systems, the buffers for unix sockets or tcp connections
might have increased.
