|
From: Dave D. <dde...@es...> - 2006-04-11 19:03:21
|
Daniel J Sebald <dan...@ie...> writes:
> Dave Denholm wrote:
>> Daniel J Sebald <dan...@ie...> writes:
>>
>>>>I also disagree with the comments about
>>>>/* NOTE: The removing of plots via the ErrorHandler routine is
>>>>rather
>>>> tricky. The error events can happen at any time during execution of
>>>> the program, very similar to an interrupt.
>>>
>>>I think it is. I spent a lot of time on that code trying to dream
>>> up a safe way of maintaining the list.
>>>>It's nowhere near as bad as that. The errors can only be delivered to
>>>>the program when xlib is actually reading from the socket. That can
>>>>only happen either when it is waiting for a reply to a round-trip
>>>>request, or when you are reading events.
>>>
>>>I'm not sure that implies the problem doesn't exist. The issue is
>>>the following. The ErrorHandler is called in response to the "close
>>>window" or "destroy window" (whatever it is called) that comes from
>>>the system by pressing that little box with an x in it at the top
>>>right corner.
>> Well, that's true at a high level, but you have missed many important
>> details.
>
> Dave, you obviously know much more about X than I. I mean, I looked
> at plenty of the documentation, fooled around with xprop, watched
> for messages, etc., but I think that unless a person really
> understands the concept of what the system core of X is doing, it's
> a case of addressing the problem with a programming solution as
> opposed to setting up the X communication appropriately.
>
I used to do a lot of work at the x protocol level. (google for
ntrigue or wincenter if you are interested). We didn't have xlib, so
we were working directly at the packet level.
A really useful tool is "xmon" : comes in two parts, which you pipe
together :
xmonui | xmond
(slightly weird). Xmonui puts up a gui, and sends commands out on
stdout. xmond is the actual protocol monitor, reading config from
stdin. It tends to get confused by the many X extensions,
unfortunately. I think there is a newer protocol monitor available now.
So with
$ xmonui | xmond -port 1 -server eclipse:0
$ DISPLAY=localhost:1 gnuplot
I then have gnuplot connecting through xmond and forward onto the real
X server on eclipse:0
> It sounds like you are thinking that the window could be configured
> to have that "close button" send the window an event like any other
> so that the core can just simply take care of it, as opposed to that
> notification coming back through ErrorHandler.
>
As far as I can see, we already have that property set.
I do 'test' in gnuplot, to create the X window. Then close it with the
window manager. On xmond I get the following output
....SYNTHETIC EVENT: ClientMessage
............REQUEST: NoOperation
............REQUEST: DestroyWindow
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
............REQUEST: FreePixmap
..............EVENT: UnmapNotify
..............EVENT: DestroyNotify
............REQUEST: NoOperation
so the window manager sent a synthetic ClientMessage event to gnuplot,
reporting that I had attempted to close the window. In turn gnuplot
asked for the window to be destroyed. There were no errors generated
anywhere. (I'm using an old solaris CDE system, BTW).
It was presumably the code in gnuplot
case ClientMessage:
if (event->xclient.message_type == WM_PROTOCOLS &&
event->xclient.format == 32 && event->xclient.data.l[0] == WM_DELETE_WINDOW) {
Remove_Plot_From_Linked_List(event->xclient.window);
}
that deleted the window. And of course this definely happens synchronously.
However, that assumes an ICCCM-compliant window manager.
I tried using xprop to delete the WM_PROTOCOLS property from the
window. But then when I tried closing the window, the server dropped
the connection completely, rather than just closing the window. Window
manager probably did an XKillClient() which is what xkill does.
So I'm still not sure what errors you actually got. So I'd be
reluctant to change working code without being able to reproduce the
scenario you were seeing.
dd
--
Dave Denholm <dde...@es...> http://www.esmertec.com
|