Re: Connect gnuplot_x11 to exterior application window

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

Dave Denholm wrote:
> 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

You are way above my skill level on this.


> 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.

You are probably right on that.  (In fact, you are.  I've just searched back through emails and patches.)  Maybe it wasn't the x-box that caused the error directly.  I see there is another way to Remove_Plot_From_Linked_List(event->xkey.window) inside process events.  I can't recall now the circumstance when the system issues an error.  It seemed common, an I must have been doing it fairly easily in order to test things.

Who knows, maybe when I first looked at it the "close" event option wasn't set up right so it may have been the scenario you suggested, i.e., X loopbacks an error because of the mishandled "close".  Perhaps in the meantime it was fixed and I figured to just let the error handler stay as is.

Ethan and I had some conversation about XKill, but that doesn't ring a bell.

Can you think of any other way to close an Xwindow?  Maybe this chunk of error handling code is no longer relevant.

...

BTW, I see that this

 	prevErrorHandler = XSetErrorHandler(DrawRotatedErrorHandler);
[snip]
	XSetErrorHandler(prevErrorHandler);

construct is probably to avoid queueing the plot for destruction in the case of an error generated by an X font problem.  A better way of doing that would probably simply be to add a selective condition in the above ErrorHandler based upon error_event.

Dan