Re: Connect gnuplot_x11 to exterior application window

[Daniel J S. <dan...@ie...>]

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.

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.

If you want to look at this, go ahead.  Things don't crash so watching communication shouldn't be too bad.  (It's when it continually crashes that it is no fun.)  I could help but it would have to be in the middle of this summer some time.

Dan


> 
> When you close the window, the window manager may send the app a
> request to close the window, or it may just delete the window. That
> will trigger some events to the app to tell you it has closed. (It
> depends on whether you add a property that tells the window manager
> that you want to handle the close yourself.)
> 
> eg if I run xprop on my firefox window, I see
> 
> WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS
> 
> 
> I think that's the one that tells the window manager I want to be told
> about closes.
> 
> Ah - I see gnuplot sets the WM_DELETE_WINDOW hint too. So that means
> that the window shouldn't get closed abruptly by a compliant window
> manager.
> 
> 
> If the app ignores these events, and continues to send requests which
> mention this window (or if there were requests in transit, since the
> protocol is asynchronous), that will trigger errors to be sent to the
> application.
> 
> But the error handler is not invoked until the application reads them
> from the socket (from a getnextevent call or similar). And that should
> only happen under the control of the app.
> 
> if you put a breakpoint on the error handler, and look at the call
> stack when it is invoked, it should always be from a fn that reads the
> network.
> 
> 
> I guess the only time it could be asynchronous is if you are using a
> multi-threaded version of xlib.
> 
> 
> dd